The MED-V Blog

MED-V URL redirection is not working and no *.mdvurl file is being created

J.C. Hornbeck — Mon, 13 Feb 2012 19:48:19 GMT

Here’s a new Microsoft Enterprise Desktop Virtualization (MED-V) Knowledge Base article we published today. This one talks about an issue where a restricted user can attempt certain actions that they don't have permission to yet get a (false) message indicating it was successful.

=====

Symptoms

Microsoft Enterprise Desktop Virtualization (MED-V 2.0) URL redirection does not work and no temporary URL file *.mdvurl is created in %localappdata%\temp (e.g. C:\Users\username\AppData\Local\Temp\tmpE38B.tmp.mdvurl).

Cause

This can occur if the URLs in the MED-V URL list are not valid. An example would be a URL that has a trailing * such as:

http://www.msn.com*

Resolution

To resolve this , navigate to the following registry location and remove the trailing * from any URL addresses listed.
HKLM\software\microsoft\medv\v2\UserExperience\RedirectUrls

More Information

The only issue relevant to this problem is addressed in the first blog post listed below, in the first section, regarding the creation of the temporary URL file containing the URL to pass the guest via RDPcopy (*.mdvurl). All the other issues that cause URL redirect failures outlined in these two articles do not exist in this scenario.

Understanding and Troubleshooting MED-V v2 URL Redirection
http://blogs.technet.com/b/medv/archive/2011/08/10/understanding-and-troubleshooting-med-v-v2-url-redirection.aspx

GPO Settings That Could Potentially Cause Issues with MED-V Features
http://social.technet.microsoft.com/wiki/contents/articles/5127.aspx#Internet_Explorer_Policies

=====

For the most current version of this article please see the following:

2671040 : MED-V URL redirection is not working and no *.mdvurl file is being created

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Microsoft Enterprise Product Roadmap Webcast

J.C. Hornbeck — Thu, 19 Jan 2012 17:16:47 GMT

Please join us for a high level discussion into Microsoft software investments designed to cover most of the major product lines. This will be a 35,000 foot view into the following areas:

Windows Family
Virtualization
Office System
Unified Communications
IT Management
Security

This particular webcast is scheduled for Friday, January 20 at 1:00pm Pacific Time although others are scheduled as well. See this link for more information.

J.C. Hornbeck | System Center & Security Knowledge Engineer

Get the latest System Center news on Facebook and Twitter:

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

MED-V Host Agent Setup fails with “MED-V Host Agent requires Windows Virtual PC 7 version 6.1.7600 or higher”

J.C. Hornbeck — Thu, 19 Jan 2012 17:08:35 GMT

Hi everyone, Mark Stanfill here and today I wanted to take a minute to quickly tell you about an issue I recently ran into where the MED-V Host Agent Setup (MED-V 2.0 Host Agent) fails with the following error message:

MED-V Host Agent Setup

MED-V Host Agent requires Windows Virtual PC 7 version 6.1.7600 or higher.

This is an error you can get if Windows Virtual PC is not present on the host OS and it does not have the 958559 update applied. Now fortunately for us this is an easy fix. To resolve this issue and allow the MED-V 2.0 Host Agent to install, use the following steps:

Download and install the 958559 update (http://support.microsoft.com/default.aspx?scid=kb;EN-US;958559).
Reboot the host OS when prompted.
Re-run MED-V_HostAgent_Setup.exe

That’s it!

Mark Stanfill | Senior Support Escalation Engineer

Get the latest System Center news on Facebook and Twitter:

MED-V: Troubleshooting Application Publishing in V2.

Steve TH - MSFT — Wed, 30 Nov 2011 23:33:14 GMT

MED-V builds on top of the RAIL (Remote Applications Installed locally) model that is also in Virtual PC for Windows 7 and Windows XP Mode for Windows 7.

Unlike XP Mode or Virtual PC (which put the applications in a specific Start menu Folder) MED-V V2 will scan the All Users Start Menu in the guest operating system to determine what should be published and where it will place it (in its equivalent location) in the Host’s Start Menu. The basic process of application publishing will basically be:

1. Application installed before MED-V Image is deployed must create a shortcut in the All User’s Start Menu folder of the guest. Applications installed on a MED-V image after it is deployed must also create a shortcut in the start menu to also be discovered.

2. MED-V will continually monitor any changes to shortcuts in the start menu of the deployed MED-V image.

3. MED-V will publish changes in the shortcuts to the start menu of the host workstation as they are discovered.

The MED-V Client is responsible for monitoring the folder in the host where Virtual PC publishes its shortcuts for additions or deletions. When an application shortcut is added to this monitored folder, the shortcut watcher will copy the published shortcut to the same location in the host Start menu as it occupies in the VM’s Start menu. Likewise, when an application shortcut is deleted from the monitored folder, the shortcut watcher will delete the published shortcut from its corresponding location in the host Start menu.

When application publishing in Virtual PC has been enabled, the Remote Desktop Services WMI Provider in conjunction with the Win32_TSPublishedApplication class is used to add the application information to the Virtual PC’s registry. The published application is given a unique published application identifier (PAI) that is used to reference it from both the host and the VM. The PAI value is stored as command line parameter in the shortcut file in the host.

For example: "C:\Program Files\Microsoft Enterprise Desktop Virtualization\MedvHost.exe" /LaunchApp %SystemRoot%\system32\vmsal.exe "Windows XP Compatibility (Shared)" "||a93686d" "Pre-Auto Published Command Line"

It is also stored as a registry key in the Virtual PC Guest OS:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current version\Virtual machine\AppAllowList\<PAI>

These same PAI’s are also stored in the user’s registry on the host in:

HKEY_CURRENT_USER\Software\Microsoft\MEDV\Application Publishing\<Workspace name>\<PAI>

Without MED-V, Virtual PC publishes remote applications to host folder location “%APPDATA%\Microsoft\Windows\Start Menu\Programs\Windows Virtual PC\<VM Name> Applications”.

If for some reason, either an application that was installed prior to deployment does not appear where expected or it was added post-deployment and it does not get published. In the event that application shortcuts that are copied into the VM Start menu are not being published to the host Start menu, the following items should be checked:

Ensure that the Integration Components are installed on the VPC
Ensure that Auto Publish is enabled on the VPC
Verify that the Virtual PC RemoteApp patch update is installed in the VM.
Run the MED-V Host toolkit using the following command:

MEDVHOST /toolkit

Click “View Published Applications

You can also leverage the following VBScript to query the applications

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\Microsoft\Medv")
Set colItems = objWMIService.ExecQuery("SELECT * FROM PublishedApplication",,48)
For Each objItem in colItems
Wscript.Echo "-----------------------------------"
Wscript.Echo "PublishedApplication instance"
Wscript.Echo "-----------------------------------"
Wscript.Echo "Arguments: " & objItem.Arguments
Wscript.Echo "Name: " & objItem.Name
Wscript.Echo "PAI: " & objItem.PAI
Wscript.Echo "Path: " & objItem.Path
Next
Verify that the AppPublishingEnabled value is set to 1 in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Medv\v2\UserExperience
Make sure the shortcut to the application is using an .EXE file as its destination.
Check for shortcut extraction objects in %LOCALAPPDATA%\Microsoft\Windows Virtual PC\Virtual Applications\<VPCNAME>
If no shortcuts appear, you can look for the PAI identifier. Look in:

HKEY_CURRENT_USER\Software\Microsoft\MEDV\Application Publishing

Subkey will be WWorkspace Name. AppPubIds will be below it. i.e. - HKEY_CURRENT_USER\Software\Microsoft\MEDV\Application Publishing\Windows XP Compatibility (Shared)\2b719975
If you see the PAI, test the application using the MEDVHost.exe /launchapp command. This option allows you to launch a MED-V v2 published application from the command line. Use the following syntax:

"C:\Program Files\Microsoft Enterprise Desktop Virtualization\MedvHost.exe" /LaunchApp %SystemRoot%\system32\vmsal.exe "WorkspaceName" "||AppID" "AppName"

For example, the following command line launches a pre-published application called " "Pre-Auto Published Command Line" from the workspace called "Windows XP Compatibility (Shared):"

C:\Program Files\Microsoft Enterprise Desktop Virtualization\MedvHost.exe" /LaunchApp %SystemRoot%\system32\vmsal.exe "Windows XP Compatibility (Shared)" "||a93686d" "Pre-Auto Published Command Line"
Ensure an entry exists for the application under the AppAllowList and TSAppAllowList registry keys.
Ensure the executable for the application is not listed under the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtual Machine\VPCVAppExcludeList.
Copy an application shortcut into the VPC All Users folder and check to see if the application was published to the host by looking in the VPC7 Host Publication folder. If it was not then check the following items:

Copy an application shortcut into the VM Current User folder and check to see if the application was published by checking the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TsAppAllowList\Applications. If no key was created for that application, then an error is occurring with the MED-V Host Agent.
Copy a VPC application shortcut to VPC Host Publication folder. This shortcut target must be formatted properly with the VMSAL command line parameters. Check to see if the shortcut was copied to the “%APPDATA%\Microsoft\Windows NT\CurrentVersion\Start Menu\Programs” folder.
If the application shows up with a PAI in the Guest OS under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\Virtual machine\AppAllowList\<PAI>. Check for a value called IgnoreForPublishing and remove it if it is set to 1.
Does the application start from a mapped drive? If so, change it to use a UNC path instead in the shortcut?
The Windows Event Log should also be checked to validate that no errors have occurred during the publication process.

GPO Settings That Could Potentially Cause Issues with MED-V Features

J.C. Hornbeck — Wed, 30 Nov 2011 18:34:39 GMT

Here’s one more article I found over on the TechNet Wiki that was written by Microsoft’s very own Steve Thomas. This one talks about some GPO settings that could potentially cause issues with MED-V features:

=====

MED-V V2 leverages underlying VPC and RDP\RemoteApp technologies to facilitate support for URL, Print, and document redirection. In addition, a special BHO is used by the host browser to redirect URL’s configured for legacy guest browsing to the guest browser. There are certain group policies that could impact MED-V’s functionality and/or performance if they are configured. If you are encountering issues with MED-V, verify your applied GPO’s to determine the following…

=====

To continue reading Steve’s article see http://social.technet.microsoft.com/wiki/contents/articles/5127.aspx.

J.C. Hornbeck | System Center Knowledge Engineer

MEDVHost.EXE Command Line Options

J.C. Hornbeck — Tue, 29 Nov 2011 19:07:57 GMT

Here’s another great article I found over on the TechNet Wiki that was written by Microsoft’s very own Steve Thomas. This one goes through and explains the various MEDVHost.EXE command line options such as exit, FullScreen, RebootVM, toolkit and others:

http://social.technet.microsoft.com/wiki/contents/articles/5093.aspx.

J.C. Hornbeck | System Center Knowledge Engineer

Ramifications of Switching between NAT (Shared Networking) Mode and Bridged Mode with MED-V V2.

Steve TH - MSFT — Tue, 29 Nov 2011 00:09:00 GMT

In a previous blog article, I wrote about the differences between NAT and Bridged Mode in MED-V v2. The differences between the two were discussed in detail. You can find the article here:

http://blogs.technet.com/b/medv/archive/2011/11/03/nat-mode-vs-bridged-mode-in-med-v-v2.aspx

Often I get the question, “What if I want to change the networking mode? Can I do this after the MED-V workspace has been deployed? Or will I have to re-deploy the workspace?”

Administrators can change the deployed mode after the workspace has been deployed. This can be helpful if, for some reason, the current mode will not suffice. If you choose to change the networking mode post-deployment, It is important to consider the following issues that will most likely occur.

1.) Regardless of networking mode, there will always be 4 network interfaces in the guest operating system. This is by design. This is to allow for multiple adapters on the host to be allowed into the workspace with MED-V if the VPC is running in Bridged Mode (i.e. VPN, virtual, tunneling adapters from the host.)

2.) Switching between NAT Mode and bridged mode while the workspace is running will cause a delay in network availability in the workspace guest operating system.

3.) Switching to Bridged mode from NAT only recommended when using DHCP in bridged mode. While static IP addresses are supported in bridged mode, they are not in NAT mode.

In any scenario, there will likely be a temporary automatic IP address (169.254.x.x) when switching while the workspace is running. You may need to trigger an IPCONFIG /RELEASE and IPCONFIG /RENEW command to speed up the process.

You can also automate the network configuration switching using a variety of means:

Using a .REG file to switch to NAT Mode

Windows Registry Editor Version 5.00

; Registry file created using Microsoft MEDV Configuration commands

[HKEY_LOCAL_MACHINE\Software\Microsoft\Medv\v2\VM]

"NetworkingMode"="NAT"

Using a .REG file to switch to Bridged Mode

Windows Registry Editor Version 5.00

; Registry file created using Microsoft MEDV Configuration commands

[HKEY_LOCAL_MACHINE\Software\Microsoft\Medv\v2\VM]

"NetworkingMode"="BRIDGED"

WMIC command to set the workspace to Bridged Mode

wmic /namespace:\\root\Microsoft\Medv PATH Setting set VmNetworkingMode=BRIDGED

WMIC command to set the workspace to NAT Mode

wmic /namespace:\\root\Microsoft\Medv PATH Setting set VmNetworkingMode=NAT

VBScript code to set the MED-V workspace to NAT Mode

Set objMedv = GetObject("winmgmts:root\Microsoft\Medv:Setting=@")

objMedv.VmNetworkingMode="NAT"

objMedv.Put_()

VBScript code to set the MED-V workspace to Bridged Mode

Set objMedv = GetObject("winmgmts:root\Microsoft\Medv:Setting=@")

objMedv.VmNetworkingMode="BRIDGED"

objMedv.Put_()

How an Enterprise Administrator Can Determine MED-V 2.0 FTS Completion and Provide Remediation Quickly

J.C. Hornbeck — Mon, 28 Nov 2011 19:43:01 GMT

Here’s a great article I found over on the TechNet Wiki that was written by Microsoft’s own Steve Thomas. This one shows how an enterprise administrator can determine MED-V 2.0 FTS completion and provide remediation quickly:

=====

When deploying large amounts of MED-V 2.0 workspaces in the enterprise, Microsoft offers several flexible options for determining on a large scale if MED-V First-time-setup occurred properly. The goal of this is to be able to incorporate this into an existing software/operations management infrastructure.

Event Viewer/Event Collections

In Windows 7, under the Applications and Services Event Logs, is the MEDV Event log for the Host Agent. If you are tracking event logs through an operations management application or other event collector you can leverage the following Event ID’s for tracking FTS progress…

=====

To continue reading Steve’s article see http://social.technet.microsoft.com/wiki/contents/articles/4597.aspx.

J.C. Hornbeck | System Center Knowledge Engineer

NAT Mode vs. Bridged Mode in MED-V V2

Steve TH - MSFT — Thu, 03 Nov 2011 18:24:56 GMT

For MED-V V1, we made the following recommendations for MED-V workspaces running in NAT Mode (using VPC Shared Networking.) The article is found here: http://blogs.technet.com/b/medv/archive/2010/10/20/additional-recommendations-when-using-med-v-workspaces-configured-for-nat-mode.aspx For MED-V V2, those recommendations are still in place. But if you decide to use bridged mode instead of NAT mode, there are some important items to consider.

If you use bridged mode, the interface in the MED-V workspace appears external to the machine which means you will need to either apply a static IP address to it or make sure DHCP is available. Otherwise, the IP address will be an APIPA address (169.254.x.x.) This is not a MED-V issue, but rather a VPC issue.
If you have moved from NAT mode to bridged mode please make sure make sure of the following:

1.) Virtual Network Services are enabled on the host NIC.
2.) IP Address is assigned to guest either through DHCP or via a static IP address. For MED-V, it is recommended to use DHCP.

If you are using NAT mode, bear in mind the items mentioned in the following article

http://blogs.technet.com/b/medv/archive/2010/10/20/additional-recommendations-when-using-med-v-workspaces-configured-for-nat-mode.aspx

Especially the section on the following items:

- Disable Slow Link Detection
- Force Kerberos over TCP

These items all hold true for v2 in addition to the extensive information outlined in the following article:

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

Also understand the following:

1.) NAT Mode will require FQDN’s (fully qualified domain names) when configuring domain join information in the SYSPREP.INF file used in the MED-V FTS (First-time-setup.)
2.) ICMP does not work in NAT Mode for regular users.
3.) UDP does not work well in NAT Mode for regular users.

NAT Mode basically turns MED-V host computer into a NAT router where the VPC gets a class C 192.168.x.x address in the range 192.168.131.1 to 192.168.1.253 and the VPC NAT routing software routes out through the host. This address is not configurable and you will not be able to assign a static IP address. The VPC is connected to a private network that includes a built in DHCP server (192.168.131.254) and a built in NAT service as the default gateway (192.168.131.254). This requires no extra configuration on the host computer and the VPC’s can connect to any IP Address. MED-V Administrators need to ensure that the network adapter within the VPC guest operating system is configured to obtain a dynamically assigned IP address. This is a default when using SYSPREP. By default, the DNS server settings will be copied automatically from the host machine. It is important to note that NAT will not provide any inbound traffic to the VPC. So the host and none of the other VPC’s would be able to communicate to any other VPC.

Using NAT mode with SCCM (Configuration Manager)

It is important to remind administrators who want to use SCCM (Configuration Manager) to manage/patch/update MED-V workspaces using NAT mode of the required SCMM 2007 hotfix referenced in the following article:

http://support.microsoft.com/kb/2504904

This allows for ONLY MED-V workspaces running behind NAT to be managed as intranet CCM clients. Otherwise, the virtual machines cannot perform automatic site assignment or cannot find the closest distribution point to download content based on its current network location.

How MED-V V2 Manages Memory of Virtual PCs

Steve TH - MSFT — Sat, 15 Oct 2011 20:46:09 GMT

The MED-V Host Agent controls how memory is allocated to the underlying VPC. This memory can be controlled either dynamically where the memory is allocated a certain amount based on host memory configuration or set using a static value.

Dynamic Memory

Dynamic memory is the default configuration. The following registry key is used to toggle this configuration on or off.

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Medv\v2\VM or HKEY_CURRENT_USER\Software\Microsoft\Medv\v2\VM
Value: HostMemToGuestMemCalcEnabled
Data Type: DWORD
Default: 1

When enabled, the memory allocated for the guest is not calculated from the memory present on the host based on upon a matrix. If not enabled, the static value is used.

The dynamic memory matrix is based on ranges determined in the HostMemToGuestMem and GuestMemFromHostMem registry values (found in the same registry paths as above.)

HostMemToGuestMem: This is a REG_MULTI_SZ value that determines the host range for the dynamic memory matrix. Possible values can be from 1024 to 16384.
GuestMemFromHostMem: This is a REG_MULTI_SZ value that determines the guest range for the dynamic memory matrix. Possible values can be from 128 to 3712.

For example, when the following registry settings are configured . . .

- HostMemToGuestMem: 1024, 2048, 4096, 8192, 16384

- GuestMemFromHostMem: 256, 512, 1024, 2048, 3072

. . . the memory settings will follow these guidelines:

*If Host Memory is . . .*	*Then Guest memory will be . . .*
1024	256
2048	512
4096	1024
8192	2048
16384	3072

Static Memory

You can bypass dynamic memory and set the memory using a static value by creating a DWORD value called Memory in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Medv\v2\VM.

- Value: Memory

- Data Type: DWORD

- Default: 512

This setting is ignored if the HostMemToGuestMemEnabled setting is enabled. If this setting is NOT there and the HostMemToGuestMemEnabled is disabled then the default will be 512 MB. The range for this value can go from 128 MB to 3712.

Issues

It will require the MED-V International patch to use any memory values over 2048 for either static or dynamic memory. If you are finding that the settings are not exceeding 2048, please make sure this patch has been applied. You can download the MED-V International patch here:

http://www.microsoft.com/download/en/details.aspx?id=6590

Be careful when Testing Memory Settings

Never use the Virtual PC console when testing memory settings. When MED-V is deployed, even though the VPC console shows the workspace as a registered VPC, you will still not be seeing an accurate view of what MED-V is using for memory. MED-V overrides internally what is set in the VPC console.

For example, here the VPC for XP Compatibility shows 2048 GB in the Virtual PC window. MED-V will register the Virtual PC with its default settings based on the VMC configuration – however – the memory configuration will be overridden by whatever memory settings have been configured under the MED-V Host Agent.

To test what MED-V has as the memory set for the VPC used by MED-V, it is recommended to either display MED-V in MED-V’s full-screen diagnostic mode (by running the command MEDVHOST /FullScreen) or test in its deployed mode (seamless mode) by using a pre-published command prompt to serve as a “jumping-off” point for testing.

For example, in this scenario, I will launch a command prompt from XP using the same VPC.

Once this command prompt is launched, I will then launch “Control” and then from the Windows XP Control Panel, I will click “System.”

In this dialog box, I see that actually only 512 MB of RAM has been allocated to the VPC.

In order to change this, I would need to either:

- Adjust the matrix used to govern Dynamic Memory (Host-to-Guest Memory Calculation.)

- Disable MED-V Dynamic Memory (Host to Guest Memory Calculation) and set the memory using a static value.

This will require both the Guest OS to restart as well as the MED-V Host Agent. This is often missed as the default action for closure on the MED-V workspaces is often set to hibernation. One way to ensure both the workspace and the host get properly reset would be to restart the MED-V host agent and then force a restart of the workspace. The command “Shutdown –r” will trigger this within the workspace.

Once the MED-V Host Agent and Workspace have full restarted, you can test the memory allotment using the method above or just simply run the following command from the pre-published Windows XP command prompt:

WMIC PATH Win32_OperatingSystem GET TotalVirtualMemorySize.

When it comes to performance baseline testing with memory configurations, always test memory configuration changes using seamless mode. It's the only thing MED-V overrides.

Please note, these values (listed above) could be either in the registry's machine path (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Medv\v2\) or the user's path (HKEY_CURRENT_USER\SOFTWARE\Microsoft\Medv\v2\.) Either way way is acceptable however, it is important to review how MED-V uses the following search path when looking for the resultant settings values:

MED-V first looks in the machine policy.
If the value is not found, MED-V looks in the user policy.
If the value is not found, MED-V looks in the HKEY_LOCAL_MACHINE\System hive.
If the value is not found, MED-V looks in the HKEY_CURRENT USER registry hive.
If the value is still not found, MED-V uses the default.

MAC Address Management with MED-V V2 Workspaces

Steve TH - MSFT — Thu, 13 Oct 2011 23:42:25 GMT

In general, it is recommended to leverage the Virtual PC NAT mode (shared networking) when implementing MED-V workspaces. This will take care of any IP address and MAC address management issues. There may be reasons, however, for you to leverage bridged mode in place of NAT mode.

Bear in mind, when you choose bridged mode, the host network adapter enters into promiscuous mode and the MAC and IP address of the VPC will appear to the external network. To all network entities outside the host, the VPC appears as a separate entity different from the host. In this mode, the network service redirects all incoming and outgoing network traffic. Traffic is filtered based on the MAC addresses and routed to the correct VPC.

MED-V workspaces configured to use host network adapter networking setting can communicate with other virtual machines that are configured to use the same host network adapter, with the host computer, and with all computers on the external network.

Since MED-V is delivering a stand-alone single image that will be sysprepped possibly to multiple users, Virtual PC has to avoid deploying the virtual machine with the same MAC address to many users. It has to be assured that each virtual machine will get a new MAC address the first time it starts.

The VMCX will have the value changed:

<ethernet_card_address type="bytes">0003FFXXXXXX</ethernet_card_address>

to this

<ethernet_card_address type="bytes"></ethernet_card_address>

Virtual PC will then create a new address for the VPC during MED-V's FTS.

Post-Deployment MAC Address Management

In some cases, you may desire the MED-V workspaces maintain a fixed MAC address due to DHCP IP address management or other netowrk-related policies.

Ensuring the VMCX file maintains a static address will have to happen post deployment (POST FTS.) You will need to modify the VMCX file to have it at the desired static MAC address you want. The locations will vary depending on whether the workspace is multi-user or not.

Shared Workspace - Even though the VHD is stored here - C:\ProgramData\Microsoft\Medv\AllUsers\Virtual Machines, there will still be a per-user registered VMCX file in the user's profile (C:\Users\<USERNAME>\Virtual Machines\<VPCNAME>.VMCX. This is only the registration as the XML you would modify with the static image would be in %LOCALAPPDATA%\Microsoft\MEDV\v2\Virtual Machines\<VPCNAME>.vmc
Per-User Workspaces - C:\Users\<Username>\AppData\Local\Microsoft\MEDV\v2

Please note the MED-V Workspace’s MAC address will also change under these conditions:

When a MAC address conflict is detected with another running virtual machine.
When the virtual machine is registered - In the case of MED-V could be after any reset, additional user logs on and triggers FTS. The purpose of this is so that if a user takes an existing virtual machine and copies it - they can then bring it up without having to worry about duplicate MAC addresses.
When the workspace is reset in MED-V. This re-triggers FTS

Using WMI Filters to Disable Legal Notices on MED-V Workspaces

Steve TH - MSFT — Thu, 06 Oct 2011 17:29:00 GMT

An issue that we have been seeing with MED-V in all versions is the issue of the use of the LegalNoticeCaption and LegalNoticeText values creating disconnects with the seamless user experience while running MED-V workspaces. While the legal notice is sufficient for logging on to the host, since the MED-V workspace is also running an underlying operating system, a logon is required for accessing the published applications running under Windows XP.

In our Best Practices guide (http://technet.microsoft.com/en-us/library/gg548491.aspx) we recommend to disable this through group policy. Customers, however, often ask, “What if I want to use the same OU for both the Windows 7 host and the Windows XP guest workspace? How can I prevent a GPO containing the LegalNotice Caption and LegalNoticeText values from affecting the XP workspaces yet allow them to still affect the Windows 7 hosts?”

WMI Filter

The best way to do this is through a WMI filter. When you apply a WMI filter to a GPO, the GPO will only apply if the WMI filter (which is a WQL query) evaluates to TRUE. WMI filters are created and applied to a GPO using the Group Policy Management tool.

It is important to note that this will be best effective if the following conditions are true:

1.) The policy regarding legal notices are applied at the OU level

2.) The policies within the GPO for legal notice

Creating and Linking a WMI Filter to a GPO

To create and apply a WMI GPO filter, you must be a member of the Domain Administrators group, or otherwise be delegated permissions to modify the GPOs. You will then use the GPMC to create a WMI filter that will query for a specified version of Windows.

On a computer that has the Group Policy Management feature installed, click Start, click Administrative Tools, and then click Group Policy Management.
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
In the navigation pane, expand your forest and domains until you get to your desired domain level. Then click WMI Filters.
Click Action, and then click New.
In the Name text box, type the name of the WMI filter. In this example, I have created one called “MED-V OS Filter.”
Click Add.
Leave the Namespace value set to root\CIMv2.
In the Query text box, type:

select * from Win32_OperatingSystem where Version like "6.%"

This will return true for computers Windows Vista or Windows 7 but not Windows XP.
Click Save to save your completed filter.
After you have created a filter with the correct query, link the filter to the GPO. Filters can be reused with many GPOs simultaneously; you do not have to create a new one for each GPO if an existing one meets your needs.
In the navigation pane, find and then click the GPO that you want to modify. In this example, I have created a GPO WMI Filter called MED-V OS Filter and I am applying to the Default Domain Policy.
Under WMI Filtering, select the correct WMI filter from the list.
Click Yes to accept the filter.

You will need to fully restart both the MED-V host and Workspace for this to take effect if the workspace has already been deployed.

MED-V V2: Error: "Open virtual applications found." when launching MED-V applications

Steve TH - MSFT — Tue, 20 Sep 2011 19:46:29 GMT

When launching a MED-V application, a user may get the following message:

"Open virtual applications found. The virtual machine cannot be opened while virtual applications are open. Save any unsaved application data, and then click Close All to continue."

This is caused when the user state/session has changed between the last time MED-V was launched and this current time. This can happen often if MED-V is attempting to start and there are applications running under a different user session (even if it is the same user but a session different from when the last time the user ran MED-V.) When you switch between MED-V's v2 seamless mode function and VPC's full desktop within the same Windows 7 host logon session, this can occur. This is the most common cause of this issue. You are switching technologies when you do this and there was not a designed method of transitioning back and forth unlike MED-V v1 where there was both a full desktop and a seamless mode controlled exclusively by MED-V.

You could disregard this message however, there is a danger of application state data or unsaved work being discarded upon exiting the previous session.

New KB: How to use the Process Monitor tool to generate a log file for an application in the MED-V virtual environment

J.C. Hornbeck — Tue, 13 Sep 2011 19:26:20 GMT

Here’s a new MED-V KB article we published this morning that shows you how to use ProcMon to generate a log file for an application in the MED-V virtual environment:

=====

Summary

This article describes how to use the Process Monitor tool (ProcMon.exe) to generate a log file for an application in the Microsoft MED-V virtual environment. The log file provides information about the files and about the registry keys that an application accesses inside the workspace when Process Monitor is running.

More Information

Obtaining and Preparing Process Monitor:

Option 1

1.) If you have not already done so, add in a published Command Prompt shortcut (%SYSTEMROOT%\system32\cmd.exe) in the All Users Start Menu Folder (C:\Documents and Settings\All Users\Start Menu\Programs) in the Windows XP workspace.
2.) Ensure that in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Medv\v2\UserExperience registry key, the value AppPublishingEnabled is set to 1.
3.) Restart the MED-V Host Agent.
4.) Launch the legacy published Command Prompt.
5.) In the command prompt, trigger the legacy browser (the instance of Internet Explorer running inside the Windows XP workspace) by typing it along with URL:

start iexplore http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

6.) Click Download Process Monitor (913K), and then click Save. Save to local directory on XP Workspace.
7.) Type “Explorer” in the command prompt. This will bring up an Explorer window inside the MED-V workspace.
8.) Locate and extract Process Monitor.
9.) From the command prompt, navigate to the directory where you extracted Process Monitor and type:

procmon /accepteula /noconnect

10.) On the Options menu, click Enable Advanced Output.
11.) When you are ready to reproduce the issue, start capturing from within Process Monitor. While Process Monitor is capturing, reproduce the issue.
12.) Once you have finished, save the file as PML and place it in the “My Documents” folder inside the workspace.

Option 2

1.) From the MED-V Host computer (Windows 7) download Process Monitor. To do this, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

2.) Click Download Process Monitor (913K), and then click Save.
3.) Save the file to the host to the current user’s Documents folder.
4.) If you have not already done so, add in a published Command Prompt shortcut (%SYSTEMROOT%\system32\cmd.exe) in the All Users Start Menu Folder (C:\Documents and Settings\All Users\Start Menu\Programs) in the Windows XP workspace.
5.) Ensure that in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Medv\v2\UserExperience registry key, the value AppPublishingEnabled is set to 1.
6.) Restart the MED-V Host Agent.
7.) Launch the legacy published Command Prompt.
8.) Type “Explorer” in the command prompt. This will bring up an Explorer window inside the MED-V workspace.
9.) Locate and extract Process Monitor (which is located in the “My Documents” folder.)
10.) From the command prompt, navigate to the directory where you extracted Process Monitor and type:

procmon /accepteula /noconnect

11.) On the Options menu, click Enable Advanced Output.
12.) When you are ready to reproduce the issue, start capturing from within Process Monitor. While Process Monitor is capturing, reproduce the issue.
13.) Once you have finished, save the file as PML and place it in the “My Documents” folder inside the workspace.

=====

For the most current version of this article please see the following:

2616986: How to use the Process Monitor tool to generate a log file for an application in the MED-V virtual environment

J.C. Hornbeck | System Center Knowledge Engineer

MED-V v2: Differences between Shared and Separate Workspaces

Steve TH - MSFT — Wed, 07 Sep 2011 21:06:41 GMT

When you package a workspace in MED-V, you will need to determine if this workspace will be deployed to a machine where multiple users will be logging on or a single user. If you will be dealing with multiple users, you have two options for deploying the workspace as outlined in the following article:

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

You can decide that you want to create a unique MED-V workspace for each end user or that you want the MED-V workspace made available to all end users who share the computer. The default is that the MED-V workspace is unique for each end user.

This setting is then stored in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Medv\v2\VM

Value: MultiUserEnabled

If MultiUserEnabled is set to 1, the workspace is shared otherwise it is separate which is the default.

Separate Workspace Storage

In the separate, or per-user scenario, the parent workspace disk is stored in C:\ProgramData\Microsoft\Medv\Workspace

In this scenario, individual differencing disks will be used for each user. These differencing disks will be stored on a per-user basis in the user’s local profile in the C:\Users\<Username>\AppData\Local\Microsoft\MEDV\v2 directory.

Shared Workspace Storage

In the shared workspace storage mode, the parent VHD will still be stored in C:\ProgramData\Microsoft\Medv\Workspace however the differencing disk will be shared for all users therefore it will be stored in C:\ProgramData\Microsoft\Medv\AllUsers\Virtual Machines.

Changing Mode Post-Deployment

It is important to understand that the configuration mode is designed for handling workspaces upon startup or first use. It is a setting not designed for toggling back and forth between the two modes. If you change this value (stored in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Medv\v2\VM under the value MultiUserEnabled, it will re-trigger an FTS process all over again and display the following error:

MED-V V2: Strange Message - was closed with a user logged on.

Steve TH - MSFT — Wed, 24 Aug 2011 21:03:40 GMT

Are your MED-V v2 users ever having this happen? When they go to start a MED-V published application in seamless mode or launch a virtual machine from the Virtual PC window, you get the following message:

<Virtual PC name> was closed with a user logged on

Click Continue to open the virtual application. This will log off the user from <Virtual PC name> and you will lose any unsaved data.

This is technically caused by a triggering of a RAIL (RemoteApp Installed Locally) application while a regular VPC RDP session is in use or vice-versa. The user scenarios can be mixed. In some cases the users are trying to log on when the Virtual PC still has the local administrator account logged on. This can happen if the Autoadminlogon count is set too high in the SYSPREP.INF file. The logon account should really never exceed 2 except in some rare scenarios. Another example you may see this is when you attempt to start MED-V or a MED-V published application after working with the Virtual PC in Full Desktop mode. There is really no Full Desktop mode technically in MED-V 2.0. When you are launching a VPC in Full Desktop mode you are doing that exclusively in Virtual PC and MED-V is not aware. A full desktop VPC connection is RDP-based (using a regular Windows shell) while a MED-V seamless application is using RAIL (which uses the RDPSHELL.) When you start the MED-V workspace/published application, it detects that a different session was already present in the virtual environment and it must log off that session before starting the MED-V RemoteApp session (as it uses the RDPSHELL instead of Explorer as the base shell) or vice versa if accessing the virtual machine from the Virtual PC console.

One way to prevent this if it is the local Administrator being logged on is to ensure that the AutoAdminLogonCount account is at 2 in the SYSPREP.INF file.

In addition, users will have to be educated that if they go back and forth between MED-V seamless integration and VPC Full Desktop, that they will need to log off on the Virtual PC full desktop mode before closing/hibernating the VPC. In addition, they will need to disable Fast Start on the MED-V v2 side.

In the first version of MED-V, we leveraged the Kidaro shell for Full Desktop and Seamless Integration. In v2, MED-V uses its own implementation of RemoteApps for Seamless integration and leaves full desktop access exclusively to the VPC engine (which itself uses RDP for integration components when running in Full Desktop mode.)

Here is an example of a scenario in which this may happen. If a user currently has the MED-V agent running and want to view the desktop in Full Screen mode, they would have to switch over to Virtual PC. Upon doing that, they will see the virtual machine for the workspace. Once they open up the Virtual machine in Virtual PC (for full desktop access) MED-V is no longer in the picture. Upon closing the Virtual PC in full desktop mode, it hibernates the virtual PC by default. At this point, when you try to launch an application under MED-V (back in seamless mode) this new user session that was saved upon VPC hibernation will prompt the user with message from Virtual PC. This will also work vice-versa.

Another way to tell if it is the high AUTOADMINLOGONCOUNT issue, connect to the virtual machine from the Virtual PC console.

Enter your credentials:

If it takes you to the desktop directly, then it is likely the switching back and forth between MED-V and Virtual PC that is causing the error. If you get a message regarding the logon of the local administrator account still being in use, then it is likely because your AutoAdminLogonCount setting in the SYSPREP.INF file is set too high.

NOW LIVE: The Microsoft TechNet Gallery

J.C. Hornbeck — Thu, 18 Aug 2011 14:52:31 GMT

As many of you probably already know, for a long time the Script Repository (a special-purpose gallery) has been an engine of great content and community engagement on TechNet. Well starting last week it was upgraded significantly and launched as the new TechNet Gallery, supporting not only just scripts but many other technical resources for Microsoft products including App-V, Exchange, and System Center.

Also of note is that in addition to English, the new gallery is available in French, German, Spanish, Japanese, Simplified Chinese, Traditional Chinese, Brazilian Portuguese, Russian, Italian, Korean, Czech, Polish, and Turkish. Individuals’ contributions and engagement with the TechNet Gallery are tracked in their TechNet profiles and fully integrated with our reputation system which is also fully localized.

If IT resources like scripts, management packs, utilities, and extensions are important for your success, you’ll definitely want to bookmark this one.

TechNet Gallery

J.C. Hornbeck | System Center Knowledge Engineer

Looking for an Anti-Virus exclusion list? Here’s your one-stop shop

J.C. Hornbeck — Tue, 16 Aug 2011 18:49:08 GMT

Security is something that is at the top of everyone’s mind, but what if your A/V software actually causes an issue with some of the software you’re running? If that’s the case then there’s probably an exclusion you need to make to keep things safe, secure and working smoothly. Luckily Microsoft’s own Jeff Patterson and Tony Soper have put together a pretty comprehensive list of ALL the AV exclusions you might want to configure for Windows Server, including AD, OpsMgr, ConfigMgr, Hyper-V, SQL, WSUS, MED-V, DPM, App-V and much much more. You can check it out on our TechNet Wiki below:

Windows Anti-Virus Exclusion List

J.C. Hornbeck | System Center Knowledge Engineer

Understanding and Troubleshooting MED-V v2 URL Redirection

J.C. Hornbeck — Wed, 10 Aug 2011 16:25:58 GMT

Hi everyone, Steve Thomas here and I wanted to take a minute to talk about understanding and troubleshooting MED-V v2 URL redirection. One of the most important reasons for deploying MED-V v2 is for legacy Internet Explorer browser compatibility. Like in V1, URL redirection is included to enhance the user experience and to ensure that any URL typed in the host will get properly redirected to the legacy browser running in the guest browser. The process is slightly different in v2. In MED-V 2, URL Redirection involves the process of passing a URL resource between the host and the guest by way of a remote copy leveraging the underlying RDP support from Windows Virtual PC for Windows 7. This is important to know in the event you may experience problems with URL redirection.

The MED-V Host agent will create a temporary URL file containing the URL to pass into the guest via RDPcopy. For example:

C:\Users\steveth\AppData\Local\Temp\tmpE38B.tmp.mdvurl

The MED-V Host agent will then launch the guest browser application by triggering a command similar to as the following:

"C:\Windows\System32\vmsal.exe" "Windows XP Compatibility (Shared)" "||BrowserLauncher" "BrowserLauncher" "C:\Users\steveth\AppData\Local\Temp\tmpE38B.tmp.mdvurl"

In the above example the “BrowserLauncher” application from my currently running workspace “Windows XP Compatibility (Shared),” is called through the VMSAL.EXE process (VPC application launcher.)

How to Troubleshoot

If you encounter issues where a configured URL is not redirected from the host to the guest properly, follow these steps to help you nail down where the issue may.

1) Verify the syntax of the URL.

2) Verify you are not encountering the issue outlined in the following KB:

http://support.microsoft.com/kb/2504970

3) If the above fails, create a text file in an accessible location on the host (like C:\Temp). Put the URL in the file. Call it Test.mdvurl.

4) Assuming the file created is ”C:\Temp\test.mdvurl”, MED-V is installed in “C:\Program Files\Microsoft Enterprise Desktop Virtualization”, and your VM is named “myvm”, launch the URL in the guest with the following command:
“C:\Program Files\Microsoft Enterprise Desktop Virtualization\MedvHost.exe" /LaunchApp “C:\windows\system32\vmsal.exe" "myvm" "||BrowserLauncher" "BrowserLauncher" "C:\Temp\test.mdvurl"
(REPLACE "MYVM" WITH YOUR VM NAME)
This will test the MED-V Host Agent’s capability to trigger the Virtual PC application launcher to trigger the guest browser launcher.

5) If that fails, try the Virtual PC application launcher command by itself as the next step:

“C:\windows\system32\vmsal.exe" "myvm" "||BrowserLauncher" "BrowserLauncher" "C:\Temp\test.mdvurl"

(REPLACE "MYVM" WITH YOUR VM NAME)

If #3 works but #2 does not, there is a problem with the vmsal wrapper in MED-V. If #2 fails too, you can try running the BrowserLauncher directly by going into the VM (for example, via a guest command prompt window), creating the .mdvurl file by hand, and then running:

“C:\Program Files\Microsoft Enterprise Desktop Virtualization\BrowserLauncher.exe" "C:\Temp\test.mdvurl"

If this works but the previous two attempts do not, there is probably a problem with the tsclient mappings to the host filesystem. This can be confirmed by trying to list \\tsclient\c\temp, for example. If the attempt to do this fails, this indicates a VPC failure to create the mappings. Often when this happens because auto-publish and integration components have not been enabled in the guest VPC. Also be careful that RDP/TS policies are not affecting your MED-V Hosts. The two policies that we have seen inadvertently cause MED-V folder redirection issues are:

Path: Administrative Templates\Windows Components\TerminalServices\Terminal Server\Device and Resource Redirection

Policy: Do not allow drive redirection

Path: Computer Configuration, Administrative Templates, Windows Components, Terminal Services, Client/Server data redirection

Policy: Do not allow drive redirection

Steve Thomas | Senior Support Escalation Engineer

Additional Recommended Updates for MED-V 2.0 that Address Application Issues

J.C. Hornbeck — Wed, 20 Jul 2011 14:17:27 GMT

Hi everyone, Steve Thomas here. If you are using MED-V version 2.0, you are also using RDP 7.0 and the RemoteApps feature for application publishing. Both MED-V and XP Mode rely on this technology for guest application publishing to the host. Instead of the Windows 7 RDP client connecting to an RDS server, it is connecting to the virtual machine’s guest operating system. Virtual PC for Windows 7’s integration components enable this.

It is recommended to use Windows 7 Service Pack as the host operating system version however, if you have not updated to Windows 7 Service Pack 1, I would recommend installing these RemoteApp updates which address behaviors that can also appear in MED-V v2 environments:

2287493: The RemoteApp program is not terminated after the idle session time limit expires on a computer that is running Windows Server 2008 R2

2384602: The pop-up windows of a RemoteApp program may be hidden in Windows Server 2008 R2 and in Windows 7

2388381: You cannot start a RemoteAPP program that is hosted on a Windows XP SP3 virtual machine through Terminal Services Web Access or Remote Desktop Web Access in Windows Server 2008 R2, in Windows 7 or in Windows Vista

If Windows 7 Service Pack 1 has been installed on the MED-V Host, I would recommend these post-SP1 updates for RemoteApps/RDP:

2522743: You cannot use a calendar control in a RemoteApp application when you use the RDC 7.0 client to connect to the RemoteApp application from a computer that is running Windows 7 or Windows Server 2008 R2

2524668: The single sign-on feature does not work in Windows 7 or in Windows Server 2008 R2 when you try to start a full remote desktop connection through RD Web Access

2526629: The logon message is not displayed correctly when you connect to a RemoteApp application from a computer that has multiple monitors and that is running Windows 7 or Windows Server 2008 R2

Remember: MED-V V2 leverages RDP/RemoteApps technology. Troubleshooting and data collection of these scenarios often follows a parallel approach to troubleshooting an RDP client connecting to a Remote Desktop/Terminal Services server.

Steve Thomas | Senior Support Escalation Engineer

Official Deployment Guidance for Microsoft Enterprise Desktop Virtualization 2.0 (MED-V v2)

J.C. Hornbeck — Thu, 23 Jun 2011 13:23:14 GMT

If you’ve been waiting for the official, authoritative guide for the deployment of Microsoft Enterprise Desktop Virtualization 2.0 (MED-V v2) then wait no more, for Microsoft’s own Tim Crabb, David Trupkin, and Jeff Gilbert just published one of the finest whitepapers on the topic that I’ve ever seen. Whether you’re new to MED-V or a seasoned veteran, you won’t want to miss this one. I have the table of contents below so you can get an idea of what’s inside but you can download the complete whitepaper here.

Enjoy!

J.C. Hornbeck | System Center Knowledge Engineer

Tips on Improving MED-V Workspace Application Performance

J.C. Hornbeck — Mon, 13 Jun 2011 14:38:57 GMT

If you are still using MED-V version 1, UPGRADE! But, if you are unable to due to workflow or platform issues, here are some additional tips to improve application performance for your published MED-V guest applications.

Disable Unnecessary Services and startup programs:

Regardless of whether you are using MED-V v1 or MED-V v2, you will want to minimize unnecessary utilization inside the guest operating system.These can be done by disabling the services in the services MMC snap-in, the MSCONFIG.exe utility, or even through the AUTORUNS utility available here:

http://technet.microsoft.com/en-us/sysinternals/bb963902

Allocate Adequate Workspace Memory

Ensure enough memory has been allocated to the Virtual PC within the MED-V Workspace policy. I would recommend on a machine with more than 2GB of RAM on the host to allocate at least 512 MB to the VPC. Anything less will result in sub-optimal performance. If you are using MED-V V2, you may have found that you are limited to 2 GB of memory allocation for the virtual machine. You can remove this restriction by installing the Localization Update which fixes this issue. You download the MED-V v2 localization update here:

http://www.microsoft.com/download/en/details.aspx?id=6590

Configure 16-bit Applications to run in their own memory Space

One popular application compatibility scenario for both MED-V v1 and v2 is the 16/64 appcompat scenario where companies still want to run 16-bit applications but also want to deploy 64-bit operating systems. MED-V is the only way to accomplish this seamlessly. However, it is recommended that when you do this, you create a batch file for 16-bit applications that leverage the internal START command as follows:

Start /separate <command>

This means the 16-bit application will run in its own separate underlying virtual DOS and Win16 machine (remember those?) Publish this batch file as the application.

Leverage another Physical Drive for the Virtual Machine

If using version 1.0, move the VHD to another hard drive (another spindle) on the host machine. The location of the MED-V images files on the local machine can be controlled during the installation and as well by making modifications after the installation.

C:\ProgramData\MED-V\Local\LocalSettings.xml

<LastImageStoreRootPath type="System.String">C:\MED-V Images\</LastImageStoreRootPath>

C:\ProgramData\MED-V\Profile\ProfileInfo.xml

<VmsFolder type="System.String">C:\MED-V Images\</VmsFolder>

The above are the defaults. The drive letter/directory and location can be adjusted after the fact (of course, a reboot will be required.

NOTE: This cannot be done for MED-V version 2.

CPU Utilization

If you are running MED-V version 1.0 and finding the application is generating heavy CPU utilization where the utilization is at or near 100 percent when running in seamless mode

OPTION 1: Remove the Frame Functionality from the workspace image. This cuts out a hooking function which could improve performance.

1. Publish a workspace command prompt using the "Applications" option in the workspace policy.

2. Start the workspace using an account with administrative privileges.

3. Launch the command prompt. Start Registry Editor from the command prompt.

4. Navigate to the following registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

5. Remove the KIDARO~3.DLL entry from the AppInits_DLLs value.

6. Restart the workspace and re-test the application.

NOTE: This will remove the frame functionality where the seamless application no longer has a colored frame surrounding it.

OPTION 2: Apply the ForceSimpleWindow Application Compatibility Fix to the application in the guest operating system.

If you option 1 is not desired due to the fact the painted frame is desired, you can apply an application compatibility fix using the Application Compatibility Toolkit (ACT.) Download the ACT from here:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=24da89e9-b581-47b0-b45e-492dd6da2971

Install it and run the Compatibility Administrator (COMPATADMIN.EXE)

Select “New” to create a new database.

Under “Custom Database” you will see “New Database.” Right-click it and select “Create New” followed by “Application Fix.”

Fill in the application information. Browse to the file location of NLNOTES.EXE Click “Next.”

On the “Create new Application Fix” skip and click “Next.”

On the “Compatibility Fixes” page, please select “ForceSimpleWindow” and click “Next.”

When prompted, select the conditions from the list and click Finish.

You will need to save the Shim Database into an SDB file that you can use to deploy the shim to your Windows XP Guest containing the application.

The command line to use is sdbinst.exe. More information is here:

http://technet.microsoft.com/en-us/library/dd837647(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc749169(WS.10).aspx

Hope this helps,

Steve Thomas | Senior Support Escalation Engineer

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

J.C. Hornbeck — Thu, 02 Jun 2011 21:53:16 GMT

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:

http://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:

http://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: http://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:

http://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:

http://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 (http://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: http://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 KB article: http://support.microsoft.com/kb/2308590

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

Hope this helps,

Steve Thomas | Senior Support Escalation Engineer

MED-V Tip: Offline Folder/File Synchronization Should Be Disabled Inside MED-V Guests

J.C. Hornbeck — Wed, 18 May 2011 15:25:17 GMT

Hi everyone, Steve Thomas here and today I wanted to pass along a couple tips about configuring offline folder and file synchronization within MED-V guests. The issue is that folder redirection does not function within Windows XP SP3 guests without removing the ability to sync offline files. It can cause one or more of the following in MED-V version 2.0:

Guest Hibernation Issues.
Differencing Disk Corruption causing entire MED-V Workspace for a user to become unusable.
Conflicts if both Host and Guest folders are redirected to the same network path.

In addition, this was also problematic when using redirected folders in MED-V 1.0 as well. Folder redirection for MED-V 1.0x was a critical feature as there is no native MED-V means to pass data from the host to the guest. Customers needed to enable features such as folder redirection to allow them to save and use files across the guest and Host operating systems. For V2, it is recommended to use the redirected local folders via RDP for host-guest file synchronization rather than leveraging network-redirected folders. In either case, the use of offline folders (client-side-caching) in the guest is not recommended as it can cause problems.

Disabling offline folder/file synchronization is recommended for all MED-V guests.

One quick way to do this is to deploy the following command to existing workspaces.

REG ADD HKLM\software\Microsoft\Windows\CurrentVersion\NetCache /V Enabled /T REG_DWORD /F /D 0

You can also disable this interactively in the guest by doing the following (either before or after image deployment.)

1. Open My Computer.

2. On the Tools menu, click Folder Options.

3. On the Offline Files tab, de-select the Enable Offline Files check box if it is not already de-selected.

More information on Offline Folders in Windows XP can be found here: http://technet.microsoft.com/en-us/library/bb457104.aspx

In addition, if you have group policies that may have this enabled, you can create a custom GPO for your MED-V workspaces by turning the following setting off:

In addition, you will likely want to turn the following settings on:

Hope this helps,

Steve Thomas | Senior Support Escalation Engineer

Meet a couple of our System Center engineers

J.C. Hornbeck — Wed, 11 May 2011 15:54:18 GMT

I just wanted to let you know about a couple of our System Center support engineers that were recently profiled on Microsoft’s Customer Service & Support (CSS) People First blog. There’s a chance that you might have talked with one of these guys if you’ve worked with any of our System Center products and needed to call us for help with an issue, so if you ever wondered what they look like or where they come from then here’s your chance. And even if you haven’t had the pleasure of working with either, they offer some great insight into what it’s like working in our CTS support organization and at Microsoft as a whole.

The first is Rich Pesenko, a Senior Support Escalation Engineer who specializes in Operations Manager and Mobile Device Manager: http://blogs.msdn.com/b/peoplefirst/archive/2011/04/20/profile-richard-presenko.aspx

Also profiled is our virtualization lead Steve Thomas (aka The Mad Virtualizer) who is also a Senior Support Escalation Engineer and he specializes in App-V, MED-V, VDI and SCVMM: http://blogs.msdn.com/b/peoplefirst/archive/2011/05/06/profile-steve-thomas.aspx

Enjoy!

J.C. Hornbeck | System Center Knowledge Engineer