For years, Terminal Services administrators have been drooling over the idea of having a feature like Citrix Presentation Server's Published Applications. Citrix administrators got to have all the fun -– publishing individual applications and content instead of full desktops with their users sometimes never even knowing that their applications weren't running locally.
Well, the wait is over. The
What are Terminal Services RemoteApps? Simply put, a RemoteApp allows the Terminal Services administrator to create a published desktop -- without the desktop. Only the application is visible to the user. This means that users no longer need to deal with the confusion of double desktops with their double Start menus.
TS RemoteApps come as part of the Terminal Services server roles. You'll need to install the role as well as the Terminal Server Role Service to a candidate server. Once complete, Server Manager should include a new node for Terminal Services, and below it you'll see an entry for TS RemoteApp Manager.
Within the TS RemoteApp Manager the administrator can manipulate a number of settings associated with application deployment. Configuring global RDP settings, digital signatures and application distribution options are all done from within the TS RemoteApp Manager.
How does this new functionality change the way we look at Terminal Server-hosted applications? With previous operating systems, the only options we had were to install applications to a terminal server and then provide user access to that TS's desktop. Any applications not otherwise controlled were immediately available to any user that could log into the desktop.
With RemoteApps, this changes a bit. You no longer need to provide any access whatsoever to the desktop if you don't want to. This means that your desktops in some ways don't require the same levels of draconian lockdown that TS administrators traditionally prided themselves. Users with access to an application such as Microsoft Word won't have the same capabilities to play around with their session like they did with full desktops. Yes, there are ways to break through some applications to get to command prompts and other forbidden interfaces, but this change helps keep the honest people honest.
Also exciting about RemoteApps is the reduction in the potential for resource use on the server. With full desktops, users could misbehave in their Terminal Services session. They could open 10 instances of Adobe Acrobat while surfing eight different websites, all of which consumed more than their fair share of physical resources. With RemoteApps, it's much harder to do that, so fewer resources are likely used. This makes for happier users overall.
When you create a new TS RemoteApp, you may first want to determine the primary executable for the software you want to make available. For example, if we want to make Microsoft Word available to our users, Word's primary executable is winword.exe.
Once we know this information, we can create the RemoteApp by right-clicking the TS RemoteApp Manager node in Server Manager and selecting Add RemoteApps. A list of the available applications currently installed on the server will appear. If your application is present, you can select it from the list.
Knowing the primary executable is necessary because at times the list doesn't include all possible applications. If it doesn't, click the Browse button and enter the path to your application's primary executable there. Then, select the Properties button to find additional information about the application, such as its name and alias or whether the RemoteApp will be available through TS Web Access. Complete the wizard to create the RemoteApp.
Once created, the RemoteApp needs to be deployed to users. Here's where the real beauty of this new feature truly shines. Unlike the single desktop-centric interface of previous operating systems, there are four ways to deploy TS RemoteApps to clients in Windows Server 2008:
RDP file on a file share: The TS RemoteApp Manager can automatically create an RDP file. That RDP file can be stored on a file share for users to click on and start their applications.
MSI file installed to a workstation: Also possible through the same interface is the automatic creation of an MSI file. This MSI file doesn't install the application to workstations. Rather, it installs the link to the server. Once installed, users will see the application in their Start Menu. When they click the link, they're directed to your terminal server.
File name extension association: The previous mechanism was great, but most users don't usually start Word by clicking the Start Menu item for Word. Instead they launch Word by double-clicking a Word document to launch the application with their documents. Creating a file name extension association provides this capability to your users.
TS Web Access: RemoteApps can be added to a Web page where users can go to launch their apps.
Wait until you see this feature set in action. The new capabilities make Terminal Services a robust, enterprise-worthy tool for deploying applications to your users.
ABOUT THE AUTHOR
Greg Shields, MCSE, is an independent author and consultant based in Denver with many years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization. His recent bookWindows Server 2008: What's New/What's Changed is available at www.sapienpress.com.
This was first published in June 2008