vSphere 4.1 Troubleshooting Guide Released
Feb 21st
VMware has released the latest iteration of its vSphere troubleshooting guide. It can be downloaded from the VMware Communities site. The design and layout of the guide is a little different, but in a good way. It provides step-by-step instructions for troubleshooting common issues. The guide was written by VMware’s Chethan Kumar.
Eric Sloof of NTPRO.NL also has a great slideshow presentation for vSphere troubleshooting.
Windows Update Breaks View Client
Feb 16th
Microsoft patches 2482017 and 2467023 will cause the View client on Windows 7 to freeze after login. To fix this, the View client needs to be un-installed and re-installed with build 353760 or later, which depending on your software delivery method could be easy or not.
However, there are no details in the VMware KB 1034262 on how to update the version of the client that is downloaded via the login portal. To do this, simply take the latest build of the View client and replace the executables in C:\Program Files\VMware\VMware View\Server\broker\webapps\downloads.war\ on the Connection Servers. Nothing needs to be updated on the Security servers, as they retrieve the files from the Connection Servers.
Approximately a week after this was first discovered, there are still no public releases of versions of the View client with Local Mode.
Be very careful with updating anything in your View environment without giving the updates significant time to test (for both Windows updates AND VMware updates), and it’s also worth checking out the VMware View Communities Site to stay up to date on the latest issues people are having.
View: Removing Auto Log in As Current User
Jan 4th
What happens if you select “Log in as current user” in your View Client, but want to log in as another user? It’s not exactly easy to remove the checkbox so it doesn’t log you in automatically, but there are ways to undo it.
Option 1) Launch the client with the “-logInAsCurrentUser false” parameter:
“C:\Program Files\VMware\VMware View\Client\bin\wswc.exe” -logInAsCurrentUser false
Option 2) Make a registry change to undo the setting:
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\Client\Security\LogInAsCurrentUser_Default = 0
You can also disable the ability to even set the “Log in as current user” option with the other registry key “LogInAsCurrentUser_Display”.
vSphere 4.0/4.1 Linked Mode Issues
Dec 20th
According to the vSphere 4.1 Release Notes, vSphere 4.1 and 4.0 should gracefully co-exist in a Linked Mode configuration. This, however, does not seem to fully be the case. We ran into an issue where we could not mount ISOs within the 4.0 vCenter’s virtual machines; it would simply hang at “Connecting.” A glance at the client logs (C:\Documents and Settings\<Username>\Local Settings\Application Data\VMware\vpx\viclient-*.log) shows the following:
[ :Failed t:P:16] 2010-12-17 02:20:07.811 System.Net.WebException: The remote server returned an error: (501) Not Implemented.Server stack trace:at System.Net.HttpWebRequest.GetResponse()Exception rethrown at [0]:…at System.Net.HttpWebRequest.GetResponse()at VirtualInfrastructure.Utils.WebDownload.GetResponse()[ :Failed t:P:16] 2010-12-17 02:20:07.811 System.Net.WebException: The remote server returned an error: (501) Not Implemented.Server stack trace: at System.Net.HttpWebRequest.GetResponse()Exception rethrown at [0]: … at System.Net.HttpWebRequest.GetResponse() at VirtualInfrastructure.Utils.WebDownload.GetResponse()
From speaking with VMware support, they believe this is an issue with the client not gracefully communicating to the older vCenter. Basically, it is trying to send functions to the older version that only exist in 4.1. When you have Linked Mode with different versions of vSphere, it prompts (actually, it requires) you to download both vSphere clients, so one would presume this would be for issues like this… unfortunately, that doesn’t seem to happen.
There are a few ways to resolve this:
- Unlink the vCenter instances.
- Upgrade the 4.0 version to 4.1.
- Accept that ISO mounting within vCenter will not work on the 4.0 vCenter, and manually connect to the VM through the host (thus bypassing vCenter) to mount the ISO. Avoiding vCenter “resolves” the issue.
If none of the above work for you, perhaps it is worth hounding VMware Support to resolve this, since it is listed as supported in documentation (Note: Support tried to claim this configuration was not supported during our case, but acknowledged it was after being presented the vSphere 4.1 Release Notes). Their final response was that having 4.1 and 4.0 in tandem was only meant to be a “temporary migration” setup. It wasn’t really worth fighting the good fight here since we are upgrading the 4.0 instance to 4.1 soon anyway.
Nifty PowerCLI One-Liners
Oct 15th
The following are a few PowerCLI commands that I have found useful at one time or another. The VMware Communities section for PowerCLI is a great starting point for more information on setting up and using PowerCLI. If you have a question about how to do something, the discussion forum is a great resource; there are tons of incredibly intelligent and helpful individuals that will be more than happy to point you in the right direction.
Get Running VMs without VMware Tools Installed:
Get-View -ViewType “VirtualMachine” -Property Guest,name -filter @{“Guest.ToolsStatus”=”toolsNotInstalled”;”Guest.GuestState”=”running”} | Select Name
List all Snapshots:
Get-VM | Sort Name | Get-Snapshot | Select VM,Name,Description,Created
VMs Created Recently:
Get-VIEvent -maxsamples 10000 | Where {$_.Gettype().Name -eq “VmCreatedEvent”} | Select createdTime, UserName, FullFormattedMessage
VMs Removed Recently:
Get-VIEvent -maxsamples 10000 | Where {$_.Gettype().Name -eq “VmRemovedEvent”} | Select createdTime, UserName, FullFormattedMessage
VMs with more than 2 vCPUs:
Get-VM | Where {$_.NumCPU -gt 2} | Select Name, NumCPU
Check for invalid of inaccessible VMs:
Get-View -ViewType VirtualMachine | Where {-not $_.Config.Template} | Where{$_.Runtime.ConnectionState -eq “invalid” -or $_.Runtime.ConnectionState -eq “inaccessible”} | Select Name
Get Errors in the last week:
Get-VIEvent -maxsamples 10000 -Type Error -Start $date.AddDays(-7) | Select createdTime, fullFormattedMessage
Get VMs with Memory Reservations:
Get-VM | Get-VMResourceConfiguration | Where {$_.MemReservationMB -ne 0} | Select VM,MemReservationMB
Get VMs with CPU Reservations:
Get-VM | Get-VMResourceConfiguration | Where {$_.CpuReservationMhz -ne 0} | Select VM,CpuReservationMhz
Delete all Snapshots with Certain Name:
Get-VM | Sort Name | Get-Snapshot | Where { $_.Name.Contains(“Consolidate”) } | Remove-Snapshot
AutoView: Most Underrated View Tool?
Sep 29th
In my journey to find the best method to convert an old workstation into a thin client for our View deployments, I came across many solutions before we came upon AutoView by Justin Emerson at VM Junkie. AutoView is a series of scripts and registry edits that convert an XP machine into a thin client in minutes with only one click.
The general premise of what it does is:
1. Create a user called ‘user’ and temporarily adds this user to the Administrator group so it can make the necessary registry changes.
2. Modify the Winlogon registry settings for the local machine so that ‘user’ logs on automatically, and that upon the next reboot another batch script executes.
3. Reboots the system.
4. After reboot, it sets a VBScript to execute the View client in a loop as ‘users’s logon shell. This makes it so that the user only sees the View client, and not the start menu, etc. It also disables Task Manager, Lock Workstation, and Password Change options from the Ctrl+Alt+Delete menu.
5. It then removes ‘user’ from the Administrators group and reboots the system.
6. The system now boots up, auto-logs into the ‘user’ account, and only shows the View client to the user.
If the View client is exited, it simply re-opens automatically. If you need to get to the Administrator account or to another account, simply Ctrl+Alt+Del and hold down ‘Shift’ while clicking Log off. This will exit you out to the normal Windows logon screen. If shift is not held down, it simply logs back into the user account.
The great thing about this is that you can convert someone’s existing workstation and leave it untouched in case they are unhappy with their virtual desktop. All you have to do is make it so the ‘user’ account doesn’t auto-login which can be done by modifying the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ForceAutoLogon key to 0 then they’re back to their regular desktop.
Overall, this has been the perfect solution for us in our deployments without hardware thin clients. It may not be perfect for everyone, because you’re still using a Windows license on the underlying system, but that is not a problem for our environment.
More information on AutoView from the Author’s blog: Part 1, Part 2.
Other Solutions
I won’t go into detail with these, because we didn’t choose to pursue them after initial testing, but I will give my general impressions.
We use several Wyse thin clients, so we did explore their PC Extender solution. We tested this, and came out generally unimpressed. You could tell it didn’t get a lot of TLC from Wyse, which I suppose makes sense… they would obviously prefer you to buy their hardware thin clients. The setup and implementation wasn’t great, and they would only support a limited number of PC makes/models. It definitely has potentional.
We also considered Devon IT’s VDI Blaster, which was an impressive product. It didn’t have quite the amount of polish I was hoping for, but it was a solid solution. Once issue we ran into is that the hostname of their management suite was hard-coded into the software and required a bit of work to fix.
Lastly, another option is ThinLaunch. This software does literally the exact same thing that AutoView does. There are no features in ThinLaunch that are not provided by AutoView. If you don’t believe me, feel free to watch their video demonstration. The real problem with this? It costs $25 per computer, and AutoView is free and modifiable.
View 4.5 vs. Read-Only Domain Controllers
Sep 13th
When trying to update our Automated Pool after upgrading to View 4.5, we ran into an issue where the virtual desktops being provisioned would fail with an error saying they could not join the domain. If we logged into the virtual desktops through the vSphere client, the machine were actually, in fact, on the domain.
Checking the C:\Windows\Temp\vmware-viewcomposer-ga-new.log file, we could see the following error:
2010-09-10 10:13:08,284 [3636] FATAL CSvmGaService – [svmGaService.cpp, 116] Domain join failedError 1265 (0x4f1): The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
We had full rights to join the domain with the account in question, and we didn’t have any problem using our QuickPrep settings with 4.0.1, so this was quite a mystery. We called VMware Support, and we ran through several troubleshooting routes with no avail. Eventually, through the VMware Communities forum, a VMware employee suggested we try Microsoft KB 944043. The patch provided within this KB is not applied by default with normal updates.
It appears that in 4.5, VMware has modified the QuickPrep process which causes this issue to occur. Luckily, this is an easy fix if you know about it.
View 4.5 First Thoughts
Sep 12th
View was released around 9pm on Thursday, and I had our environment upgraded shortly there-after. We don’t have a ton of users on virtual desktops yet, and VMware is typically very good about not releasing unstable products, so why not? 
Upgrade Process
The upgrade process is very easy, as described in the View 4.5 Upgrade Guide. It’s, more of less, simply a matter of launching the executables on each of your nodes (connection server(s), security server, vCenter server, and desktops). The only part that I wish was a little less cumbersome is upgrading the agents on Individual Desktops. The upgrade guide specifically says:
If you use full-clone desktops or other virtual machines that you added as individual desktops or as part of a manual pool, upgrade View Agent by using whatever third-party tools you usually use for software upgrades.
I think VMware kind of “passed the buck” in this regard. We just upgraded all of our individual desktops manually. It was kind of tedious, but luckily we didn’t have too many. Rolling out the updated agent through recomposing our linked clones was much easier: simply update the master image, create a new snapshot, point to that snapshot, recompose. The agent essentially becomes a core piece of the operating system, it would be nice if they had a more automated-way even if it was similar to how VMware Tools upgrades work.
New View Manager Interface
The interface has been completely revamped with this release, and it is entirely for the better. It now requires Adobe Flash to be installed to view it, however.
One of the best new features if the ability to manipulate User Data Disks much more easily. You can detach them and attach them all now through the Persistent Disks tab under the Inventory section. This is particularly useful if you want to delete a VM, but re-use the UDD on a new VM. It is unfortunate RTO Virtual Profiles did not make it into this release, but this certainly makes dealing with UDDs much less cumbersome.
View Manager Event Logging
When you log into View Manager for the first time after the upgrade, you will notice it wanting you to configure the event database. You will need to point it to a supported Database server type specifically for it to store logs. Information will now be stored to this database, such as users logging in/out of virtual desktops, login audits for View Manager, generic stats like maximum number of users with concurrent desktop sessions, adding pools, composer events, etc. You also have to ability to export the log data to third-party log analysis tools. It’s a very nice addition.
Windows 7 Support
In View 4.0, Windows 7 was listed as experimental. They would still offer support for it, but the quality wasn’t quite there. In 4.5, Windows 7 is now completely supported, both as a client and as a virtual desktop. We didn’t have any problems with 4.0 and Windows 7, but 4.5 does feel snappier. Maybe it’s all psychological, though.
Other features
This is the first release with a Mac version; it only supports RDP, just like the Linux client. One of the non-noted features in View 4.5 is that the Windows View Client now has the ability to Auto-Connect USB devices. The graphics for all of the features now have a more polished professional look, as well.
Some more additions in View 4.5 that I haven’t had a chance to tinker with directly are:
Tiered storage. By placing the Replicas on a separate storage device from Linked Clones, they can be shared by all Linked Clones. You can also use high performance solid-state disks (SSDs) to improve recomposition performance.Local Mode or Type 2 hypervisor. Formerly known as Offline Desktop, Local Mode provides encrypted, encapsulated, and uninterrupted desktop services. IT professionals have full control on data synchronization, replication schedule, or deployment policies including Local Only smart card access, USB access, and more.Smart card and two-factor authentication. By adding your root certificate from a domain certificate authority, you can secure your organization’s workstations with smart cards and smart USB tokens.
Summary
Overall, this is a solid release. Were there tons of new revolutionary features and extensions added? Not really. They did, however, put an immense amount of polish on View 4.0. I believe it is a solid release, and that View is heading in the right direction. It is definitely worth upgrading.
Direct Connections and View Security Server
Sep 8th
When using Wyse thin clients, specifically WTOS and TCX, they require that you enable Direct Connections to the Virtual Desktops for full functionality, as listed in the VMware View and WTOS Best Practices Guide.
Unfortunately, this creates a problem when using the View Security Server. This is because if you’re using direct connections, what is trying to occur is for your client to directly connect over port 3389 to the Virtual Desktop. If you try to connect through the Security Server with this enabled, you will be able to log in to the portal, select your VM, and even select Connect, but that is when it fails. This is because there is no way for your external machine to connect directly to the internal virtual machine via RDP with most firewall/networking practices, and making a rule to allow this is not generally a good idea. (Note: Connections will work if, for some reason, you are trying to connect through the Security Server from inside.)
Fortunately, this is a relatively easy fix, and the best way to fix it is to simply create a Replica Connection Server with Direct Connections not enabled, then link your Security Server to that Replica. This causes your Security Server connections to not pass directly to the VM, but your Wyse devices will still use the main server and get the benefits of direct connections. Setting up a Replica is fairly straightforward, and outlined in the View Manager Administration Guide.
UPDATE: In View 4.5, they have changed the terminology for this. Now you need to disable “Use secure tunneling” for TCX to work properly.
PCoIP VRAM Fix
Aug 30th
One of the biggest annoyances I’ve ran into when deploying VMware View is the finickiness of PCoIP. The problem is that if the video settings within your VM are not just right, then you will run into issues like:
- You cannot re-size the screen
- Resizing only works down instead of up.
- Resizing responds very slowly or fails after several resize attempts.
- You cannot switch between full-screen and windowed.
Obviously, these are rather deal-breaker bugs. To say the least, VMware’s response and fix to the issue are disappointing. Their “fix” involves jumping through a lot of hoops that make the process way more tedious than it should be. The KB article for this fix is 1018158.
It doesn’t appear that the vSphere client saves changes to the Video Settings fully to the .vmx file, but fortunately ermac318 over at VM Junkie has created a PowerCLI function to fix this issue. You can grab the script from his site or from a local mirror here. To run it, do the following:
> Connect-VIServer -server vCenterServer.tld
> . .\set-vramsize.ps1
> $vm = Get-VM -name VirtualMachineToModify
> Set-VRamSize($vm)
This should modify the .vmx file for the VM. You can confirm by downloading the .vmx file through vCenter and seeing if the file contains the expected modifications.