Windows Server 2003 Migration: Tasks Part 4 – Implementation
We documented our inventory, created a plan, allocated the resources, procured the budget, and practiced our migration in a development environment. Now we are at the point where we need to implement our design in production. On the Active Directory side, this is a migration that should require minimal to no downtime. On the application side, downtime needed is determined by the application being migrated. Even if you believe there will be no downtime, it is preferable to schedule a maintenance window for the cutover and do the prep work beforehand. If we wait until a scheduled maintenance window, users know that access to systems is limited. The maintenance window gives you time to work without the pressure of connected users being inconvenienced. As we all know, even with scheduled downtime, you will always have that user who will be upset because you had a system down between the non-working hours of 2 to 5 a.m. on the Sunday morning of a holiday weekend. Even though your company has absolutely no weekend business hours. Ever. To be fair though, don’t make your scheduled maintenance window for your tax firm the morning of April 15.
As stated, the Active Directory side can be done with minimal to no down-time. We can build the required servers and have them ready for integration. We may want to wait until the maintenance window to promote the new domain controllers. We will have less chance of issues and faster initial replication when there is minimal network traffic. You may even want to isolate your servers from the rest of the network (if possible). One idea is to keep servers on separate switches from the rest of the network. If you need to isolate the servers, just pull the plug on the connection to the other switches.
How we integrate the new servers will determine the amount of changes that need to populate to the client side. Do not cut corners for the sake of expedience. For instance, giving a new DNS server the IP address of the existing DNS server it is replacing would keep you from having to change the populated DNS server address on the clients. For a very small environment, this may work fine. However, for a larger environment, it may not turn out to be as seamless as we think. Instead, we should consider a short period of coexistence as we move towards the new servers. Changes to settings on the clients can then be performed in groups of clients at a time. This will give us the opportunity to fix issues without everyone being affected. Almost all new settings on the client side can be populated utilizing DHCP and GPOs. If we utilize GPOs, we can delegate who gets the changes and when. Also, there are some steps in the migration process that we may want to set and then wait before doing more. Here are the general steps in performing an AD migration from Server 2003 to Server 2012:
- Make sure your current domain does not have any existing issues. This can be accomplished by running DCDIAG. Resolve any issues that the DCDIAG reports. This is usually the time that someone discovers an existing replication issue they did not know about.
- Make sure the domain functional level is Windows 2003. If not, change it. We are, of course assuming that you do not have any Windows 2000 Domain Controllers. That would require more planning and steps for this project. There is a confusion about domain functional level. This refers to the level of your domain controllers only. It does not matter is you have member servers of a previous generation. For instance, you can have a domain functional level of 2008 and still have Windows 2003 servers in it. The 03 servers are just not domain controllers.
- Know which servers have the FSMO roles. (On a domain controller, open a command prompt and run ‘netdom query fsmo’.)
- Prepare the domain if needed. If you are migrating to Windows 2008 R2, you will need to run ADPREP. If you are migrating to Windows Server 2012 R2, you do not have to run ADPREP. It is included in the process when adding the Active Directory Domain Services (AD DS) role to the 2012 server.
- Install your 2012 R2 server and add it to the domain.
- Add the AD DS role to your 2012 R2 server. Follow the steps in the wizard.
- Transfer your FSMO roles.
- Configure services like DHCP for the new servers.
- Update settings on the client side.
- Run for an initial coexistence period.
- Remove your Windows 2003 domain controllers by demoting them.
- Raise the domain functional level.
This procedure is for the migration of Active Directory. It does not take into account the migration of applications hosted on Windows Server 2003. Those tasks are a separate part of the plan, but you should now be ready to move forward on those tasks.
At this point, this series of posts has given you the basic steps needed to perform a migration from Windows Server 2003 to Windows Server 2012 R2. This series was meant to give you an overview of the process and help you find the information you need. I cannot stress enough, how important it is for you to plan this out properly and test. If done right, a migration from 2003 AD is not difficult and usually goes very smoothly. If you run into issues, you are affecting your Active Directory configuration. Recovering AD can be a difficult task. In some cases, it’s so difficult, it was easier to just rebuild the domain from scratch. If you do not have the in-house expertise or are uncomfortable with aspects of this project, you can always seek help. I recommend getting help from the trained network professionals at Custom Systems.
As always, I welcome your comments or questions. Please feel free to leave them below or email me directly. Also, be sure to bookmark our site for more information from Microsoft. Also, please be sure to register for our live, Microsoft event – Windows Server 2003: Security Risk and Remediation on February 18.
Craig R. Kalty (CCIA, CCEE, CCA, MCITP:EA, MCITP:SA, VCP)|
Sr. Network Consultant
craig.kalty@customsystems.com
©2015 Custom Systems Corporation