MED-V: More Detail on Full-Screen vs. Seamless Mode
I recently had a customer inquire further as to how the mechanics differ between all of the application modes in MED-V. I would have thought this far into the life cycle of MED-V that I had gone into enough detail on the subject. Turns out, while the article I wrote on TechNet a couple of years back (http://blogs.technet.com/b/medv/archive/2011/06/02/med-v-v2-why-would-an-application-fail-in-seamless-mode-when-it-succeeded-in-full-desktop-mode.aspx) gave a good high-level explanation, more clarification is needed.
So in addition to the information I laid out back in 2011, I’ve done some more diving into RAIL (Remote Applications Installed Locally) the inline VPC implementation of TSRemoteApp (now called RemoteApp) where the RemoteApp Server component was ported to Windows XP for the guest integration.
First of there are actually two “full-screen” modes in MED-V 2. One involves starting full screen mode from either the MED-V toolkit or using the command MEDVHOST /fullscreen to launch the workspace in full screen mode with the MEDV Guest services and agents still engaged. If you were to access the Virtual PC out of band using the VPC Window or by double-clicking on the .VMCX file, you would get the warning message about another user being logged on (see http://blogs.technet.com/b/medv/archive/2011/08/24/med-v-v2-strange-message-lt-virtual-pc-name-gt-was-closed-with-a-user-logged-on.aspx)
I outlined the basics of the differences in this high-level chart:
RDPINIT/RDPShell and Active Setup
In addition to items that depend on Explorer.exe such as Login Scripts, Active Setup also does not run. You may can get around this by leveraging group policies and the RUNONCE.EXE command. You can specify the startup applications as a part of a user’s logon settings in Group Policy. Because Group Policy controls these settings, any startup application that you specify runs as expected when the user logs on. To specify the startup applications as a part of a user’s logon settings, follow these steps:
1. In the server Group Policy Management Console (GPMC), select the GPO (that applies to the GUEST OS [XP]) and edit.
2. Click Computer Configuration, and then click Administrative Templates.
3. Click System, double-click Logon and then double-click Run these programs at user logon.
4. In the Run these programs at user logon Properties dialog box, click Enable.
5.Click Show, and then click Add.
6.Type the name of the startup application – runonce.exe /AlternateShellStartup (must include the argument)
7.Click OK two times.
One Final Note on Termination
When a Remote Application is terminated, the process on the XP Guest that is associated with the application is terminated. However, the RDP session remains in a disconnected state until is reset by an administrator. This behavior can be modified by using the group policy “Set time limit for logoff of remote app sessions.”
Any other processes that should be terminated when the Remote Application is terminated can be specified in the following Registry key.
This is a registry key that the RDP RAIL Shell uses to filter out “system” processes (in addition to rdpshell.exe and rdpinit.exe). Processes configured via this key are ignored by the RAIL Shell. In addition, they will be terminated upon exiting of the RDP session.
A process can be added by adding a REG_DWORD value with a name of the process and a value of 0x0. The following is a list of processes that are terminated by default when a Remote Application ends.
Clipsrv.exe Conime.exe Ctfmon.xe Dwm.exe Imepadsv.exe
Lmsvcs.exe Msgsvc.exe Nddeagnt.exe Netdde.exe Netstrs.exe
Os2srv.exe Proquota.xe Rdpclip.exe Screg.exe Taskeng.exe