If you’ve been managing an Active Directory infrastructure for the last 5-10 years, you might have noticed that the pace of change has rapidly increased. After surviving the migrations from Windows NT to Windows 2000 and then Windows 2003, we settled into a nice lull for about 5 years. Suddenly Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012 released in about a four year time frame. Now the rumors around the web are hinting at another new version of Windows.
As a lover of technology, all this new stuff is exciting. As a support professional who has to help customers implement all this change, I can understand that you may feel overwhelmed. Can you imagine trying to manage and upgrade an AD infrastructure that has domain controllers running a mix of one/more/all of the following: Server 2003, Server 2008, Server 2008 R2 and Server 2012?
Now is the time to start planning and build your roadmap for moving forward. Don’t worry, because we’re here to help. AskPFEPlat has already given you a great look at Windows Server 2012. Greg’s even given you some practical information on deploying the first Windows Server 2012 Domain Controller.
What we’re going to deliver to you now (and in some soon-to-follow blogs), is everything you need to know about the upgrade process in general as well as some great specifics. I know that there is already good information on TechNet and elsewhere on the internet. What we have to offer is comprehensive and practical information based on our experiences helping hundreds of customers through this process.
An Overview of the Process
Let’s start by talking about a framework to manage the process. At the end of the day, it is simple:
Assess your environment
Start by assessing where you are today with your Active Directory infrastructure. Specifically:
Document your current Architecture, Design and Sizing. Where, how many and how big are your current domain controllers?
Research and document your dependents. Which applications in your environment depend on AD? What applications run the business, and what dependency, if any, do they have on Active Directory?
Discover and document your current Domain Controllers configuration. Any non-default configurations that you need to carry forward?
Research the changes to the default OS behavior in the “new” versions of Windows. Do you know what these are, and how they might affect you?
Inventory other applications/services that are running on your DCs. Don’t forget that these might need to be migrated as your old DCs disappear.
Plan Your Upgrade
Now think about where you’re going, and what you have to do to get there. Use your assessment data to drive the plans. Specifically:
Decide which version of Windows Server you are heading for – Windows Server 2012?
Determine whether you are ready for this new version of Windows. Do you have a tried and tested build?
Document your desired architecture. Are you going to carry your current architecture forward? Do you have the right number of DCs in the right place of the right capacity?
Decide if the type of DC you deploy will change. What about Read-Only DCs, or Virtual DCs? Should they play a role in your new infrastructure?
Research which of your dependents are compatible with these new types of Domain Controllers.
Determine which application/client dependents need to be tested against new DCs.
Plan to manage the behavior changes in the default configuration of the new the OS. Will you roll these changes back (can you roll them back?), roll these changes forward before you deploy new DCs, or let them trickle in as new DCs are deployed?
Sequence the introduction of new DCs. Where will you start, and how quickly will you introduce them?
Sequence the retirement of old DCs. How will you migrate “other” services off of these DCs? Do you need to move IP addresses (or hostnames) from old DCs to new DCs?
Ideally, you test every proposed change. Practically, you need to determine what you must test and what you can test, and how you will test. In some cases you will test in a lab, in other cases you may test in production (with a pilot or limited deployment, for example).
If you haven’t already introduced the new OS into production elsewhere, test your server build for the new OS.
I know this is a lot to take in, and we’re not sharing technical details here. However, once you have the framework for the upgrade process, you just have to fill in the blanks. Stay tuned for future blogs that will cover these phases in much more detail.
Doug “I’ll drag you along the AD upgrade, Kicking and Screaming” Symalla