New user profile is created after recompose

[Andy79201110141]

After recomposing a pool of desktops users lose their settings. So we compared the bad pool to another pool that doesn't have the issues and noticed two things. 1)After the the user log back in the VM, Windows chooses not to use the existing profile, so it creates a new user profile for the user, 2) the Personality folders were missing. I don't know if those two things are related but they are consistent with the pools that have the issue.

Anyone else seen this?

[kgsivan]

Your observations are valid. But this should not happen if you have created a linked clone pool, with user data redirected to persistent disks.

For floating pools (or dedicated pool without user data redirection ) this problem is expected.

Please confirm your setup

[Andy79201110141]

Yes,  I'm using persistent pools. What are the "personality" and "personality.bak" folders suppossed to do? Is there any group policy that would cause  the user profile to be duplicated or cause a conflict with View 45. or MS Vista?

[mittim12]

When we first started using persistent disk we had an issue where after a recompose a new profile was generated.  The old one was still there it was as if the OS didn't want to use it.   It turned out that my profile was still listed under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVerison\ProfileList on the template.   This ended up being my issue.   

[kgsivan]

I too have doubt on the same (profiel list entry). Please compare the settings with a vanilla OS

[Andy79201110141]

We didn't find much information about the Personality folders created per user profile, but we figured out that those folders contain very similar information as the register entries for the user profile. It seems to me that View checks into that folder when the users logs in. If ther personality folder is not there, View assumes that the users is logging in for the first time so it creates  a new profile instead of using the existing profile contained in the persistan disk before recomposing the pool. Our solution to the issue was to recreate the master VM and install the View agent again. Reinstalling the agent in the problem master wasn't just enough.