Windows 2003 DC to Windows 2008 R2 DC with same name and same IP
Environment = Windows 2003 native domain with 8 DCs
I've got an old domain controller that is running 2003, CA Enterprise role, DHCP, DNS, a few GPO scripts that point to shares on it, and some other minor functions. All our servers point to it as their primary DNS, and there's lots of references to its IP or name throughout the domain at this point (8+ years later). I really don't feel like manually changing all of this, it would be a pretty massive undertaking.
I want to follow this guide: http://msmvps.com/blogs/acefekay/archive/2010/10/09/remove-an-old-dc-and-introduce-a-new-dc-with-the-same-name-and-ip-address.aspx to hopefully end up with basically an "in-place upgrade" so to say.
I considered just doing a P2V of the box, but we don't really want to keep it around running 2003 to be honest. I also considered using a CNAME and adding a 2nd IP (the old one) but again, it seemed like it would be cleaner using the attached link.
My actual question:
Any gotchas or big caution signs when doing what the link suggests? Anyone gone down this road and have advice on how to proceed?
This is a relatively common operation. Ace is a good AD resource so it's pretty easy to take his word on it for the pure DC piece.
He doesn't spend a lot of time on the other services, which in your case are important:
The CA couldbe a little painful because to do it right you will need to upgrade the DC that is current in place, unless you're willing to lose all of the information on issued certificates (cf. http://support.microsoft.com/kb/298138). Depending on what you use the CA for this may or may not be OK. I've certainly seen this done with losing the CA configuration and replacing it without a major hit to the environment. Just make sure that you don't create the new CA until you've already renamed and promoted the new machine because you can't do those operations on a CA.
Migrating the DNS data will happen magically assuming AD integrated, otherwise you'll need to set up as a secondary then change it to primary and reconfigure after assigning the old IP to the new server.
Migrating the DHCP data is possible and not bad if you follow directions (cf. http://support.microsoft.com/kb/962355). Ace does cover this in the linked page.
Migrating the shares will involve the data and the permissions. Normally you would use something like the FSMT (http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=10268) but you're not doing a permanent server name change. So just use robocopy to copy over the files to the new server including permissions (/copyall) and bring the share definitions over (by hand or something like http://support.microsoft.com/kb/125996).
There is a thread at ArsTechnica (http://arstechnica.com/civis/viewtopic.php?f=17&t=1117166) about this, which recommends using a "swing server". I have done that in SBS migration cases but I believe it's overkill in your case since you have so many existing DCs.
You didn't say if DNS and DHCP exist on other servers as well or just on this one; if just on this one, first of all, bad because of single point of failure etc., but also this means you're looking at a very visible downtime to end users while you're doing this, in which case a swing server may make sense (two smaller blips instead of one larger blip).
Great stuff. It all looks good and @MikeBaz is good to point out the CA, which ACE doesn't mention, but is common to be on a DC. A less "all or nothing" changeover is to just take it slow and move each service to a new location as it's own mini-project. DNS is likely the only one you need to concern yourself with the IP for (assuming you don't have WINS Server on it).
Your network should be deisgned so that AD DC's are fault tollerent, in that no single DC failure would affect network services like DC, DNS, DHCP, CA, netlogon, etc. I recommend taking this server replacement as a chance to improve your design of each one of those to be highly-available. Good news is each one can be with minimal effort, making the NEXT DC replacement much easier.
For scripts, if they are pointing/running from netlogon which is on all DC's (and replicated between them) then any servernames in the scripts shouldn't point to \\old-dc\netlogon but rather \\domainname.com\netlogon, which is the prefered way so that clients will grab scripts and supporting files from their closest DC. If you're storing files on other shares in scripts/GPO's, then consider using DFS + DFSR which is easy to use and prevents any single file share outage from preventing file access.
For DNS, with that many DC's in your network you should have all clients and servers set to at least two DNS servers. If that's the case then taking down one DC isn't a concern during migration. For DHCP clients just change the DHCP scope to a different DC/DNS host, which you can do now. For servers with static IP's, you can use a script or assign the jr. admin the task to manually ensure they all have the proper DNS entries. DNS is the lifeblood of AD and when possible I actually put in 3+ DNS entires on server NICs (NEVER less then 2), because of cases just like this where DNS servers need to be changed out or given new IP's.