Shared User Profiles – Alternative to Migration
by dwarfsoft on Mar.12, 2010, under Novell, Scripting, Tweet, Work
Well, I have been very slack in that I haven’t updated with my Group Policy investigations or the eDirectory VBScript classes I was working on, but what I have been involved in recently is working on Migrating Workstations from Novell eDirectory to Active Directory.
In this process I have come across an array of options in migrating accounts from a Local User account to Domain User account and transferring the profiles across to keep the user “look and feel” that they are accustomed to.
One problem: In this scenario it makes for a very manual rollback strategy, no matter how much scripting and automation is involved in the migration process. This boils down to Novells implementation of “Dynamic Local User” which effectively creates a Local User Account that is not really bound to a User Account in eDirectory for Authentication or mapping purposes (which you can see if you look at the account SIDs).
So, how can you Migrate a local profile to a Domain User account while still maintaining a seamless rollback option (without using Roaming Profiles… This is out of the question)? The solution I have worked on is what I am terming “pre-staging” or “seeding” the Domain User Profile.
- Enumerate all Local Enabled Users (except for “Administrator”)
- Get the SID for that User (and the SDDL/String SID)
- Read the Profile Path for that User from Registry
- Set an ACL on that folder for <Domain>\<UserName> (we have the UserName being replicated between eDirectory and Active Directory
- Mount the existing users NTUser.dat into HKU\<UserName>
- Set ACL on HKU\<UserName> and all subkeys for <Domain>\<UserName>
- Set ACL on HKU\<LocalUserSID> and all subkeys for <Domain>\<UserName> (just in case the user is actually logged in)
- Dismount HKU\<UserName>
- Mount the User Class hive (UsrClass.dat) into HKU\<UserName>_Classes
- Set ACL on HKU\<UserName>_Classes and all subkeys for <Domain>\<UserName>
- Set ACL on HKU\<LocalUserSID>_Classes and all subkeys for <Domain>\<UserName> (just in case the user is actually logged in)
- Dismount HKU\<UserName>_Classes
- Read the ACL on the Profile Folder (set Earlier) for <Domain>\<UserName> to get the Domain User SID
- Convert the Domain User SID to an SDDL/String SID
- Pre-stage/Seed the Domain User Profile by creating a new Registry key in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\<DomainUserSDDL>
- Write in a few choice keys, the two most important being ProfileImagePath (String) and Sid (Binary). (The others I seeded were the DWords State and Flags, which were set to 0, and CentralProfile, which was an empty string).
Once the eDirectory user is no longer a member of a DLU enabled User Profile Package, they will be forced to log on through the Active Directory Domain (yes, we are still logging on through the Novell Client). The Profile used for the Domain User will be the same as that used by the Local user. The added benefit is that our rollback strategy becomes “Add user to a DLU enabled User Policy Package” and gets them to log back into their original profile. To safely secure a situation where there is a catastrophic failure of the profile (loss) a backup of the profile can also be done at the seeding stage (just check %userdomain% for equality with %computername% to see if they are logging on with a Local account or a Domain Account).
This has had only minor testing at this stage, but as no paths have changed and there appears to be no problem with the Domain User using the existing Profile I believe this is a reasonably comprehensive solution. This, I must stress, is not a recommended way to deal with migrating users, but it is a tricky little feature that can be abused as I have just demonstrated.
Code (or VBScript) will follow soon
Cheers, Chris.
[…] dwarfsoft on Mar.15, 2010, under Novell, Scripting, Tweet, Work Print This Post As promised, here are the scripts required for the Pre-staging of Domain User Profiles on the local machine. […]
I’m doing something very similar but instead of setting the folder and registry ACLs manually, I will be using moveuser.exe from the Windows Server 2003 Resource Kit. The /k option should leave the local user in place for now to provide an easy rollback option. We will remove the local user later, once we are sure everything is working.
I started scripting the profile detection process, went to the Internet to look something up, and stumbled across your StageAllUsers function – exactly what I was working on! Thanks!
Well, the moveuser approach was one that was assessed, and it didn’t fit the same way. Profile migration had to happen when a user was logged off, and it also had to preserve the local user login credentials so that if connection to the server was lost before the user logged in then they could still log in. moveuser /k did not keep the user in a functional state, although it did keep the account. The profile was completely moved and the local user was left with nothing. In order to roll back you needed to run moveuser again to send the profile back to the local account. There were also some other issues that I fail to remember now.
The difference between the approaches is that mine does not remove or modify the original account, but simply adds a new one to match the migration. In order to have less impact on end users it makes implementation and rollback so much easier. In less complex environments I know that moveuser, or the Microsoft User State Migration Tools, would have done the trick nicely. I was actually fairly annoyed that there was none available to do the work for me as I needed it done. I spent weeks testing many different tools and switches trying to get a combination that would work for seamless migration.
I hope your migration goes smoothly and I am glad the Profile detection script is of use to somebody.
Cheers, Chris.