1

Due to an acquisition of several smaller organizations we now have to migrate users and their machines (Windows 2000 & XP Pro) from their old domains (NT & 2000) to a 2003 domain. What are best practices? How best to ensure that locally installed apps do not break?

Are there good tools (free and non-free) available to help? We're looking at about 2500 users and machines.

Here's a twist: all users have had their email (Exchange 2003) set up on their current setup so they have user accounts on the new domain.

5 Answers 5

2

IME, the server side is relatively easy. Create new computer and user accounts and set the password to a known value, forcing change on next logon.

The real PITA is the local profile - though we sometimes like to pretend otherwise, users are really attached to their profiles. Just logging in as another user doesn't cut it.

I like ForensiT User Profile Wizard for this. It'll resync the NTFS and Registry permissions to the new SID, and point the new account to the old profile. When users login with their new user account, they're profile will just continue to work. It's scriptable, and can also join a new domain as part of the process.

Since Outlook is already setup under their existing profile, using the same profile should work fine for that.

The only possible oddity is having a user named mbrackett (eg., because of policies dictation first initial, last name) having a %USERPROFILE% of C:\Users\mark (eg., because that was the name of the old account).

2

Having lived through a small domain migration, it's doable. But...expect pain. And having Exchange in the mix can mean a world of pain, if you don't have some kind of plan to mitigate the changeover.

The issue isn't so much that applications will break, but rather, how many things will break due to account privs missing on files, etc. To give you an idea of the effort involved, our setup was a simple one - file services, print services, email handled by a linux box. It took four people working 38 hours without breaks to get everything moved and running, because the user accounts had to be redone, meaning new SIDs along the way. New SIDs = nothing had the correct security settings. We moved from a flat NT4-style domain model to one that had just two tiers.

Exchange's use of existing AD accounts can both help and hinder you. Because those accounts are going away, there won't be a way for Exchange to figure out who gets what mailbox (those SIDs are just gone now). So, it's important to have a full backup of the data store. Unless you have someone well versed at running Exhcange, you might be better off using a fresh installation and restoring your mailboxes from backup. Getting the restore to recognize which account has what mailbox will be key. Plan on several practice runs.

1

Microsoft's free Windows User State Migration Tool might be of assistance here. I've used it on a small scale, converting local user accounts to domain accounts.

I ran into a few small glitches, but almost everything came across intact.

1

Not free - I have had great success with the Quest tool with exactly that issue -

0

Have a look at Microsoft's ADMT 3.x toolset. It lets you transition users (with passwords) as well as computers, profile shares and the works. Its quite nifty. There is a quite heavy (as usual) doc that accompanies it, but it all boils down to a pretty straightforward migration, in my opinion. If you google admt you'll get a bunch of good blog post with the basics.

-Trond

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .