Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Replacing server with new. Domain name & SIDs??? 3

Status
Not open for further replies.

jferrante

MIS
Aug 6, 2003
119
US
Hello all,
I'm replacing a 5 year old SBS2003 server with a new one. The new one came factory loaded with SBS2003 R2 standard. This is only a 3 user office. (XP Pro)

This company currently uses individual POP3 email accounts. We will be using Exchange on the new one as they have purchased a static IP.

My questions are really, what happens to the XP computers if I use the same account names and internal "domain.local" nanimg that they currently have. What problems will I have or should I create a different "domain.local" address and/or change the user account information?

I have daily backups of all user computers and pst files, etc.

I am approaching this as a first time SBS server installation and plan to do everything manually.

Thanks in advance.

Jeff
 
It's still a different domain. You'll need to remove them from the current domain, and then add them to the new one. They'll get all new profiles on their machines. You can go through the hassle of copying or moving them. But I'd suggest to do a swing migration.

Pat Richard
Microsoft Exchange MVP
 
You can use the same exact names, but you should probably move each workstation from the domain into a workgroup and then from the workgroup into the new domain, after creating computer accounts on the new domain. Even if the domain name is the same as the old one. While the systems are in the workgroup, take the old server offline and bring the new server online using the same IP address. Or if the new server has a different IP, reconfigure the client DNS configuration so that they point at the new server for name resolution. If you want both server to be on the same subnet at the same time, you are going to have to, at the minimum, disable the DHCP server on the old server and create a live scope on the new one. A /release /renew will bring the clients over to the new scope.

With only three users, you are probably fine with starting fresh instead of trying to manage a swing migration, but before you do the migration, run the Files and Settings Transfer Wizard on each workstation and save the dump locally. After you've logged on to the new server with that user's account for the first time, rerun the wizard and import all their settings.

On the mail side, you have a few options. I'm assuming that you used POP accounts and then had the users store the mail on the server. If you had them storing the mail locally, you have no problems, but the following can be done if it was stored on the old server. You can use Exmerge to pull the user data out into .pst files, but there's a 2gb cap on size. You could also switch each user's mailbox settings so that they are storing their mail in a local .pst and watch them suck it all off the server.

Dave Shackelford
MCSE, CCNA, Microsoft MVP: Exchange
Shackelford Consulting
 
Pat, thanks for your opinion. I'll save the swing method for more complicated setups.

Dave, thank you, that's the information I needed. I had forgotten about moving the workstations to a workgroup to avoid problems and some of the other steps.

Jeff
 
Users tend to get mad when they lose their desktops. I'd do as Pat suggested and copy the profiles to local accounts so SBS can migrate them to the new domain.

Another alternative that gives the same result is to log on with a local user ID for the users. then log back in as Admin. Edit the registry to point the local profile to use the directory of the old domain ID.

You will find the registry settings you need under HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\UserSID\ProfileImagePath

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at
Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.
 
Mark, are you saying that the Files and Settings Transfer Wizard will not properly migrate the profile? In my use of it, I haven't seen users "losing their desktop" since it migrates over most of the HKCU and the Desktop folder among dozens of other things.


I'd like clarification, since I'm always interested in a better way, if it exists.

Dave Shackelford
MCSE, CCNA, Microsoft MVP: Exchange
Shackelford Consulting
 
I've seen problems with Files and Settings Transfer Wizard not moving application data. In addition to that, I can change the registry key in a few seconds and don't have to wait for the wizard to complete and then don't have the added step of re-importing data.

The Migration Wizard is still a great tool for saving data. When you have a larger SBS implementation of 50-75 users to migrate I like to look for the fastest solution, especially since the conversions are typically done on fixed cost.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at
Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.
 
Ok. For me the plus-side of the FSTW is that I can easily tell the users to run it themselves on the day of the migration so that when I'm ready to get to work, I only have to verify it's existence, and I can also back it up the profile dump and give management the opportunity to have users swap workstations if necessary.

I see the benefit of the reg entry, especially when you've inadvertently run the FSTW on a user who kept 8gb of .mp3s in their My Music directory...

Dave Shackelford
MCSE, CCNA, Microsoft MVP: Exchange
Shackelford Consulting
 
Exactly Dave. We had a user with 38GB of MP3 files once. FSTW is likely to bomb because of insufficient disk space.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at
Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.
 
Dave & Mark,

Thanks for the education today. Some things I knew, others I had forgotten, and still others I never thought of. Please keep it up.

This could be exam 70-282.99

Jeff
 
I've done this at least 4-5 times, and I just did it last week on a domain w/ 6 machines. Hands down, adjusting the registry key is SOOOOO much easier:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\UserSID\ProfileImagePath

There is a bit of a rhythm to it, however.

1. Remove client PC from old domain (i.e. join workgroup). Reboot.
2. Join PC to new domain either manually or through the Connect Computer wizard ( must create PC accounts on server first).
3. Make sure the user is a member of the local admins group, then login as the user. This creates a new profile for that user. Note the new profile location (usually c:\documents and settings\user.newdomain).
4. Reboot (you may be able to get away w/ a logoff, but I always reboot).
5. Login as an administrative user.
6. Run regedit. Locate the key mentioned above and change ProfileImagePath to the user's old profile from the old domain name.
7. IMPORTANT - now you need to give the user permission to access their old registry.
8. Select HKLM.
9. Select File>Load Hive.
10. Locate the user's old docs and settings folder and then the file ntuser.dat.
11. You'll be prompted to assign it a key name, call it anything you want. For the sake of this, we'll call it 'old_profile'.
12. 'old_profile' now shows up under HKLM. Right click on it and select permissions.
13. Add the user's account to the list and make sure they have full control.
14. IMPORTANT - Unload this hive now by selecting 'old_profile' and then File>Unload Hive. I forgot to do this once, it cost me a few hours to figure out.
15. That should do it. Exit the registry and reboot (you may be able to get away w/ a logoff, but I usually reboot).
16. Login as the user. It should now bring up their old profile from the old profile location under docs and settings. In fact, you should be able to delete the folder c:\docs and settings\user.newdomain without any issue to avoid future confusion.

I've managed to use this method on the last few domain upgrades I've done, one of which was just last week.

Hope this helps!
 
Oh, one thing to note. I did notice last week that with this method Outlook did not retain the POP3 passwords and the users had to enter them in again, but if you're using Exchange, this isn't an issue.
 
A few comments to your list Lifeguard2

You could really simplify this.

1. Locate the users current profile path. (I have a script that reports it to me).
2. Create a new Admin account (just in case it is needed)
3. Move the PC to a workgroup. Do not reboot.
4. Run The Connect Computer will MAKE the use a local Admin.
The system will reboot a few times on its own.
5. Log on as the user in the new domain to create a local profile.
6. Log off.
7. Log on as domain admin
8. Edit the registry key for the new users profile as I specified above.
9. Log out and back in as the user. Profile is preserved.

soapbox.gif
[red]Side note: I just wrote a script that will do all the profile stuff before you even disjoin from the domain. This will be included in the next release of my Admin Script Pack and I expect will save me many hours of work in the future.[/red]

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at
Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.
 
markdmac, in my experience, I've had the most success and fewest amount of issues when I load the old user profile's registry hive and specifically grant the new domain user permission to it.
 
With my script I actually build a new registry structure, so that is not needed.

I hope you find this post helpful.

Regards,

Mark

Check out my scripting solutions at
Work SMARTER not HARDER. The Spider's Parlor's Admin Script Pack is a collection of Administrative scripts designed to make IT Administration easier! Save time, get more work done, get the Admin Script Pack.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top