Ghost Solution Suite

The problem:

We are running into an issue with Windows 7 where we restore a captured profile, of a user who previously had administrative rights, to a machine where they will no longer have admin rights. The problem is that the user can no longer access the C: drive, programs, etc. It appears that the profile is corrupt; however, if we add that user account back into the local admins group, everything returns to normal.

Testing:

We restored user profiles to a fresh test machine with limited admin access and then logged in as the user. The problem persists and the users cannot access things properly.

We restored user profiles to a test machine where the user has logged into the machine BEFORE the profile restore (without admin rights) and after the restore, the user is able to function as a non-admin just fine.

Question:

Is some reg setting being transferred with the GSS captured user profile that is clashing with it's new restricted rights?
What could be the issue here?

Is this a sysprepped image?  Are you using roaming profiles?

Yes, this is a sysprepped image. We are not using roaming profiles.

When you sysprep a machine, many of the security identifiers are removed, as is the licensing information, for example. Are you working with local or domain accounts by the way?

Since permissions are based on security identifiers, if you are using domain based accounts and hoping to preserve the permissions, then I think this is where the problem lies.

We are using domain accounts. We do not; however, expect security permissions to remain intact. We have many users who's domain user accounts were members of the local administrators group on their workstation. Upon reimaging their workstation, we decided to transition them to standard accounts, not administrators. This is where the problem was identified.

These users can login to our domain workstations as standard users (if their profile has not been restored to said pc using GSS), and function properly in this environment. It is only when a profile (captured with local admin rights) is restored to a freshly re-imaged machine, BEFORE the user logs in for the first time, that the profile becomes unusable.

Any thoughts?

Strip the captured profile of any NTUSER*.* files and see if that resolves the issue. 

I looked in the captured profile using both the User Migration Package Explorer and WinRar, and I don't find any NTUSER files. I see that the profile migration is capturing REG settings in HKCU and HKLM, would those be the culprit? There are quite a few for settings of different things...

The user registry is contained in the NTUSER.DAT file (which is a hidden file), so it is perfectly possible for user security information to be captured both in HKCU and in HKLM.

Without seeing the REG files, it would be difficult to determine what content may be holding security information. For what it's worth, security identifiers (SIDS) are basically GUIDs.

The ntuser.dat file is not included in the USMP as best I can tell. I extracted all contents using WinRar and showed hidden files.

Is there a way to view all reg settings from the USMP?

>Is there a way to view all reg settings from the USMP?

Frankly, I'm a great believer in not migrating user profile content due to the many issues it creates,  consequently I cannot advise you on what the USMP can do as I've never used it. Hopefully another forum member may have some salient advice to offer in this respect.

I wanted to update this post with some further troubleshooting information.

We decided that after restoring a user profile and experiencing the problems listed above, we would follow the microsoft recommended steps to recreate a corrupt profile. Copying folders and files from the corrupt user profile folder to the newly created profile folder yielded some promising results.
I discovered that everything was fine until I copied the file "usrclass.dat" located in "C:\users\user_name\appdata\local\microsoft\windows\"

This file is apparently a registry hive, so I loaded the hive under an administrator account into the registry and checked permissions. The hive had "administrators" listed as having access, but not the specific user account that I was having problems with - which would explain why the user account would function correctly with administrator priveleges and not without. I granted access to the specific user and everything appears to be functioning properly.

I will continue to do some production testing, but it appears that this may be the solution.