News

Longhorn's Terminal Services: The Server Manager

• By Greg Shields
• 11/01/2007

This is the second installment of a five-part series by contributing editor Greg Shields, which takes a close look at Microsoft's upcoming Windows Server 2008 operating system, commonly referred to as Longhorn. This installment examines the new capabilities of Terminal Services. Click here to see last month's installment.

If you've played with Windows Server 2008 at all, you've likely noticed its new Server Manager. Although a little complicated to get used to, where Server Manager shines is in its centralization of much of the installation and initial configuration of Server 2008 services.

Server Manager is brought up on the initial logon by an administrator or by right-clicking Computer and choosing Manage. If you're used to the old Computer Manager screen you'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.

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.

It 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 contain our old friends Terminal Services Manager and Terminal Services Configuration, as well as the new menu item TS RemoteApp Manager. Unlike previous versions of Windows, where we had to go to multiple places to manage our Terminal Server configuration, nearly all of it's done now within this single interface.

Citrix Published Apps in Terminal Services
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, you 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 then 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 of 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, simply right-click on the TS RemoteApp Manager and choose 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 deploy applications behind the scenes 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 Windows 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 amount of confidence.

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.

Now, obviously there are going to be some environments where this isn't the optimum configuration. If the print server is close 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.