What Windows technology exists to create a desktop from which programs are launched, but which actually launches them on another server?  Typically a shortcut causes the application to load its image in the local machine and execute there.  What I need to do is set up a desktop on which all the shortcuts launch applications throughout the enterprise, none of which are probably running locally to the shortcuts.

Ideas?

I believe to do something like this through the .NET Framework Remoting services would likely be fairly easy.

Actually, I take that back.  You want to:

1.) Have a shortcut to a program that is most likely not installed on the local machine
2.) Load the image on the remote machine where the program is installed
3.) Display the user interface on the local machine where the shortcut exists?

You might be able to achieve this with Remoting....  But I don't really think so.

If I were to do it, I'd probably write some kind of algorithm for determining what parts of a window has changed, send image data to the client and translate input data from the client into simulated input at the server.  I would think the hard part would be to figure out how an efficient method of transmitting window image data to the client, and in the case of multiple user windows on the server, figuring out which one is being used.

.NET Remoting would be the wrong thing to use.  Try looking for an X-server for Windows.  Cygwin/X is the only free X-server I know of.

Does the launched process need to be interactive on the local machine?

[quote author=Arta[vL] link=topic=10157.msg94782#msg94782 date=1105388072]
Does the launched process need to be interactive on the local machine?
[/quote]

No.  Typical would be an at-home operator (maybe due to bad weather) using VPN to access the LAN, then using Terminal Services Desktop to reach an operator "console" (desktop with all the processes icons numbered and arranged).  The operator may launch the programs from this console, but this stub actually just causes a process elsewhere to start.  The process may take seconds or hours, but the operator is not held up.

I was considering using MMC snap-ins, which allow you to connect to other servers.  Then I could build a MMC profile linking to the programs wherever they might be, letting the operator have appropriate access to everything.

Well if you don't need to run something interactively, then .NET Remoting could work.  Just make a remote server and run Process.Start on the remote server.  Not too many lines of code, about an hour of work tops.

In that case, if you don't need too many bells & whistles, I suggest using psexec.

[quote author=Arta[vL] link=topic=10157.msg94861#msg94861 date=1105431134]
In that case, if you don't need too many bells & whistles, I suggest using psexec.
[/quote]

Good start.  I'll share it with the developers here to get their opinions.  But it looks like we could build our applications to support psexec.