Additional recommendations when using MED-V Workspaces configured for NAT Mode

Article
10/20/2010

In working with MED-V and supporting MED-V, I have found that there are three major areas that can be affected when using NAT mode instead of Bridged Mode with persistent mode MED-V workspaces.

- Application Icons not displaying properly (or being cached properly)
- Single-Sign-on (SSO) either does not work or has intermittent issues.
- Connections to domain resources fail

A lot of these issues can be avoided by doing some additional configuration changes to the underlying guest operating system to allow for these workspaces to behave better in a domain-joined setting.

Force Kerberos over TCP

Relying on UDP for authentication may cause issues with virtual machines running in Shared Network (NAT Mode.) For XP guest joined to Windows 2003 domains and later, you will alleviate many authentication-related issues by forcing Kerberos to use TCP instead of UDP. Use the registry setting originally outlined in KB article 244474.

- Registry key: HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters
- Value name: MaxPacketSize
- Value type: DWORD
- Value Data: 1

ICMP and Group Policy Slow Link Detection

You will also want to get in front of any group policy processing issues with the guest operating system running in NAT Mode. With VPC 2007, There is an ICMP restriction for non-administrators. If this is an option for guest users, one recommendation would be to make the user a member of the local administrators group in the guest OS. If this is not desired, you will want to disable GPO slow link detection using the following registry modifications.

- Registry key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System
- Value name: GroupPolicyMinTransferRate
- Value type: DWORD
- Value Data: 0

- Registry key: HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System
- Value name: GroupPolicyMinTransferRate
- Value type: DWORD
- Value Data: 0

NOTE: All registry changes recommended here need to be implemented prior to image deployment if possible otherwise every active workspace will need to be touched.

How to Troubleshoot Network Connectivity in MED-V v1 Workspaces

On regular Windows hosts, a network monitor trace is often the best way to nail down what may be going wrong. Isolating issues with network communication and authentication for MED-V workspaces should be troubleshot in the same way.

When dealing with connectivity issues, it is best to take a trace from the server side (the shared resource, domain controller, etc.) and workspace (guest) side at the same time. The challenge for active workspaces is getting a network monitor utility into the active workspace. You can update the policy to publish out a custom menu, command prompt, or Windows explorer instance and then use the File Transfer Wizard to copy the Network Monitor bits into the workspace.

Getting a Network Monitor installation inside the Workspace

First, it is recommended to publish out a command prompt as it is simple and lightweight. This way you can use this to install the Network Monitor utility (without having to redeploy the entire image.)

You can download the most recent version of Netmon here:

https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f

You then can use the MED-V File Transfer Wizard to copy the Netmon installer package into the workspace. You can do this by going to the MED-V System Tray and selecting Tools – then File Transfer.

You can then open up your published command prompt or explorer and run the setup either interactively or non-interactively using the following command:

NetmonSetup.exe /Q

Once NetMon or whichever protocol analyzer you are using is installed, troubleshooting will be along the same lines as if you were troubleshooting the behavior of a regular workstation.

Steve Thomas | Senior Support Escalation Engineer

Additional recommendations when using MED-V Workspaces configured for NAT Mode

Additional resources