Using VMware vSphere and Windows 7

Author: John Hales

Abstract

VSphere is VMware's enterprise-class virtualization platform, also known as ESX (or ESXi) version 4.0. It was released while Windows 7 was still in beta; thus, the GA version of vSphere is not fully compatible with Windows 7. However, many in the IT industry have adopted Windows 7 and want to be able to administer vSphere using their desktop OS. This white paper will show you several work-arounds to achieve that goal.

vSphere

VSphere is VMware's enterprise-class virtualization platform, also known as ESX (or ESXi) version 4.0. It was released while Windows 7 was still in beta and thus the GA version of vSphere is not fully compatible with Windows 7. However, many in the IT industry have adopted Windows 7 and want to be able to administer vSphere using their desktop OS.

GA(Pre-Update 1)

While many of those with production environments will update to Update 1, both the classes and exam for vSphere are written around the GA version of vSphere. There are also those environments that don't want to upgrade for other organizational or technical requirements.

This section reviews running the vSphere Client and the Host Update Utility on Windows 7 (or Windows 2008 R2, which uses the same code base and experiences the same issues).

Running the vSphere Client on Windows 7 (or Windows 2008 R2)

The basic problem stems from updates to the .NET infrastructure. Windows 7 installs (by default) .NET 3.5 SP1, but the version is not completely compatible with other installations on other platforms. The error that is generated when the vSphere client is launched is "Error parsing <server> clients.xml file. Login will continue. Contact your system administrator." followed by "The type initializer for 'VirtualInfrastructure.Utils.HttpWebRequestProxy' threw an exception." and you are then returned to the login dialog box. The problem is resolved in Updates 1 and later of the vSphere client (as discussed below).

There are three main ways the problem can be resolved (without using the Update 1 versions), as follows (in order of increasing complexity): Use Compatibility Mode, create a batch file, or use PowerShell to automate deployment of a work-around. The advantages and disadvantages of each of these methods will also be discussed. Note that none of the methods described in this section are supported but, nevertheless, they usually work. Make these changes at your own risk.

Compatibility Mode

Using Compatibility mode is the simplest solution (at least in a 32-bit environment; use in a x64 environment hasn't been tested). To do so, follow this procedure:

1. Install the application normally.
2. Right-click on the shortcut on the desktop (or in the Start menu, or wherever you launch it from) and
select Properties.
3. In the Properties dialog box, select the Compatibility tab.
4. Check the box Run this program in compatibility mode for it and in the drop-down menu, select Windows
XP (Service Pack 3). If this is not an available option in the drop-down list, select an alternate
method of resolving the problem (either a batch file or via PowerShell).
5. Click OK.

Note that for this to work, your computer must support either Intel VT or AMD-V and have it enabled in the BIOS. This method may also cause the client to run somewhat slower than the other two options mentioned.

Batch File

For most people, a simple batch file is probably the simplest and easiest fix. I'll begin by giving you the contents of the batch file, then I'll describe what each step does. In addition to creating a batch file, you'll also need to edit an XML configuration file as described below. Note that the technique described here bypasses the usual .NET framework method of operation, so be careful if there are other apps that do the same thing, as it is possible to run into problems.

The steps are as follows:

• Before you can begin, you'll need to obtain system.dll from a non-Windows 7 computer running .NET 3.5 SP1. This file is located in the %SystemRoot%\Microsoft.NET\Framework\v2.0.50727 directory on the source computer (%SystemRoot% is usually C:\Windows). You'll need to copy this to your Windows 7 box (the batch file below assumes the path will be \Program Files\VMware Infrastructure\Virtual Infrastructure Client\Launcher\Lib, but other paths may be used as long as they match the path in the batch file). Note that some people have had trouble with version 2.0.50727.4927, but version 2.0.50727.3053 seems to work fine. Other versions may or may not work.
• Create the batch file with the commands listed in the table below (change the path to the file if necessary in the batch file).

Note in the above batch file that if you are running on an x64 version of Windows, you’ll need to change all references of %ProgramFiles% to %ProgramFiles(x86)%, as the vSphere client is a 32-bit app.

• This approach also requires an update to the configuration file used to launch the vSphere client. The reason is that it, like all other .NET apps, uses the default system installed version of .NET which, as explained above, won’t work in this case. To force it to use the .NET version copied into the location above, make the addition listed in bold text in the VpxClient.exe.config XML file:

    <?xml version=”1.0” encoding=”utf-8”?>
    <configuration>
    <system.net>
    <connectionManagement>
    <clear/>
    <add address=”*” maxconnection=”8” />
    </connectionManagement>
    </system.net>
    <appSettings>
    <add key = “protocolports” value = “https:443”/>
    </appSettings>
    <runtime>
    <developmentMode developerInstallation=”true”/>
    </runtime>
    </configuration>

• Optionally, replace the desktop shortcut to the vSphere client with this batch file so it will automatically run instead of running the standard version, which will fail. This isn’t an issue if you chose to create an environmental variable; the original icon will work just fine when the other changes described in this section are implemented.

PowerShell
The third option is to use a PowerShell script to automate this process if you have many workstations to deploy the change to. You’ll need an actual PowerShell script to do so, which is beyond the scope of this white paper, but you can go to the link described in the References section to get the script and use it.

Running the vSphere Host Update Utility on Windows 7

The problem described in the previous section also applies to those who use the vSphere Host Update Utility to manage updates for vSphere instead of using VUM (VMware Update Manager). To remedy this problem, first follow the instructions in the previous section to get the vSphere client working, and then do the following tasks:

1. Copy the Vpxlient.exe.config file (usually located in C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\ for an x64 edition of Windows or C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\ for an x86 version) to VIUApp.exe.config in the ..\Infrastructure\VIUpdate 4.0\ folder. This is done because they both need the same change to the XML configuration file; alternatively, you could edit the VIUApp.exe.config file and make the changes previously described.
2. Create a batch file that launches the Host Update Utility as described above, except you’ll need to run the host update utility instead of the vSphere client by changing the path to also include the directory where the host update utility is installed (the VIUpdate 4.0 directory) and then running VIUApp.exe instead of VpxClient.exe.

vSphere Update 1 and Later

Windows 7 (as well as Windows 2008 R2) and the vSphere Client work as they should once the Client from Update 1 is installed. Note that as of Update 1, Windows 2008 R2 is still not a supported OS for vCenter, the vSphere client, or the Host Update Utility, however.

One other very important note here: If you made the changes described in the previous section to allow the vSphere Client and/or the Host Update Utility to run, you’ll need to uninstall them, edit the XML file (or files, if you changed them both), and remove the bolded text that was added earlier. The reason for this is that uninstalling does not delete these files. After they have been modified, install the Update 1 version of the vSphere client and/or Host Update Utility (one way to do so for ESX hosts is to point a browser at the service console IP address and downloading the vSphere client from there; another is to use the Update 1 version of the vCenter CD).

View Windows 7

Version 4
View is experimentally supported on Windows 7. This means that it may work, but VMware cannot guarantee compatibility at this point. This will probably be fixed in an upcoming patch in the future, but as of the GA release of View 4, it is only experimental. There may be limitations as well that other supported OS options don’t have, such as Autofit (sizing the window to fit the resolution specified in the guest) not working properly with Windows 7 when PCoIP is used. Another known issue at this point is that if you connect using PCoIP to a Windows
7 desktop and the single sign-on information is not correct for the virtual desktop (for example, because the VM is not part of the domain), you will be left with a blank screen. At that point you have two options: try to enter them without any video input or press the Escape key to cancel the login and return to the client you were connecting from to try again.
It is also important to note that View does not support any x64 OS at GA (XP, Vista, or 7). More details on this can be found in the View 4 Admin guide. In fact, with Windows 7 x64, the SVGA driver won’t even install. You can get around this if you install the drivers located in C:\Program Files\Common Files\VMware\Drivers\wddm_video (the standard Windows 7 vMware Tools Update 1 drivers) over the newer, but incompatible,
View 4.0 drivers. In addition, the VMware Tools driver included with vSphere Update 1 does not support and will not work with x64 guests using PCoIP, but Microsoft’s RDP will work properly with x86 guests.

Version 3

Windows 7 is not supported in View 3 at all, but can be made to work if the agent is installed, and you tell vCenter that the installed OS is Vista, not Windows 7. If you have trouble getting it to install, you may need to use the registry hack listed in the References section titled VMware View and Windows 7 to see if it helps.

Related Courses

VMware vSphere: Install, Configure, Manage [V4]
VMware vSphere: Fast Track [V4]
VMware vSphere: Troubleshooting [V4]
Implementing and Administering Windows 7 in the Enterprise
Planning and Managing Windows 7 Desktop Deployments and Environments