Longhorn's Terminal Services: The Server Manager
- By Greg Shields
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.
Server 2008 does a much better job than previous versions of Windows 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 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
- 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.