I just completed a migration for a domain running 2003 Domain Controllers with Windows 2000 Forest/Domain functional levels to 2008R2 with Windows 2008R2 Forest/Domain functional levels.
This was a fun project and it wasn’t too terribly difficult as I was only dealing with a single domain in a single forest.
I learned several interesting things that I didn’t expect to learn while doing this project.
1. I had to move a Certificate Authority (CA) server that someone had setup one one of the 2003 DCs for encrypting files in a sharepoint server. Moving a CA is actually fairly straight-forward. If you Google it, you will find a ton of articles from both Microsoft and the other engineers on the subject. I found Scott Feltmann’s blog post extremely useful because it combined Microsoft’s various articles into a single document that was easier to read. The biggest thing is the CA needs to keep the same name. If I understood the documentation, you can have a different server name, but the CA name must stay the same. To keep things easier for support going forward, I kept the server the same name when I moved CA off of a 2003 DC and onto a 2008R2 member server. I also did not put it on one of my two new 2008R2 domain controllers. I know that it can be done, but I was interested in creating it’s own server to keep things simpler to troubleshoot down the road if a problem develops.
2. You can hard-code an Exchange server to use a specific Global Catalog (GC) server. In an Exchange 2003 environment, the engineer who built it out several years ago made the registry changes needed to designate a Global Catalog that the Exchange Server should always use. Microsoft has good documentation on this. Every time someone rebooted this particular domain controller when it was patched or for a scheduled reboot, we would lose mail connectivity from this 2003 environment. It was interesting to see and learn how much Exchange depends on a Global Catalog to do it’s job effectively.
3. You can save yourself a lot of time by “stealing” the IP addresses from your two 2003 DCs and assigning them to the 2008R2 DCs. The only potential gotcha I ran into was with an Exchange 2003 server that was looking for a particular DC, not a particular IP address. As all of your servers are still using that IP for a 2008R2 DNS/DC instead of the 2003 DNS/DC, clients can still login. I waited 24 hours, but I think it might be less than that before all of the other servers have flushed the old DNS records and know that their DNS server is actually your new server. There likely is a way to push this change out to everything that is tied to the domain, but I found this to be a much easier process.
One thing I would highly suggest doing if this is your first time migrating to a 2008R2 Active Directory setup, is to do it all in lab and to play around with the product a bit. I tend to err on the side of being overly cautious, especially on items that if there is a problem, such as authentication issues, it is a very big problem, one that will keep the phone ringing off the hook and stress out your staff.
The biggest reasons for this move was the fine-grained password policies as there are multiple password needs in this domain and it was difficult trying to fit them all under one roof. The recycle bin is an added bonus. I’ve never had to do a production AD restore in a 2003 environment, only a test restore in lab, but I can imagine the stress when an OU is gone, people are having problems, and restoring the OU isn’t a three step process. Having a recycle bin will certainly make Administrators who have dealt with a mistake of this nature sleep more easily at night.
