The capabilities of Terminal Services in Windows Server 2008 are far ahead of those in Windows Server 2003.
One of the features likely to get the most attention from end users is the support for RemoteApps. Previously, native Terminal Services could present only a desktop view of the terminal server. If you wanted to display individual applications, you'd need to create an RDP file that included a path to the application and its working directory. Anyone launching this RDP file would get only a single application, but it would still have the icon for the remote session -- instead of for the application being run -- and it was within a remote session frame. This wasn't much use to either users or Terminal Server administrators.
Windows Server 2008 now adds a new capability to terminal servers: RemoteApps.
RemoteApps launch from special RDP files, but they display the application as though it were running locally with no extra frames and with the right icon for the TaskBar. RemoteApps running from the same server will share a session. To set this up, the terminal server administrator installs the applications as usual, then uses a wizard-based tool to determine how the RemoteApp is delivered: as a RDP file on the user's desktop, wrapped in an MSI package for delivery using Group Policy, in a browser using Terminal Server Web Access, or TSWA.
Terminal Services Web Access -- Once you deploy an RDP file for a RemoteApp, how do you ensure that people are using the most current version? If you use Group Policy to deploy them, that helps, but you can't update client computers not joined to the domain. One way to ensure that your users are always using the latest RDP file to open their RemoteApps is to display those RemoteApps in a browser and create the RDP files on the fly. That's what TSWA does.
TSWA connects a terminal server and an IIS server to present applications in a browser, accessible via the intranet or on the Internet. All RemoteApps that the administrator has selected to be visible via TSWA -- this is part of creating a RemoteApp -- display their icons in the browser window. The user must be authenticated to the Web site to see the application icons.
When a user clicks an icon and is authenticated on the terminal server, this creates an RDP file with the settings appropriate to that user and terminal server, and the application launches. Only those RemoteApps the administrator has explicitly selected will appear in the browser. This delivery method also avoids the problem of "stale" RDP files with outdated paths.
TSWA cannot filter applications based on user identity, but shows all users the same application set. However, some Terminal Server ISV partners have announced that they're developing solutions to filter applications to show a personalized view of the portal to each user.
Licensing improvements -- Licensing isn't really a feature, but it's a necessity that everyone running a terminal server farm must deal with -- whether for one terminal server or hundreds. Because you must use it, improvements really matter. There are a lot of improvements to licensing — enough that I could have spent the entire article on them. In brief, though, here are some of the top fixes.
TS licensing diagnostic tool -- Not sure what's wrong with the connection between the terminal sever and the license server? A new set of tools can help you diagnose and fix the problem.
Reporting and tracking of per-user licensing -- One of the headaches associated with licensing is that per-user licenses in Windows Server 2003 aren't tracked, so it's hard to keep honest about licensing. Windows Server 2008's license manager adds a reporting tool for per-user licensing.
Manual revocation of per-device licenses -- In Windows Server 2000 SP2, unused per-device licenses would return to the license pool after a randomly chosen interval of 52 to 89 days. However, admins had no way to manually return unused licenses to the pool. In Windows Server 2008, you'll be able to revoke up to 20% of your per-device licenses at a time, returning them to the pool for allocation.
"Not Yet Defined" licensing mode -- Windows Server 2003 was the first version to support both per-user and per-device TSCALs. Therefore, some administrators didn't think to change the terminal server's licensing mode to per-user. So the terminal server would detect a license server, thereby ending the grace period, but it would not have access to any per-device licenses on the license server. People would connect to the terminal server with temporary TSCALs. When those temporary CALs expired, however, those devices would be locked out of the terminal server. Although there were warning messages alerting the TS admin of the problem, these often didn't do the trick.
To work around this problem, there is no default licensing mode for Windows Server 2008 Terminal Services. Instead, when you install the terminal server, you'll have the option to choose whether you want it to be in per-device mode, per-user mode or to not configure it yet -- perhaps if Terminal Tervices is new to your organization and management isn't yet sure what type to purchase. You'll have 180 days to configure the new licensing mode, set up a license server and install licenses.
Christa Anderson is a program manager on the Terminal Services team at Microsoft. Author of Windows Terminal Services, The Definitive Guide to MetaFrame XP, and co-author of Mastering Windows 2003 Server, she is also the author of the forthcoming Terminal Services Resource Kit from Microsoft Press.