MED-V V2: Why Would an Application Fail in Seamless Mode When it Succeeded in Full Desktop Mode?

Article
06/02/2011

A common issue that comes into the MED-V support team involves the following scenario: An application that was used in MED-V v1 was brought over to the new Virtual PC engine. The application functions perfectly when ran from the Virtual PC when accessing in the full desktop mode feature of Virtual PC. However, when the application is published seamlessly, it fails to either publish, launch, and/or behave as expected.

Differences between seamless mode and full desktop mode

To understand why this may happen, it is important to understand the differences between the two methods of launching the applications. When you launch an application in Full Desktop Mode, it is running exclusively under Virtual PC. Once the Integration Features have been enabled, you are in essence connecting to the virtual PC as an RDP client where instead of a Terminal Server or another host being the destination, the destination is, instead, the guest operating system. When you launch an application in seamless mode, you are launching it by way of RAIL.

RAIL (Remote Applications Installed Locally)

RAIL stands for Remote Applications Installed Locally. This is the same technology that is used in Remote Desktop Services in Windows Server 2008 and beyond to enable TSRemoteApps (Remote Applications). TSRemoteApps are applications that are installed and executed on a Terminal Server or Remote Desktop Session Host Server, but are integrated with the Remote Desktop client machine in a way that makes them appear to be running locally on the client. Although a Remote Desktop session has been established to a server, the user does not see the desktop of that session; they just interact with the application as if it was installed locally. This is the model for seamless application integration leveraged by MED-V v2.

The following table outlines the processes that are used to facilitate each application mode:

Mode	Application on Host	Shell on Guest
Full Desktop	VMWindow.EXE	Explorer.exe
Seamless	VMSAL.EXE	RDPSHELL.EXE

As explained in the table above, the management process on the host is VMSAL.exe instead of VMWindow.exe when ran in seamless mode and the shell used is RDPShell instead of Explorer.

The Process

When a user starts a MED-V seamless application from the host, an instance of VMSAL.exe is launched to initiate, monitors, and controls the application. An in-process ActiveX control, MSTSCAX.dll, actually acts as the RDP client. VMSAL.exe will create a named pipe to connect to the appropriate RDP server service on the VM guest and specifies port TCP port 3389 as the target server port on the guest.

In order to present a seamless application to the user as if it is running locally instead of providing a full desktop, a shell unique to virtualized applications is launched when the RDP session is created. The process is as follows:

1.) Launching the application initiates a remote desktop session on the server.

2.) The normal logon process, WinLogon.exe, calls the user initialization process, UserInit.exe, to perform tasks such as applying group policies and running logon scripts.

3.) If the logon was initiated by the launch of a seamless application, UserInit.exe loads RDPInit.exe, an initialization process specific to seamless applications.

4.) Instead of loading the standard desktop shell, Explorer.exe, RDPInit.exe loads RDPShell.exe. RDPShell.exe is a shell that was designed specifically for the purpose of presenting the remote application to the user as if it is running locally.

Tip: Use Group Policy Preferences Instead of Logon Scripts

If you are planning on deploying applications that will relay on settings or mapped drives that normally are created through logon scripts, you will need to use a an alternative method of establishing these preferences.

If you are unfamiliar with Group Policy Preferences, take a look at the following white paper:

https://www.microsoft.com/downloads/en/details.aspx?FamilyID=42e30e3f-6f01-4610-9d6e-f6e0fb7a0790

You will also want to ensure that the Group Policy Preference Client-Side Extensions for Windows XP are set up in the guest:

https://www.microsoft.com/downloads/en/details.aspx?FamilyId=E60B5C8F-D7DC-4B27-A261-247CE3F6C4F8&displaylang=en

Also make sure the Group Policy Preferences Client-Side Extension Hotfix Rollup is installed as well: https://support.microsoft.com/kb/974266

Tip: Avoid Conflicts with Existing Terminal Services/RDP Group Policy Settings

If your host machine and/or workspace are in the same Active Directory OU as your terminal servers and clients, you may possibly run into some conflicts if you are using Group Policies to control the settings on those Terminal Servers.

Group Policy Settings Associated with Terminal Services in Windows Server 2003 can be found here:

https://technet.microsoft.com/en-us/library/cc776289(WS.10).aspx#w2k3tr_ts_tools_eujw

Group Policy Settings Associated with Terminal Services in Windows Server 2008 can be found here:

https://technet.microsoft.com/en-us/library/cc770884(WS.10).aspx

Tip: Install the International Update

The Microsoft Enterprise Desktop Virtualization (MED-V) 2.0 – Localization Software Update (https://www.microsoft.com/downloads/en/details.aspx?FamilyID=3a185a14-5ab0-4260-ae6b-418b3ca77bf7) also contains some minor fixes addressed since the initial release of MED-V 2.0.

Tip: Use Process Monitor from an auto-published command prompt for further diagnosis.

When all else fails, Process Monitor can be your friend in diagnosing what is going wrong. Process Monitor can be downloaded from here: https://technet.microsoft.com/en-us/sysinternals/bb896645

One of the first things I do when investigating this type of issue is to insert process monitor into the guest (usually by the shared Documents folder) and launch it from an auto-published command prompt. I then reproduce the attempt to launch the application. Usually a single capture running from the guest will reveal the root issue, however, at times, I have had to take additional comparison traces under the following conditions when a single trace did not yield enough data:

· Trace from the guest of application running in Full Desktop Mode

· Trace from host when trying to run seamless application (to capture VMSAL activity)

Don’t forget to check for the obvious

Basic problems that can arise with auto-publishing and their solutions are outlined in the following article: https://blogs.technet.com/b/medv/archive/2011/11/30/med-v-troubleshooting-application-publishing-in-v2.aspx

It almost goes without saying to check the common mistakes outlined in this article first.

Hope this helps,

Steve Thomas | Senior Support Escalation Engineer

Partager via

MED-V V2: Why Would an Application Fail in Seamless Mode When it Succeeded in Full Desktop Mode?

Ressources supplémentaires