Link to home
Get AccessLog in
Avatar of my51chevy

asked on

Fall back strategy on new Domain Controller deployment with same name/IP

Hello Experts-
I'm asking for a sanity check.
Simple environment:
SERVER1 - Windows 2003 Std Ed,primary file/print, FTP services, secondary DNS
SERVER2 - Windows 2003 Ent Ed, SQL 2000, holds all FSMO roles, primary DNS
Domain functional level: W2K Native, Forest functional level: W2K
All clients Windows 2000 SP4 or Xp SP2 with statically-assigned IP addresses and settings.
Client wants to deploy 2 new servers (to replace aging servers) and re-deploy the old servers in different roles. The process I know is straight-forward. The rub is that the new servers must take the names and IP addresses of the old servers due to limitations of a custom application. There is no way around this. Also, our window to perform this is only 5 hours as this is a 24/7 outfit.
I've read many posts regarding how to do this and it seems quite easy. My question is the best fall back strategy should this DC renaming process fail. Plan is:
1. Build, patch, promote and deploy new DC's with all services of old servers
2. Transfer roles to new DC's, check replication
3. Demote old DC's to member server status, check replication one by one
4. Rename old DC's to new names (say SERVER1-OLD..)
5. Change old DC's IP addresses to new IP addresses. Reboot and check DNS for new settings
6. Rename first new server (without Schema Master role) using the NETDOM computername process, reboot and check replication
7. Rename second new server per step 6
8. Test
Now, that makes sense to me but what if this fails? Do you think a Directory Services restore would be best? Authoratative restore? Perform on the new hardware?
I'll have system state and full data backups of each server using NT Backup. My biggest concern is making sure we can revert back to our original state in our window should anything happen.
Avatar of valicon
Flag of United States of America image

See this thread here on EE:

A Directory Services Restore is not necessary in your scenario.
You could also use a temp server and swing the migration. Put the temp DC online, transfer everything to the temp server and then bring down the old server. Next put the new server online with the same name and IP address of the old server and then transfer everything to it from the temp DC. I have done this many times and it works well. And finally here is another thread that pretty much sums it up:
Avatar of my51chevy


Thanks for the quick response, Valicon..
I understand the process but my main concern is recovery should a problem occur.
I've done this same procedure a few years ago for another client with no issues but I want to make sure I have a back out plan should there be logon problems, security problems etc.. It all stems to the "same DC name, same IP" for the new server. I've read of this procedure causing logon problems for workstations even though DNS and AD appears to be ok with the change. Something deep in AD did not get properly changed when the rename process took place.
So the question is: If problems arise, should I: Fix AD? or Restore AD to it's original state? Would my AD integrity be compromised by restoring to the old servers?
I like the swing approach but unfortunately, not an option here..
Of course, it would all depend on what exactly went wrong I'm just looking for a solid opinion.
Make sense?
What is running on the DC's?
SERVER1 = File, print, FTP data repository for nightly store sales uploads
SERVER2 = SQL 2000 SP3, custom app (developer will be onsite to assist with db/table issues
Forgot to mention that I am less concerned with SQL than AD. Don't factor in any kind of SQL recovery in your response....
Okay, so then it is a pretty easy move. I would just follow the threads above and you should have no problem. Once you add a new server to the domain and promote it to a DC, AD is now on that server. All you need to do then is move your FSMO roles over and file and print services etc. Take down the older server but only after you ensure that everything is running correctly. You can do this by unpluuging the old  server. I don't think you will have any issues. You would need to fix AD or restore AD as you will have a copy of AD on your newly promoted DC. Just do one at a time and check your work.
DNS? Is DNS installed on these domain controllers?  If so, is DNS AD integrated?
Yes, DNS is AD-integrated and running on the new DC's.
Replmon and event logs look good on replication
FSMO roles transferred to new DC's - although Domain Naming Master is not available in AD Domains and Trusts...looking into that.
Print services deployed to new DC's (used Printmig)
Data, shares, folder security to be configured in next hour or two
Only thing I'm worried about is the new DC rename to the old IP and name
Avatar of valicon
Flag of United States of America image

Link to home
This content is only available to members.
To access this content, you must be a member of Experts Exchange.
Get Access
ok. Thanks for your check. I'll be performing this at 2p tomorrow.
The DC renaming and IP re-addressing process went flawlessly so thanks for the sanity check, Valicon. I rated the solution as partially complete as it was never hammered out the appropriate recovery procedure should a problem arise - try to fix AD or revert back to the last backup.
Fortunately, it was not necessary.