One of the biggest improvements and enhancements of Terminal Services in Windows Server 2008 is in the area of experience features, Terminal Services RemoteApp, which enables users to access standard Windows-based programs from anywhere by running them on a terminal server instead of directly on their client computers. In previous versions of Terminal Services, you could remote only the entire desktop to users’ computers. So when a user wanted to run a program remotely on the terminal server, she typically double-clicked on a saved .rdp file that the administrator previously distributed to her. This connected her to the terminal server, and after logging in (or being automatically logged in using saved credentials), a remote desktop would appear on her computer with a pin at the top pinning the remote desktop to her local (physical) desktop. The user could then run applications remotely on the terminal server from within her remote desktop, or she could minimize the remote desktop if she wanted to run applications on her local computer using her physical desktop.
TS RemoteApp solves this problem (and makes the lives of harried help desk staff easier) by allowing users to run Terminal Services applications directly on their physical desktop. So instead of having to switch between two desktops, the user sees the RemoteApp program (the program that is running remotely on the terminal server instead of on her local computer) sitting right there on her desktop, looking just like any other locally running program.
Using TS RemoteAppFirst, we’ll open Server Manager and select the TS RemoteApp Manager node under Terminal Services. (We could also open TS RemoteApp Manager from Administrative Tools.)
TS RemoteApp Manager lets us specify which programs our Terminal Services users will be able to run remotely on their normal desktops. Right now, we have no programs on the Allow list, so let’s click Add RemoteApp in the Action pane at the right. This launches the RemoteApp Wizard. Clicking Next presents us with a page that allows us to choose which installed programs we want to add to the RemoteApp programs list. We’ll choose Paint.
Clicking Next and then Finish causes Paint to be added to the RemoteApp programs list with default settings.
If we select Paint in the center (Details) pane and click Properties in the Action pane, we see the default settings for running this RemoteApp program:
What these default settings indicate are that users will not be allowed to add their own command-line arguments when running Paint. (This is usually a good idea, though as far as I know, Paint doesn’t have any command-line switches.) The settings also indicate that the RemoteApp program will automatically be made available to users through Terminal Services Web Access (though we actually haven’t added that role service yet to our terminal server). In addition, we could change the name of the RemoteApp program to something other than “Paint” if we want users to know that they’re running the RemoteApp version of the program and not the version installed on their local computer.
Once we’ve added Paint to the RemoteApp programs list, how do we actually enable the user to run the RemoteApp program? To do this, we need to deploy a package containing the RemoteApp information for Paint to our users. We can package our RemoteApp program in two ways: as a Windows Installer file or as a Remote Desktop Protocol file. Let’s use the Windows Installer file approach because as administrators we’re used to deploying Windows Installer packages to client computers using Group Policy.
Start by selecting Paint in our RemoteApp programs list, and then click Create Windows Installer Package in the Action pane. This starts the RemoteApp Wizard again, but after you click Next the wizard displays the following page instead of the previous one:
By default, we see that our Windows Installer package (which will actually be created with the extension .rap.msi, with RAP presumably standing for RemoteApp Package) will be saved at C:Program FilesPackaged Programs. We could elect to save it there, or we could save it on a network share instead, which is likely the better choice. This page of the wizard also lets us customize the terminal server settings (server name, port, and authentication settings), specify that the package is digitally signed to prevent tampering, or specify Terminal Services Gateway settings if we’re using this feature.
For detail of this article please visit : Computer Technology Guide: