How does each Version of MED-V use Proxies?

In Version 1, the MED-V Management Console, will use the IE proxy settings of the current user to connect via HTTP to the MED-V Policy Server. If the proxy server is not configured correctly, it will trigger an Event ID 75 error:

“The MED-V Server is unreachable at <URL> “

Please check your connectivity and try again.

In fact, any operation in the MED-V Management Console (v1) will use the user’s proxy settings including the uploading of images to an image distribution server. For the MED-V Client service and application, it is different in that it uses the system’s proxy configuration for all operations including authentication, policy, and image download.

MED-V Version 2

For MED-V Version 2, there are no images or policies to download. So the likelihood of proxy issues with MED-V agents specifically will likely not be an issue although it is important to point out that Host and guest proxy configurations are not automatically kept in sync by MED-V.

Setting Proxies at the System Level

For Windows XP,  you use the proxycfg command to set system account proxies.

For Windows Vista and Windows 7, you would use the netsh command:

netsh winhttp set proxy – http://technet.microsoft.com/en-us/library/cc731131(WS.10).aspx

MED-V 1.0: Unhandled Exception when running the VM Prerequisite Wizard

If you are still using MED-V v1, you may run into this issue when you are running the VM pre-requisites utility on the Windows XP image:

“Unhandled exception has occured in your application. If you click Continue, the application will ignore this error and attempt to continue. if you click Quit, the application will close immediately.”

“Critical error.”

Details will show the following:

************** Exception Text **************
System.Management.ManagementException: Critical error
   at System.Management.ThreadDispatch.Start()
   at System.Management.ManagementScope.Initialize()
   at System.Management.ManagementObject.Initialize(Boolean getObject)
   at System.Management.ManagementClass.GetInstances(EnumerationOptions options)
   at System.Management.ManagementClass.GetInstances()
   at Kidaro.VMPreparation.PreparationUtils.IsMasterDriveSCSI()
   at VMPreparationTool.VMPreparationToolActivator.Activate()
   at VMPreparationTool.VMPreparationToolForm.OnApplyClicked(Object sender, EventArgs e)
   at VMPreparationTool.VMPreparationToolControl.ApplyClickHandler(Object sender, EventArgs e)
   at System.Windows.Forms.Control.OnClick(EventArgs e)
   at DevExpress.XtraEditors.BaseButton.OnClick(EventArgs e)
   at DevExpress.XtraEditors.BaseButton.OnMouseUp(MouseEventArgs e)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at DevExpress.XtraEditors.BaseControl.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

This is caused by a corrupt WMI repository.

You will also see the following in the event logs:

“WMI ADAP was unable to process the performance libraries: 0x80041001” and/or “WMI ADAP failed to connect to namespace \.rootcimv2 with the following error: 0x8004100a”

if this has happened, you will need to run the WMI Diagnosis utility for Windows XP to find out what may be wrong with the repository. You can download it here:

http://www.microsoft.com/downloads/en/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en

If necessary, you may need to rebuild the WMI repository although this should only be done as a last resort.

Click Start, Run and type the following command:

rundll32 wbemupgd, UpgradeRepository

This command is used to detect and repair a corrupted WMI Repository. The results are stored in the setup.log (%windir%system32wbemlogssetup.log) file.

 

MED-V v1 and Image Version Lineage

We speak of version lineage in MED-V, we are speaking of the model for version change control. Some application environments, such as Microsoft’s App-V (formerly called Softgrid) will use GUID identifiers to represent a version and separate it from the GUID identifier for the package itself. It allows App-V servers to manage versioning through its data store.

While there is a methodology for lineage in MED-V v1, it is very simple. It simply bases its version from the filename ending. Original image version will end in “_1” and will carry the underscore format. When you pack locally, or upload a new image to a MED-V server, it will always append

1.) Don’t use image names ending in “_1” when using the console. This will simply wind up having the image file names with confusing suffixes. For example, if you pack an image in the console and call it “XPImage_1,” it will pack it as “XPIMAGE_1_1.CKM” instead. Let the console do it for you.

2.) When you select an image to upload to a server, and you have multiple versions, it will upload only the latest one based solely on filename.

3.) Don’t modify version stamps outside of the console.. While you can do it, users often forget to modify the .INDEX file that corresponds and if there is any mismatch in expected file name between the .CKM file and its corresponding index file, the MED-V console will just ignore the image altogether.

4.) Deleting an image version from the console WILL delete the CKM file and INDEX file for the image. Be very careful when deleting images.

It is also important to understand that MED-V will always download the latest version whether it is from a MED-V image distribution server or even in the event of pre-staged folders. Even though TrimTransfer does not work with pre-staged images, version lineage does.

MED-V: Performance Issues when using Internet Explorer 8 and later in a v1 workspace

Due to performance limitations of Virtual PC 2007 and the additional resources required for Internet Explorer version 8 and later to function properly, it is not recommended to use any version greater than Internet Explorer 7 in the MED-V 1.0 Workspace.

Only Windows Internet Explorer 6 SP2 and Windows Internet Explorer 7 are officially supported for the MED-V 1.0 SP1 workspace installation. This is referenced on the following link:

http://technet.microsoft.com/en-us/library/ff603753.aspx

For Version 2 of MED-V, Windows Internet Explorer 6, Windows Internet Explorer 7, Windows Internet Explorer 8, and Windows Internet Explorer 9 are supported for the MED-V 2.0 workspace installation.

MED-V 1.0: How to Correct Auto-logon Errors with Revertible Workspaces

A requirement of using revertible workspaces in MED-V 1.0 is to have auto-logon enabled. Otherwise, you will get the following error when trying to start the workspace:

“Failed to start the Workspace, because auto-logon must be enabled when a revertible machine is started.”

You will get this if either of the following registry values are set incorrectly or not set in the registry in the guest operating system:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

AutoAdminlogon – Must be set to 1.

DefaultUsername – Must be correct

DefaultPassword – Must be correct

Correcting this using the VM pre-requisite tool is recommended. Then you can pack the image as a new version. Please note that if you are using pre-staged Images, It will not download the new image. You will need to delete the local cache before it pulls down the next version of the image. Saving a V1 and V2 in the same Pre-staged folder will always cause the most recent version to be used.

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 v1.0: Virtual PC Engine Crashes

When you attempt to start a MED-V 1.0 workspace using a test image or a deployed image, the Virtual PC engine may crash and generate a Fault Report using Windows Error Reporting. Subsequently, the MED-V Workspace will fail to start.

The Virtual PC engine crash will show the following fault:

{virtual pc.exe, 6.0.210.0, unknown, 0.0.0.0, ffff08ef}

You will also see the following event in the Application Event Log:

Log Name: Application
Source: MED-V Workspace
Date: 9/22/2009 12:24:30 PM
Event ID: 0
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: CSS-W013
Description:

The following information was included with the event:

Failed intializing the service log: System.TimeoutException: Timed out waiting for the shared memroy client to initialize
at Kidaro.Foundation.Log.PrettyLogProxy.InitializeSharedMemoryClient()
at Kidaro.Foundation.Log.PrettyLogProxy.Start()
at Kidaro.Workspaces.Service.WorkspaceService.ServiceStartThread()

Failed intializing the service log: System.TimeoutException: Timed out waiting for the shared memroy client to initialize
at Kidaro.Foundation.Log.PrettyLogProxy.InitializeSharedMemoryClient()
at Kidaro.Foundation.Log.PrettyLogProxy.Start()
at Kidaro.Workspaces.Service.WorkspaceService.ServiceStartThread()

Cause

This can happen if the MED-V Workspace (the workspace installation) binaries have been installed along with the client on the physical host machine. The MED-V workspace installer should only be run inside the virtual machine being used to create the workspace.

To resolve this issue, please do the following:

1.) Uninstall both the MED-V Workspace and the MED-V Client.

2.) Reinstall the MED-V Client.

MED-V 1.0: Error in VM Prerequisite Wizard: “An unsupported version of Virtual Machine Additions is installed.”

When preparing a Virtual Machine for deployment for use with MED-V v 1.0 SP1, you will need to ensure that in addition to the MED-V workspace installation being installed inside the virtual machine, you will need to have the minimum level of Virtual PC additions for Virtual PC installed as well.

Upon completion of the workspace installation, it will prompt you to run the MED-V VM Pre-requisites Wizard. If the version of VPC additions is not at least at version 13.822.0, you will get prompted with the following message:

“The following errors were detected:

1) An unsupported version of Virtual Machine Additions is installed. Please make sure the latest KB of Microsoft Virtual PC 2007 SP1 is installed on the host machine, and reinstall Virtual Machine Additions through the Action menu of the virtual machine.” Even though the error refers to VM additions, technically these are called VPC additions.

This is caused by not having the minimum version of the VPC additions installed (Version 13.822)

The resolution is as follows:

On the host machine, running the virtual machine, ensure the following are installed:

1.) Virtual PC 2007 SP1

2.) The Bundled QFE with MED-V 1.0 for Virtual PC 2007 SP1 (KB958162.msp)

Then remove Virtual Machine Additions from the guest VM and reinstall VPC Additions through the Action menu of the virtual machine.”