Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a windows 7 SOE for my school which involves two partitions - C: for system (windows) and programs, and D: for Data. The "Users" folder is kept on D:. All users are in Active Directory.

I would like to be able to re-image drive C: when there is a problem, and have the user be able to pick up where they left off with the data on drive D:. However, when I tried re-imaging just drive C:, when I logged in for the first time, it created a new user folder in drive D: - I still had access to the old one, but it wasn't the default location for my files (the old one was named 'myusername' while the newly created one was named 'myusername.DOMAIN')

Any ideas how I can 're-link' the account to the pre-existing user drive? Registry entry? Sysprep command?

share|improve this question

2 Answers 2

up vote 4 down vote accepted
+50

The logic that you're seeing is a designed behavior on Microsoft's part. The HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVerison\ProfileList subkey for the user's SID doesn't exist on the freshly re-imaged machine and when Windows "sees" the existing "D:\Users\username" folder it assumes this folder contains existing data and creates a new folder instead.

To my knowledge the specific details of the "...\ProfileList" subkeys are not publicly documented. Conceivably you could write a Startup Script to "pre-create" these entries based on the contents of the "D:\Users..." folder but, frankly, I think you'll be fighting a losing battle to get it working right. This may be your only option.

You can just logon as the user, allow the new folder to be created, logoff, logon temporarily as another user to modify the "...\ProfileList" subkey for the initial user, and then clean up the then-unused "...DOMAIN" user profile folder that Windows created on the initial logon. It's a tedious and manual process but it would work.

Storing your users' data and profiles on server computers would get around this whole mess but I assume you're not doing that already for some reason.

share|improve this answer
    
I've tried some manual manipulation of ProfileList in the past and it didn't go well! The specific problem here is that the machine has a new SID and so the user's SID has changed. You'd need to pre-populate ProfileList with entries using the new SID and pointing at the old profile locations, and also update the permissions on the profile files themselves to match the new user. Unfortunately this wasn't sufficient in our case because other apps caused problems, but it may work for you. –  Adam Feb 20 '13 at 10:03
    
The machine SID is irrelevant and the user SIDs are consistent because the OP said they're Active Directory accounts. The NTFS permissions and ACL in the users' registry hives will be fine, too. I would discourage manual manipulation of these "undocumented" data structures but it will work. At least until Microsoft changes how things work... –  Evan Anderson Feb 20 '13 at 12:48
    
Ah yes, I misread things. Much more feasible to fix things then (although still probably not a great idea) –  Adam Feb 20 '13 at 14:12
    
I've just tested exporting that registry key prior to re-imaging, then importing it back in after re-imaging, and it appears to work. I also checked that the registry entry was identical after a re-image, and it seems to be. Now to automate the process... –  askvictor Feb 21 '13 at 0:12
    
I was thinking about a completely b0rked Windows install. Suggesting you export that data and import it after imaging didn't occur to me! I do a goodly amount of imaging using WinPE and adding code to mount the machine's old SOFTWARE hive, export data, and import it after imaging would be a cinch. I already do something similar to preserve computer names across imaging sessions. I can't say I have need for what you do re:profiles, but this is definitely a neat idea. –  Evan Anderson Feb 21 '13 at 7:38

Have you thought about leveraging the User State Migration Tool ("USMT")? It's designed for this type of scenario if I'm reading the OP right.

This will bring over profile data and bind it specifically to the AD user within the machines registry so when that user logs in, he/she will use the same profile.

Is this what you're asking?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.