[Samba] How to keep local profiles when joining domain?

[Jonathan Johnson]

On Wed, 16 Jun 2004, Nash Computer Technology wrote:

> However, we are now in the final stages of deploying a
> Samba server to replace the Novell one.  The Samba
> server is configured as a Primary Domain Controller, and
> seems to be working fine.  We do not wish to use roaming
> profiles, so the profiles will be held locally on each PC.
> 
> unsure how to join the new domain, such that the existing
> profiles (eg desktop layout, applications, etc etc) are
> retained for each user.  When we simply change the PC
> properties to join the domain, we lose the users’ settings.

This method is unreasonable for more than a few users, due to the time
involved, but it has worked for me.

1. Make a note of the user's profile directory. I'll assume it is in
C:\Documents and Settings\mike

2. Log in to the PC in question as a LOCAL Administrator, other than
Mike.

3. Make a copy of Mike's profile, just in case things get screwed up
royally. It's a good idea to use ntbackup for this (if you're dealing
with XP, it can be installed from the CD) so you don't lose the ACLs.

4. Rename Mike's profile to something like C:\Documents and Settings\Mike.temp

5. Join the workstation to the domain and reboot as prompted.

6. Log into NEWDOMAIN as Mike. A new profile for Mike will be created,
hopefully it will be C:\Documents and Settings\Mike, but make a note of
whatever the path is.

7. Log out Mike and log in as the local or domain administrator again.

8. DELETE the new profile that was just created. (You did make a note
of it's exact name, didn't you? If you didn't, go back to step 6.)

9. RENAME Mike's old profile from Mike.temp to C:\Documents and
Settings\Mike (Or whatever the path created in step 6 was)

10. Change the ACLs (security descriptors) on this profile to allow
NEWDOMAIN\Mike full access to the folder and all child entries.

11. If the path of the profile that was created in step 6 DOES NOT
match the original path of the profile, your job just got a lot harder.
Skip to step 13.

12. You should now be able to log in as NEWDOMAIN\Mike and have all his
profile back. Thank your chosen diety you were able to make the new
profile use the same path as the old profile, and skip the rest of
these steps and go on to the next workstation.

13. While you're still logged in as an administrator, open up regedit.
Load the registry hive C:\Documents and Settings\(new path)\NTUSER.DAT

14. EDIT the registry, replacing all instances of the old path with the
new path. Make sure you also check for instances of 8.3 munged names.
There will be WAY TOO MANY of these; I've found that sections of the
registry can be exported to a text file with can then be
search-replaced. Maybe there's a registry tool out there that makes
this easy; I haven't found it.

15. BEFORE YOU CLOSE REGEDIT, be sure to UNLOAD the hive you loaded in
step 13. Otherwise, Mike will not be able to log on.

16. You should now be able to log in as Mike. If things are totally
screwed up, well, that's why you made a backup, right?

Yes, I've actually done this. Several times. It's only fairly easy if
you can make the "new" profile use the same path as the old profile.
That's why we renamed the old profile first. There may be a way to
temporarily use roaming profiles and the User Profiles tool in the
system properties, along with Samba tools on the UNIX end to accomplish
the same thing in a quicker, easier manner, but I haven't investigated
that.

~~Jonathan Johnson
Sutinen Consulting, Inc.
jon at sutinen.com