OK - so what programs can be run as RemoteApps? Basically, any program that can run in a Terminal Services session or in a Remote Desktop session should be able to run as a Remote Application. The Remote Application feature is available to all platforms that support the new RDC 6.x client. There are different ways that a user can access a RemoteApp program - depending on how the program was deployed:
- via a link to the program on a web site by using the improved Terminal Services Web Access features in Windows Server 2008
- via a custom .RDP file that is created and deployed to users. The RemoteApp is started when the user double-clicks the file
- via a Windows Installer (.MSI) package that can be deployed to users and will create a program icon on the Desktop or Start Menu
- via a Windows Installer (.MSI) package that can be deployed to users and will associate a specific file extension with a RemoteApp program
The .RDP file and .MSI package contain the settings needed to connect to a Windows Server 2008 Terminal Server and run the RemoteApp program. After opening a RemoteApp program on their local system, the user can interact with the program as if it were installed and running locally. Icons that are associated with the Remote Application that would normally appear in the notification area of a user's Terminal Server session will appear in the notification area on the local system when a remote application session is active. For example - if you were using Microsoft Outlook as a Remote Application, new mail notifications and other pop-ups and application notifications would appear in the notification area as you would expect them to if the application were installed and running locally.
Now let's quickly go over the architecture of RemoteApp programs. There are two executables in particular to be aware of:
- RDPINIT.EXE
- RDPSHELL.EXE
An instance of RDPINIT.EXE runs on the Terminal Server for each users RemoteApp session. RDPINIT.EXE is loaded by USERINIT.EXE as a RemoteApp specific implementation of USERINIT.EXE. RDPINIT.EXE acts as a watchdog to launch RDPSHELL.EXE and monitor process startup and shutdown. RDPSHELL.EXE is the shell that is used instead of EXPLORER.EXE to provide RemoteApp functionality. RDPINIT.EXE monitors the process lifecycle of RDPSHELL.EXE and restarts it in the event that it abnormally terminates. RDPSHELL.EXE loads a set of Windows event hooks onto each user desktop in the session. These event hooks allow RDPSHELL.EXE to monitor the state of all windows on the desktop. The interaction between these components is shown below:
When a Remote Application is terminated, the process on the Terminal Server that is associated with that application is terminated. However, the Terminal Server session itself remains in a disconnected state until it is reset by an administrator or the Group Policy setting that defines the time limit for disconnected sessions to remain in that state.
So much for the theory - now let's configure a RemoteApp on a Windows Server 2008 Terminal Server. On the Terminal Server I have been using for demos, the Terminal Server Role Service is already installed. However, I did not install the Terminal Server Web Access Role Service. That is going to be the first step so that I can access the Terminal Server through my web browser. When I select the TS Web Access Role Service for installation, the following dialog is displayed. As we can see, there are some dependencies (fairly obvious ones) that TS Web Access has - such as IIS and some .NET features.
In this instance, my Terminal Server hosting the RemoteApp and TS Web Access server are the same machine. However, if these roles exist on separate machines, you will need to add the Computer Account of the TS Web Access Server to the TS Web Access Computers security group on the Terminal Server. Once TS Web Access has been installed, I need to configure it to populate the list of RemoteApp programs that appear in the Web Part from a specific Terminal Server or Terminal Server farm. By default, TS Web Access populates this list from a single Terminal Server and points to the local host. The Web Part is populated by all RemoteApp programs that are enabled for TS Web Access on that terminal server's RemoteApp Programs list. In order to administer TS Web Access, I have to use either the local Administrator account or an account that is a member of the TS Web Access Administrators group on the TS Web Access Server.
You will know whether or not you have rights to administer TS Web Access from the main TS Web Access interface. The first image shows user without TS Web Access Administrator privileges, the second is for a user with TS Web Access Administrator privileges. Note the additional Configuration option.
In the Editor Zone area under the Configuration option, I can set the Terminal Server that will provide the list of RemoteApp programs. Since the Terminal Server and TS Web Access server are the same machine, I can leave the option set to localhost .
In order to make a RemoteApp program available to users, I have to add the program to the RemoteApps list. By default, programs added to this list are also configured to be available through TS Web Access. To add a program to the RemoteApps list, I need to use the TS RemoteApp Manager MMC snap-in. Click the Add RemoteApp Programs item in the Actions pane to launch the RemoteApp wizard. On this machine, I actually have two versions of the Windows Debugging Tools (x86 and x64) installed that I want to make available as RemoteApps - as you can see below, there are two versions installed, but ... which one is which?
This is easy enough to resolve - by selecting one of the executables, and then clicking on Properties, I can figure out which one is which just by looking at the install path:
Now that I know which one is which, I can modify the properties to my needs - the display name, or any command-line arguments I need to specify. For my purposes, I just need to fix the display names:
Select the programs by checking the boxes, and click Next . This brings up a Review Settings dialog so you can verify your selections. Click Finish and now in your RemoteApp Manager window, you have two RemoteApp programs that are enabled for TS Web Access:
When I refresh my TS Web Access page, I can see both applications. I also added a Remote Desktop connection back to the Terminal Server itself.
If I launch the x86 Windows Debugger, once I pass my credentials, I am presented with the RemoteApp Startup box
Once the application is launched, I get the taskbar item for the Debugger - as you can see, there is no indication that this is a RemoteApp from an initial inspection - the integration with my local desktop is seamless.
However, if I hover over the taskbar item, then I can see that this is a RemoteApp
If I wanted to deploy these RemoteApps via a .RDP or .MSI file, I would select the application in the TS Remote App Manager snap-in and then select either of the options under the Other Distribution Options section on the main snap-in page:
And with that, it is time to bring this post to a close. We've mentioned TS Web Access in this post - in tomorrow's post, we will look at the TS Web Access Architecture. Until next time ...
| Share this post : |
|
|
|
|
|