Click here to Skip to main content
15,887,416 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
Hi all,

Windows Terminal Server has the 'traditional' remote desktop mechanism, but starting from Windows Server 2008 there has been also RemoteApp.

If you have used that, what kind of experiences you have? Did it perform well, any issues with connectivity to other locally run applications (via clipboard etc), what about shared memory or other communications between two separate RemoteApps and so on?

I know the question is actually very large, but all pieces of information / opinions are very welcome :)
Posted

1 solution

We have used this starting about 18 months/two years ago and it works great. In practice, when a user launches the remote app it creates a remote desktop session on the term server, logs the user in, and launches the application. The UI is passed from the terminal server to the user's workstation and appears on the user's desktop.

If the user launches an additional remote app on the same server, it appears as well. The term server didn't create a second session, it just launches the app in the first.

We found the normal stuff worked just like remote desktop... so sounds, clipboard, etc all worked. Printers, generally, would merge from the local machine into the remote session. That caused some confusion so we shut that off and used the login scripts to map the same set of printers. Printing would go through the spooler on the term server if the printing was done from the remote app just as if the user had been in remote desktop.

Closing all of the remote apps would not immediately close the remote session. It was the same as if the user just closed the remote desktop screen. The session stays alive until the system recycles it.

We found that in practice, the load on the term servers seemed to be about the same whether a client connected with remote desktop or remote app. Which I thought made sense when it seemed clear that the same underlying session was taking place on the server regardless of how it was being presented back to the user.

Users could tell the remote apps because of a bit longer startup time (not too bad though... certainly no worse than remote desktop) and the fact that the application window had the look and feel of the desktop theme on the term server. (If they had customized their colors the remote apps would follow the scheme on the server making it clear it wasn't running on their machine.)

Be warned, apps that don't play well on the term server to begin with won't play well in remote app. Remote app is really nothing more than throwing back the application's window(s) rather than the whole desktop. The full desktop session is still there and can be accessed by switching to remote desktop (with the remote app running and available) if the user wants to. There is no extra magic sauce there really.

Incidentally, we observed the same points with application publishing from XP Mode/Windows Virtual Machine on Win 7 desktops. Apps published from the virtual machine and launched on the desktop worked basically the same as remote apps. VMWare does something similar with Unity mode. All of these systems are doing the same thing, just returning the application windows instead of the whole desktop.
 
Share this answer
 
Comments
Wendelius 13-Dec-12 14:38pm    
Thank you! This was a really enlightening answer. Actually I haven't thought about the whole situation much yet so the information that two applications running from same terminal server actually share a session behind the scenes is really promising.

Eventually I need to integrate the application to local resources on the client, but based on your answer it seems that this is doable.

Thanks again,

mika

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900