Consolidating Multiple Windows Domains
If you’re considering bringing Windows Server 2008 onto your network, then one of the decisions that you will eventually have to make is how you plan to integrate this new operating system into your network. In the vast majority of cases, Windows Server 2008 domain controllers are simply added to existing domains, or some of the existing Windows Server 2003 domain controllers may be upgraded to Windows Server 2008. These types of migrations will require you to update the Active Directory schema, and you may have to do some application compatibility testing, but aside from that the actual implementation process is easy and straightforward.
On the other hand though, I have heard of a few different companies lately who are using an upgrade to Windows Server 2008 as an excuse to restructure a dysfunctional Active Directory. These types of migrations are much more difficult to perform, and require a lot more planning. In the end though, they can be very rewarding because you end up with an Active Directory structure that is specifically tailored to meet your needs.
Of course this idea of restructuring an Active Directory is nothing new. The Active Directory was designed to be flexible from the very beginning, but restructuring has gotten progressively easier from one version of Windows to the next. This is helpful if you find yourself in the middle of a corporate merger, or if you just decide that your current Active Directory design isn’t getting the job done.
The tool of choice for restructuring the Active Directory or for consolidating domains is the Active Directory Migration Tool. The Active Directory Migration Tool is designed to make the process of restructuring the Active Directory or of consolidating domains a lot easier. Version 3.0 even allows you to move Active Directory objects between forests. There are of course some limitations that you need to be aware of.
Interforest Migrations vs. Intraforest Migrations
The Active Directory Migration Tool allows Interforest migrations and Intraforest migrations. Interforest migrations are migrations that involve moving Active Directory objects into a separate forest. Intraforest migrations involve moving Active Directory objects between domains within a single forest.
It should come as no surprise that intraforest migrations are a lot easier to perform than Interforest migrations. The main reason for this is because when you move an object from one domain to another within a forest, the user’s GUID is preserved. Because of this, the user’s local profiles are migrated automatically, so long as users are not using Windows NT Workstation 4.0 or an earlier version of Windows. Even the user’s passwords are retained throughout the migration.
The primary requirement for intraforest migrations is that every domain within the forest must be running in either Windows 2000 Native Mode or at the Windows Server 2003 functional level. The reason for this is that moving objects between domains requires Windows to use the SIDHistory attribute, which is only available in Windows 2000 (and higher) native mode.
One interesting thing about intraforest migrations is that using the Active Directory Migration Tool is not a requirement (although it does make things easier). Windows 2000 and 2003 include a command line utility called MoveTree that can be used to move objects between domains. To the best of my knowledge, this tool is not included in Windows Server 2008, because Microsoft prefers you to use the Active Directory Migration Tool instead.
Interforest migrations are a whole lot more complex, and require extensive planning. The good news is that Interforest migrations are not true migrations, but rather copies. When you migrate an object to a new forest, the original forest still retains a copy of the object. This means that if the move goes badly, then you can easily roll back the process because no objects have been removed from their source domains.
Another nice thing about migrating objects between forests is that you don’t have to worry about maintaining a SID history (although that is an option). Typically though, you will have to use a program such as the Active Directory Migration Tool to help you with the migration process. Otherwise, you won’t be able to migrate user’s local profiles.
In this article, I have explained that if your Active Directory design isn’t working for you, then it is possible to restructure your forest, or to create an entirely new forest and move your existing Active Directory objects into it.
If you are interested in learning more about the Active Directory Migration Tool then I recommend downloading a copy of the Active Directory Migration Guide. You can also download the actual Active Directory Migration Tool.
Got a question? Post it on our Active Directory Forums!
More in Active Directory
Microsoft Rolls Out Azure AD Verifiable Credentials Service to More Customers
May 11, 2022 | Rabia Noureen
Active Directory vs. Azure AD (and Other Identity Providers)
May 9, 2022 | Michael Taschler
Apple Finally Discontinues Support for macOS Server App
Apr 25, 2022 | Rabia Noureen
Microsoft Issues New Guidance on Securing Domain Controllers
Apr 15, 2022 | Rabia Noureen
Best Practices for Installing Active Directory Domain Controllers in a Virtual Machine
Apr 15, 2022 | Michael Taschler
Microsoft Details Efforts to Fight Russian Cyber Attacks Targeting Ukraine
Apr 8, 2022 | Rabia Noureen
Most popular on petri