View 5.1 BUG Alert!

I found one!

I just upgraded our environment to the latest build of 5.1 over the weekend and in the processes upgraded the agent to 5.1 on our base virtual machines. On Tuesday, one of our users (who's using a zero client) reported they could no longer change the resolution to their desktop. I checked all the settings as recommended by KB article 1020809 and even though I could move the slider on the display settings (it is a Windows XP virtual machine) and then apply it, the display would then go dark like it was changing the resolution and when it came back, the resolution would still be the native resolution of the monitor. I even tried a little documented command:

VMwareResolutionSet.exe 0 1 , 0 0 1280 800

(btw, that command is located in "c:\Program Files\Common Files\VMware\Teradici PCoIP Server\")

which sets the resolution on the first monitor to 1280x800... no luck. Same outcome as before. One of my co-workers who also has a zero client and a Windows 7 desktop tried to change his to test and his wouldn't change either. The only resolution we could change it to was 800x600.

When I dropped the user down from agent version 5.1 to 5.0, they could again change the resolution settings. I told VMware about the bug but so far, I haven't received any type of response back from them. Hopefully they'll have a fix out for it soon.

update: Turns out it was the firmware version on the zero client. As of the time of this writing, there wasn't a firmware that supported View 5.1. This issue has since been fixed.

ESXi, vCenter and Active Directory

I don't have any confirmation on this (in fact VMware support has no idea how this happened), but after spending 11 hours on Saturday rebuilding one of my vSphere servers (which houses the entire View environment), I think I figured out why 90% of my vm's went orphaned on me after I took the server offline for some hardware upgrades (like ironically, a fibre HBA to hook into our new EMC VNX5300).

When I originally built this vSphere environment, I did so with the thought that this would be all I get to work with. I didn't have any shared storage (not even a decent iSCSI/NFS store), nor did I have vMotion... and apparently I didn't really know exactly what I was doing ("gasp!" - getting that out was hard for me because I hate to think that I did anything wrong). I had an idea of what I wanted but VMware was still a little new to me. Fast forward six months, and I've gone through "Mastering vSphere 5" twice, read most of VMware's vSphere 5 documents and have taken the vSphere 5 class (my VCP test is registered for June 4th). I have a MUCH better understanding of how the whole vSphere environment works. So this is how I think I killed 96 virtual machines - causing me to re-register each and every one of them and taking down my entire View environment.

I added the ESXi host to vCenter using a domain account whose password changes every 60 days.

See, I went through and set up access to the ESXi host before adding it to vCenter. I really didn't understand how vCenter played such an important role in management until recently. Here's my train of thought (granted, none of this is verified - just my own suspicions):

• I add the ESXi host to vCenter with a domain account
• vCenter cache's the username and password used to connect and authenticate the ESXi host
• I add some VM's to the host through vCenter
• vCenter uses those cached credentials to register those VM's with the ESXi host itself
• My domain account's password is changed
• I then proceed to build out my entire view environment on this host
• Each time a VM is created in vCenter, vCenter adds it to it's database then tries to register it with the ESXi host using the original cached credentials
• uh-oh... those credentials are expired. vCenter gets to actually create the virtual machine files on the datastore but the ESXi host refuses to add the VM to its list of hosted virtual machines
• Fast forward to Saturday and I take the host down to put the new HBA cards in it
• When I bring the host back online, vCenter tries to re-add the host but is unable to do so using the cached credentials
• I have to re-add the host to vCenter, this time realizing I need to use the ESXi host root username and password.

Again, this is my speculation, but it seems to be the only logical answer to how this happened. I mean, there's no way taking a host offline on purpose should make 90+ VM's orphaned you know?

Anyways, if anyone ever reads this and they know of official documentation from VMware that supports this theory, I'd love to read it!

Hostnames and View Volatile Environment Registry Entries

We're starting to deploy a large amount of linked clones that require the zero client machine name to base network printer mappings too. I created this batch script to grab the volatile environment machine name key and shove it into a environmental variable but before I go on with the story, here's the batch script if anyone can use it for something else:

@echo off

FOR /F "tokens=4 delims= " %%A IN ('whoami.exe /user /sid') DO SET RegKey="HKU\%%A\Volatile Environment"

c:\windows\system32\reg.exe copy %RegKey% "HKCU\Volatile Environment" /f /s

c:\windows\system32\setx.exe (your variable here) -K "HKEY_CURRENT_USER\Volatile Environment\ViewClient_Machine_Name"

So a few weeks go by and the new guy on the staff get's asked to build another script to map the network printer... now he's never worked with VMware View before so keep that in mind. I go off to fix some end user issue and the next time I see him two hours later he's still working on trying to write the script but he asks me to come over and take a look at something so I do. He then proceeds to type in:

echo %ViewClient_Machine_Name%

into a command prompt and wouldn't you know... his zero client's name came up. I was like "wha??". So I had him log into his desktop using his iPad and try it again. Low and behold, the variable changed. I was like "no way". I had literally worked a half a day on that above script to get the variable created based on the key location within the HKEY_USER sub section of the registry. I guess my next question is why isn't that info documented more... The fact that all those volatile environmental entries in the registry are already made into environmental variables slipped past not only the View class I took but also 98% of all web pages out there. Grrr.

quick way to break a virtual desktop...

Just FYI. If you take ownership of the c:\windows\system32 directory away from "nt service\trustedinstaller", you'll break vmware view.