Server/Domain-Controller Swap Help (Windows Server 2003 R2)

[xzelence]

I currently have a single domain-controller using active-directory, providing login services, file-shares, and print services to about 60+ users within our domain. I bought a new server to replace the current one, and plan to make the current one a backup domain-controller (as in, will no longer hold the FSMO roles or have the same IP). I've been trying to (on a dummy network and with two dummy servers) trying to simulate the transfer but I've been running into some hitches and I have yet to have a successful or smooth transition.

My strategy was to first set up the new server as another domain-controller, along-side the current server--this way the current active-directory is replicated onto the new server. Then, using the DFS (Distributed File System) Management snap-in, I created a file-replication group--this replicated all the shares and data on the current server to the new server. Once the new server "mirrors" the current server (in almost every way except their IP addresses and names), I would prepare for the switch, first by transferring all the FSMO roles from the current server to the new server as well as creating a global catalog (GC) on the new server.

Here's where things never go according to planned: at this point my strategy is to demote the current domain-controller to no longer be a domain-controller, using DCPROMO. Once the new server assumes the sole responsibility for the domain, then I remove any of the old server's objects from Active-Directory. After this, I rename the new server with the old server's name, and change it's IP address to that of the old server. This way, once the new server is online with the new name and IP, the clients will be unaffected (in theory): they won't notice any changes and they won't have to do anything (e.g., change their primary DNS server's IP address).

The problems I have had so far range from the servers not recognizing or getting a response from each other when I go to do the DCPROMO, to not being able to change the name of the new server to that of the old one because it thinks it still is in the Active-Directory and would cause a conflict.

I basically want to make the transfer as painless for the clients as possible (meaning little downtime and little, or no changes on the clients part), but perhaps the most important thing is preserving/replicating the current data/file-shares and active-directory onto the new server. I know one way of replacing the current server is to do it by hand, building up--while off the network--the new server as an exact mirror of the current server, with the same name and IP, and copying by hand the AD and all the data. The data is the hardest part because there's over 200GB of files, and they need to be as up to date as possible on the new server, and I don't want to have a huge downtime because I need to copy the data over and prevent the clients from using their shares.

I'm going to try the simulation again, but this time just go straight to the DCPROMO once I have the AD and file shares replicated to the new server, since DCPROMO should automatically transfer the FSMO and GC over to the new one. Hopefully it works.

If any of you have had experience with something like this (swapping out a server) or could give me some advice, tell me where I went wrong, what I'm forgetting, or give me a strategy/suggestion, I'd greatly appreciate it. Thanks!

[smakkythecamel]

Some ideas just off the top of my head.

Do clients access the server via the IP address or hostname? Is it just for fileshares and printers?

in DHCP options add a DNS entry for secondary server so that these will roll out to clients. That way when A goes offline, B will still get DNS queries.
create the new server (B) with a different name and different IP address to existing server (A)
dcpromo it as a secondary domain controller, let everything replicate.
transfer the 5 AD roles to B
copy all data via DFS or whatever method you chose.
demote A, give B time to adjust, then rename A to C and promote C again, so you have a secondary domain controller.
add DNS Alias entry on server B, so there is an alias with the same name as A, so clients can still access fileshare via \\A\sharename
(in future make a DNS Alias for your fileserver called 'fileserver' or something similar, that way you can point it to whatever server you want)

Obviously this needs refining, but it's off the top of my head. Hopefully gives you another option to look at.

Renaming a DC can be tricky, and I would avoid it if it is the only DC.

Also, there's a print migrator tool on the MS site somewhere that works quite well.

[Xylker]

...since DCPROMO should automatically transfer the FSMO and GC over to the new one. Hopefully it works.

It is not clear to me from your writing that the two servers are fully setup prior to the demotion. A little documentation and what I think you are expecting to occur...
http://support.microsoft.com/kb/324801
http://support.microsoft.com/kb/223346

http://www.petri.co.il/forums/showthread.php?t=16631

"NOTE Actually, there is one case where AD automatically moves the FSMO role: when you use DCPROMO to demote a domain controller that holds one or more FSMO roles into a member server. DCPROMO finds another appropriate domain controller and moves the FSMO roles to that DC. In that case, decommisioning the Pentium 200 would have resulted in no problems. So perhaps the best advice here is, 'When you want to get rid of a domain controller, always use DCPROMO to decommission it before FDISKing it.'" From Mastering Windows Server 2003 by Mark Minasi.

In an ideal world, I would restore the backup of the running server to one of the two systems on the test network, dcpromo the other one, make the file transfers, etc, etc. You even get some practice with disaster recovery that way...

[zgirl]

I've always done it with without changing the name. I find it easier. But I assign drive mappings and printer via login scripts. I simply setup robocopy jobs using the /mir option. So I install new server, DCPROMO it up, setup my copy jobs, let that work for a few days (week), pick a time to re point all the user and script to the new server, shut off sharing on the old. Troubleshoot the next business day(usually nothing to do, but there is always someone who had something persistent). Let the two server run for a while (always helps to have the old location around to recover anything that got missed, this happens more in much larger environments.)

Then a week or so later take the old server downwith DCPROMO, the process will move all the roles. Done.

I've done this more times then I can count and I've always had little or no issues. Leave everyone pointing at the new server don't screw with changing names and IPs. Way too much headache.

[xzelence]

Thanks all.

Z-man, your plan seems to be the easiest, but I have a few questions...

Our domain is actually a sub-domain within a larger domain, and all our IP addresses are assigned, meaning our servers don't do DHCP. That being said, all our clients have their primary DNS server set to our current server (xxx.xxx.xxx.101, for example). The new server is going to use the IP address xxx.xxx.xxx.102. So, supposing I take your route Z-man, once I take the old server down with DCPROMO, will clients still be able to access the domain/the new server without having to change everyone's Primary DNSs?

Also, the thing about the drive mappings will be tricky. Most of our users have 3-4 shares mapped on their computers (I don't know if that roams with the account--we don't have any roaming profiles). I haven't done much with login scripts, but I know that in AD there's a default drive-mapping option for each account, but it's only for 1 (one) share. Is there (1) some easy way of finding out what shares/drives all the accounts have mapped on their computers, (2) some easy way of changing all the pointers for those mapped drives, and/or (3) an easy way of setting up/show me how to set up login scripts for each account to preserve their mappings?

Thanks.

[zgirl]

and all our IP addresses are assigned, meaning our servers don't do DHCP.

Am I understanding this correctly? All your IP address are statically set? Seriously? Doesn't matter if you are assigned a range from up stream, you should still be using DHCP to handout IP address and associated settings. It make it easier to change this during a migration such as this. You could hand out both IPs for a while. Using DHCP you can change everyone's primary DNS address from your desk with a click of the mouse.

will clients still be able to access the domain/the new server without having to change everyone's Primary DNSs?

No if you the intention is to make a new server the primary DNS then the clients primary DNS setting will have to be changed at some point. DHCP could have done this for you, but I don't think it is in your environment.

(1) some easy way of finding out what shares/drives all the accounts have mapped on their computers,

Do you know any type of scripting language? This can easily be done with vbscript and I am sure others. Google vbscript and 'enumerate drive mappings', plenty of samples.

(2) some easy way of changing all the pointers for those mapped drives, and/or (3) an easy way of setting up/show me how to set up login scripts for each account to preserve their mappings?

login.bat
net use <driveletter> /detele <---repeat for H: through Z: if you want to clear out any old mappings.
net use <driveletter> \\<servername\<sharename>
or
net use <driveletter> \\<servername\<sharename>\subfolder(s)

Extremely simple. I personally use vbscripts to make a modular login script that I can use for that among other things. At least I did in the 2k and XP world. No one of my clients have rolled out vista yet so I can't talk about that side. but I cannot imaging it not working.

[xzelence]

Yeah, all our IPs are static and are assigned from another, upper department. Whether they use DHCP to assign our addresses, I don't know, but I have to request an IP from them anytime I want to get a PC connected to the internet or on our network.

Would enabling DHCP on our server to facilitate changing the Primary DNSs interfere with everyone's statically set IPs in any way?
And, even if I couldn't, would I just be able to change the IP on the new server to the old server once I DCPROMO the old server down?

Regarding the scripts, some of the accounts we have already have a login scripts (probably from previous IT) but the path just says the "<name>.vbs". Where exactly is this script located? And, if I make my own scripts for drive mappings, where should I put them, and would I write the entire path in the AD setting?

[dolemitecomputers]

I would highly recommend that you manually move all the FSMO roles over before running DC promo on the old server. If they are having problems communicating then more than likely you have a DNS issue. I would install the support tools and run dcdiag as well as netdiag and see what errors are occuring. It is best to let make sure sites and services is setup correctly, let replication happen for some time then move the roles over and demote the old server.

[Xylker]

I would highly recommend that you manually move all the FSMO roles over before running DC promo on the old server.... It is best to let make sure sites and services is setup correctly, let replication happen for some time then move the roles over and demote the old server.

Er, what z-man said? (I know, not quite)

Back to the original question...why are YOU doing this? Just to be clear ahead of time, I am not questioning your competence. However, if the network is SO controlled and you aren't even sure if DHCP is in use, the why on Earth are you being tasked with this mission? My feeling, from supporting people who get stuck in the middle, is that you need more info/support from your "higher headquarters" if you are going to successfully pull this off. Anyway, that said, kudos for asking questions here before you are committed to an irreversible course.

Slightly OT, I had a case recently where one of America's largest retailers allocated 2 hrs for migration of an Exchange server physically located in Puerto Rico.... How's that for bad planning?

[zgirl]

What Xylker said. At this point in the game is seems you are taking on more then you can handle. No offense. Honestly there is just to much information to describe here and most of it any decent admin should know. Not to mention I am not familiar with your environment. Honestly it is at this point I come onsite and start charging you. Not to mention it would be fast and less painful for me to do it then to explain it to you.

Also anyone managing a network with static addressing should be dragged out into the street and shot. Seriously. DHCP saves massive amounts of time and energy not to mention simplifies everything. Hell I even use it to hand out static IPs to devices that need them. (you simply assign IP to the devices MAC address. So it always has the same one). Even if address are be managed upstream they should have given you a subnet of addresses that could be handled via DHCP. Really there is no excuse for anything else and they are idiots if they tell you differently.

Really, this should be a matter of installing a new DC, letting data replicate and/or robocopy it over. Adjust DHCP setting to allow clients to start connecting to the new server. Move roles, (DCPROMO will do this for you when you run it to demote the old box, never had an issue myself in a single server environment), adjust scripts to reflect changes. (really, mapping drives and printer should always be handled by scripts to since it makes life easier when these types of things happen. Make changes in 1 location not 100), cut over data, Let things run, remove old server when ready.

I'm sorry if that isn't going to be much help to you now.

[Buub]

In AD each computer is uniquelly identified by a GUID. Changing the name and IP will NOT make it the same machine in AD. My suggestion would be to stop trying to outsmart AD and just be more deliberate.

Introduce your new DC with the formula you described, move the roles and GC, give the hosts a day or three to recognize the changes. If you must remove the old DC, then demote it and do so, but don't then go start changing the running DCs name or IP. It's up and running -- leave it alone.

[Scrotos]

Well besides the spambot necro'ing the thread, now I'm curious as to how this actually turned out.