MED-V 1.0 SP1: CD/DVD/Optical Drive Access Appears Problematic

MED-V V1 SP1 running on either Vista or Windows 7:

If a workspace configured by policy to use the host machine’s optical drive starts without Optical Media injected (in either full desktop mode or seamless mode) the following may happen:

When you insert an optical disk post workspace start, the drive in Explorer will show the proper-media injected however when you try to open the workspace while the workspace is running you will get the error:

“Please Insert a disk into <TYPE> Drive (n:).”

Likewise – the same also happens inside the guest operating system as well.

After restarting the workspace, it is, however available to the host and guest.

This is caused by a combination of the process for VirtualPC not being elevated and the drive is captured only at startup for a standard user process.

There are four ways to work around this:

1.) Simply restart the workspace with the disk in the drive.

2.) Start the MED-V Client elevated (run as admin.)

3.) Disable UAC.

4.) Disable the feature in the workspace policy.

If required for guest OS’es use a drive mapping to the shared optical drive.

Virtual PC 2007 SP1 x64 edition installs into the Program Files(x86) directory

When you install Virtual PC 2007 Service Pack 1 on a computer running Windows Vista or Windows 7 x64 edition, the installation appears in a subdirectory of the “Program Files (x86)” directory. Additionally, the VirtualPC.exe process displays in Task Manager as a 32-bit process.

When Virtual PC 2007 is installed on a 64-bit host Operating System it installs to the 32-bit program files directory. This is because unlike Virtual Server, Virtual PC 2007 is a 32-bit application which uses 64-bit drivers when necessary.

In order to run on a 64-bit host Operating System the drivers must be 64-bit themselves, but the only benefits of making the application 64-bit is the ability to access larger amounts of memory and to run more virtual machines at the same time. While both of these things are very important for Virtual Server, they are not as important for Virtual PC.

This works as designed for hosting 32-bit operating systems as guests on x64 hosts.

MED-V 1.0: Workspace Fails to Start with “Adjusting VM Window” Message

Has this ever happened to you?

You receive the following error when attempting to launch a MED-V workspace.

“Failed to start Workspace ‘Workspace_name’

“Starting the session failed in the following phase: Adjusting VM Window.”

This issue can arise if there is a dialog box triggered from Virtual PC. This issue has been seen happening with first-time deployments that also involve first time launching of the Virtual PC engine.

A common specific cause of this is found on Windows Vista and Windows 7 where their is an underlying firewall alert that does not appear within regular user contexts but will display immediately with an administrative account. You will see the following message:

“Windows Firewall has blocked some features of this program”

“Windows Firewall has blocked some features of Virtual PC 2007 SP1 on all public, private, and domain networks.”

If you find that when starting the workspace from an Administrative account you get this error, you can enable firewall exemptions for the Virtual PC 2007 SP1 program through the Windows Security Alert dialog box. Once this has been done, a re-attempt of the workspace launch should not get this error again.

A more proactive approach would be to push these firewall exemption rules down via group policy or pre-launch the Virtual PC Console on the workstation as an Administrator and that will also trigger this alert.

MED-V 1.0 SP1: Windows Firewall blocks VPC 2007 network activity by default for standard users

By default, Windows firewall blocks Virtual PC 2007 SP1 network activity, and when Virtual PC 2007 SP1 initiates on the client computer, there is a firewall message that blocks its startup sequence and all network access. If you are logged on to the machine as an administrator, you have the option to enable these exceptions.

For newly deployed MED-V Clients where the user logging for the first time are not local Administrators, they will not have this option and they will not have virtual machine network access

The cause of this is an issue by design with Virtual PC 2007 in Windows Vista and Windows 7.

Right now, the current solution is to update the firewall exception by using Group Policy before MED-V is used by the end user. a Domain level group policy is probably the most recommended route to take here.

MED-V 1.0: Guidelines for GINA-Chaining Inside MED-V Workspaces

NOTE: Officially, GINA chaining is officially not supported inside the MED-V workspace. The following information can be used for a case where the use of a custom GINA in addition to the MED-V GINA is mandatory and a workaround is needed.

Prior to Windows Vista, Microsoft used the graphical identification and authentication (GINA) module system to provide secure authentication and interactive logon services. The Microsoft GINA is a replaceable dynamically linked library that is loaded early in the boot process in the context of the Winlogon.exe process. Winlogon can be configured to use a different GINA, providing for non-standard authentication methods such as smart card readers or identification based on biometrics, or to provide an alternate visual interface to the default GINA.

GINA Chaining was a widely used practice with Windows 2000 and Windows XP by 3rd party vendors but not one for which we normally provide any guidelines (or support).  Vendors have implemented chaining in different ways, generally by storing the old GINA in another location (usually OriginalGinaDll,) then later calling it from within their custom GINA and passing through the credentials.  The MED-V GINA acts in this fashion as well.

Generally, the MED-V GINA does forward calls to the GINA listed under OriginalGinaDll (beneath the Winlogon registry key). If this value does not exist, then the chaining is performed to MSGINA. However, there are some calls that we do not forward (e.g. calls related to locking, which MED-V handles). It is hard to diagnose the issue without knowing exactly what the other GINA is requiring (e.g. what is it expecting that does not happen? Should the additional 3rd party GINA display a window prior to the login? Post login? While the workstation is locked? Etc.).   For instance, the Checkpoint VPN GINA hooks the login window to detect when the user presses the OK button. Since MED-V uses auto-login, the OK button is never pressed and so Checkpoint does not detect the login.  Additionally, it should be noted that the use of these types of configuration have not been tested, and every GINA replacement has quirks of its own.

1. Create the  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\OriginalGinadll “<Path>\Ginaname.dll” and test the logon process again.

2. If this doesn’t work, contact the 3rd party vendor to find out how their GINA hooks the login window.