Trouble Recomposing View 5.x Desktops After Upgrade to vSphere 5.0 U2

I’ve finally gotten around to upgrading my View environment from 5.0 to 5.1.2. Just before I attempted the upgrade I also applied the latest patches to all my hosts taking them up to vSphere 5.0 U2. This is where some fun started, but fortunately to avoid some of this fun the solution is very easy.

Before I embarked on my upgrade to View 5.1.x I updated my SSL Certificates to use CA Signed Certificates. I found it easy enough updating the certs on View 5.0 prior to the upgrade (made the upgrade smooth). When I went through and updated the SSL Certs on View 5.0 with my CA Certs I followed the instructions in KB 1008705. A couple of tips:

1. The line mentioned in there “keytool -importcert -keystore <keys.jks> -storepass <secret> -keyalg “RSA” -trustcacerts –file <certificate.p7>” should read “keytool -import -keystore <keys.jks> -storepass <secret> -keyalg “RSA” -trustcacerts –file <certificate.p7>”
2. You need to make sure you get the full PKCS7 Cert Chain from your CA if using jks keystores. From a Microsoft CA you would select to download the certificate chain.

When it comes to the computer running View Composer you can use the request new certificate workflow as described by Derek Seamen in his blog article VMware View 5.1 Installation Part 1 – View Connection Server. The process he uses to use SSL Certs is very easy and is also a good option for Connection Servers.

After upgrading to View 5.1.2 when I went to test View Composer and deployed a new desktop pool from one of the Win7 Parent VM’s. I found I was unable to access any of the vDesktops. All of the NIC’s were showing as connected in vCenter, but inside the Guest OS the VMXNET3 driver was showing as not working correctly in device manager. Upon uninstalling the driver through device manager and detecting hardware changes the NIC would start working. This wasn’t going to be a workable solution though manually updating every vDesktop that I deployed.

Fortunately the solution was easy. I simply had to update VMware Tools inside the Parent VM, take a new snapshot and then recompose the desktops in my test pool. This proved not only my new View 5.1.2 environment and View Composer (on a standalone host) was working, but that also the problem was related to View 5.1.2 not wanting to work with the old version of VMware Tools on a newly upgraded vSphere 5.0 U2 host with the previous version of Tools. After upgrading my hosts to vSphere 5.0 U2 I had not updated VMware Tools in all of my View Parent VM’s.

Based on this experience my advice would be to always update VMware Tools in the Parent VM’s prior to a recompose operation after your vSphere Hosts have been updated to a new version. Even though older versions of VMware Tools are supported on newer versions of vSphere sometimes weird things like this happen. Just as well I was testing this in an isolated test pool in my lab prior to recomposing any of my other desktop pools. This shows the importance of testing any changes in your View environments or vSphere environments, even if they seem like a small change.

My only remaining problem is that no matter what I try I can’t get Thin Print installed in the Parent VM. Regardless if I try and install it using VMware Tools or via the View 5.1.2 Agent. The installer always freezes and never continues when it comes to the point where it’s trying to install the Thin Print driver. So I still have some more troubleshooting ahead of me. But at least the critical components are working.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster. All rights reserved. Not to be reproduced for commercial purposes without written permission.