Introduction
Active Directory has been around a long time--since Windows 2000 Server in fact. I can still remember migrating our Windows NT 4.0 primary domain controller (PDC) and backup domain controller (BDC) to Windows 2000 Server to create a mixed-mode Active Directory domain which I later on switched to native mode. Migrating from Windows NT 4.0 domains to Active Directory was fairly simple and allowed us to take advantage of the new capabilities Active Directory provided. In fact, shortly after Windows 2000 Server was released Microsoft also released a tool called the Active Directory Migration Tool (ADMT) which helped you identify potential problems prior to starting your migration and even let you consolidate NT domains or convert them into organization units (OU) within the target Active Directory domain. But deploying Active Directory also posed some challenges, especially for large enterprises.
Advertisement
In the beginning
In the beginning when Active Directory was first released as part of Windows 2000 Server, the biggest challenge with implementing Active Directory was how to structure your organization's forest and its domains and organizational units (OUs). For example, let's say your company had offices in several countries and a complex organizational hierarchy. Should your forest have one domain tree or several, one for each country? Should each tree consist of a single domain or a hierarchy of domains? Should your organizational unit hierarchy mirror the organizational structure of your company or should it be based on a network administrative model?
Many enterprises assumed it would be best if they deployed multiple Active Directory domains instead of only a single domain. Part of the reason for this decision was uncertainty whether a single domain could scale to the number of users and computers a very large company owned. A second reason for choosing the multiple domain approach was because it was assumed that IT staff in each geographical location--or in each corporate division if the company's operations were structured that way--would assume full responsibility for managing the assets (computers, users, groups, printers, shared folders and so on) in their location or division. A third reason was that WAN links in those days were slow yet costly--think T1 line if you can remember that far back in your IT career. Since all domain controllers in an Active Directory domain had to replicate with each other, one had to be careful about deploying a domain that spanned several sites that were connected by slow WAN links.
Finally, a fourth reason why many companies deployed several domains instead of one was simply because Microsoft recommended it as an option in their initial documentation on Active Directory design. This documentation is still available for viewing in the TechNet archive if you're interested. There's even an old WindowsNetworking.com article that describes how to use the ADMT to migrate NT domains to Active Directory, see this article if you're feeling nostalgic.
Baking in the structure
The problem however is that restructuring things is generally harder and more time-consuming than simply leaving them as they are. So when Microsoft released Windows Server 2003 and companies started upgrading their Windows 2000 Server infrastructures to take advantage of the features of the new platform, most companies simply upgraded their domain controllers and left their existing Active Directory forest and domain structure just the way it was. And although Windows Server 2003 included a new tool called Rendom.exe that enabled companies for the first time to rename the domains in their forest, many companies didn't bother doing this unless there was a compelling business reason to do so, for example a branding issue due to a merger or acquisition occurring.
Note:As an aside, I should point out that domain rename is no longer supported by most (if not all) current versions of Microsoft server applications such as Exchange Server and SharePoint. Instead of renaming a domain, you need to use the ADMT to migrate the domain and its resources to a new domain or into another existing domain. For more information, see my Tip of the Week in Issue #989 of our newsletter WServerNews. And while you're at it, why not subscribe to WServerNews and get weekly updates on the latest cloud solutions, server technologies, IT best practices, third-party tools, security issues, and other topics relevant to both in-the-trenches IT pros and those who manage the business end of IT. You can subscribe to our newsletter here.
Anyways, with Windows Server 2003 comfortably in place, the issue of consolidating or restructuring the domains in the forest was pushed to the bottom of the agenda for IT departments of most large companies. But end-of-life (EOF) for Windows Server 2003 is now less than a year away. That not only means it's time for procrastinating enterprises to migrate to Windows Server 2012 R2, it also means now is the time to consider consolidating and restructuring your domains to reduce your administrative overhead.
Note:As another aside, if you're planning on migrating your infrastructure from Windows Server 2003 to Windows Server 2012 R2, you might want to check out the free course Migrating to Windows Server 2012 Training from the Microsoft Virtual Academy. There is also a helpful walkthrough called "Migrate Active Directory from Windows Server 2003 R2 to Windows Server 2012 R2" in the TechNet Wiki. which you may want to read through if you don't want to perform any domain consolidation or restructuring as part of your migration.
With that said, the remainder of this article and the articles that follow it in this series will describe various considerations you need to be aware of before restructuring or consolidating Active Directory domains and forests as part of your Active Directory migration planning.
Finding the latest version of the ADMT
Knowledge of the Active Directory Migration Tool (ADMT) and how to use it is fundamental to any Active Directory migration process including domain restructuring and consolidation. The most recent version number of the ADMT is version 3.2 which was originally released for Windows Server 2008 R2. However, if you try to download ADMT 3.2 from the Microsoft Download Center and read the system requirements and other information on this page, it says that you will need to install ADMT 3.2 on a sever running Windows Server 2008 R2. It also says you will need at least one domain controller running Windows Server 2008 R2 in your target domain (the domain you are consolidating Active Directory resources into) and that the domain and forest functional levels of the target domain will also have to be set to Windows Server 2008 R2 level.
However, there is actually a more recent version of the ADMT, one you can install on any supported version of Windows Server including Windows Server 2012 and Windows Server 2012 R2. What's confusing however is that this newer version of ADMT still has the same version number (3.2) as the one released for Windows Server 2008 R2 way back in 2010. Microsoft says that's because the functionality of the tool hasn't changed, only the platforms for which it is supported. To get the updated ADMT 3.2 you'll need a Windows Live ID so you can log on to Microsoft Connect and download the tool. You can read more about it on TechNet and you should also check out an article on Jorge's Quest For Knowledge. Finally, you can read the documentation for the updated ADMT 3.2 on TechNet and you can download this documentation for offline viewing from the Microsoft Download Center.
In the next article we'll continue discussing what you need to know before consolidating or restructuring your Active Directory domains.
