On 17^th of April I will be presenting at the Leeds VMUG. Session is about Optimise Virtual Desktops & ProfileUnity. Come see my presentation, bring a business card for a chance to win an Apple TV. My session is part community part vendor pitch. People are just starting to take VDI seriously now and if you want some ideas to get started come see my session. My topics will include:

• Where to start
• Building a base image
• Deployment using  a broker
• Dynamically define a desktop
• Deliver Apps

Should be interesting….remember bring a business card for a chance to win an Apple TV.

BTW…the night before there is a vBeers sponsored by Whiptail.

I found an issue in my lab and I think it would be useful to post about it on my blog. In my lab I was running  a 2003 Domain, vSphere 5 and VMware View 5.0. Everything was working just fine until recently when I upgraded my Domain to 2008. Straight away I noticed that my XP desktops no longer attached to the domain using VMware View Quickprep. This is common issue which is well documented and fixed with this hotfix from Microsoft:

http://support.microsoft.com/kb/944043

Then I noticed my Windows 7 View desktops acting erratic but only for one user. I use ProfileUnity on my lab to manage profiles and my first thought was “delete the profile for this user”  user being “ricky”. Actually this made no difference at all. I just couldn’t put my finger on it, and then I remember something. When I setup my master View linked clone image for my Windows 7 desktops I remember I logged in with the user “ricky” so that meant there was a local cache copy of a profile for “ricky” in the master image.

What I did next was open up the master image, logged on as Administrator and deleted the local cache copy of the profile folder for “ricky”

I found this wasn’t enough. In the registry there is a key also associated with this profile which I had to delete and is found:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-45054391-3288665767-689454583-1000]

The key at the end S-1-5-21-blah blah blah will differ from user to user. To find the right one just delete the one that has the username in the ProfileImagePath string.

This fixed the problem and I can only guess that the issue lay in a change in SIDs when upgrading the domain. Whatever it was my domain had its knickers in a twist with this user profile.

You could argue there is a GPO that cleans up local cache profile, however that only works when you logout. My issue was the rouge local cache profile was embedded in the View linked clone master.

As promised I have to started to record videos demonstrating at that our products are what we say they are in allegations of FUD… I’ll start referring to this situation as FUDGate. This shows that Profile Unity our Persona Management solution is the fastest to deploy, simplest to configure and has the thinnest foot print.

If you are not familiar with any other solution, YouTube it and find an equivalent video. The one I found spread the deployment over 5 videos of a competitive solution… Don’t take my word for it “try for yourself”