Thoughts from the EPS Windows Server Performance Team
Welcome to the twenty-second day of our series. Only a few more days until Launch Day. We'll be sticking with Terminal Services through the end of our series. Today's topic is Terminal Services RemoteApps, a new feature in Windows Server 2008. RemoteApps are programs accessed remotely through Terminal Services, and appear as though they are running locally on the user's machine. RemoteApps are seamlessly integrated with the client desktop, running in their own (resizable) window with their own taskbar entry. Users can run RemoteApp programs alongside their local programs. If a user is running multiple RemoteApp programs on the same Terminal Server, the RemoteApp programs share the same Terminal Services session.
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:
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:
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 ...
- CC Hameed
Cool stuff - I foresee that once you get 3d virtualization running a combination of this kind of thing + virtualization could spell the end of Windows' backwards compatibility nightmares. Setting the compatibility flag of a program to say, Windows 98 could actually cause it to run in a virtualized Windows 98 instance that is then hoisted into the local session.
Really nice tech, but I've got a question.
How deep does the integration with the user's local machine go?
For example, you have a user running MS Word on their local machine, and Outlook via a remote app. They receive an email with a Word file as attachement.
If they open the attachment, does the file open on their local machine? Or does the load fail?
Ryan - since Outlook is the Remote App, it has no visibility into what file formats are understood on the client machine. It is only aware of what is installed on the Terminal Server. As an example, since I have Office 2007 loaded on my Terminal Server when I open a .doc file attachment in an email, it opens a REMOTE session of Word. Similarly, if I send myself a .pdf file, the Terminal Server does not know what to do with the file because I have not installed Adobe Reader or another PDF Viewer program on the Terminal Server. If I create an empty .pdf and associate that extension with Word (for example) when I try to open the file from a Remote Outlook session - a Remote instance of Word is launched.
Hope this answers your question.
When i open TS Web Access console using administrator login, under the Configuration tab i can see only the terminal server name as localhost . I couldn't see the option to change into active directory mode. Help me to change the data source to active directory mode...............
Ryan, if I wanted to start a local app, lets say I log into our terminal service and start our developed application for our products, I asked our developer to see if the application can startup the program located on my local machine (lets say it's notepad) is it possible to do this through terminal services or within the developed application (start a local app)
I've gone over the install/config of TS Web Access for two days and can't figure out why apps that are "published" on the terminal server are not being shown on the TS Web Access site. The TS Gateway/App event log tells me that "No programs on terminal server (it then names the TS Gateway servername)are configured to display in TS Web Access. Verify the program settings on that server." Why would it say that when thru the configuration wizard I have the proper TS Gateway identified as well as the terminal server (different server) identified? What am I overlooking? Thanks for the help.
We recently installed a TS. We are having a problem accessing webpages which load as a pop up. The problem is isolated to users on a remote session. Pages load no problems when accessing sites directly from the server. We have disabled pop up blocker, enabled scripting within our group policy security setting. It seems to happen with php and asc coded pages.
Can TS RemoteApp be configured to serve up IE and therefore remote users can use IE web applications? Also, can local resources be shared so that when i am using the remote web application i can see my local hard disk and printers to print to?
With .msi istalls for remote apps this all makes sense, but with Outlook it only works for .pst files. How do you get the browser or other email enabled applications on local desktop to recognize Outlook (remote app) as default email program.
TS RemoteApp msi created for Word 2003 installed on server, after create the RDP. Shared out to users via Group Policy. New users log in, get application icon installed as well as file extension .DOC associated to the RDP file (WINWORD).
Double-click on icon works fine and opens remote Word.
Double-click on document saved to desktop - RemoteApp Starting window opens and displays Microsoft Office Word 2003. Then an error window opens: RemoteApp Error: The program Microsoft Office Word 2003 was not found. For assistance, contact your Sytem Administrator.
The only errors showing up on the server logs are informational about TS CAL licensing not being successful and do not prevent access, such as a Remote Desktop session or just running Word.
Any clues - we've just about torn all our hair out over this one. Thanks -
Any Hints on how to configure Outlook as RemoteApp for multiple users ?
When i create an .rdp file within my RemoteApp Manager, it will start with the default profile.
So is it possible to start it with arguments to use different profiles with different users ?
I've got a .Net 2 app running fine via remote desktop on Server 2008. The connection string is currently set to use SQL authentication.
However, when I publish via RemoteApp and launch via TSWeb, I get the following SQLClient error:
System.Security.SecurityException: Request for the permission of type 'System.Data.SqlClient.SqlClientPermission, System.Data, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Data.SqlClient.SqlConnectionFactory.PermissionDemand(DbConnection outerConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
With a .RDP file, I would like individual users to open an Access Front End file on their profile desktop.
Is there a way of writing the TS RemoteApp .RDP file LOCATION that will direct to an application file on an individual's profile desktop, corresponding to their LOG IN username?
We have tried the following location:
This location path goes to the "Default" desktop.
I recognize I could create 40 different TS RemoteApp .RDP files, but I'm looking for a better (read: easier to maintain) way:
I'm looking for a variable to reference each user profile based on the Log On Username for the location path. (The filename will be the same on everyone's desktop.)
Any info on adding two or more terminal servers in the Editor Zone as the app resource?
}} Any info on adding two or more terminal servers in the Editor Zone as the app resource?
Instead of putting a server in a server name, put in a DNS name that has multiple addresses associated with it.