Upgrading Separate AD Forests to a Single Forest Using Mixed-Mode Domain Redirect


Active Directory domains that are running in Windows 2000 Mixed mode can be joined into a separate forest without the need for domain migration tools or workstation reboots. To accomplish this, however, you must run a previously unknown process known as Mixed-Mode Domain Redirect on the environment.

Mixed-Mode Domain Redirect is useful in situations in which branch offices have deployed their own separate Active Directory forests, and the need later surfaces to join these disparate forests into a single, common forest. It is also useful in corporate acquisitions and mergers, where separate forests are suddenly required to merge into a single, unified directory.

Prerequisites and Limitations of the Mixed-Mode Domain Redirect Procedure

The first prerequisite for Mixed-Mode Domain Redirect is that each Active Directory domain in a forest must be running in Windows 2000 Mixed mode. If an organization needs to merge forests but has already gone to Windows 2000 Native mode, other procedures such as using the Active Directory Migration Tool v2.0 or synchronizing directories must be utilized instead.

A big caveat and limitation to this approach is that Windows 2000/XP/2003 clients may already view the domain as an Active Directory domain, requiring themselves to be rejoined to the domain or have their machine/domain password relationship reset using the netdom utility after the operation is complete. Unfortunately, there is no way around this as these client machines eventually discover that their NT domain has become an AD domain, and adjust themselves accordingly. Post-operation, it will become necessary to identify these machines and rejoin them to the new domain structure. This caveat does not hold true for Windows NT 4.0 clients, however.

In addition, this procedure also requires several reboots of existing domain controller servers and is subsequently best performed on a weekend or over a holiday.

Mixed-Mode Domain Redirect Procedure

The concept behind Mixed-Mode Domain Redirect is simple: Take an existing Active Directory domain, downgrade it to a Windows NT 4.0 domain, and upgrade it back into a different environment, as illustrated in Figure 17.12.

Figure 17.12. The Mixed-Mode Domain Redirect procedure.


The example in the diagrams and in the following sections is based on a fictional scenario. You can modify this scenario, however, to include any environment that satisfies the prerequisites outlined previously.

In this scenario, CompanyXYZ has been acquired by CompanyABC, and the need has arisen to merge the CompanyXYZ Windows 2000 forest with the CompanyABC Windows Server 2003 forest. Because the CompanyXYZ domain is running in Windows 2000 Mixed mode, the staff determined that using the Mixed-Mode Domain Redirect procedure would be the most straightforward approach, and there would be no need to change any client settings.

Establishing a Temporary Windows 2000 Domain Controller

The first step in the Mixed-Mode Domain Redirect process is identifying two temporary servers that will be needed in the migration. These servers do not necessarily need to be very fast servers because they will be used only for temporary storage of domain information.

The first temporary server should be set up as a Windows 2000 domain controller in the current Active Directory domain. After the operating system is loaded (Windows 2000 server or Advanced Server), you can run the dcpromo command to make it a domain controller in the current domain, per the standard Windows 2000 domain controller upgrade procedure. In addition, this domain controller does not need to be made into a global catalog server.

In our merger scenario, the temporary server SFDCTEMP01 is built with Windows 2000 and Service Pack 3 and added to the companyxyz.com Windows 2000 domain, where it becomes a domain controller, as illustrated in Figure 17.13. The current domain controllersSFDC01, SFDC02, LADC01, and SDDC01are illustrated as well. These four domain controllers will be migrated to the new environment.

Figure 17.13. Establishing a temporary domain controller.


Moving Operations Master Roles and Demoting Existing Domain Controllers

After the new server is introduced to an environment, the five OM roles must be moved from their existing locations and onto the temporary server. This can be done by using the nTDsutil utility. The steps to move OM roles were demonstrated previously in the "Moving Operation Master Roles" section of this chapter.

In the merger example, the schema master and domain naming master OM roles were moved from SFDC01 to SFDCTEMP01, and the OM roles of PDC Emulator, RID Master, and Infrastructure Master were moved from SFDC02 to SFDCTEMP01.

Demoting Production Domain Controllers

Because the old Active Directory forest will be retired, you need to run dcpromo on the remaining domain controller servers and demote them from domain controller duties. This effectively makes them member servers in the domain and leaves the only functional domain controller as the temporary server built in the preceding section.

In the merger example, as illustrated in Figure 17.14, SFDC01, SFDC02, LADC01, and SDDC01 are all demoted to member servers, and only SFDCTEMP01 remains as a domain controller.

Figure 17.14. Demoting production DCs.


Building a Temporary NT 4.0 Domain Controller

An NT Domain Controller will need to be built to allow the procedure to work. It must be brought up as an NT Backup Domain Controller (BDC) for the domain. Because there are no more NT domain controllers, the DC account for the computer must be created on the first temporary domain controller established. The DC account can be created by typing the following at a command prompt:

netdom add SFDCTEMP02 /domain:companyxyz.com /DC 


It is important to note that even though the domain is in Mixed mode, the account must be created in advance if the Primary Domain Controller (PDC) function in the domain runs on a Windows 2000 domain controller; otherwise, the BDC cannot be added to the domain. When the account is established in advance, the second temporary domain controller must be built with Windows NT 4.0 and configured as a BDC in the domain that will be migrated. Because the domain is still in Windows 2000 Mixed mode, NT BDCs are still supported.

In the merger example, the second temporary domain controller is established as SFDCTEMP02 after the computer account is created on SFDCTEMP01 using the neTDom procedure just described. All existing computer and user accounts are copied into the SAM database on SFDCTEMP02.

Retiring the Existing Forest

The existing Windows 2000 forest can be safely retired by simply turning of the temporary Windows 2000 domain controller. Because this machine controls the OM roles, the Active Directory is effectively shut down. The added advantage of this approach is that you can resurrect the old domain if there are problems with the migration by turning on the first temporary server.

As illustrated in Figure 17.15, the SFDCTEMP01 server is shut off, retiring the companyxyz.com Active Directory domain. However, the COMPANYXYZ NetBIOS domain still exists in the SAM database of SFDCTEMP02, the NT BDC.

Figure 17.15. Retiring the old forest.


Promoting the Second Temporary Server to NT PDC

The NT BDC that you set up then needs to take over as the PDC for the domain, which effectively resurrects the old NetBIOS NT domain structure. This also leaves the domain in a position to be upgraded into an existing Active Directory structure.

In our example, the NT BDC SFDCTEMP02 is promoted to the PDC for the COMPANYXYZ NT domain, preparing it for integration with the companyabc.com Windows Server 2003 domain.

Promoting the NT PDC to Windows Server 2003 and Integrating with the Target Forest

Next, the NT PDC can be promoted to Windows Server 2003 Active Directory. This procedure upgrades all computer and user accounts to Active Directory, and the client settings will not need to be changed.

In the merger example, the Windows Server 2003 CD is inserted into the SCDCTEMP02 server, and a direct upgrade to Windows Server 2003 is performed. As part of the upgrade, the Active Directory Wizard allows the domain to be joined with an existing AD structure. In this case, the CompanyXYZ domain is added as a subdomain to the companyabc.com domain, effectively making it companyxyz.companyabc.com, as illustrated in Figure 17.16.

Figure 17.16. Redirecting the CompanyXYZ domain to the CompanyABC forest.


Re-establishing Prior Domain Controllers and Moving OM Roles

Another useful feature of this approach is that all the original servers that were domain controllers can be promoted back to their original functions without reloading the operating system. The DCPromo process can be run again on the servers, adding them as domain controllers for the domain in the new forest. In addition, the OM roles can be transferred as previously defined to move the original roles back to their old locations.

In our example, all the original domain controllers that are now member servers in the domain are re-promoted using DCPromo. SFDC01, SFDC02, LADC01, and SDDC01 are all re-added as domain controllers, and the proper OM roles are replaced, as illustrated in Figure 17.16.

Retiring the Temporary Domain Controller

The final step in the Mixed-Mode Domain Redirect is to retire the promoted NT BDC from the domain. The easiest way to accomplish this is to run DCPromo to demote it and then simply shut off the server. Both temporary servers can then be retired from duty and recycled into other uses.

In CompanyXYZ, the SCDCTEMP02 server is demoted using DCPromo and turned off. Overall, the procedure spares the company the need to change client logins, user settings, or server hardware and allows it to re-create the existing Windows 2000 domain within a different Windows Server 2003 Active Directory forest.




Microsoft Windows Server 2003 Unleashed(c) R2 Edition
Microsoft Windows Server 2003 Unleashed (R2 Edition)
ISBN: 0672328984
EAN: 2147483647
Year: 2006
Pages: 499

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net