In-Depth

On The Server Side of Terminal Services

Windows Server 2008 is just a month away and one can't-miss feature is Terminal Services. In this second of three parts, a look at Server Manager.

• By Greg Shields
• 01/11/2008

Server Manager is brought up upon the initial logon by an administrator or by right-clicking Computer and choosing Manage. If you're used to the old Computer Manager screen we've seen since the Windows of old, this one will strike you in how different it really is. To enable Terminal Services, you need to first right-click the top Server Manager node and select Add Role.

Server 2008 does a much better job than previous OSes in terms of componentizing the various Windows services you would normally install onto a server. If you don't enable the service, the bits aren't there. This helps reduce the attack surface of the server and ultimately increases its security profile.

Services are now broken down into Roles, Role Services, and Features, with Roles generally encompassing "what you want the server to do" and Role Services being the processes that support that role. Often, a Role requires one or more Role Services as dependencies before it can be installed. Each Role also has a number of Features that can augment that role. For our example, we see the following:

• Role: Terminal Services
• Role Services: Terminal Services, TS Licensing, TS Session Broker, TS Gateway, and TS Web Access
• Features: TS RemoteApp Manager

In order to enable a minimal installation of Terminal Services, you'll need to enable the Terminal Services Role and Role Service as well as the TS Licensing Role Service. If you want to manage remote applications, you'll need to enable the TS RemoteApp Manager within Features.

It all sounds complicated, but the engine does a relatively good job of telling you which components must be installed for the Role to function as you want.

Once the initial installation is complete, Server Manager will now contain our old friends Terminal Services Manager and Terminal Services Configuration as well as the new menu item TS RemoteApp Manager. Unlike with previous OSes, where we had to go to multiple places to manage our Terminal Server configuration, nearly all of it is done now within this single interface alongside every other Role's configuration.

Citrix Published Apps in Terminal Services
What does Citrix have that Terminal Server admins have always lusted after ... at least until now? The ability to launch published applications in addition to published desktops. For years, one of the biggest draws to the Citrix platform has been its ability to securely publish not only Windows desktops, but seamless Windows applications as well. Now with Server 2008, we get that functionality in the box and for no extra charge.

TS RemoteApp adds the ability to publish a specific application to your users. Combined with the TS Web Access functionality that we'll talk about in the final part of this series, you'll see that this new functionality is Server 2008's killer feature. If anything, this alone may drive your upgrade to Server 2008 faster than any other.

What is TS RemoteApp? Add the Terminal Server role to your Server 2008 system, then the TS RemoteApp Manager Feature. You'll see a new configuration window in Server Manager that gives you the ability to identify the initial executable for common applications and create RemoteApps from them. From this configuration screen, you can publish those applications to a web page using TS Web Access. This means your users need only go to their Web Access web page to get all their applications and they'll appear like they're running locally. The result looks more or less exactly like Citrix's implementation of Seamless Windows.

To create a new RemoteApp, right-click on the TS RemoteApp Manager and choose to Add RemoteApps. All installed applications on your system that can be enumerated via WMI will be displayed for you to select. If your application isn't listed, you can click the Browse button to select an application or customize an existing one with execution switches. Click Finish to complete.

Once the application is created, there are four ways to deploy that application to users. First, as discussed above, you can publish that app through TS Web Access. You can also create and deploy an .RDP file or install it via an .MSI file. Lastly, you can associate a file name extension with a RemoteApp.

Interestingly enough, the GUI for the RDC currently doesn't support connecting to a RemoteApp unless you double-click a pre-generated .RDP file. But, using a combination of the mechanisms above, you can behind-the-scenes deploy applications to your users and centralize your application support back on your Terminal Servers.

Easy Print is Easy
No matter how users traditionally got their applications, printing and printer drivers have long been the bane of Terminal Services administrators. The pain of keeping the right drivers on the right servers -- while hoping and praying that none of them would cause the dreaded blue screen of death -- has kept many an admin awake at night. With previous versions of Terminal Services, it was critical that the device driver on the server matched the one installed on the client. With driver names all over the place, ensuring that one-to-one mapping was correct often ended up in failure.

With Vista and Server 2008, a big portion of this pain goes away. In Server 2008's Terminal Services, the administrator no longer needs to install drivers onto the Terminal Server. This functionality works due to the incorporation of the new XPS print path built into Vista. That print path, combined with the ability to redirect the printer device down to the client means that the user can utilize their local print drivers to print to remote printers. Because the XPS print path is available by default on every Vista client, print jobs can be redirected with a maximum of confidence they'll accurately print using the client's driver.

What does this look like to the client? When a client uses Vista to connect to a Server 2008 Terminal Server and clicks to view their print properties, they'll see the same interface for printer properties they've always seen with their local driver. In fact, the UI used to configure that printer is actually run from the client machine. Clicking print creates an XPS print job on the server that is pushed down to the client where it is printed via their local connection.

Now obviously there are going to be some environments where this isn't the optimum configuration. If the print server is in network proximity to the Terminal Server instead of the client, then that job will need to traverse the network twice. Citrix has a built-in mechanism for configuring local printing on the Citrix server for these sorts of scenarios. But for most configurations, the printer is usually located right next to the client and away from the Terminal Server. So, most of us will appreciate this new feature.

If you're not using Windows Vista, you can download the XPS components from the Microsoft Web site here.

In the last installment, we'll cover application delivery.

(This article is adapted from "Terminal Services in Windows Server 2008," by Greg Shields at the Realtime Windows Server Community. To read the original version of this piece, click here.)