VMware View 5.0 user profiles on a Windows 7 linked-clone virtual desktop are not redirected to persistent drive

I ran into an interesting problem last week when I was told that one of the users in a VMware View deployment I had completed a few weeks ago was losing their signature in Outlook.  The majority of the desktops in the environment were linked-clones with a dedicated 10GB disk assigned to every user so that their profiles could get redirected to a persistent disk and thus retained their customized Windows and Office settings every time I refreshed the desktops with an updated image.  Seeing how no one else had issues with their desktops, I was curious as to why the user was experiencing this problem so I went ahead and logged onto her desktop to find that her profile was not redirected to the persistent D drive.  This meant that every time I refreshed the linked-clone’s master image, she would lose all of her customized settings and files in her My Documents, My Pictures, etc folders (Whoops!).  My initial thought was that perhaps I could assign her to a different desktop and her profile would get redirected properly but after trying that on a few free desktops without any luck, I knew something else was wrong.  To make a long story short, the problem was caused by the fact that the master image was logged on by that user’s account and therefore had a profile for the user stored on the C drive.  I initially thought that the problem would be solved if I simply deleted the profile from within the master image but quickly noticed that it was a bit more demanding than that so after hacking away at the problem and finally fixing it, I took the time to document the steps when went back to another account that was experiencing the same problem.

The first step in troubleshooting this issue is to confirm that the profile is indeed not directed so log onto the virtual desktop with the VMware View Client, click on the Start menu and type in %appdata% then enter:

From within the Windows Explorer window that automatically launches, review the path’s drive.  If it’s pointing to the C drive as shown in the screenshot below then the profile is not redirected:

The next step is to check the persistent drive’s (usually D) root directory’s Users folder:

If the Users folder contains no folder with the login name of the user account then you can be sure that whatever you save into your My Documents, My Pictures, etc folders are not redirected:

The next item to check is the profiles folder located in the Personality folder on the persistent drive.  Notice how this folder contains files with no extensions and the name of the files are SIDs:

Here’s a list of SIDs found in the profiles folder for the example I’m going to use:

• S-1-5-18
• S-1-5-19
• S-1-5-20
• S-1-5-21-2876550492-3781512850-3958252139-500
• S-1-5-21-597650934-770836382-26564730-1020
• S-1-5-21-597650934-770836382-26564730-1034
• S-1-5-21-597650934-770836382-26564730-1821
• S-1-5-21-597650934-770836382-26564730-4332
• S-1-5-21-597650934-770836382-26564730-4335

These SIDs you see in the folder actually represent the folders listed under your virtual desktop’s C:\Users folder and they map to the user profile folders:

As I mentioned earlier, the first idea I had in mind was to simply delete the problematic user’s profile from within the System Properties:

If you delete the profiles in here, Windows 7 will automatically remove the registry key from within the registry that contains the user’s profile (I’ll write more about this a little later):

**Note that the Delete button is grayed out in the screenshot above because I’m actually logged on as ccsadmin.

If you proceed with simply deleting the user’s profile on the master image, snapshot your master image and recompose your linked-clones with the new snapshot, you’ll run into the following error when you log in with this problematic user:

You have been logged on with a temporary profile.

You cannot access your files and files created in this profile will be deleted when you log off. To fix this, log off and try logging on later. Please see the event log for details or contact your system administrator.

Since simply deleting the profile off of the master image didn’t seem to fix my problem, I stepped back and thought about the issue and decided to take a closer look at the SIDs listed in the D:\Personality\profiles and determine their respective mappings.  For those who aren’t familiar with SIDs, more information about them can be found here:

http://en.wikipedia.org/wiki/Security_Identifier

As some Microsoft administrators would know, certain SIDs are always mapped to certain accounts and the following are these mappings:

S-1-5-18
Local System, a service account that is used by the operating system.

S-1-5-19
NT Authority, Local Service

S-1-5-20
NT Authority, Network Service

S-1-5-21-2876550492-3781512850-3958252139-500
S-1-5-domain-500 - A user account for the system administrator. By default, it is the only user account that is given full control over the system.

Aside from the persistent mappings above, there were also additional additional SIDs included in the folder and these were the ones that I wanted to determine what accounts they were mapped to:

• S-1-5-21-597650934-770836382-26564730-1020
• S-1-5-21-597650934-770836382-26564730-1034
• S-1-5-21-597650934-770836382-26564730-1821
• S-1-5-21-597650934-770836382-26564730-4332
• S-1-5-21-597650934-770836382-26564730-4335

Since I had a target account that I wanted to fix, I opened up ADSIedit and opened the properties of the user account but as I quickly remembered what I always didn’t like was how the objectSid is stored:

While there’s an option of displaying it in hexadecimal, binary, etc, none of them matches the format that the SID is listed in the profiles folder:

There are many ways to convert the SID into the proper format but the easiest way I’ve found is to simply navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

… in the registry of the Windows 7 desktop.  The key above is where Windows 7 stores all of the users who have logged on and a profile created for them:

After browsing through the profile list, I found that the SID I was looking for was the following:

S-1-5-21-597650934-770836382-26564730-4332

Within this key, you can also find the SID variable that also matches the objectSid value in the object’s attribute in ADSIedit:

Now that I have identified the SID to name mapping, I fired up the master Windows 7 image, logged in with the local administrator account:

Proceeded to delete the profile:

Then double checked that the SID was no longer present in the registry:

From there, I proceeded to shutdown the master Windows 7 image, snapshotted it, and then recomposed the problematic user’s virtual desktop in View Administrator:

Once the recompose operation completed, I went ahead and browsed the virtual desktop’s D drive:

… navigated to \\ccsadmin\d$\personality\profiles:

… and then deleted the problematic user’s SID reference:

Since there was also a personality.bak folder which contained the same files, I went into that folder and deleted the SID as well:

\\ccsadmin\d$\personality.bak\profiles

With the SIDs deleted from both the personality and personality.bak folders, I proceeded to log into the virtual desktop:

To my surprise, I noticed the same message I received earlier:

You have been logged on with a temporary profile.

You cannot access your files and files created in this profile will be deleted when you log off. To fix this, log off and try logging on later. Please see the event log for details or contact your system administrator.

With that being said, what I did notice differently this time was that the TEMP profile that was created was now stored on the persistent D drive:

So I proceeded to log off of the virtual desktop, deleted the TEMP profile and performed a refresh of the virtual desktop:

I went ahead and logged back onto the virtual desktop after the refresh completed, and noticed that the profile was now successfully created on the D drive:

The process definitely appears to be a bit cumbersome but it looks like it worked.  What I think I learned from this was is:

1. Never log into the master image with an account a user will be using to log into a linked-clone spawned from it.
2. Always double check to ensure the users of your linked-clone desktops have their profiles redirected to persistent disks.

In hindsight, I don’t think #1 surprises me because I’ve always had problems Citrix’s User Profile Management application if the master image had a user’s profile stored on the C drive.  It’s unfortunate that no logs are found in the Windows or View logs that tell you what might be wrong so I hope this post will be able to help others out there who may encounter the same problem.