windows 2000 domain rebuilt, how to keep local user profiles?

[Kevin Levie]

At work, I've got a problem that I've been stuck with for almost an
entire day, but I really can't figure out what's going on.

We used to have a Windows 2003 domain controller and a Windows 2000
fileserver running. As the Windows 2003 machine is going to have some
other task, the Windows 2000 machine has become domain controller.
Since the AD schema at the 2003 machine was in 2003 native mode, we
had to rebuild it at the 2000 machine and get all 40 workstations to
rejoin the new domain. Not a nice task, but not too big of a problem
either.

All these workstations contain one or more local user profiles (which
keep some settings, an Outlook PST file, and those sorts of things). I
can't copy the profiles using the 'Copy to' function in the System
dialog anymore, because I demoted the old domain controller since (I
know, quite stupid indeed).

I tried connecting these existing local user profiles with 'new'
domain users (who obviously have new SIDs):
* I tried copying the entire profile folder contents to the new
profile folder
* I tried copying the entire profile folder contents to the new
profile folder, except for the user part of the registry (ntuser.dat),
and copied the latter using regedt2 (after I read this article in
another microsoft newsgroup -
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=Pf#ThC4iCHA.212@cpmsftngxa06)
* I tried logging on to a workstation as the domain users first, then
changing the profile path (ProfileImagePath) for the user SID in
question in HKLM\Software\MS\Windows NT\CurrentVersion\ProfileList

The first two options hardly work at all. The latter works fine... if
the user is a local administrator. If he's not, the user can still
logon, but can hardly do anything afterwards. Outlook won't run,
saying that mapi32.dll can't be found (though it works fine when
logged on as Administrator), Outlook Express completely lost its
identities while they're still in their folder, and various other
applications refuse to run.

Of course I checked all file permissions. I even tried giving users
all permissions and ownership for the old and the new local profile
directory using the subinacl tool from the resource kit. The Domain
Users group has been mapped to the local User group (as it should be),
and should therefore be able to read programs and dlls. So at the end
of the day I don't have the faintest idea how to solve this problem -
how can it be that someone with the same permissions at the new domain
as at the old one, suddenly can't do everything he used to be able to
anymore?

Our users are now working using an empty, new profile (logging on to
the domain and using network shares is still possible; apparently the
problem is really at the workstations), but I really want to restore
these local user profiles as quickly as possible. Is there something
I've missed? Or is there another way to link these local profiles to
users, even if the user that used to be the profile's owner doesn't
exist anymore?

Thanks a lot in advance for your help.

Yours sincerely,
Kevin Levie

 

[Kevin Levie]

At work, I've got a problem that I've been stuck with for almost an
entire day, but I really can't figure out what's going on. (...)

Unfortunately, no-one posted a possible sultion for my problem. Might
me my bad for posting to the wrong group, or something. Anyway, I'll
post the solution I found myself here for future reference by others
who have weird permission and conversion problems like I had. Or
rather:

---
** How do I link an existing local user profile with a new domain
user, avoiding possible permission problems if I already demoted my
old domain? **

# Log in as the domain user whose profile you want to copy, so that a
new local profile is being created. Check what the old and new local
profile paths are (e.g. username.DOMAIN and username.DOMAIN.000). Then
log out and log in as domain administrator.

# Look for the new profile's key in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current
Version\Profile List (you know that from the ProfileImagePath option
that shows the profile path, as the option's name suggests). Change
the ProfileImagePath in this key to the old profile's path. Save the
SID that belongs to this profile (which is identical to the key name)
to the clipboard by clicking your right mouse button and selecting
Copy Key Name.

# Make sure you have the Microsoft tool subinacl at hand (it's got an
msi installation, but once extracted you can use subinacl.exe
separately without any problems). This tool is very useful for setting
ownership and permissions on directories recursively.
Use the following commands to correct the permissions for the old user
profile:

subinacl /subdirectories "c:\documents and
settings\username.DOMAIN\*" /setowner=DOMAIN\username
subinacl /subdirectories "c:\documents and
settings\username.DOMAIN\*" /grant=DOMAIN\username=F

# Start regedt32 (which differs quite a lot from regedit in Windows
2000, though you can simply use regedit in Windows XP). Click on
HKEY_USERS and then click File -> Load hive. Browse for the file
oldprofilepath\ntuser.dat and load it with the SID as the keyname.
(Remember, you just saved the SID on the clipboard - the only thing
you have to do after you pasted it is chopping of the first part, so
that only S-1-5-etc is left)

# Select the key and click Security -> Permissions... Give Full
Control for this key to Everyone (don't forget clicking advanced and
selecting 'Reset permissions on all child objects'). This does not
imply a security risk - at least on my systems the permissions were
automatically set correctly when the user logged on next time.

The steps regarding ntuser.dat aren't necessary if the user in
question is a local administrator. If he's not though, he'll have
insufficient rights to access his old user registry (ntuser.dat): only
his old domain user account has access to that file. Therefore, a user
will not be able to log in or will experience difficulties using
applications such as Outlook (Express). Apparently, registry
permissions are in no way related to file permissions for ntuser.dat
(which I find slightly illogical, though I suppose it is by design).
---

As an alternative, you can also try to avoid having to go through all
these steps by making sure you never end up with a f**cked up
situation like I described above ;-)

Cheers,
Kevin Levie

 

[Dan]

Kevin,

Doubt you'll come back and read this....i've read it
about 8 hours too late haha

Same issue, not as bad. Installed new server manually
creating the same AD, DNS, DHCP etc config. Stupid me
didn't think that all the systems would see it as a "new"
domain and "new" users (even though same name) so
presented the same issue you had.

I gave up in the end and hooked backup the old server
haha

Im gonna attack it tommorrow differently. Im gonna do a
complete backup of the old server and restore on the new
and hope it works.....seems perhaps the quickest way.
There is the option of setting up as a Backup DC and then
transferring roles etc but i think this could be just as
messy.?

 

[Kevin Levie]

Hi Dan,

Same issue, not as bad. Installed new server manually
creating the same AD, DNS, DHCP etc config. Stupid me
didn't think that all the systems would see it as a "new"
domain and "new" users (even though same name) so
presented the same issue you had.

The weird thing at my place was that though there were no computer
accounts yet in the 'new' domain, the clients connected correctly and
used their old profile initially. So I first thought I *could*
actually fool the client PCs this way. It was not until next morning
that I found out about the permission problems for the old user
profiles.

Seems like the only option for this situation is correcting it on all
machines in the domain... and that's what I spent the entire Friday
night doing

There is the option of setting up as a Backup DC and then
transferring roles etc but i think this could be just as
messy.?

That's probably the nicest way to do it - you'll be sure that the
entire schema is being copied. If you want to replace a DC with a new
one that runs the same OS, that'd be the way I'd recommend.
For me, that wasn't an option though - as I wrote in my first post,
the original DC was a Windows 2003 machine with a native mode schema,
so I couldn't downgrade it to Windows 2000 using a third machine.

good luck with your conversion,
Kevin