You will need to create a VM which runs either Windows XP Professional, or any of the non-Home editions of Windows Vista or Windows 7; you can do this using an existing template or manually. This virtual machine will be the one that end users connect with from their physical machine. The Home editions of Windows do not support RDP connections and cannot be added to the Microsoft Active Directory Domain. Both of these features are requirements for VMware View to work. As you can tell VMware View is really about delivering a corporate desktop to corporate users wherever they are on the network – be it at home or work. Finally, it is possible to store virtual desktops on local storage, but doing so precludes features such as VMotion, DRS and HA. If you need to upgrade the ESX server software and you use local storage, you will be unable to move your virtual desktops to another ESX server without affecting the end users.
As you might expect, common problems normally exhibit themselves in the initial build of the Windows virtual desktop. Prior to installing the VMware View Agent, it’s worth creating a checklist to confirm that the VM corresponds with your normal corporate build. For example I always confirm the following:
- The virtual desktop is joined to the domain
- RDP has been enabled. I would recommend that if you are using Vista or Windows 7 that you use lower security for RDP. This will mean any physical client will be able to connect without security errors occurring - it will allow a Windows XP physical client to connect to a Windows 7 virtual desktop. The higher level of security offered by RDP in Vista and Windows 7 is incompatible with older editions of the Remote Desktop client and may cause problems with dumb terminals. The screen grab below shows me enabling RDP on Windows 7 (Beta) and allowing the members of a group I called Virtual Desktop Users in Active Directory the privilege of Remote Access. When you first enable RDP on Windows 7 you will receive a pop-up message warning you to change the power settings to stop the hibernation and sleep settings from prematurely ending remote access:
- Confirm you can connect to the virtual desktop by using the Microsoft RDP Client and an ordinary user account from the Active Directory Domain. The most common reason for this failing is simply forgetting to put the user accounts that will access the virtual desktops into the right group!
- Turn off Sleep and Hibernate Settings – Most modern editions of Windows come with power management settings that either sleep, suspend or hibernate the OS. This will stop all remote access as neither RDP or PCoIP have the APIs to control this power state functionality. If you do want to suspend or power off a virtual desktop when it’s not in use, this can be controlled via settings on your desktop pools within View
- Optimize your virtual desktop. This book isn’t really the place to discuss the perfect Windows XP/Vista/7 build. But before you make this virtual desktop a potential template to be used with your virtual desktop pools, you might want to think about how to harden and optimize your Windows builds for performance and security. This may include steps such as disabling services, running a defragment or perhaps using the shrink feature in VMware Tools to reduce the storage footprint of a VM. If you do intend to carryout a defrag process beware this cause problems with the “thin” virtual disk format, and cause the size of the VM to increase, as defrag reads and writes files across the disk to decrease fragmentation.
|Want to read more of this guide?
Download the full “Administering VMware View 4.5” Guide (21 Chapters). The full guide contains additional step-by-step instructions and screen shots in each chapter.
This was first published in September 2010