In the early days of VDI, there was much talk of a virtual desktop being this ultra-rich environment that the user could customize with impunity. There was frequently talk of a virtual desktop being your own computer or laptop which you could access and customize anywhere with an internet connection. When I heard this, I smiled wryly, knowing that corporate standards often decree restrictions over what users can and cannot do. In the current economic climate, it’s a sobering thought that repeated studies show that end users waste time and are unproductive during working hours if they are distracted by a computing environment that permits work avoidance behaviour. Personally, I find this a rather cheerless view of working life, and I think to some degree these studies have taken a rather Dickensian view of the world of work. Nonetheless, the facts and studies speak for themselves, and if it was my company…
So, it would be somewhat remiss of me not to acknowledge in some way the significance of desktop restrictions within a VDI environment, despite the fact that this isn’t a VMware issue or VDI problem, per se. After all, it’s not VMware who puts Pinball and Solitaire on the Start Menu. I’m assuming you’re probably already familiar with removing access to the run command or access to the registry tools in Microsoft Active Directory Group Policies. Indeed, you may have gone so far as abandoning the use of GPOs in favour of some other desktop lockdown tool such as Scriptlogic or PowerFuse. After all, there are some limitations with GPOs that reduce your ability to configure unique per-user settings for each application. That said, Microsoft GPOs remain popular because they are included as part of Active Directory. With those caveats and assumptions in mind, in this short section I want to explain and demonstrate some little known or used GPO settings. If I am forced to use Microsoft Active Directory GPOs, my goal is to use as few settings as possible - this speeds up the login process and users therefore spend less time reading the “Applying your personal settings…” message during the login process.
However, policies encompass a much wider remit than simply restrictions of the end user’s Windows environment. VMware View ships with its own policy system, which allows control of the user’s experience from a virtual desktop perspective too.
In this part of the guide, I have opted to use Windows 2008 Active Directory, in previous releases I was still using Windows 2003 Group Policies. With this said, if you have yet to upgrade you should still find the policies are more or less the same. Additionally, although I primarily used Windows XP during the testing process, in this section I opted to use Windows 7 as the target system – I consider this version of Windows to be the most likely guest operating system to be used in modern VMware View deployments. If you want to have access to the latest policy settings for Windows 7, you will need to run Windows 7 as the management system. In my humble opinion, the setup for this is quite convoluted, but there really is no other option, I’m sad to say.
|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