5

First off this is a Windows Server 2003 to 2012 DC/DNS/AD migration. We do have a backup 2003 DC/DNS/AD server as well, but I don't think that is a concern at the moment but can be used if needed. I have already done some of the heavy lifting and have a new 2012 server configured and set up as a AD/DC/DNS host (to the best of my knowledge) using several step-by-step guides including the following:

Step-By-Step: Adding a Windows Server 2012 Domain Controller to an Existing Windows Server 2003 network

I have tested the server with a client offline and it seems everything is working as intended. This worked surprisingly well much to my surprise.

Now the tricky parts:

  • All 200+ client workstations are static addressed
  • Clients are spread across multiple remote locations behind VPN connectivity
  • Clients are about 75% XP and 25% Windows 7 Pro
  • 2003 DCs have been in place for a decade, no realistic idea how much they are actually doing

My co-workers and I are spit-balling options to make this as painless as possible but none of us have performed a migration quite like this. The following are the most feasible so far.

Option 1

  • Transfer FSMO Roles
  • Power down 2003 DC
  • roll IP on 2012 DC (off hours) and cross fingers that the MS gods do not require a sacrifice.

PROS: Sounds easy enough
CONS: If we are missing jobs that are running on 2003 there will be allot of back and forth. Possibly loads of Client/Domain trust errors. Probably more issues that I cannot foresee.

Option 2

  • Use Scripts and Group Policy to change as many client Primary DNS using netsh to 2012 DC
  • Transfer FSMO roles

PROS: Likely no Trust issues. Both servers can be up in case we miss jobs, files etc.
CONS: Scripts are complicated likely to miss some if not MOST clients.

I am hoping for something a little closer to best practices and a little less risky.

Thank you in advanced for any additional ideas of how we can get this accomplished as painlessly as possible.

Mitch
  • 2,363
  • 14
  • 23
Simon
  • 73
  • 3
  • 1
    Why are you trying to change DNS at the same time as the DC? Get your new DNS running, then change DC's, or get your new DC online, then change DNS. Both of them at the same time is asking for trouble. – Mitch Feb 20 '14 at 18:19
  • How many DC total do you have? – longneck Feb 20 '14 at 18:28
  • DNS/DC is all currently running on the same server currently. I could get one or the other job running on the new server, but I'm still back in the same spot. This question is really directed toward the DNS on the clients as long as nobody sees any reason that I would have domain trust issues from changing the IP of a Primary DC/DNS server. This is a very small outfit we only have Primary and Backup DCs. Not counting the new server, and one that will replace the backup at a later date. – Simon Feb 21 '14 at 15:06
  • Whichever way you go dont forget to change any network printers, switches, access points etc that may need dns. This would also be a good time to switch client pcs to use dhcp so you don't have this issue next time you upgrade. – Grant Feb 21 '14 at 16:03

2 Answers2

1

Personally I'd go with option 1, but in several steps. Since the new 2012 servers have been configured already, and you've already confirmed that they are correctly functioning as AD / DNS servers, then that side of things is working as it should.

(1)I'd first of all transfer the FSMO roles to the new servers, then wait for a while to ensure no issues surface from that.

(2)Then, make a list of all the functionality that should / must work across the network on a day to day basis, and work out how to test that. I'd suggest asking people in other departments about what they use if possible, as the last thing you want to discover is some critical isn't running that you weren't even aware of.

(3)Out of hours, reassign the 2003 servers IP's to the 2012 boxes, AND set the old 2003 boxes to run on new IP's. That way if you do find something is missing they're still online and available for you to access / check / grab what is required. Work through your check list and make sure everything is working as it should.

(4)Next day, prepare for issues, ensure everyone who might be needed is in and available, and ready to fix anything that comes up. Avoid doing the switch on a day when loads is happening, eg a launch, payday, invoicing day, Monday or Friday. Hopefully nothing will, but it's WAY better to plan for the worst and hope for the best.

(5)Finally once things have been running without issue for a few days, shut the old servers down, but keep them available for a while longer just in case.

The reason I'd avoid Option 2 is that the very things that will likely catch you out, are the same things you wouldn't think to script. Also, with an old setup there's bound to be something somewhere which is hard coded to point to the old servers, and no doubt it'll be something which Group Policy or your scripts wouldn't change.

Simon
  • 73
  • 3
Keith Langmead
  • 857
  • 1
  • 7
  • 14
  • Thanks Keith. The one things about option 1 one that bothers me is moving the IP after the role transfer, and it is simply my lack of understanding as to how MS handles the trust, and the hidden Critical jobs I'm positive will come up. The hard coded items thought was pointed out to me late yesterday, so I think Option 1 may very well be what we have to go with unless some other MS guru drops a better option in my lap. Thanks for your input – Simon Feb 21 '14 at 15:18
0

Why not change the DNS entries on the clients now to the new 2012 DC's? After you think you have them all, then shutdown the 2003 DC's. If things go south, you can bring the 2003 DC's back online without any issues. Or just demote the 2003 DC's and leave them up until you are more certain any other processes/jobs/fileshares/etc are migrated correctly.

Rex
  • 7,895
  • 3
  • 29
  • 45