Defective Clone – Rouge Local Profile

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.