How Domain Rename WorksUpdated: March 28, 2003

How Domain Rename WorksIn 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, DNS, Group Policy, and security.

It is imperative that you not attempt a domain rename operation until you read and understand the contents of this technical reference.

Rules for a Well-Formed ForestThe domain rename capabilities that result in the restructure of a Windows Server 2003 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 ServiceAn 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 an Active Directory 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. • 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 Active Directory 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.

Top of pageDomain Rename Processes and InteractionsDomain 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 in Windows Server 2003 forests. 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.

The Domain Rename State FileWhen 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 StatesRendom 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” later in this section.

General Steps in the Domain Rename ProcessThe 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 will perform, is provided in the “Step-by-Step Guide to Implementing Domain Rename” in Windows Server 2003 Domain Rename Tools on the Microsoft Web site. The tools that are required to perform the procedures are available in the same location.

The general steps in the domain rename procedure are as follows:

1. 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.

2. 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. 3. 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. 4. 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. 5. Fix up Group Policy: Update metadata in the directory so that policy settings can continue to be applied after the domain rename. 6. 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 RenameBefore a domain rename operation begins, the following requirements must be met:

• The forest functional level must be Windows Server 2003. • 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 RequirementThe domain rename operation is supported in an Active Directory forest if — and only if — all domain controllers in the forest are running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition, and the forest functional level has been raised to Windows Server 2003. 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 RequirementYou 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 relationshipsA hierarchy of Active Directory domains is implemented by trust relationships between domains. The following types of trust relationships are established between domains in an Active Directory forest:

• Parent-child: The trust that is established when you create a new domain in an existing tree in the forest. The Active Directory 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 Active Directory 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 Active Directory installation process is that there is complete trust between all domains in an Active Directory 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 Active Directory 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 forestIf 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 relationshipFor 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

Precreating multiple parent-child trust relationshipsFor 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

Precreating a tree-root trust relationship with the forest root domainWhen 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

DNS Zones RequirementWhen an application or client requests access to Active Directory, the domain controller locator (Locator) mechanism finds an Active Directory server (that is, a domain controller).

In response to client requests for Active Directory 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 Active Directory. Therefore, before you rename an Active Directory 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 Active Directory domain are identical to the DNS requirements for supporting an existing Active Directory domain. Your current DNS infrastructure already provides the necessary support for your Active Directory 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 Active Directory domain sales.cohovineyard.com to marketing.cohovineyard.com. If the SRV resource records that are registered by the domain controllers in the Active Directory 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 Active Directory domain.

For more information about how DNS provides support for Active Directory, see “DNS Support for Active Directory Technical Reference” and “Designing the Active Directory Logical Structure” in Designing and Deploying Directory and Security Services in the Microsoft Windows Server 2003 Deployment Kit. For more information about the Locator, see “Locator Mechanism” later in this section.

Folder Redirection RequirementWindows 2000 Server and Windows Server 2003 provide the ability to redirect a special folder for users, such as the My Documents folder, from the local computer to a network location. Folder Redirection is an extension to Group Policy that you can use to identify network locations for these folders on specific servers or DFS roots. If you are redirecting folders to network locations that use domain-based DFS paths (\\DomainName\DFSRoot), renaming the Active Directory domain invalidates the domain-based DFS path. If the redirected path is no longer valid, Folder Redirection stops working.

Note

• If the NetBIOS name of a domain is used in domain-based DFS paths and the NetBIOS name of the domain is not changed during a domain rename operation, the domain-based DFS path will continue to be valid.

To ensure that Folder Redirection continues to work after a domain rename operation, folders that are redirected to a domain-based DFS path for a domain that is going to be renamed must instead be redirected to a server-based share or stand-alone DFS path before the domain is renamed. Server-based paths are not affected by the domain rename

operation. You can configure Folder Redirection to a server-based path instead of a domain-based DFS path by using the Group Policy extension for Folder Redirection.

For more information about how to use Group Policy to redirect special folders to a network location, see Help and Support Center in Windows Server 2003. For more information about Folder Redirection, see “Folder Redirection Extension Technical Reference.”

Roaming User Profile RequirementWindows 2000 Server and Windows Server 2003 provide support for roaming user profiles where the user profile (as well as the home directory) can be placed on a network location. Just as for Folder Redirection, if roaming user profiles (and the home directory) are placed on network locations using domain-based DFS paths, renaming the domain invalidates the path, and roaming profiles that use the path stop working.

Note

• If the NetBIOS name of a domain is used in domain-based DFS paths and the NetBIOS name of the domain is not changed during a domain rename operation, the domain-based DFS path will continue to be valid.

To ensure that network share-based user profiles continue to work after a domain rename operation, user profiles that are located on a domain-based DFS path for a domain that is going to be renamed must instead be relocated to a server-based share or stand-alone DFS path. Server-based paths are not affected by a domain rename operation.

For information about how to create roaming user profiles, see Help and Support Center in Windows Server 2003. For more information about roaming user profiles, see “Folder Redirection Extension Technical Reference.”

Computer Host Name RequirementBy default, the primary DNS suffix of a member computer of an Active Directory 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 Active Directory 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 changeThe primary DNS suffix, and therefore the full DNS name of a member computer in an Active Directory 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.

These conditions represent the default configuration for computers running Windows 2000 Server, Windows XP, and Windows Server 2003.

Note

• The DNS host names of domain controllers in a renamed domain are not changed 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 will remain unchanged. The domain controllers can be renamed 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 computersIf 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 Active Directory. 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

Active Directory 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 renameTo 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 following domain rename, you can ensure that these computers are not renamed after 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 Active Directory, either organizational units (OUs) or sites or both.

Configuration requirements before application of Group PolicyWhen 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 Active Directory 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 RequirementsManagement 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 Active Directory 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 Active Directory 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 StructureAfter 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 Windows Server 2003 in What Is Domain Rename?.

Current Domain Names: Generating the Forest Description FileThe 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 FileThe 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 Active DirectoryAfter 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 FileTo 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 instructionsThe 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 trackingWhile 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 RenameWhen 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 NameIn 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 mechanismActive Directory 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 Active Directory, 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 Active Directory 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 nameAccording 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.DnsDomainNameThe 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.comFor more information about the Locator and the DNS resource records that are registered by an Active Directory domain controller, see “How DNS Support for Active Directory Works.”

Publishing two sets of Locator SRV resource records in DNSThe directory service is extended in Windows Server 2003 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.comNote 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 ReplicationThe 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 Active Directory 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 Active Directory 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.comNote 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 NameThe 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 Active Directory 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 Active Directory 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 SPNsSoon 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 CommandThe 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 configurationIf 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 ReadinessThis 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 CommandThe 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 Active Directory 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 ModeTo 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, Active Directory 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 TransactionAll 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 modeAs 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 namesFurther, 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 CommandThe 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 CompletionIn 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 (run the Configure Your Server Wizard to remove Active Directory) 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 RenameWhen 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. 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 RenameFollowing completion of the domain rename process for a forest, you use the rendom /clean command to remove the old domain names from Active Directory. 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 Active Directory 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.