How Domain Rename Works
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
How Domain Rename Works
In this section
Domain Rename Processes and Interactions
Related Information
You can use the domain rename process to change the names of your domains, and you can also use it to change the structure of the domain trees in your forest. This process involves updating the Domain Name System (DNS) and trust infrastructures as well as Group Policy and service principal names (SPNs).
Because the domain rename process involves updating the DNS and trust infrastructures as well as Group Policy and SPNs, a domain rename operation affects every domain controller in the forest. Domain rename is a multistep process that results in updates to the directory and in other side effects. This section provides details about the domain rename process and its interactions with Active Directory Domain Services (AD DS), DNS, Group Policy, and security.
Note
In Windows Server 2003 and Microsoft Windows 2000 Server, the directory service is named Active Directory. In Windows Server 2008 R2 and Windows Server 2008, the directory service is named Active Directory Domain Services. The rest of this topic refers to AD DS, but the information is also applicable to Active Directory.
It is imperative that you not attempt a domain rename operation until you read and understand the contents of this technical reference. The domain rename operation is not supported in Microsoft Exchange Server 2007 or Exchange Server 2010. DNS domain rename is supported in Exchange Server 2003. However, renaming of the NetBIOS domain name is not supported in any version of Exchange Server. Other non-Microsoft applications might also not support domain rename. For more information about other Microsoft applications that are incompatible with domain rename, see article 300684 (https://go.microsoft.com/fwlink/?LinkId=185229) in the Microsoft Knowledge Base.
Rules for a Well-Formed Forest
The domain rename capabilities that result in the restructure of a forest support any set of changes to the DNS names and network basic input/output system (NetBIOS) names of the domains in a forest that results in the forest being “well-formed.”
In a well-formed forest, the following conditions are true:
The DNS names of the domains in the forest form one or more trees.
The forest root domain is the root of one of these trees.
An application directory partition cannot have a domain directory partition as a child.
Domain Rename Conditions and Effects on Service
An understanding of the conditions and effects of the domain rename process, and a willingness to fully accommodate them, are important prerequisites for undertaking the process.
The following conditions and effects are inherent in the domain rename process:
Domain rename is supported in a forest in which Exchange Server 2003 with Service Pack 1 (SP1) is deployed. However, domain rename is not supported in an Active Directory forest in which Exchange 2000 Server is deployed. When the domain rename tool detects this condition, it will not proceed with the domain rename process.
Domain rename is also not supported in a forest in which Exchange Server 2007 or Exchange Server 2010 is deployed.
Remote management (also known as headless management) is helpful in the domain rename process. Each domain controller in the forest is contacted individually with the domain rename changes; the changes do not spread across the forest through AD DS replication. This condition does not imply that each domain controller in the forest has to be visited physically by an administrator. However, if you want to rename a domain in a large forest, it is highly recommended that you implement remote management of the domain controllers in the forest. In the event that some domain controllers do not respond during the domain rename process, remote management greatly improves your ability to troubleshoot the problem.
The forest is out of service for a short period of time. Forest service is interrupted during the time it takes for each domain controller to perform the directory database updates that are necessary for the domain rename and to then reboot. The time that the forest is out of service is proportional to the number of domain controllers in the forest. This relatively short service interruption is preferable to the alternative of having the forest in odd “in-between” states for a much longer period of time.
All domain controllers must either complete the domain rename operation successfully or be eliminated from the forest. The domain rename takes effect even if it is impossible to update some domain controllers in the forest. For the domain rename operation to be complete, every domain controller in the forest must be contacted and updated. If you declare your domain rename operation complete without updating some number of domain controllers because you could not contact them, you must remove all the domain controllers that you could not contact from the forest.
Each member computer that is joined to a renamed domain must be rebooted twice after all domain controllers are updated. Computers running Windows NT 4.0 must be unjoined and then rejoined to the renamed domain instead of being rebooted.
If you want DNS host names of domain controllers to match a new domain name, you must perform domain controller rename procedures after the domain rename operation is complete. The DNS host names of domain controllers are not changed automatically by the domain rename operation to reflect the new domain name. In other words, the primary DNS suffix of a domain controller will not match the new domain DNS name after the domain has been renamed. Having the host name of a domain controller decoupled from its domain name has no impact on forest service. However, domain controller rename requires a separate, multistep procedure after the domain rename operation is complete.
The DNS suffix of host names for member computers in a domain that is being renamed might not match the new DNS name of the domain for a period of time. By default, the DNS suffix portion of member computer names is updated automatically when the domain to which the computers are joined changes (as happens when you rename a domain). In general, the period of time during which the DNS name of the domain does not match the DNS suffix of member computer names is proportional to the number of computers in the domain. In some cases, you might want to configure the computers to keep the computer names from being updated automatically.
Domain Rename Processes and Interactions
Domain rename is implemented in a monitored, step-by-step process that ensures that every domain controller in the forest completes its changes one step at a time — that is, the next step in the process cannot occur until the current step is complete at every domain controller in the forest.
The Domain Rename Tool (Rendom)
Rendom.exe is the command-line utility for renaming domains. Rendom is included on the Windows Server 2003 operating system CD. However, an updated version of Rendom is available for download in Windows Server 2003 Domain Rename Tools on the Microsoft Web site. This version of Rendom makes domain rename possible in forests that have Exchange Server 2003 with SP1 deployed.
Rendom.exe is built into domain controllers that run Windows Server 2008 R2 and Windows Server 2008. It is also available in Remote Server Administration Tools (RSAT).
The Domain Rename State File
When you issue the first command to begin the domain rename process, Rendom generates an XML-structured text file, called a state file, which contains a list of all the domain controllers in the forest. As domain controllers progress through the various steps in the procedure, Rendom updates the state file to track the state of each domain controller relative to the completion of the domain rename process.
As you perform each step in the domain rename operation, Rendom automatically updates the state file. By using the state file to monitor the state of completion of each domain controller in the state file, you receive the information that you need to issue the next Rendom command in the sequence.
Domain Controller States
Rendom records four states of completion for each domain controller in the state file:
Initial: Each domain controller that is reachable during the domain rename procedure starts out from the Initial state.
Prepared: When the domain rename instructions that are written by Rendom have been verified by a domain controller independently, it advances to the Prepared state.
Final: From the Prepared state, a domain controller advances to one of two Final states. The domain rename process stops when every domain controller in the forest has reached either of the following states:
Done: This state signifies that the domain rename is complete at that domain controller.
Error: This state implies that some irrecoverable error has occurred, and further progress on the domain rename is deemed to be impossible at that domain controller.
The steps in the domain rename procedure that attempt to take a domain controller from the Initial state to the Prepared state and from the Prepared state to a Final state can be executed only after every domain controller in the forest has reached the required state. A step can be executed multiple times for any domain controllers that cannot be reached in an initial attempt. Each such additional execution of the same step attempts to contact only those domain controllers that have not achieved the required state.
For more information about the contents of the state file, see Domain Rename Script and State File.
General Steps in the Domain Rename Process
The following set of steps is a very high-level representation of what happens during the domain rename process. A more detailed explanation of each step is provided later in this section, beginning with “Specifying the Target Forest Structure.”
Note
Do not try to complete the following general steps or any steps that are described in this technical reference. Do not undertake any domain rename procedures until you read and understand all information in this technical reference. The fully documented set of procedures, including all the tasks that you perform, is provided in Administering Active Directory Domain Rename (https://go.microsoft.com/fwlink/?LinkID=187639).
The general steps in the domain rename procedure are as follows:
Before beginning the domain rename process, prepare a list of domains in the forest: Specify the new forest structure that will be represented by the set of changed domain names in the forest.
Be sure to avoid any possible name conflicts with the new names that you choose. Name conflicts can cause unpredictable and severe results. For example, a conflict with the NetBIOS name can render a domain controller unusable because you might not be able to properly remove AD DS from it.
To begin the domain rename procedure, generate a script that contains the instructions for renaming domains in the forest: Generate domain rename instructions that are encoded as a special script based on the specified new forest structure and transfer it to every domain controller in the forest.
Verify that all domain controllers are adequately prepared to make the necessary updates to rename the domains: Verify the validity of the domain rename instructions (in the script) at every domain controller, and verify that every domain controller is ready to execute those instructions.
Execute the actual domain rename instructions: Execute the domain rename instructions at every domain controller in the forest. At this step, a brief interruption in the forest service may occur.
Fix up Group Policy: Update metadata in the directory so that policy settings can continue to be applied after the domain rename.
Clean up all domain rename–related metadata that is written to the directory so that the directory is ready for another round of the domain rename operation, if necessary: After the domain rename procedure is complete, remove all metadata that the domain rename operation writes to the directory.
Requirements for Domain Rename
Before a domain rename operation begins, the following requirements must be met:
The forest functional level must be Windows Server 2003 or higher.
If the position of domains will change, trust relationships must be created to provide trust between any domain that will be renamed (and therefore repositioned) and the domain that is to be its parent in the new structure.
DNS zones must exist for the new domains.
Domain-based Distributed File System (DFS) folder redirection paths must be redirected to a server-based path.
Domain-based roaming user profiles must be relocated to a server-based share or stand-alone DFS path.
Computers in the to-be-renamed domains must be configured to change their host names to reflect the new domain names.
Certification authority (CA) requirements must be met.
Forest Functional Level Requirement
The domain rename operation is supported in an AD DS forest if—and only if—no domain controllers in the forest are running Windows 2000 Server and the forest functional level has been raised to Windows Server 2003 or higher. Raising the forest functional level to Windows Server 2003 requires that all domains in the forest have a domain functional level of at least Windows 2000 native, regardless of what domains you are renaming.
For more information about forest and domain functional levels, see “Active Directory Functional Levels Technical Reference.”
Trust Relationship Requirement
You can use the domain rename process to reposition any domain in the domain tree hierarchy of a forest, with the exception of the forest-root domain. Remember that although you can rename the forest root domain (you can change its DNS and NetBIOS names), you cannot reposition it in such a way that you designate a different domain to become the new forest root domain. If your domain rename operation involves restructuring the forest through repositioning of the domains in the domain tree hierarchy, as opposed to simply changing the names of the domains in place, you must first create the necessary shortcut trust relationships between domains so that the new forest structure has two-way, transitive trust paths between every pair of domains in the target forest, just as your current forest does.
Types of trust relationships
A hierarchy of AD DS domains is implemented by trust relationships between domains. The following types of trust relationships are established between domains in an AD DS forest:
Parent-child: The trust that is established when you create a new domain in an existing tree in the forest. The AD DS installation process creates a transitive, two-way trust relationship automatically between the new domain (the child domain) and the domain that immediately precedes it in the namespace hierarchy (the parent domain).
Tree-root: The trust that is established when you add a new domain tree to the forest. The AD DS installation process creates a transitive, two-way trust relationship automatically between the domain that you are creating (the new tree-root domain) and the forest root domain.
Shortcut: A manually created, one-way or two-way, transitive trust relationship between any two domains in the forest that is created to shorten the trust path.
The effect of the transitive, two-way trust relationships that are created automatically by the AD DS installation process is that there is complete trust between all domains in a forest — every domain has a transitive trust relationship with its parent domain, and every tree-root domain has a transitive trust relationship with the forest root domain. If you use the domain rename process to restructure an existing forest by altering the domain tree hierarchy, the necessary trust relationships are not created automatically. Therefore, as part of the preparation phase of the domain rename process, you must manually create the trust relationships that are required to preserve complete trust between all domains in your new forest after it is restructured.
Precreating trust relationships for a restructured forest
If you plan to use the domain rename process to reposition one or more domains in the domain tree hierarchy, for each domain that you plan to reposition, you must create the necessary shortcut trust relationships between the domain that you want to reposition and its new parent domain (or the forest root domain if the repositioned domain becomes a tree root). These newly created trust relationships substitute for the required tree-root or parent-child trust relationships that will be missing in the restructured forest.
Precreating a parent-child trust relationship
For example, suppose that the Coho Winery company wants to restructure the cohowinery.com forest so that the products.sales.cohowinery.com domain becomes a child of the cohowinery.com domain. Before the domain rename operation is performed to carry out this restructure, a two-way, transitive, shortcut trust relationship between products.sales.cohowinery.com and cohowinery.com must be created first. This trust relationship establishes the basis for the two-way, parent-child trust relationship that will be required for the targeted parent and child domains.
The following figure shows the before and after domain structures and the shortcut trust relationship that will serve as a parent-child trust relationship in the target forest.
Shortcut Trust Relationship That Becomes a Parent-Child Trust
.gif "Shortcut Trust That Becomes a Parent-Child Trust")
Precreating multiple parent-child trust relationships
For scenarios in which you want to restructure a domain that is both a child domain and a parent domain, you might need to create shortcut trust relationships in two places. For example, suppose the Coho Winery company wants to restructure the cohowinery.com forest to move the hr.sales.cohowinery.com domain so that it becomes a child of the eu.cohowinery.com domain. At the same time, the company wants to make its child domain, payroll.hr.sales.cohowinery.com, a direct child of its current grandparent domain, sales.cohowinery.com. To perform this restructure operation, shortcut trust relationships must be created that become the parent-child trust relationships for the new forest after the restructure, as follows:
A two-way, transitive, shortcut trust relationship is created between the eu.cohowinery.com and hr.sales.cohowinery.com domains, which will effect a two-way, transitive, parent-child trust relationship between eu.cohowinery.com and hr.eu.cohowinery.com after the restructure.
A two-way, transitive, shortcut trust relationship is created between the sales.cohowinery.com domain and the payroll.hr.sales.cohowinery.com domain, which will effect a two-way, transitive, parent-child trust relationship between sales.cohowinery.com and payroll.sales.cohowinery.com after the restructure.
The following figure shows the before and after domain structures and the shortcut trust relationships that will serve as parent-child trust relationships in the target forest.
Shortcut Trust Relationships to Reposition Two Domains
.gif "Shortcut Trust to Reposition Two Domains")
Precreating a tree-root trust relationship with the forest root domain
When a domain is renamed to become a new tree root, the new tree-root domain must have a two-way, transitive trust relationship with the forest root domain. For this scenario, you create a two-way, shortcut trust relationship between the domain that you want to rename to become a new tree-root domain and the forest root domain.
For example, suppose that there is a deep tree in the cohowinery.com forest and the Coho Winery company wants to create a new tree by moving the lowest-level domain, eu.sales.cohowinery.com, to become a tree-root domain. The following figure shows the two-way, shortcut trust relationship that is created, and the tree-root trust relationship that it provides after restructure, when the eu.sales.cohowinery.com domain is renamed to create the tree-root domain cohovineyardandwinery.com.
Shortcut Trust Relationship Providing a Tree-Root Trust Relationship
.gif "Shortcut Trust Providing a Tree-Root Trust")
DNS Zones Requirement
When an application or client requests access to AD DS, the domain controller locator (Locator) mechanism finds an AD DS server (that is, a domain controller).
In response to client requests for AD DS services, the Locator uses service (SRV) resource records in DNS to locate domain controllers. When DNS SRV resource records are not available, directory clients experience failures when they try to access AD DS. Therefore, before you rename an AD DS domain, you must be sure that the appropriate DNS zones exist for the forest and for each domain. If the appropriate DNS zones do not exist, you must create the DNS zone or zones that will contain the SRV resource records for the renamed domains. It is also highly recommended that you configure the DNS zone or zones to allow secure dynamic updates. This DNS zone requirement applies to each domain that is renamed as a part of the domain rename operation.
The DNS requirements for renaming an AD DS domain are identical to the DNS requirements for supporting an existing AD DS domain. Your current DNS infrastructure already provides the necessary support for your AD DS domain’s use of its current name. Usually, you simply mirror the existing DNS infrastructure to add support for the new name of your domain.
For example, suppose the Coho Vineyard company wants to rename its existing AD DS domain sales.cohovineyard.com to marketing.cohovineyard.com. If the SRV resource records that are registered by the domain controllers in the AD DS domain named sales.cohovineyard.com are registered in the DNS zone named sales.cohovineyard.com, a new DNS zone called marketing.cohovineyard.com must be created, corresponding to the new name of the AD DS domain.
For more information about how DNS provides support for AD DS, see DNS Support for Active Directory Technical Reference. For more information about the Locator, see Locator mechanism.
Folder Redirection and Roaming User Profile Requirement
If you are using Folder Redirection or roaming user profiles, you might need to relocate the network paths for them before the domain rename operation. If you place Folder Redirection or roaming user profiles (and the home directory) on a network location by using a domain-based, Distributed File System (DFS) namespace, renaming the domain invalidates the path to this domain-based namespace, and Folder Redirection or roaming user profiles that use this path stop working. For roaming user profiles, this prevents user logons until the paths are fixed. However, if the NetBIOS name of a domain is used to connect to a domain-based DFS namespace and the NetBIOS name of the domain is not changed during a domain rename operation, the path to the domain-based DFS namespace continues to be valid. The same is true for the fully qualified domain name (FQDN); if the FQDN name of a domain is used to connect to a domain-based DFS namespace and the FQDN name of the domain is not changed during a domain rename operation, the path to the domain-based DFS namespace continues to be valid. If you are not using DFS namespaces at all and paths are not specified to server names using FQDNs, the paths will continue to be valid.
For more information, see Relocate Folder Redirection and Roaming User Profiles (https://go.microsoft.com/fwlink/?LinkId=205684).
Computer Host Name Requirement
By default, the primary DNS suffix of a member computer of an AD DS domain is configured to change automatically when domain membership of the computer changes. The same default behavior is true when the DNS name of the domain to which a computer is joined changes. Therefore, a rename of an AD DS domain can cause modification of the primary DNS suffix and, consequently, of the full DNS host names of the computers that are the members of the renamed domain.
For example, if the sales.cohowinery.com domain is renamed to marketing.cohowinery.com, the primary DNS suffix of the member computers of this domain might also change from sales.cohowinery.com to marketing.cohowinery.com, depending on whether the default behavior is in effect. If the default behavior is in effect, the full DNS host name of a computer in the renamed domain will change from hostName.sales.cohowinery.com to hostName.marketing.cohowinery.com.
Conditions for automatic computer name change
The primary DNS suffix, and therefore the full DNS name of a member computer in an AD DS domain, changes when the domain is renamed if both of the following conditions are true:
The primary DNS suffix of the computer is configured to be updated when domain membership changes.
No Group Policy setting specifies that a primary DNS suffix is applied to the member computer.
Note
The DNS host names of domain controllers in a renamed domain do not change automatically to use the new domain DNS name as the primary DNS suffix, regardless of the primary DNS suffix configuration. In other words, unlike the names of member computers, the DNS names of domain controllers in a renamed domain remain unchanged. You can rename the domain controllers in a separate step, using a special domain controller rename procedure, after the domain rename operation is complete.
Replication effects of renaming large numbers of computers
If the conditions that prompt automatic update of the primary DNS suffix for all computers in the domain are true, and if there are a large number of member computers in the domain that are being renamed, replication of that many changes might cause excessive traffic on your network. The replication traffic that results from member computer names being updated is a function of the number of computers that are members of the renamed domain. This replication “storm” that can result from thousands of computer names being changed at approximately the same time is a problem for only the largest deployments. You can avoid this condition by changing the setting the prompts automatic update of the primary DNS suffix. If you do not think that the resulting replication traffic poses any problem to your infrastructure (that is, a risk of network congestion or saturation), this preparatory step is not required.
A computer name change triggers update of the dnsHostName and servicePrincipalName attributes on the corresponding computer account in AD DS. These attributes are typically updated during a reboot of the member computer, as required by the domain rename procedure after the domain is renamed. Update of these attributes by a large number of computers in a short period of time might trigger replication activity that saturates the network. Moreover, a computer name change triggers updates of the host address (A) and pointer (PTR) DNS resource records in the DNS database. Such updates also cause additional replication traffic, regardless of whether DNS zones are stored in AD DS or in some other DNS store. For these reasons, you should prepare for the domain rename operation in advance by reconfiguring the default behavior that changes the primary DNS suffix on member computers when a domain is renamed.
Group Policy revision of the primary DNS suffix before a domain rename
To avoid replication and other update traffic that is caused by automatic update of the primary DNS suffix on all member computers following a domain rename, you can use Group Policy to revise the primary DNS suffix to the new domain name before the domain rename operation. When you use Group Policy for this purpose, member names are not automatically updated, but they have the correct primary DNS suffix when you perform the domain rename.
Rather than going to each computer and changing the setting so that the computer name is not updated automatically when the domain name changes, you can use Group Policy to establish the primary DNS suffix for all computers in the domain as the target DNS domain name. Using Group Policy to establish the primary DNS suffix has the following beneficial effects:
You disable the default behavior of updating the DNS suffix when the DNS domain name changes, thereby avoiding excessive replication traffic.
The computer names are preconfigured to have a primary DNS suffix that matches the target domain name after the domain rename operation.
Note
The primary DNS suffix does not have to match the new domain name. If your current implementation uses a primary DNS suffix that does not match the DNS name of the domain to which the member computers are joined and if you do not want the DNS suffix to change after the domain rename, you can ensure that these computers are not renamed after the domain rename by verifying that at least one of the two conditions in “Conditions for automatic computer name change” earlier in this section is not satisfied.
You can use the Group Policy setting Primary DNS Suffix to establish the primary DNS suffix for the domain as the new DNS domain name. When this Group Policy setting is in effect, it overrides the default behavior of changing the primary DNS suffix when the DNS name of the domain changes. In this case, the computer names remain the same when you rename the domain, and replication of name changes does not occur.
However, just as automatic change of the primary DNS suffix causes replication, setting Primary DNS Suffix causes replication as well. For this reason, Group Policy should be applied in stages to member computers. To apply Group Policy to all member computers in the domain or domains being renamed — while also avoiding replication on a large scale, divide computer objects among several locations in AD DS, either organizational units (OUs) or sites or both.
Configuration requirements before application of Group Policy
When you apply the Group Policy setting Primary DNS Suffix, the DNS suffix of member computers no longer matches the DNS name of the domain of which they are members. To allow the member computers of a domain to have a primary DNS suffix that does not match the DNS domain name, you must first configure the domain to accept the names that the DNS suffix can have. This configuration must be in place before you can set Group Policy to apply to a set of computers.
The msDS-AllowedDNSSuffixes multivalued attribute of the domain object (the domainDns object for the domain) contains a list of DNS suffixes that member computers of the AD DS domain can have. The Group Policy setting Primary DNS Suffix uses the values in this attribute. By editing this attribute to add the primary DNS suffix of the new domain, you make it possible for Group Policy to set the new domain name as the primary DNS suffix.
CA Requirements
Management of enterprise certificates can continue during a domain rename procedure when the following requirements are in effect before domain rename:
The CAs are not installed on domain controllers.
As a best practice, all the CAs should include both Lightweight Directory Access Protocol (LDAP) and Hypertext Transfer Protocol (HTTP) Uniform Resource Locators (URLs) in their Authority Information Access (AIA) and certificate revocation list (CRL) distribution point extensions.
Note
If any certificate that is issued by a CA has only one of these URL types, the certificate may or may not work. Depending on the complexity of your domain configuration, the steps described in the “Step-by-Step Guide to Implementing Domain Rename” (in Windows Server 2003 Domain Rename Tools on the Microsoft Web site) might not be sufficient for proper management of CAs after the domain rename operation. Anyone who undertakes domain rename in an environment that uses certificates must have considerable expertise in managing Microsoft CAs.
If one or more of the following conditions exist at the time of domain rename, CA management is not supported:
The CA is configured to have only LDAP URLs for its CRL distribution point or AIA. Because the old LDAP extensions are invalid after the domain rename operation, all the certificates that are issued by the CA are no longer valid. As a workaround, you have to renew the existing CA hierarchy and all issued End Entity certificates.
An interdomain trust relationship is based on cross-certification with name constraints. After the domain rename operation, the name constraints might not be valid. As a workaround, you have to reissue cross-certificates with appropriate name constraints.
An e-mail name in the style of Request for Comments (RFC) 822, “Standard for the Format of ARPA Internet Text Messages,” is used in the AD DS user account. If the CA (or the certificate template) is configured to include RFC 822–type e-mail names and this e-mail name style is used in the certificates that are issued, these certificates will contain an incorrect e-mail name after a domain rename operation. You should change any such user accounts before any certificates are issued.
For more information about certificates and CAs, see “Certificates Technical Reference” and “CA Certificates Technical Reference.”
Specifying the Target Forest Structure
After you plan your domain rename, you begin the domain rename process by using the domain rename tool (Rendom) to make a list of the domain names, including application directory partition names, in the current forest structure. After you use Rendom to create this list, you create the new forest structure by editing the names in the list. In accordance with the DNS hierarchical naming scheme, the structure of the forest is implicit in the set of DNS names for the domains and the application directory partitions that make up the forest. In addition to specifying DNS name changes for domains and application directory partitions, you can also change the NetBIOS name of any domain. Changes to the DNS and NetBIOS names of the domains and to the DNS names of the application directory partitions that constitute the forest are supported, subject to the constraints outlined in “Domain Rename Constraints” in What Is Domain Rename?.
Current Domain Names: Generating the Forest Description File
The rendom /list command generates the current forest description and writes it to an output file (which has the default name Domainlist.xml) using an XML-encoded structure. This file contains a list of all domains and application directory partitions in the forest, along with their corresponding DNS and NetBIOS names. (Application directory partitions do not have NetBIOS names.) Each domain and application directory partition is also identified by a globally unique identifier (GUID), which does not change with a domain rename. To simplify specifying the new forest structure, Rendom gathers and compiles the current forest structure automatically in such a way that the new forest structure can be overlaid on top of the current forest structure.
The following figure shows an example forest description file that is generated for a forest that has three domains named cohovineyard.com (the forest root domain), sales.cohovineyard.com, and hr.sales.cohovineyard.com, as well as four application directory partitions named DomainDnsZones.hr.sales.cohovineyard.com, DomainDnsZones.sales.cohovineyard.com, DomainDnsZones.cohovineyard.com, and ForestDnsZones.cohovineyard.com that are used by DNS. In the example, nonvariable values are designated in bold text.
Forest Description File (Domainlist.xml) from the rendom /list Command
<Forest>
<Domain><!-- PartitionType:Application --><GUID>78438a56-f4a7-383a-5c82-fe05a76ed464</GUID><DNSname>DomainDnsZones.hr.sales.cohovineyard.com</DNSname>
<NetBiosName></NetBiosName><DcName></DcName></Domain><Domain>
<GUID>89cf8ae3-f4a3-453b-ac5c-cb05a76bca40</GUID>
<DNSname>hr.sales.cohovineyard.com</DNSname><NetBiosName>HR</NetBiosName><DcName></DcName></Domain><Domain><!-- PartitionType:Application --><GUID>b9748a56-c4a7-385a-5d84-7490e76ba484</GUID><DNSname>DomainDnsZones.sales.cohovineyard.com</DNSname><NetBiosName></NetBiosName><DcName></DcName></Domain><Domain><GUID>89238a56-f3a1-343b-bc5c-cb05a76bc341</GUID><DNSname>sales.cohovineyard.com</DNSname>
<NetBiosName>SALES</NetBiosName><DcName></DcName></Domain><Domain><!-- PartitionType:Application --><GUID>ea658a56-f4a7-383a-5c82-cb05a76bdf35</GUID><DNSname>DomainDnsZones.cohovineyard.com</DNSname><NetBiosName></NetBiosName><DcName></DcName></Domain><Domain><!-- PartitionType:Application --><GUID>ea658a56-f4a7-383a-5c82-cb05a76bd461</GUID>
<DNSname>ForestDnsZones.cohovineyard.com</DNSname><NetBiosName></NetBiosName><DcName></DcName></Domain><Domain><! — ForestRoot --><GUID>34fg8ae3-f4a3-453b-ac5c-3ce5a76bca42</GUID><DNSname>cohovineyard.com</DNSname><NetBiosName>COHOVINEYARD</NetBiosName><DcName></DcName></Domain></Forest>
Target Domain Names: Editing the Forest Description File
The current forest description file that is generated by the rendom /list command is a text file that you can edit to express the target forest structure as new domain names. To express the new structure, you simply modify the <DNSname> and <NetBiosName> fields to contain the new names where they are needed.
Note
- The domain GUID value in the <GUID> field represents a fixed name for a domain, and it cannot be modified. The GUID provides a permanent identity that can be used to identify a renamed domain in the new forest structure.
For example, using the preceding forest description file, if you want to change the DNS name of the hr.sales.cohovineyard.com domain to payroll.sales.cohovineyard.com and change its NetBIOS name from HR to PAYROLL, you replace the variable values in the appropriate lines in the forest description file as follows. (Nonvariable values are designated in bold text.)
Current DNS and NetBIOS names:
<DNSname>hr.sales.cohovineyard.com**</DNSname>**
<NetBiosName>HR</NetBiosName>
Modified DNS and NetBIOS names; the two lines above are modified as follows:
<DNSname>payroll.sales.cohovineyard.com</DNSname>
<NetBiosName>PAYROLL</NetBiosName>
Based on the new forest structure, Rendom reads information for each domain from the directory and then generates a set of directory update instructions. By default, the information that is collected by Rendom is retrieved from any available domain controller in each domain. However, you have the option to specify a particular domain controller in each domain from which to retrieve the information that is required to generate the domain rename update instructions. To use this option, simply add the DNS host name of the desired domain controller in the <DcName></DcName> field of the forest description file.
After you edit the forest description file, you can use the rendom /showforest command to display the new forest structure that is contained in the file. (This command does not have any effect on the directory itself.) The user-friendly format uses indentations to reflect the domain hierarchy in the forest.
Transferring Domain Rename Instructions to AD DS
After you create the new forest structure by editing the forest description file, the next step in the domain rename process involves translating the new forest structure into a sequence of directory update instructions to be executed individually on each domain controller in the forest. This translation occurs when you issue the rendom /upload command, and the resultant domain rename instructions are uploaded to the configuration directory partition at the domain controller that is currently the domain naming operations master for the forest. The instructions are then replicated to all other domain controllers in the forest through normal replication of the configuration directory partition. Only after these rename instructions replicate to every domain controller in the forest and the required conditions are verified at each domain controller can each domain controller proceed with executing the rename instructions.
The following sections describe the details of the changes that are produced by the rendom /upload command. The actual sequence of actions that occur in response to the command are described in “Actions Performed by Rendom in Response to the rendom /upload Command” later in this section.
Domain Rename Script and State File
To transform the current forest structure into the target structure, Rendom translates the new forest description to a set of update instructions that the domain controller uses to update its replica directory partitions to make the name changes effective. The rendom /upload command generates the required domain rename instructions, which are encoded in a special script format that is private to the implementation. The rendom /upload command also generates the state file that is used to track the progress of the domain rename operation.
Note
- The actions that are performed by the rendom /upload command and the resultant changes that are made to the directory are in preparation for the rename operation. No domain name changes occur at this step.
Domain rename script for update instructions
The script that is generated by the rendom /upload command is private to the domain rename procedure, and it does not create the directory changes themselves. Rather, the script provides instructions for domain controllers to execute in response to Rendom commands. The script is an XML-encoded document that has three components:
Test: a read transaction to validate that the directory replica at the domain controller is in an appropriate state to perform an action.
Action: an update transaction to be performed on the directory database at the domain controller.
Signature: a cryptographic hash that proves to the domain controller that the script was prepared by the Rendom utility (and, therefore, that it is authentic and correct) and not manually by someone acting as an administrator.
State file for tracking
While translating the forest description to the update instruction script and transferring the script containing the description to the directory, Rendom also generates the state file (which has the default name DClist.xml). This file is structured as an XML-text document to facilitate tracking the state of each domain controller as it progresses through the various steps of the domain rename process. This file contains an entry for every domain controller in the forest. Each domain controller is identified by its DNS host name, along with fields for its current state and the last error encountered on the domain controller while it processed the domain rename instructions.
Preparing Domain Controllers for Domain Rename
When you run the rendom /upload command, certain changes occur on the domain naming operations master in preparation for the actual execution of domain rename. On the domain naming master, the XML-encoded script that contains the domain rename instructions is written to the single-valued, octet-string attribute msDS-UpdateScript on the Partitions container object (cn=partitions,cn=configuration,dc=ForestRootDomain) in the configuration directory partition. The Partitions container can be updated only on the domain controller that is the domain naming master for the forest; therefore, the msDS-UpdateScript attribute is necessarily changed on the domain controller that holds the domain naming operations master role (also known as the flexible single master operations (FSMO) role). From this source domain controller, the script that is stored in the msDS-UpdateScript attribute replicates to all domain controllers in the forest through normal replication of the configuration directory partition.
Establishing a DNS Alias for a New Domain Name
In addition to the msDS-UpdateScript value being written to the Partitions container, the new DNS name of each domain being renamed is also written by Rendom to the single-valued, Unicode-string attribute msDS-DnsRootAlias on the cross-reference object (class crossRef) that corresponds to that domain. Again, because cross-reference objects are stored in the Partitions container and the Partitions container can be updated only on the domain naming master, the msDS-DnsRootAlias attribute can be changed only on the domain controller that holds the domain naming operations master role. From this source domain controller, the DNS name in the msDS-DnsRootAlias attribute replicates to all domain controllers in the forest through normal replication of the configuration directory partition.
Locator mechanism
AD DS clients require DNS so that they can locate domain controllers. The Locator is an algorithm that runs in the context of the Net Logon service. The Locator finds the best domain controller for a request, based on network proximity, by using the resource records that are registered by domain controllers in DNS. During the installation of AD DS, the SRV and A resource records are dynamically registered in DNS by the Net Logon service. Both types of records are necessary for the functionality of the Locator mechanism. To find domain controllers in a domain or forest, a client queries DNS for the SRV and A DNS resource records of the domain controller. The resource records provide the client with the names and IP addresses of the domain controllers. In this context, the SRV and A resource records are referred to as Locator DNS resource records. Every domain controller also registers a canonical name (CNAME) record for use by AD DS replication.
The general format for DNS resource records includes several fields, including, but not limited to, the following:
Owner name time to live record class record type data/host name
According to the client request, the Locator can use various specified criteria that map to values in the SRV resource records to locate domain controllers with specific roles or capabilities. For example, the Locator can find a domain controller that has a full, writable replica of a domain directory partition; a domain replica in a specified site; or a domain controller that is a global catalog server. The owner name in an SRV resource record provides the specific information about the type of domain controller to be located. For example, a domain controller can be located in a specific site by using the following format:
_Service._Protocol.SiteName._sites.DnsDomainName
The following owner name in an SRV resource record specifies a domain controller (identified by the LDAP service running over the TCP protocol) in the East site and the Cohowinery.com domain:
_ldap._tcp.east._sites.cohowinery.com
For more information about the Locator and the DNS resource records that are registered by a domain controller, see “How DNS Support for Active Directory Works.”
Publishing two sets of Locator SRV resource records in DNS
The directory service is extended in Windows Server 2003 and later forests to use the msDS-DnsRootAlias attribute to support the concept of a DNS alias for a domain. The presence of this attribute prompts the Net Logon service running on the domain controller to register the DNS domain name value of this attribute in DNS.
With the addition of the msDS-DnsRootAlias attribute, the Net Logon service has the ability to register not one but two domain names in DNS. The identities of the real (original) domain name and the alias (target) domain name are established by publishing two sets of resource records in DNS, as follows:
The real domain name is published in DNS. Each domain normally has a single DNS name. The domain-specific DNS records that are published by the Net Logon service are derived from the dnsRoot attribute on the cross-reference object for the domain, which holds the real DNS name of the domain (as opposed to an alias). The forest-specific DNS records are derived from the cross-reference object for the forest root domain, which holds the real name of the forest root domain. The Net Logon service running on a domain controller also responds to Locator pings for the domain name and performs secure channel setup between a computer that is joined to the domain and the domain controller on which the Net Logon service runs.
The alias domain name is published in DNS. Soon after the msDS-DnsRootAlias attribute value on a cross-reference object is set on a domain controller, either by an originating write or by a replicated write, the Net Logon service on the domain controller additionally publishes a parallel set of DNS Locator records for the domain alias name that is held in the msDS-DnsRootAlias attribute. The domain-specific DNS records are derived from the msDS-DnsRootAlias attribute on the cross-reference object for the domain, and the forest-specific DNS records are derived from the msDS-DnsRootAlias attribute on the cross-reference object for the forest root domain. Further, on domain controllers for a domain whose msDS-DnsRootAlias value is set, the Net Logon service responds to the Locator pings for the DNS alias as if the value in msDS-DnsRootAlias were the real domain name. Also, secure channel setup from a domain member that connects to a domain controller for a domain that is named in the msDS-DnsRootAlias attribute succeeds as if it were the real domain name.
Note that in the published SRV resource record corresponding to the alias domain name, the owner field reflects the new domain name, whereas the host name field reflects the actual DNS name of the domain controller. For example, if the domain cohovineyard.com is being renamed to cohowinery.com, the Net Logon service publishes the following two SRV resource records for the LDAP service on a domain controller named DC01 in that domain:
_ldap._tcp.cohovineyard.com SRV 0 0 389 dc01.cohovineyard.com
_ldap._tcp.cohowinery.com SRV 0 0 389 dc01.cohovineyard.com
Note that in the second SRV record above, the owner field corresponds to the new name to which the domain will be renamed, and the host name field reflects the true DNS name of the domain controller.
Prepublishing CNAME Records for Replication
The set of domain-specific resource records that are published in DNS by the Net Logon service running on a domain controller includes a DNS CNAME record that AD DS uses for replication.
The owner name of the CNAME record is provided by:
<DsaGuid>._msdcs.<DnsForestName>.
which allows a domain controller to locate a replication partner in the forest.
To find its replication partner, the domain controller requires knowledge of only the GUID of the directory system agent (DSA) object for that domain controller (as represented by DsaGuid in the CNAME record). The DSA GUID is the GUID of the NTDS Settings object (class nTDSDSA). Its value is stored in the objectGUID attribute of the NTDS Settings object, which is a child of the domain controller server object. These objects reside in the Sites container in the configuration directory partition. If the forest root domain is being renamed, it is essential that this CNAME record is published beforehand in DNS so that replication continues to work after a domain controller is updated to change the forest root domain name. If the DNS CNAME records for the new forest root domain name are not published beforehand for each domain controller, and records for the old forest root name are replicated among DNS servers that use AD DS to store DNS zones, replication is interrupted as a result of a cyclic condition. This condition generates the following error: “Cannot replicate because the CNAME record cannot be read from the local DNS replica; the CNAME record is not present in the local DNS replica because it is not replicating.” Prepublication of the DNS records shortens the period during which the directory service is unavailable during the forest restructuring.
Note that in the prepublished CNAME resource record that corresponds to the new forest name, the owner field reflects the new forest name and the host name field reflects the actual DNS name of the domain controller. For example, if the forest cohovineyard.com is renamed to cohowinery.com, the following two CNAME resource records are published by the Net Logon service for a domain controller named DC01 in that domain:
<DsaGuid>.cohovineyard.com IN CNAME dc01.cohovineyard.com
<DsaGuid>.cohowinery.com IN CNAME dc01.cohovineyard.com
Note that in the second SRV record above, the owner field corresponds to the new name to which the forest will be renamed, and the host name field reflects the true DNS name of the domain controller.
Before the domain rename process can continue to the next step, the prepublished CNAME records corresponding to the value in msDS-DnsRootAlias must replicate to all DNS servers that are authoritative for those records.
Establishing SPNs for a New Domain Name
The DSA on every domain controller writes a set of SPNs to the servicePrincipalName attribute on the domain controller computer object in the domain directory partition. Among other things, SPNs are used for mutual authentication between domain controllers during AD DS replication. The specific SPN that is used for mutual authentication between replication partners has the following three-part format:
E3514235-4B06-11D1-AB04-00C04FC2DCD2/<DsaGuid>/<DnsForestName>
where the first part is the remote procedure call (RPC) interface GUID for AD DS replication, the second part is the GUID of the DSA object for the domain controller, and the third part is the DNS name of the forest root domain.
Prepublishing Two Sets of SPNs
Soon after the value for the msDS-DnsRootAlias attribute on a cross-reference object is set on a domain controller, either by an originating write or by a replicated write, the DSA on the domain controller rewrites the SPNs on the domain controller computer object so that each SPN that includes the domain name (or the forest root name) is present in two versions — one for the actual domain (or forest root) name and one for the alias that is held in the msDS-DnsRootAlias attribute of the domain (or forest root) cross-reference object. The SPN values that correspond to the domain name alias require prepublication for the same reason that the DNS CNAME records do, that is, to shorten a cyclic condition that produces the following error: “Cannot replicate because the SPN needed for mutual authentication cannot be read from the directory replica; the required SPN value is not present in the directory replica because it is not replicating.” Prepublication of the SPNs shortens the period during which the directory service is unavailable during the forest restructuring.
Before the domain rename process can continue to the next step, the prepublished SPNs that correspond to the value in msDS-DnsRootAlias must replicate to all domain controllers in the domain as well as to all global catalog servers in the forest.
Actions Performed by Rendom in Response to the rendom /upload Command
The following sequence of actions occurs in response to the rendom /upload command:
Rendom connects to the domain controller that holds the domain naming operations master role for the forest and validates the forest description against the current state of the forest. If any of these validity checks fails, the command fails now. The following requirements are verified:
Each existing domain is part of the new forest.
The new forest is well formed.
The new forest does not reassign domain names that are being relinquished as part of the current domain rename operation.
While it is still connected to the domain naming master, Rendom retrieves all the information that is needed to compute the list of rename instructions for updating the configuration and schema directory partitions.
Rendom connects to a randomly selected domain controller (or the domain controller that is specified in the <DcName></DcName> field of the domain entry in the forest description file) for each domain, one by one, and retrieves all the information that is needed to compute the list of rename instructions for updating each domain.
Rendom computes the full list of domain rename instructions for updating the entire forest (creates the script) and computes a signature to include in the script so that the authenticity of the script can be proven to a domain controller.
While it is still connected to the domain naming master, Rendom writes the resulting script to the msDS-UpdateScript attribute of the Partitions container.
While it is still connected to the domain naming master, Rendom writes the msDS-DnsRootAlias attribute of all cross-reference objects for domains that are being renamed.
On the control station (the computer from which the Rendom commands are issued), Rendom writes a new state file to track the progress of every domain controller in the forest. The state file contains an entry for every domain controller in the forest, with each domain controller entry marked to be in the Initial state.
Note
- Because the msDS-UpdateScript and msDS-DnsRootAlias attributes are first written to the directory on the domain controller holding the domain naming operations master role and then replicated to the remaining domain controllers in the forest, if the domain naming master is unavailable during the rendom /upload operation, the process cannot continue.
Side effect of the rendom /upload command on forest configuration
If certain types of changes in the forest are made after the domain rename operation begins, these changes can affect the outcome of the rename operation and cause it to fail in such a way that some of the domain controllers can never complete the domain rename process. To prevent this situation, successful execution of the rendom /upload command freezes the forest configuration with respect to these types of changes after the domain rename operation begins. The following operations cannot be performed in a forest after the rendom /upload command has completed successfully:
The addition or removal of a domain or application partition
The addition or removal of a domain controller into or from an existing domain
The addition or removal of trusts, including cross-forest trusts. (Note that attributes of an existing trust can be changed during this frozen configuration. For example, a unidirectional trust can be converted to a bidirectional trust.)
The forest configuration remains frozen as long as the msDS-UpdateScript attribute of the Partitions container has a value that indicates that a domain rename operation is in progress. The forest configuration becomes unfrozen at the conclusion of the domain rename operation through execution of the rendom /end command.
Verifying Domain Controller Readiness
This step of the domain rename process verifies that the directory database at each domain controller in the forest is adequately prepared to perform the directory modifications that are dictated by the script in the msDS-UpdateScript attribute. In response to the rendom /prepare command, the necessary verification is performed on each domain controller through execution of the test component of the script in msDS-UpdateScript as a read-only transaction on the local directory database. The test checks for the following conditions:
The correct script in msDS-UpdateScript replicating to this domain controller
Any trust relationships that are required by the new forest structure
Prepublished SPNs for all domain controllers
Name conflicts that are attributable to administrative errors since the time the script in msDS-UpdateScript was created. For example, an administrator might have mistakenly removed a trust that is required in the new forest or created a computer account whose SamAcountName equals the new name of some trusted domain, creating a name conflict with an interdomain trust account.
In addition, the test includes an authorization check on each domain controller to determine whether or not the user running the rendom /prepare command is authorized to execute the domain rename instructions that are contained in msDS-UpdateScript. The authorization check verifies that the user has Write permission on the msDS-UpdateScript attribute on the Partitions container. If the user is not authorized, the command fails with an error.
Actions Performed in Response to the rendom /prepare Command
The following sequence of actions occurs in response to the rendom /prepare command:
Rendom issues a special RPC (for internal use only) to every domain controller in the forest in turn, requesting authorization and verification of readiness as encoded in the test component of the script in msDS-UpdateScript. Rendom issues the RPC to multiple domain controllers at a time with a high degree of concurrency, while ensuring that resource limits on the computer that is executing the command are not exceeded. The RPC request and response are signed and sealed for integrity and privacy.
In response to the RPC, each domain controller performs the authorization check, ensures the authenticity of the script in msDS-UpdateScript by validating the signature, and verifies the test component of the domain rename script before responding. If any of these checks fails on a domain controller, the RPC returns an error for that domain controller.
Rendom updates the state file with the state of each domain controller that was successfully contacted and verified. The state of each successfully verified domain controller is updated from the Initial state to the Prepared state. The Prepared state indicates that the domain controller authorized the execution of the restructure and that the contents of its directory database are consistent with the rename instructions that are contained in msDS-UpdateScript. If a domain controller cannot be contacted or if it fails any of the checks, its corresponding state in the state file remains as Initial with an appropriate error code and message to indicate the cause of failure.
Executing Domain Rename Instructions
In the final step of the domain rename process, the directory database at each domain controller in the forest is updated individually to implement the new forest structure. This process does not rely on AD DS replication. Rather, the action component of the script in msDS-UpdateScript performs the required modifications to the directory database locally on each domain controller as a single update transaction. The action component of the script is the actual update of the domain name. The rendom /execute command performs this final update step.
Note
- The actions that are performed at this step make the actual domain name changes effective at each domain controller. This step causes a brief interruption in service. Before this point in the process, forest service is not disrupted.
Single-User Mode
To perform the action component of the script in msDS-UpdateScript, the directory service on each domain controller enters a special mode called single-user mode. In single-user mode, AD DS refuses service to all normal clients of the directory service, including LDAP, Messaging API (MAPI), replication, Security Accounts Manager (SAM), Kerberos, and other directory service RPCs. In this mode, only the directory service itself can read and write the local directory database, using a single thread. The single-user mode is needed because the domain rename updates that the directory service performs invalidate internal directory data structures. After the directory service performs these updates in single-user mode, the domain controller reboots. After the reboot, the internal data structures are rebuilt to a consistent state.
Update Transaction
All the directory updates that are specified by the action component of the script in msDS-UpdateScript are performed within an Extensible Storage Engine (ESE) database transaction. If no errors occur, the transaction is committed; otherwise, the entire transaction is rolled back. Domain controllers that commit the update transaction in single-user mode and then reboot are considered to have completed the domain rename.
Entering single-user mode
As part of a successful update transaction, the nonreplicated, single-valued integer attribute msDS-ReplicationEpoch on the NTDS Settings object for the domain controller is updated to a new value through incrementation of its current value. If two domain controllers have different msDS-ReplicationEpoch values, no directory replication RPC interaction is allowed between them. In addition to replication, nested group membership evaluation and global catalog lookups are also discontinued. Because the domain rename procedure involves making these updates independently at all domain controllers in the forest, it is impossible to modify these domain controllers simultaneously. The goal of the msDS-ReplicationEpoch attribute is to minimize potentially complex interactions, including replication, between those domain controllers that have completed the domain rename and those domain controllers that have not yet completed the domain rename.
Switching real and alias DNS names
Further, as part of a successful update transaction, the values of the dnsRoot and msDS-DnsRootAlias attributes on the cross-reference objects of renamed domains are interchanged so that the new domain name, formerly stored in msDS-DnsRootAlias, becomes the effective domain name that is stored in dnsRoot. The old domain name is saved as a DNS alias until a subsequent step removes it.
Actions Performed in Response to the rendom /execute Command
The following sequence of actions occurs in response to the rendom /execute command:
Rendom checks to ensure that all domain controllers in the state file are marked with a current state of Prepared. If the state of any domain controller is not Prepared, Rendom reports an error and the process cannot continue.
When all domain controllers in the state file are in the Prepared state, Rendom issues a special RPC (for internal use only) to every domain controller in the forest requesting execution of the directory updates that are encoded in the action component of the script in msDS-UpdateScript. Rendom issues the RPC to multiple domain controllers at a time with a high degree of concurrency, while ensuring that resource limits on the computer that is executing the command are not exceeded. The RPC request and response are signed and sealed for integrity and privacy.
In response to the RPC, each domain controller first verifies the test component of the domain rename script in msDS-UpdateScript (just as in the previous step that checks for domain controller readiness). The domain controller then performs the action component of the script in an update transaction, as described in “Update Transaction” earlier in this section. If any check fails on a domain controller or if the update transaction cannot be successfully committed, the RPC returns an error for that specific domain controller.
Rendom updates the state file with the state of each domain controller that was successfully contacted. For each domain controller that successfully completed the update, Rendom changes the state from Prepared to the final state of Done. If a domain controller cannot be contacted or if it fails any of the checks, its corresponding state in the state file remains Prepared, with an appropriate error code and message to indicate the cause of failure. If the RPC returns with an error that is deemed irrecoverable, the corresponding state for the domain controller is updated to the final state of Error, with an appropriate error code and message to indicate the cause of failure.
Determining Domain Rename Completion
In a large forest, some number of domain controllers might prove impossible to contact during the domain rename process. These domain controllers never reach the final state of Done. You must decide how long to continue to try to reach domain controllers that are unreachable and how long to retry failed update attempts on domain controllers that have reached the Error state. When further progress in the forest is not possible, declare the domain rename process to be complete. All domain controllers that did not reach the final Done state, because they were either unreachable or finished in the Error state, must be demoted or removed from service, if demotion is not possible. For a forest to function without problems after a domain rename, only domain controllers that have reached the Done state can exist in the forest.
Reconciling Group Policy After a Domain Rename
When the DNS name of a domain changes, any references to Group Policy objects (GPOs) in the renamed domain through Group Policy links (the gpLink attribute) on sites, domains, and OUs are rendered invalid because they are based on the old domain name. Further, the optional attribute gpcFileSysPath on a GPO that holds a uniform naming convention (UNC) path to a Group Policy templates folder located in the SYSVOL of the renamed domain is also rendered invalid because the path uses the old domain DNS name. To correct the severed Group Policy links and the invalid UNC paths in GPOs in the renamed domain, you can use a Group Policy tool, Gpfixup.exe, to refresh the Group Policy links and the UNC paths in GPOs that are based on the new domain name. The Gpfixup tool is available for download in Windows Server 2003 Domain Rename Tools on the Microsoft Web site. The tool is built into domain controllers that run Windows Server 2008 R2 and Windows Server 2008. It is also available in Remote Server Administration Tools (RSAT). Run Gpfixup once for every renamed domain soon after the actual domain rename operation is complete and before another domain rename operation is performed.
Note
- Gpfixup refreshes all intradomain GPO references or links (that is, where the link and the target GPO are in the same domain) in the renamed domain. However, cross-domain references to GPOs in the renamed domain (that is, where the link is in a different domain from the domain containing the GPO) are not rebuilt automatically by this tool. For these cross-domain references to work, you must repair the cross-domain links manually by deleting the old Group Policy links and re-establishing new links.
Removing Old Domain Names After a Domain Rename
Following completion of the domain rename process for a forest, you use the rendom /clean command to remove the old domain names from AD DS. This cleanup step removes all values of msDS-DnsRootAlias from the domain naming operations master, and removal of this value is replicated to all domain controllers in the forest. Because this attribute holds the old domain name after the domain rename is completed, replication of the removal of the msDS-DnsRootAlias attribute value to all domain controllers in the forest prompts the Net Logon service on the domain controller to deregister the DNS Locator resource records for the old domain name. In the course of this deregistration, the DNS CNAME resource records, which are used by AD DS replication, are also removed for the old domain name. In addition, the cleanup procedure removes the msDS-UpdateScript attribute value from the Partitions container on the domain naming master.
After you run the rendom /clean command successfully, the new forest is ready for another forest restructuring operation.
Related Information
The following resources contain additional information that is relevant to this section:
Windows Server 2003 Domain Rename Tools on the Microsoft Web site
Designing the Active Directory Logical Structure in Designing and Deploying Directory and Security Services in the Windows Server 2003 Deployment Kit
“Step-by-Step Guide to Implementing Domain Rename” in Windows Server 2003 Domain Rename Tools on the Microsoft Web site