Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Abstract
This document provides the rationale and technical background for understanding the effects of a
domain rename operation in a Windows Server 2003 forest.
For the preparation instructions and step-by-step procedures for performing a domain rename
operation in your enterprise, see "Step-by-Step Guide to Implementing Domain Rename."
This is a preliminary document and may be changed substantially prior to final commercial release of
the software described herein.
The information contained in this document represents the current view of Microsoft Corporation on
the issues discussed as of the date of publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft
cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES,
EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in or introduced into a
retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission of Microsoft
Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places and events depicted herein are fictitious, and no association with any
real company, organization, product, domain name, email address, logo, person, place or event is
intended or should be inferred.
© 2003 Microsoft Corporation. All rights reserved.
Microsoft, Windows Server 2003 Datacenter Server, Windows Server 2003 Enterprise Server, and
Windows Server 2003 are either registered trademarks or trademarks of Microsoft Corporation in the
United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Table of Contents
Table of Contents......................................................... ............................3
Introduction to Domain Rename.............................................................. .4
Constraints to Restructuring Domains in a Windows 2000 Forest.......4
Constraints to Restructuring Domains in a Windows Server 2003 Forest 5
When to Use Domain Rename....................................................... ....5
Simple Rename without Repositioning................................................6
Rename with Repositioning in the Same Tree................................... ...7
Rename with Creation of a New Tree Root........................................ ...9
Rename with Repositioning to a Different Tree..................................11
Reusing a Domain Name...................................................... .............12
Rules, Conditions, and Requirements for Performing the Domain Rename Operation
.............................................................................................................. .13
Rules for a Well-Formed Forest............................................. ...........13
Domain Rename Conditions and Effects on Service........................14
How Domain Rename Works.......................................... ........................15
Overview of the Domain Rename Process.......................................15
The Domain Rename Tool.......................................................... ........15
The Domain Rename State File............................... ..........................16
Domain Controller States............................................. .....................16
General Steps in the Domain Rename Process..................................16
How Specifying the Target Forest Structure Works..........................17
Current Domain Names — Generating the Forest Description File.....17
Target Domain Names — Editing the Forest Description File.............19
How Domain Rename Instructions are Transferred to Active Directory20
Domain Rename Script and State File...............................................20
How DCs are Prepared for Domain Rename....................................21
Establishing a DNS Alias for a New Domain Name............................21
Establishing Service Principal Names for a New Domain Name.........24
Actions Performed by Rendom in Response to the /upload Command24
How DC Readiness is Verified............................................. .............26
Actions Performed in Response to the /prepare Command................26
How Domain Rename Instructions are Executed.............................27
Single-User Mode........................................................ ......................27
Update Transaction................................................ ...........................27
Actions Performed in Response to the /execute Command...............28
Determining Domain Rename Completion........................................29
How Group Policy is Reconciled Following Domain Rename............29
How Old Domain Names are Removed Following Domain Rename. 30
Introduction to Domain
Rename
Microsoft® Windows® .Server 2003 Standard Edition, Microsoft® Windows® Server 2003
Enterprise Edition, and Microsoft® Windows® Server 2003 Datacenter Edition provide the
capability to rename domains in an Active Directory forest after the forest structure is in place.
This functionality is not available in Microsoft® Windows® 2000 Server family. The structure of
an Active Directory forest is the result of the order in which you create domains and the
hierarchical names of those domains. Beginning with the forest root domain, all child domains
derive their distinguished names and default DNS names from the forest root domain name. The
same is true of every additional tree in the forest. The way to change the hierarchical structure of
an existing domain tree is to rename the domains. For example, you can rename a child domain
to have a different parent, or rename a child domain to be a new tree-root domain. In each case,
you reposition an existing domain to create a different domain-tree structure. Alternatively, you
can rename domains without affecting the structure. For example, if you rename a root domain,
the names of all child domains below it are also changed, but you have not created a different
domain-tree structure.
In Windows Server 2003, the goal of the domain rename functionality is to ensure a supported
method to rename domains when necessary; it is not intended to make domain rename a routine
operation. Thus, although renaming domains is possible in Windows Server 2003, the process is
complex and should not be undertaken lightly.
• Split a domain into two domains in a single operation. To split a domain, you must create a
new domain and then move appropriate users and resources from the existing domain into
the new domain.
• Merge two domains into a single domain in a single operation. To merge domains, you must
move all the contents from one of the domains into the other and then demote all domain
controllers in the empty domain and decommission it.
Thus, in a Windows 2000 forest, significant administrative overhead is associated with
performing such manual move operations to achieve the domain-tree restructuring or renaming
one or more domains.
placing it two levels below the forest root domain. If internal reorganization results in the
products division no longer being a subdivision of the sales organization, the company might
want to change the domain structure to put the products organization at the same level as the
sales organization. Figure 2 shows how changing the parent of products.sales.cohowinery.com
results in a restructured domain tree.
Figure 2 Domain rename to change the parent of a child domain
Introduction to Domain Rename 9
and the hr.cohowinery.com domain assumes the name cohoeurope.com in a single restructuring
operation.
However, you can accomplish the desired result by first running the domain rename procedure to
rename the cohoeurope.com domain. When you are absolutely sure that the first rename process
is completed, you can then perform the domain rename procedure again so that
hr.cohowinery.com assumes the domain name cohoeurope.com.
• The DNS suffix of member computer host names in a domain that is being renamed might
not match the DNS name of the domain for a period of time. By default, the DNS suffix
portion of the computer name is updated automatically when the domain to which the
computer is joined changes (as it does 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 computer
names is proportional to the number of machines in the domain. In some cases, you might
want to keep the computer names from being updated automatically.
procedure, you use Rendom to remove all metadata written to the directory by the domain
rename operation.
The general steps in the domain rename procedure can be summarized as follows:
1. Specify the new forest structure represented by the set of changed domain names in the
forest.
2. Generate domain rename instructions encoded as a special script based on the specified new
forest structure and transfer it to every DC in the forest.
3. Verify the validity of the domain rename instructions (script) at every DC and its readiness
to execute those instructions.
4. Execute the domain rename instructions at every DC in the forest. This is the step at which a
brief interruption in the forest service may occur.
5. Fix up Group Policy metadata in the directory so that policies can continue to be applied
following the renaming of domains.
6. Clean up all domain rename related metadata written to the directory such that it is ready for
another round of domain rename operation if needed.
Figure 5 shows an example forest description file 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
the DNS service. In Figure 5, nonvariable values are designated in bold text.
Figure 5 Forest description file (domainlist.xml) from the rendom /list
command
<Forest>
<Domain>
<! PartitionType:Application >
<GUID>78438a56f4a7383a5c82fe05a76ed464</GUID>
<DNSname>DomainDnsZones.hr.sales.cohovineyard.com</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<GUID>89cf8ae3f4a3453bac5ccb05a76bca40</GUID>
<DNSname>hr.sales.cohovineyard.com</DNSname>
<NetBiosName>HR</NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<! PartitionType:Application >
<GUID>b9748a56c4a7385a5d847490e76ba484</GUID>
<DNSname>DomainDnsZones.sales.cohovineyard.com</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<GUID>89238a56f3a1343bbc5ccb05a76bc341</GUID>
<DNSname>sales.cohovineyard.com</DNSname>
<NetBiosName>SALES</NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<! PartitionType:Application >
<GUID>ea658a56f4a7383a5c82cb05a76bdf35</GUID>
<DNSname>DomainDnsZones.cohovineyard.com</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
</Domain>
<Domain>
<! PartitionType:Application >
<GUID>ea658a56f4a7383a5c82cb05a76bd461</GUID>
<DNSname>ForestDnsZones.cohovineyard.com</DNSname>
<NetBiosName></NetBiosName>
<DcName></DcName>
Introduction to Domain Rename 19
</Domain>
<Domain>
<! — ForestRoot >
<GUID>34fg8ae3f4a3453bac5c3ce5a76bca42</GUID>
<DNSname>cohovineyard.com</DNSname>
<NetBiosName>COHOVINEYARD</NetBiosName>
<DcName></DcName>
</Domain>
</Forest>
Note
The domain GUID value in the <GUID> field represents a
fixed name for a domain and cannot be modified. The GUID
provides a permanent identity by which a renamed domain
can be identified in the new forest structure.
For example, using the description file in Figure 5, if you wanted 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 would 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 should be modified as follows):
<DNSname>payroll.sales.cohovineyard.com</DNSname>
<NetBiosName>PAYROLL</NetBiosName>
Based on the specified 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
collected by Rendom will be retrieved from any available DC in each domain. However, you can
optionally specify a particular DC in each domain from which to retrieve the information
required to generate the domain rename update instructions. To use this option, simply add the
DNS host name of the desired DC in the <DcName></DcName> field of the forest description
file.
Understanding How Domain Rename Works 20
After editing the forest description file as described above, you can use the rendom /showforest
command to display the new forest structure contained in the file (this command does not have
any impact on the directory itself). The user-friendly format uses indentations to reflect the
domain hierarchy within the forest.
Note
The actions performed by the upload command and the
resultant changes made to the directory are in preparation for
the rename operation. No domain name changes occur at this
step.
DC Locator Mechanism
DNS is required for the location of DCs by Active Directory clients. DC Locator is an algorithm
that runs in the context of the NetLogon service. It 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. The NetLogon service on every Active Directory domain controller
Understanding How Domain Rename Works 22
dynamically registers service (SRV) resource records in DNS at startup, which allow domain
controllers to be located by service type and protocol. Additionally, every domain controller also
registers a set of A (host) resource records in DNS for use by LDAP clients that do not support
DNS SRV resource records (DC Locator does not use these records), and a CNAME (alias)
record for use by Active Directory replication.
According to the client request, the DC Locator can use various specified criteria that map to
values in the SRV resource records to locate DCs with specific roles or capabilities. For example,
DC 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.
For information about DC Locator and the DNS resource records registered by an Active
Directory domain controller at startup, see "Locating Domain Controllers" in the Directory
Services Guide of the Windows Server 2003 Family Resource Kit.
Note that in the published SRV resource record corresponding to the alias domain name the
owner field reflects the new domain name whereas the hostname field reflects the actual DNS
name of the DC. For example, if the domain cohovineyard.com is being renamed to
cohowinery.com then the following two SRV resource records for the LDAP service would be
published by the NetLogon service on a DC 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
Observe that while the owner field in the second SRV record above corresponds to the new name
to which the domain will be renamed, the hostname field reflects the true DNS name of the DC.
• Still connected to the domain naming master, retrieves all information needed to compute the
list of rename instructions for updating the configuration and schema directory partitions.
• Connects to a randomly selected DC (or the one specified in the <DcName></DcName>
field of the domain entry in the forest description file) for each domain, one by one.
Retrieves all information needed to compute the list of rename instructions for updating each
domain.
• 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 such that the authenticity of the
script can be proven to a DC.
• Still connected to the domain naming master, writes the resulting script to the msDS-
UpdateScript attribute of the Partitions container.
• Still connected to the domain naming master, 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), writes a
new state file to track the progress of every DC in the forest. The state file contains an entry
for every DC in the forest with each DC 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 DC holding
the domain naming master role and then replicated to the
remaining DCs in the forest, if the domain naming master is
unavailable during the rendom /upload operation, the
process cannot continue.
• Rendom updates the state file with the state of each DC that was successfully contacted and
passed verification. The state of each successfully verified DC is updated from the Initial
state to the “Prepared” state. The Prepared state indicates that the DC has authorized the
execution of the restructure and that the contents of its directory database are consistent with
the rename instructions contained in msDS-UpdateScript. If a DC 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.
Note
The actions performed at this step make the actual domain
name changes effective at each DC. This step causes a brief
interruption in service. Prior to this point in the process, forest
service has not been disrupted.
Single-User Mode
To perform the action component of the script in msDS-UpdateScript, the directory service on
each DC 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, MAPI, replication,
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 its
internal data structures. After the directory service performs these updates in single-user mode,
the DC reboots. Following the reboot, the internal data structures are rebuilt to a consistent state.
Update Transaction
All the directory updates 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 have committed the update transaction in single-user mode and then rebooted can
be considered as having completed the domain rename.
Understanding How Domain Rename Works 28
• Rendom updates the state file with the state of each DC that was successfully contacted. For
each DC that successfully completed the update, Rendom changes the state from “Prepared”
to the final state “Done.” If a DC 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, then the corresponding state for the DC is updated to the final state of Error
with an appropriate error code and message to indicate the cause of failure.
Note
The fix-up tool gpfixup refreshes all intradomain GPO
references/links (that is, where the link and the target GPO are
within the same domain) in the renamed domain. However,
cross-domain references to GPOs in the renamed domain,
where the link is in a different domain from the domain
containing the GPO, will not be automatically rebuilt by this
tool. For them to work, these cross-domain links will need to
be repaired manually by deleting the old Group Policy links
and re-establishing new links.