What Is Domain Rename?

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).
The ability to rename domains provides you with the flexibility to make important name changes and
forest structural changes as the needs of your organization change. Using domain rename, you can not
only change the name of a domain, but you can change the structure of the domain hierarchy and change
the parent of a domain or move a domain residing in one domain tree to another domain tree. The domain
rename process can accommodate scenarios involving acquisitions, mergers, or name changes in your
organization, but it is not designed to accommodate forest mergers or the movement of domains between
forests.
Note

 In Windows Server 2003, domain rename is intended to be a supported method for renaming
domains when domain renames are necessary; it is not intended to make domain rename a routine
operation. The domain rename process is complex and requires a great deal of care in planning
and execution. In addition, the time that is required for a complete domain rename operation is
directly proportional to the size of an Active Directory forest in terms of its number of domains,
domain controllers, and member computers. Therefore, although domain rename is possible in
Windows Server 2003, it should not be undertaken lightly.
For information about methods of merging forests, see “Windows 2000/2003: Multiple Forests
Considerations White Paper” on the Microsoft Web site.
Domain Rename Constraints and Capabilities
The domain rename capabilities in a Windows Server 2003 forest provide solutions to some of the
problems that are not addressed in Windows 2000 Server. In a Windows 2000 Server forest, you cannot
rename domains after the forest structure is in place without moving domain contents or recreating them.
Although you can rename domains in Windows Server 2003 forests, there are some important constraints
on these operations. The constraints on domain rename in both Windows 2000 Server forests and
Windows Server 2003 forests are described in the next two sections, followed by a description of the
domain rename capabilities in Windows Server 2003.
Domain Rename Constraints in Windows 2000 Server
The constraints that are associated with changing domain names or restructuring domain trees in
Windows 2000 Server Active Directory are prohibitive.
In a Windows 2000 Server forest, you cannot:

 Change the DNS name or the network basic input/output system (NetBIOS) name of a domain.
Although you cannot rename a domain, you can achieve the same results by moving its contents
into a new domain that has the name that you want the existing domain to have. You can use
Active Directory Object Manager (MoveTree) in Windows 2000 Server family Support Tools to
move directory objects between domains.
 Move a domain in a forest in a single operation. You can make copies of items in a domain and
move items from a domain, but you cannot move the entire domain itself within a forest.
 Split a domain into two domains in a single operation. To split a domain, you must create a new
domain and then move 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 domain and then demote all domain
controllers in the empty domain and decommission it.
In a Windows 2000 Server forest, significant administrative overhead is associated with performing
manual move operations to rename one or more domains or to restructure a domain tree.
Domain Rename Constraints in Windows Server 2003
Domain rename is not a trivial operation, and there are important constraints on the domain rename
operation in a Windows Server 2003 forest. When you decide whether to rename or restructure domains
in an existing Windows Server 2003 forest, be sure to consider what you cannot do with domain rename
and restructuring. Although a Windows Server 2003 forest has domain rename and restructuring
capabilities, certain types of structural changes are not supported.
In a Windows Server 2003 forest, you cannot:

 Change which domain is the forest root domain. Changing the DNS name or the NetBIOS name
(or both) of the forest root domain is supported.
 Drop domains from the forest or add domains to the forest. The number of domains in the forest
before and after the domain rename and restructuring operation must remain the same.
 Rename a domain with a name that was taken from another domain in a single domain rename
and restructuring operation.
Domain Rename Capabilities in Windows Server 2003
For all Windows Server 2003 operating systems except for Windows Server 2003, Web Edition, which
does not support Active Directory, tools are provided that you can use to safely rename domains to
restructure a Windows Server 2003 forest, reapply preexisting Group Policy to the new forest structure,
and clean up the old domain names that you will no longer use.
The domain rename process involves making basic changes independently at each domain controller in a
forest. You set up an administrative computer from which you issue commands that are executed
remotely at each domain controller. These commands update the directory database at each domain
controller individually with the changes that are necessary for renaming the domains; that is, the updates
that rename the domains do not spread across the forest through Active Directory replication.
You use the Rendom tool to carry out the following multiple steps in the domain rename process:

 Freeze the current state of the forest so that no changes can occur while a domain rename
operation is being performed.
 Prepare the contents of the forest for a domain rename operation. Rendom runs multiple scripts
that perform this preparation.
 Execute a domain rename operation.
 Clean up old domain names.
Another tool, Gpfixup, is provided to reinstate Group Policy from the original domains into the newly
named domains in the forest.
The Rendom tool, the Gpfixup tool, and the instructions for using them are available on the
Windows Server 2003 operating system CD. You can also download these tools and instructions from
Windows Server 2003 Domain Rename Tools on the Microsoft Web site.
Note

 The versions of the domain rename tools that are available at the Microsoft Web site are updated
to perform domain rename operations in a forest that has Exchange Server 2003 with Service
Pack 1 (SP1) deployed. Versions of the tools that are available on the operating system CD do not
have this capability.
Core Scenarios for Domain Rename
By using the domain rename capabilities in Windows Server 2003, you can make several kinds of
changes to an existing Windows Server 2003 forest. For example, you can perform domain rename to:

 Rename domains without repositioning any domains in the forest structure.

 Create a new domain-tree structure by repositioning domains within a tree.
 Create a new tree root.
 Create a new domain-tree structure by repositioning domains to a different tree.
 Reuse a domain name.
Domain Rename Without Repositioning
You can rename domains without restructuring the forest in terms of the parent-child relationships
between existing domains. For example, suppose that an existing cohovineyard.com forest for the Coho
Vineyard company has four domains with the following names:

 cohovineyard.com (root)
 eu.cohovineyard.com
 hr.cohovineyard.com
 sales.cohovineyard.com
The company decides to expand into wine bottling and distribution and wants to change its name from
Coho Vineyard to Coho Winery. The Active Directory domain names must now reflect the new company
name. As shown in the following figure, the target forest still has four domains with the following new
names:

 cohowinery.com (root)
 eu.cohowinery.com
 hr.cohowinery.com
 sales.cohowinery.com
By renaming the forest root domain, a condition is created in which all child domains in the tree must be
renamed to preserve the original forest structure, as shown in the following figure.
(In the following series of figures, two-way arrows indicate two-way, transitive trust relationships.)
Domain Rename of Four Domains Without Repositioning Domains
Domain Rename with Repositioning in the Same Tree
You can change the structure of a domain tree by renaming a child domain to appear in a different
location in the tree. For example, in the cohowinery.com forest, the products.sales.cohowinery.com
domain is currently a child of the sales.cohowinery.com domain, placing it two levels below the forest
root domain. If the Products division is no longer a subdivision of the Sales organization as a result of an
internal reorganization, the company might want to change the domain structure to put the Products
organization at the same level as the Sales organization. The following figure shows how changing the
parent of products.sales.cohowinery.com results in a restructured domain tree.
Domain Rename to Change the Parent of a Child Domain
Domain Rename with Creation of a New Tree Root
When you restructure a forest, you can move a domain (except the forest root domain) anywhere within
the forest in which the domain resides. You can even move a domain so that it becomes the root of its
own domain tree. For example, in the cohowinery.com forest, the domain for the European branch of the
company, named eu.cohowinery.com, is a child of the forest root domain. Company management
determines that the European division’s internal domain name should better reflect its Internet DNS
name, cohovineyardandwinery.com. In the target forest structure shown in the following figure, the
eu.cohowinery.com domain is moved so that it becomes its own tree-root domain named
cohovineyardandwinery.com.
Domain Rename to Create a New Tree Root
Domain Rename with Repositioning to a Different Tree
By renaming domains, you can effectively move a child domain to a different parent, even if the parent is
in a different tree. For example, in the current example forest structure, the domain for the Human
Resources (hr) organization is a child of cohowinery.com. This domain has domain controllers in the
United States. However, changes in the company have prompted the Human Resources organization to
move its location to Europe. Company management wants to move the hr.cohowinery.com domain so that
it becomes a child of the domain cohovineyardandwinery.com, residing in another domain tree. As shown
in the following figure, the hr.cohowinery.com domain is renamed to hr.cohovineyardandwinery.com.
Domain Rename to Move a Domain to a Different Tree
Reusing a Domain Name
As described in “Domain Rename Constraints in Windows Server 2003” earlier in this section, the
domain rename operation cannot rename two or more domains so that one domain gives up its name and
another domain assumes the same name in a single forest restructuring operation. For example, in the
Current Forest configuration in the preceding figure, you cannot use a single domain rename operation to
restructure the current forest so that the cohovineyardandwinery.com domain is named something else
and the hr.cohowinery.com domain assumes the name cohovineyardandwinery.com.
However, you can accomplish the desired result by first performing the domain rename operation to
rename the cohovineyardandwinery.com domain to something else. When you are absolutely sure that the
first domain rename operation is complete, you can then perform the domain rename operation again so
that hr.cohowinery.com assumes the domain name cohovineyardandwinery.com.
Domain Rename Dependencies and Interactions with Other Technologies
So that they can interact in a forest structure, Active Directory domains require proper configuration and
functioning of the following technologies:

 DNS: Active Directory clients, including domain controllers, use DNS zone data to locate
resources in a forest. Without a proper DNS infrastructure, Active Directory security and
replication services cannot function. In a domain name operation, DNS names of domain
controllers and member computers must also change, as follows:
 o The DNS names of domain controllers must change to match the new domain names by
changing the primary DNS suffix.
o The DNS names of member computers change automatically in one of two ways: by
configuring the primary DNS suffix to change when the domain name change replicates
(with a potentially significant replication impact) or by applying Group Policy to
configure the primary DNS suffix change before the domain rename.
 SPNs: SPNs are used for mutual authentication between domain controllers during
Active Directory replication. To ensure that replication can occur following a domain rename
operation, the SPN values must change on the domain controllers.
 Trust: Two-way, transitive trust relationships between parent and child domains provide the
security infrastructure that is required for resource sharing between domains in the same forest
and for delegating management of Active Directory objects. To change the structure of a domain
tree, you must manually create the trust relationships that enable parent-child relationships in the
new structure.
In addition to these basic requirements, when the following features are in effect, they require appropriate
changes in the forest in preparation for the domain rename operation:

 Distributed File System (DFS): Folder redirection and roaming user profiles can be used to locate
the user’s home directory and user profile, respectively, in a network location. When these
features are applied using domain-based DFS paths, these paths must change to reflect the new
domain names.
 Certification authorities (CAs): Management of enterprise certificates through a domain rename
procedure requires that CAs not be installed on domain controllers and that they be configured
with appropriate Uniform Resource Locators (URLs).

What Are Active Directory Functional Levels?

In Windows Server 2003 Active Directory, domain controllers can run different versions of Windows
Server operating systems. The Active Directory functional level of a domain or forest depends on which
versions of Windows Server operating systems are running on the domain controllers in the domain or
forest. The functional level of a domain or forest controls which advanced features are available in the
domain or forest.
Ideally, all servers in an organization could run the latest version of Windows (Windows Server 2003)
and take advantage of all advanced features available with the newest software. But organizations often
 have a mixture of systems, generally running different versions of operating systems, which are migrated
to the latest version only as organizational requirements demand additional functionality, either for the
entire organization or for a specific area of the organization.
Active Directory supports phased implementation of Windows Server 2003 and advanced features on
domain controllers by providing multiple Active Directory functional levels, each of which is specific to
the versions of Windows Server operating systems that are running on the domain controllers in the
environment. These functional levels provide configuration support for the Active Directory features in
Windows Server 2003 and ensure compatibility with domain controllers running Windows 2000 Server
and Windows NT 4.0.
Windows Server 2003 Active Directory does not automatically enable advanced features, even if all
domain controllers within a forest are running Windows Server 2003. Instead, an administrator raises a
domain or forest to a specific functional level to safely enable advanced features when all domain
controllers in the domain or forest are running an appropriate version of Windows Server. When an
administrator attempts to raise the functional level, Active Directory checks if all domain controllers are
running an appropriate Windows Server operating system to ensure the proper environment for enabling
new Active Directory features.
Raising the functional level allows the introduction of advanced features but also limits the versions of
Windows Server that can run on domain controllers in the environment. Windows Server 2003 has two
types of Active Directory functional levels:

 Domain functional level. Four domain functional levels are available: Windows 2000 mixed (default),
Windows 2000 native, Windows Server 2003 interim, and Windows Server 2003. Setting the functional
level for a domain enables features that affect the entire domain and that domain only. If all domain
controllers in a domain are running Windows Server 2003 and the functional level is set to Windows
Server 2003, all domain-wide features are available.
 Forest functional level. Three forest functional levels are available: Windows 2000 (default), Windows
Server 2003 interim, and Windows Server 2003. Setting the functional level for a forest enables features
across all the domains within a forest. If all domain controllers in a forest are running Windows Server
2003 and the functional level is set to Windows Server 2003, all forest-wide features are available.
When domain controllers running Windows NT 4.0 or Windows 2000 Server are included in your domain
or forest with domain controllers running Windows Server 2003, advanced Active Directory features are
limited.
The concept of enabling additional functionality in Active Directory exists in Windows 2000 with mixed
and native modes. Mixed-mode domains can contain Windows NT 4.0 backup domain controllers and
 cannot use Universal security groups, group nesting, and security identifier (SID) history capabilities.
When the domain is set to native mode, Universal security groups, group nesting, and SID history
capabilities are available. Domain controllers running Windows NT 4.0 or Windows 2000 Server are not
aware of Windows Server 2003 domain and forest functional levels.
Active Directory Functional Level Scenarios
Functional levels provide a method for any organization to introduce the latest Active Directory
functionality. The advanced functionality can be optimized immediately, or phased in over time,
depending on the needs of each organization. The following scenarios describe how functional levels can
meet a range of deployment needs:

 A small organization running only Windows Server 2003 operating system on domain controllers. In this
scenario, a small organization might be creating an Active Directory infrastructure for the first time, using
only two domain controllers in a forest with a single domain. By installing Windows Server 2003 on both
domain controllers and raising the functional level of the forest to Windows Server 2003, the organization
can immediately take advantage of all of the advanced Active Directory features available in Windows
Server 2003.
 A mid-size organization with accelerated upgrade requirements. In this scenario, a mid-size organization
might have a native mode Windows 2000 Server domain, and would now like to start upgrading domain
controllers to Windows Server 2003. Upgrading to Windows Server 2003 on some domain controllers,
while maintaining some previously installed domain controllers running Windows 2000 Server, enables
the mid-size organization to take advantage of much of the latest functionality, even though all domain
controllers are not running Windows Server 2003. Later, after all domain controllers running
Windows 2000 Server have been upgraded to Windows Server 2003, the organization can raise the forest
functional level to take advantage of all advanced Active Directory features.
 A large organization with phased upgrade requirements. In this scenario, an enterprise with a mature and
complex forest with multiple domains, some of which are still running Windows NT 4.0 backup domain
controllers (BDCs), might now be ready to install one or more new domain controllers running Windows
Server 2003. The organization might want to raise functional levels in a phased manner (one domain at a
time). They could target certain domains that are running in mixed mode (they have a mix of
Windows NT 4.0 BDCs and Windows 2000 domain controllers) and upgrade the Windows NT 4.0 BDCs
first to Windows 2000 or Windows Server 2003. After they have upgraded all Windows NT4.0 BDCs in
the domain, they could raise the functional level of only that domain to the next functional level,
Windows 2000 native, to take advantage of additional Active Directory features.
They could then proceed to upgrade the remaining domain controllers running Windows 2000 Server to
 Windows Server 2003. Once done with that they can raise the functionality of that domain to level further
to avail additional Active Directory features. Once satisfied with the results of that domain, the
organization can carry out a similar exercise in other domains. After upgrading every domain in the forest
to Windows Server 2003, they can finally raise the functional level of the forest to Windows Server 2003
to take advantage of all advanced Active Directory features for Windows Server 2003.
Active Directory Functional Level Dependencies
Active Directory domain and forest-functionality has the following dependencies:

 After all domain controllers are running an appropriate version of Windows Server, the domain or forest
must be configured to support the appropriate domain or forest functional level. That is, to provide
support in a domain or forest for advanced Active Directory features, an administrator must raise the
domain functional level or forest functional level, which can only be done if the domain controllers are
each running the appropriate version of Windows Server.
 After the domain functional level is raised, domain controllers running earlier versions of Windows
Server cannot be introduced into the domain. After the forest functional level is raised, domain controllers
running earlier versions of Windows Server cannot be introduced into the forest.

How Domain Rename Works

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 Forest

The 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 Service

An understanding of the conditions and effects of the domain rename process, and a willingness to fully
accommodate them, are important prerequisites for undertaking the process.

The following conditions and effects are inherent in the domain rename process:

 Domain rename is supported in 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.

Domain Rename Processes and Interactions

Domain rename is implemented in a monitored, step-by-step process that ensures that every domain
controller in the forest completes its changes one step at a time — that is, the next step in the process
cannot occur until the current step is complete at every domain controller in the forest.

The Domain Rename Tool (Rendom)

Rendom.exe is the command-line utility for renaming domains 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 File

When you issue the first command to begin the domain rename process, Rendom generates an XML-
structured text file, called a state file, which contains a list of all the domain controllers in the forest. As
domain controllers progress through the various steps in the procedure, Rendom updates the state file to
track the state of each domain controller relative to the completion of the domain rename process.

As you perform each step in the domain rename operation, Rendom automatically updates the state file.
By using the state file to monitor the state of completion of each domain controller in the state file, you
receive the information that you need to issue the next Rendom command in the sequence.

Domain Controller States

Rendom records four states of completion for each domain controller in the state file:

 Initial: Each domain controller that is reachable during the domain rename procedure starts out
from the Initial state.
 Prepared: When the domain rename instructions that are written by Rendom have been verified
by a domain controller independently, it advances to the Prepared state.
 Final: From the Prepared state, a domain controller advances to one of two Final states. The
domain rename process stops when every domain controller in the forest has reached either of the
following states:
o Done: This state signifies that the domain rename is complete at that domain controller.
o 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 Process

The following set of steps is a very high-level representation of what happens during the domain rename
process. A more detailed explanation of each step is provided later in this section, beginning with
“Specifying the Target Forest Structure.”

Note

 Do not try to complete the following general steps or any steps that are described in this technical
reference. Do not undertake any domain rename procedures until you read and understand all
information in this technical reference. The fully documented set of procedures, including all the
tasks that you 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.
Be sure to avoid any possible name conflicts with the new names that you choose. Name conflicts
can cause unpredictable and severe results. For example, a conflict with the NetBIOS name can
render a domain controller unusable because you might not be able to properly remove Active
Directory from it.
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 Rename

Before 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 Requirement

The 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 Requirement

You can use the domain rename process to reposition any domain in the domain tree hierarchy of a forest,
with the exception of the forest-root domain. Remember that although you can rename the forest root
domain (you can change its DNS and NetBIOS names), you cannot reposition it in such a way that you
designate a different domain to become the new forest root domain. If your domain rename operation
involves restructuring the forest through repositioning of the domains in the domain tree hierarchy, as
opposed to simply changing the names of the domains in place, you must first create the necessary
shortcut trust relationships between domains so that the new forest structure has two-way, transitive trust
paths between every pair of domains in the target forest, just as your current forest does.

Types of trust relationships

A hierarchy of 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 forest

If you plan to use the domain rename process to reposition one or more domains in the domain tree
hierarchy, for each domain that you plan to reposition, you must create the necessary shortcut trust
relationships between the domain that you want to reposition and its new parent domain (or the forest root
domain if the repositioned domain becomes a tree root). These newly created trust relationships substitute
for the required tree-root or parent-child trust relationships that will be missing in the restructured forest.

Precreating a parent-child trust relationship

For example, suppose that the Coho Winery company wants to restructure the cohowinery.com forest so
that the products.sales.cohowinery.com domain becomes a child of the cohowinery.com domain. Before
the domain rename operation is performed to carry out this restructure, a two-way, transitive, shortcut
trust relationship between products.sales.cohowinery.com and cohowinery.com must be created first. This
trust relationship establishes the basis for the two-way, parent-child trust relationship that will be required
for the targeted parent and child domains.

The following figure shows the before and after domain structures and the shortcut trust relationship that
will serve as a parent-child trust relationship in the target forest.

Shortcut Trust Relationship That Becomes a Parent-Child Trust

Precreating multiple parent-child trust relationships

For scenarios in which you want to restructure a domain that is both a child domain and a parent domain,
you might need to create shortcut trust relationships in two places. For example, suppose the Coho
Winery company wants to restructure the cohowinery.com forest to move the hr.sales.cohowinery.com
domain so that it becomes a child of the eu.cohowinery.com domain. At the same time, the company
wants to make its child domain, payroll.hr.sales.cohowinery.com, a direct child of its current grandparent
domain, sales.cohowinery.com. To perform this restructure operation, shortcut trust relationships must be
created that become the parent-child trust relationships for the new forest after the restructure, as follows:

 A two-way, transitive, shortcut trust relationship is created between the eu.cohowinery.com and
hr.sales.cohowinery.com domains, which will effect a two-way, transitive, parent-child trust
relationship between eu.cohowinery.com and hr.eu.cohowinery.com after the restructure.
 A two-way, transitive, shortcut trust relationship is created between the sales.cohowinery.com
domain and the payroll.hr.sales.cohowinery.com domain, which will effect a two-way, transitive,
 parent-child trust relationship between sales.cohowinery.com and payroll.sales.cohowinery.com
after the restructure.

The following figure shows the before and after domain structures and the shortcut trust relationships that
will serve as parent-child trust relationships in the target forest.

Shortcut Trust Relationships to Reposition Two Domains

Precreating a tree-root trust relationship with the forest root domain

When a domain is renamed to become a new tree root, the new tree-root domain must have a two-way,
transitive trust relationship with the forest root domain. For this scenario, you create a two-way, shortcut
trust relationship between the domain that you want to rename to become a new tree-root domain and the
forest root domain.
For example, suppose that there is a deep tree in the cohowinery.com forest and the Coho Winery
company wants to create a new tree by moving the lowest-level domain, eu.sales.cohowinery.com, to
become a tree-root domain. The following figure shows the two-way, shortcut trust relationship that is
created, and the tree-root trust relationship that it provides after restructure, when the
eu.sales.cohowinery.com domain is renamed to create the tree-root domain cohovineyardandwinery.com.

Shortcut Trust Relationship Providing a Tree-Root Trust Relationship

DNS Zones Requirement

When 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 Requirement

Windows 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 Requirement

Windows 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 Requirement

By 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 change

The 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 computers

If the conditions that prompt automatic update of the primary DNS suffix for all computers in the domain
are true, and if there are a large number of member computers in the domain that are being renamed,
replication of that many changes might cause excessive traffic on your network. The replication traffic
that results from member computer names being updated is a function of the number of computers that
are members of the renamed domain. This replication “storm” that can result from thousands of computer
names being changed at approximately the same time is a problem for only the largest deployments. You
can avoid this condition by changing the setting the prompts automatic update of the primary DNS suffix.
If you do not think that the resulting replication traffic poses any problem to your infrastructure (that is, a
risk of network congestion or saturation), this preparatory step is not required.

A computer name change triggers update of the dnsHostName and servicePrincipalName attributes on
the corresponding computer account in 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 rename

To avoid replication and other update traffic that is caused by automatic update of the primary DNS suffix
on all member computers following a domain rename, you can use Group Policy to revise the primary
DNS suffix to the new domain name before the domain rename operation. When you use Group Policy
for this purpose, member names are not automatically updated, but they have the correct primary DNS
suffix when you perform the domain rename.

Rather than going to each computer and changing the setting so that the computer name is not updated
automatically when the domain name changes, you can use Group Policy to establish the primary DNS
suffix for all computers in the domain as the target DNS domain name. Using Group Policy to establish
the primary DNS suffix has the following beneficial effects:
  You disable the default behavior of updating the DNS suffix when the DNS domain name
changes, thereby avoiding excessive replication traffic.
 The computer names are preconfigured to have a primary DNS suffix that matches the target
domain name after the domain rename operation.

Note

 The primary DNS suffix does not have to match the new domain name. If your current
implementation uses a primary DNS suffix that does not match the DNS name of the domain to
which the member computers are joined, and if you do not want the DNS suffix to change
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 Policy

When you apply the Group Policy setting Primary DNS Suffix, the DNS suffix of member computers no
longer matches the DNS name of the domain of which they are members. To allow the member
computers of a domain to have a primary DNS suffix that does not match the DNS domain name, you
must first configure the domain to accept the names that the DNS suffix can have. This configuration
must be in place before you can set Group Policy to apply to a set of computers.

The msDS-AllowedDNSSuffixes multivalued attribute of the domain object (the domainDns object for
the domain) contains a list of DNS suffixes that member computers of the 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 Requirements

Management of enterprise certificates can continue during a domain rename procedure when the
following requirements are in effect before domain rename:

 The CAs are not installed on domain controllers.

 As a best practice, all the CAs should include both Lightweight Directory Access Protocol
(LDAP) and Hypertext Transfer Protocol (HTTP) Uniform Resource Locators (URLs) in their
Authority Information Access (AIA) and certificate revocation list (CRL) distribution point
extensions.

Note

 If any certificate that is issued by a CA has only one of these URL types, the certificate may or
may not work. Depending on the complexity of your domain configuration, the steps described in
the “Step-by-Step Guide to Implementing Domain Rename” (in Windows Server 2003 Domain
Rename Tools on the Microsoft Web site) might not be sufficient for proper management of CAs
after the domain rename operation. Anyone who undertakes domain rename in an environment
that uses certificates must have considerable expertise in managing Microsoft CAs.

If one or more of the following conditions exist at the time of domain rename, CA management is not
supported:

 The CA is configured to have only LDAP URLs for its CRL distribution point or AIA. Because
the old LDAP extensions are invalid after the domain rename operation, all the certificates that
are issued by the CA are no longer valid. As a workaround, you have to renew the existing CA
hierarchy and all issued End Entity certificates.
 An interdomain trust relationship is based on cross-certification with name constraints. After the
domain rename operation, the name constraints might not be valid. As a workaround, you have to
reissue cross-certificates with appropriate name constraints.
 An e-mail name in the style of Request for Comments (RFC) 822, “Standard for the Format of
ARPA Internet Text Messages,” is used in the 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 Structure

After you plan your domain rename, you begin the domain rename process by using the domain rename
tool (Rendom) to make a list of the domain names, including application directory partition names, in the
current forest structure. After you use Rendom to create this list, you create the new forest structure by
editing the names in the list. In accordance with the DNS hierarchical naming scheme, the structure of the
forest is implicit in the set of DNS names for the domains and the application directory partitions that
make up the forest. In addition to specifying DNS name changes for domains and application directory
partitions, you can also change the NetBIOS name of any domain. Changes to the DNS and NetBIOS
names of the domains and to the DNS names of the application directory partitions that constitute the
forest are supported, subject to the constraints outlined in “Domain Rename Constraints” in
Windows Server 2003 in What Is Domain Rename?.

Current Domain Names: Generating the Forest Description File

The rendom /list command generates the current forest description and writes it to an output file (which
has the default name Domainlist.xml) using an XML-encoded structure. This file contains a list of all
domains and application directory partitions in the forest, along with their corresponding DNS and
NetBIOS names. (Application directory partitions do not have NetBIOS names.) Each domain and
application directory partition is also identified by a globally unique identifier (GUID), which does not
change with a domain rename. To simplify specifying the new forest structure, Rendom gathers and
compiles the current forest structure automatically in such a way that the new forest structure can be
overlaid on top of the current forest structure.

The following figure shows an example forest description file that is generated for a forest that has three
domains named cohovineyard.com (the forest root domain), sales.cohovineyard.com, and
hr.sales.cohovineyard.com, as well as four application directory partitions named
DomainDnsZones.hr.sales.cohovineyard.com, DomainDnsZones.sales.cohovineyard.com,
DomainDnsZones.cohovineyard.com, and ForestDnsZones.cohovineyard.com that are used by DNS. In
the example, nonvariable values are designated in bold text.

Forest Description File (Domainlist.xml) from the rendom /list Command

<Forest>
<Domain><!-- PartitionType:Application --><GUID>78438a56-f4a7-383a-5c82-
fe05a76ed464</GUID><DNSname>DomainDnsZones.hr.sales.cohovineyard.com</DNSname>
<NetBiosName></NetBiosName><DcName></DcName></Domain><Domain>
<GUID>89cf8ae3-f4a3-453b-ac5c-cb05a76bca40</GUID>

<DNSname>hr.sales.cohovineyard.com</DNSname><NetBiosName>HR</NetBiosName><DcName></
DcName></Domain><Domain><!-- PartitionType:Application --><GUID>b9748a56-c4a7-385a-5d84-
7490e76ba484</GUID><DNSname>DomainDnsZones.sales.cohovineyard.com</DNSname><NetBiosN
ame></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><DcNa
me></DcName></Domain><Domain><! — ForestRoot --><GUID>34fg8ae3-f4a3-453b-ac5c-
3ce5a76bca42</GUID><DNSname>cohovineyard.com</DNSname><NetBiosName>COHOVINEYAR
D</NetBiosName><DcName></DcName></Domain></Forest>

Target Domain Names: Editing the Forest Description File

The current forest description file that is generated by the rendom /list command is a text file that you
can edit to express the target forest structure as new domain names. To express the new structure, you
simply modify the <DNSname> and <NetBiosName> fields to contain the new names where they are
needed.
Note

 The domain GUID value in the <GUID> field represents a fixed name for a domain, and it cannot
be modified. The GUID provides a permanent identity that can be used to identify a renamed
domain in the new forest structure.

For example, using the preceding forest description file, if you want to change the DNS name of the
hr.sales.cohovineyard.com domain to payroll.sales.cohovineyard.com and change its NetBIOS name from
HR to PAYROLL, you replace the variable values in the appropriate lines in the forest description file as
follows. (Nonvariable values are designated in bold text.)

 Current DNS and NetBIOS names:

< DNSname>hr.sales.cohovineyard.com</DNSname>
< NetBiosName>HR</NetBiosName>
 Modified DNS and NetBIOS names; the two lines above are modified as follows:
< DNSname>payroll.sales.cohovineyard.com</DNSname>
< NetBiosName>PAYROLL</NetBiosName>

Based on the new forest structure, Rendom reads information for each domain from the directory and then
generates a set of directory update instructions. By default, the information that is collected by Rendom is
retrieved from any available domain controller in each domain. However, you have the option to specify a
particular domain controller in each domain from which to retrieve the information that is required to
generate the domain rename update instructions. To use this option, simply add the DNS host name of the
desired domain controller in the <DcName></DcName> field of the forest description file.

After you edit the forest description file, you can use the rendom /showforest command to display the
new forest structure that is contained in the file. (This command does not have any effect on the directory
itself.) The user-friendly format uses indentations to reflect the domain hierarchy in the forest.

Transferring Domain Rename Instructions to Active Directory

After you create the new forest structure by editing the forest description file, the next step in the domain
rename process involves translating the new forest structure into a sequence of directory update
instructions to be executed individually on each domain controller in the forest. This translation occurs
when you issue the rendom /upload command, and the resultant domain rename instructions are
uploaded to the configuration directory partition at the domain controller that is currently the domain
naming operations master for the forest. The instructions are then replicated to all other domain
controllers in the forest through normal replication of the configuration directory partition. Only after
these rename instructions replicate to every domain controller in the forest and the required conditions are
verified at each domain controller can each domain controller proceed with executing the rename
instructions.

The following sections describe the details of the changes that are produced by the rendom /upload
command. The actual sequence of actions that occur in response to the command are described in
“Actions Performed by Rendom in Response to the rendom /upload Command” later in this section.

Domain Rename Script and State File

To transform the current forest structure into the target structure, Rendom translates the new forest
description to a set of update instructions that the domain controller uses to update its replica directory
partitions to make the name changes effective. The rendom /upload command generates the required
domain rename instructions, which are encoded in a special script format that is private to the
implementation. The rendom /upload command also generates the state file that is used to track the
progress of the domain rename operation.

Note

 The actions that are performed by the rendom /upload command and the resultant changes that
are made to the directory are in preparation for the rename operation. No domain name changes
occur at this step.

Domain rename script for update instructions

The script that is generated by the rendom /upload command is private to the domain rename procedure,
and it does not create the directory changes themselves. Rather, the script provides instructions for
domain controllers to execute in response to Rendom commands. The script is an XML-encoded
document that has three components:

 Test: a read transaction to validate that the directory replica at the domain controller is in an
appropriate state to perform an action.
 Action: an update transaction to be performed on the directory database at the domain controller.
  Signature: a cryptographic hash that proves to the domain controller that the script was prepared
by the Rendom utility (and, therefore, that it is authentic and correct) and not manually by
someone acting as an administrator.

State file for tracking

While translating the forest description to the update instruction script and transferring the script
containing the description to the directory, Rendom also generates the state file (which has the default
name DClist.xml). This file is structured as an XML-text document to facilitate tracking the state of each
domain controller as it progresses through the various steps of the domain rename process. This file
contains an entry for every domain controller in the forest. Each domain controller is identified by its
DNS host name, along with fields for its current state and the last error encountered on the domain
controller while it processed the domain rename instructions.

Preparing Domain Controllers for Domain Rename

When you run the rendom /upload command, certain changes occur on the domain naming operations
master in preparation for the actual execution of domain rename. On the domain naming master, the
XML-encoded script that contains the domain rename instructions is written to the single-valued, octet-
string attribute msDS-UpdateScript on the Partitions container object
(cn=partitions,cn=configuration,dc=ForestRootDomain) in the configuration directory partition. The
Partitions container can be updated only on the domain controller that is the domain naming master for
the forest; therefore, the msDS-UpdateScript attribute is necessarily changed on the domain controller
that holds the domain naming operations master role (also known as the flexible single master operations
(FSMO) role). From this source domain controller, the script that is stored in the msDS-UpdateScript
attribute replicates to all domain controllers in the forest through normal replication of the configuration
directory partition.

Establishing a DNS Alias for a New Domain Name

In addition to the msDS-UpdateScript value being written to the Partitions container, the new DNS name
of each domain being renamed is also written by Rendom to the single-valued, Unicode-string attribute
msDS-DnsRootAlias on the cross-reference object (class crossRef) that corresponds to that domain.
Again, because cross-reference objects are stored in the Partitions container and the Partitions container
can be updated only on the domain naming master, the msDS-DnsRootAlias attribute can be changed
only on the domain controller that holds the domain naming operations master role. From this source
domain controller, the DNS name in the msDS-DnsRootAlias attribute replicates to all domain
controllers in the forest through normal replication of the configuration directory partition.

Locator mechanism

Active 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 name

According to the client request, the Locator can use various specified criteria that map to values in the
SRV resource records to locate domain controllers with specific roles or capabilities. For example, the
Locator can find a domain controller that has a full, writable replica of a domain directory partition; a
domain replica in a specified site; or a domain controller that is a global catalog server. The owner name
in an SRV resource record provides the specific information about the type of domain controller to be
located. For example, a domain controller can be located in a specific site by using the following format:

_Service._Protocol.SiteName._sites.DnsDomainName

The following owner name in an SRV resource record specifies a domain controller (identified by the
LDAP service running over the TCP protocol) in the East site and the Cohowinery.com domain:

_ldap._tcp.east._sites.cohowinery.com
For more information about the Locator and the DNS resource records that are registered by an
Active Directory domain controller, see “How DNS Support for Active Directory Works.”

Publishing two sets of Locator SRV resource records in DNS

The directory service is extended in Windows Server 2003 forests to use the msDS-DnsRootAlias
attribute to support the concept of a DNS alias for a domain. The presence of this attribute prompts the
Net Logon service running on the domain controller to register the DNS domain name value of this
attribute in DNS.

With the addition of the msDS-DnsRootAlias attribute, the Net Logon service has the ability to register
not one but two domain names in DNS. The identities of the real (original) domain name and the alias
(target) domain name are established by publishing two sets of resource records in DNS, as follows:

 The real domain name is published in DNS. Each domain normally has a single DNS name. The
domain-specific DNS records that are published by the Net Logon service are derived from the
dnsRoot attribute on the cross-reference object for the domain, which holds the real DNS name
of the domain (as opposed to an alias). The forest-specific DNS records are derived from the
cross-reference object for the forest root domain, which holds the real name of the forest root
domain. The Net Logon service running on a domain controller also responds to Locator pings for
the domain name and performs secure channel setup between a computer that is joined to the
domain and the domain controller on which the Net Logon service runs.
 The alias domain name is published in DNS. Soon after the msDS-DnsRootAlias attribute value
on a cross-reference object is set on a domain controller, either by an originating write or by a
replicated write, the Net Logon service on the domain controller additionally publishes a parallel
set of DNS Locator records for the domain alias name that is held in the msDS-DnsRootAlias
attribute. The domain-specific DNS records are derived from the msDS-DnsRootAlias attribute
on the cross-reference object for the domain, and the forest-specific DNS records are derived
from the msDS-DnsRootAlias attribute on the cross-reference object for the forest root domain.
Further, on domain controllers for a domain whose msDS-DnsRootAlias value is set, the Net
Logon service responds to the Locator pings for the DNS alias as if the value in msDS-
DnsRootAlias were the real domain name. Also, secure channel setup from a domain member
that connects to a domain controller for a domain that is named in the msDS-DnsRootAlias
attribute succeeds as if it were the real domain name.
Note that in the published SRV resource record corresponding to the alias domain name, the owner field
reflects the new domain name, whereas the host name field reflects the actual DNS name of the domain
controller. For example, if the domain cohovineyard.com is being renamed to cohowinery.com, the Net
Logon service publishes the following two SRV resource records for the LDAP service on a domain
controller named DC01 in that domain:
_ldap._tcp.cohovineyard.com SRV 0 0 389 dc01.cohovineyard.com
_ldap._tcp.cohowinery.com SRV 0 0 389 dc01.cohovineyard.com

Note that in the second SRV record above, the owner field corresponds to the new name to which the
domain will be renamed, and the host name field reflects the true DNS name of the domain controller.

Prepublishing CNAME Records for Replication

The set of domain-specific resource records that are published in DNS by the Net Logon service running
on a domain controller includes a DNS CNAME record that 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.com

Note that in the second SRV record above, the owner field corresponds to the new name to which the
forest will be renamed, and the host name field reflects the true DNS name of the domain controller.

Before the domain rename process can continue to the next step, the prepublished CNAME records
corresponding to the value in msDS-DnsRootAlias must replicate to all DNS servers that are
authoritative for those records.

Establishing SPNs for a New Domain Name

The DSA on every domain controller writes a set of SPNs to the servicePrincipalName attribute on the
domain controller computer object in the domain directory partition. Among other things, SPNs are used
for mutual authentication between domain controllers during 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 SPNs

Soon after the value for the msDS-DnsRootAlias attribute on a cross-reference object is set on a domain
controller, either by an originating write or by a replicated write, the DSA on the domain controller
rewrites the SPNs on the domain controller computer object so that each SPN that includes the domain
name (or the forest root name) is present in two versions — one for the actual domain (or forest root)
name and one for the alias that is held in the msDS-DnsRootAlias attribute of the domain (or forest root)
cross-reference object. The SPN values that correspond to the domain name alias require prepublication
for the same reason that the DNS CNAME records do, that is, to shorten a cyclic condition that produces
the following error: “Cannot replicate because the SPN needed for mutual authentication cannot be read
from the directory replica; the required SPN value is not present in the directory replica because it is not
replicating.” Prepublication of the SPNs shortens the period during which the directory service is
unavailable during the forest restructuring.

Before the domain rename process can continue to the next step, the prepublished SPNs that correspond
to the value in msDS-DnsRootAlias must replicate to all domain controllers in the domain as well as to
all global catalog servers in the forest.

Actions Performed by Rendom in Response to the rendom /upload Command

The following sequence of actions occurs in response to the rendom /upload command:

 Rendom connects to the domain controller that holds the domain naming operations master role
for the forest and validates the forest description against the current state of the forest. If any of
these validity checks fails, the command fails now. The following requirements are verified:
o Each existing domain is part of the new forest.
o The new forest is well formed.
o The new forest does not reassign domain names that are being relinquished as part of the
current domain rename operation.
 While it is still connected to the domain naming master, Rendom retrieves all the information that
is needed to compute the list of rename instructions for updating the configuration and schema
directory partitions.
 Rendom connects to a randomly selected domain controller (or the domain controller that is
specified in the <DcName></DcName> field of the domain entry in the forest description file)
for each domain, one by one, and retrieves all the information that is needed to compute the list of
rename instructions for updating each domain.
 Rendom computes the full list of domain rename instructions for updating the entire forest
(creates the script) and computes a signature to include in the script so that the authenticity of the
script can be proven to a domain controller.
 While it is still connected to the domain naming master, Rendom writes the resulting script to the
msDS-UpdateScript attribute of the Partitions container.
 While it is still connected to the domain naming master, Rendom writes the msDS-DnsRootAlias
attribute of all cross-reference objects for domains that are being renamed.
On the control station (the computer from which the Rendom commands are issued), Rendom writes a
new state file to track the progress of every domain controller in the forest. The state file contains an entry
for every domain controller in the forest, with each domain controller entry marked to be in the Initial
state.

Note

 Because the msDS-UpdateScript and msDS-DnsRootAlias attributes are first written to the
directory on the domain controller holding the domain naming operations master role and then
replicated to the remaining domain controllers in the forest, if the domain naming master is
unavailable during the rendom /upload operation, the process cannot continue.

Side effect of the rendom /upload command on forest configuration

If certain types of changes in the forest are made after the domain rename operation begins, these changes
can affect the outcome of the rename operation and cause it to fail in such a way that some of the domain
controllers can never complete the domain rename process. To prevent this situation, successful execution
of the rendom /upload command freezes the forest configuration with respect to these types of changes
after the domain rename operation begins. The following operations cannot be performed in a forest after
the rendom /upload command has completed successfully:

 The addition or removal of a domain or application partition

 The addition or removal of a domain controller into or from an existing domain
 The addition or removal of trusts, including cross-forest trusts. (Note that attributes of an existing
trust can be changed during this frozen configuration. For example, a unidirectional trust can be
converted to a bidirectional trust.)

The forest configuration remains frozen as long as the msDS-UpdateScript attribute of the Partitions
container has a value that indicates that a domain rename operation is in progress. The forest
configuration becomes unfrozen at the conclusion of the domain rename operation through execution of
the rendom /end command.

Verifying Domain Controller Readiness

This step of the domain rename process verifies that the directory database at each domain controller in
the forest is adequately prepared to perform the directory modifications that are dictated by the script in
the msDS-UpdateScript attribute. In response to the rendom /prepare command, the necessary
verification is performed on each domain controller through execution of the test component of the script
in msDS-UpdateScript as a read-only transaction on the local directory database. The test checks for the
following conditions:

 The correct script in msDS-UpdateScript replicating to this domain controller

 Any trust relationships that are required by the new forest structure
 Prepublished SPNs for all domain controllers
 Name conflicts that are attributable to administrative errors since the time the script in msDS-
UpdateScript was created. For example, an administrator might have mistakenly removed a trust
that is required in the new forest or created a computer account whose SamAcountName equals
the new name of some trusted domain, creating a name conflict with an interdomain trust
account.

In addition, the test includes an authorization check on each domain controller to determine whether or
not the user running the rendom /prepare command is authorized to execute the domain rename
instructions that are contained in msDS-UpdateScript. The authorization check verifies that the user has
Write permission on the msDS-UpdateScript attribute on the Partitions container. If the user is not
authorized, the command fails with an error.

Actions Performed in Response to the rendom /prepare Command

The following sequence of actions occurs in response to the rendom /prepare command:

 Rendom issues a special RPC (for internal use only) to every domain controller in the forest in
turn, requesting authorization and verification of readiness as encoded in the test component of
the script in msDS-UpdateScript. Rendom issues the RPC to multiple domain controllers at a
time with a high degree of concurrency, while ensuring that resource limits on the computer that
is executing the command are not exceeded. The RPC request and response are signed and sealed
for integrity and privacy.
 In response to the RPC, each domain controller performs the authorization check, ensures the
authenticity of the script in msDS-UpdateScript by validating the signature, and verifies the test
component of the domain rename script before responding. If any of these checks fails on a
domain controller, the RPC returns an error for that domain controller.
  Rendom updates the state file with the state of each domain controller that was successfully
contacted and verified. The state of each successfully verified domain controller is updated from
the Initial state to the Prepared state. The Prepared state indicates that the domain controller
authorized the execution of the restructure and that the contents of its directory database are
consistent with the rename instructions that are contained in msDS-UpdateScript. If a domain
controller cannot be contacted or if it fails any of the checks, its corresponding state in the state
file remains as Initial with an appropriate error code and message to indicate the cause of failure.

Executing Domain Rename Instructions

In the final step of the domain rename process, the directory database at each domain controller in the
forest is updated individually to implement the new forest structure. This process does not rely on
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 Mode

To perform the action component of the script in msDS-UpdateScript, the directory service on each
domain controller enters a special mode called single-user mode. In single-user mode, 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 Transaction
All the directory updates that are specified by the action component of the script in msDS-UpdateScript
are performed within an Extensible Storage Engine (ESE) database transaction. If no errors occur, the
transaction is committed; otherwise, the entire transaction is rolled back. Domain controllers that commit
the update transaction in single-user mode and then reboot are considered to have completed the domain
rename.

Entering single-user mode

As part of a successful update transaction, the nonreplicated, single-valued integer attribute msDS-
ReplicationEpoch on the NTDS Settings object for the domain controller is updated to a new value
through incrementation of its current value. If two domain controllers have different msDS-
ReplicationEpoch values, no directory replication RPC interaction is allowed between them. In addition
to replication, nested group membership evaluation and global catalog lookups are also discontinued.
Because the domain rename procedure involves making these updates independently at all domain
controllers in the forest, it is impossible to modify these domain controllers simultaneously. The goal of
the msDS-ReplicationEpoch attribute is to minimize potentially complex interactions, including
replication, between those domain controllers that have completed the domain rename and those domain
controllers that have not yet completed the domain rename.

Switching real and alias DNS names

Further, as part of a successful update transaction, the values of the dnsRoot and msDS-DnsRootAlias
attributes on the cross-reference objects of renamed domains are interchanged so that the new domain
name, formerly stored in msDS-DnsRootAlias, becomes the effective domain name that is stored in
dnsRoot. The old domain name is saved as a DNS alias until a subsequent step removes it.

Actions Performed in Response to the rendom /execute Command

The following sequence of actions occurs in response to the rendom /execute command:

 Rendom checks to ensure that all domain controllers in the state file are marked with a current
state of Prepared. If the state of any domain controller is not Prepared, Rendom reports an error
and the process cannot continue.
 When all domain controllers in the state file are in the Prepared state, Rendom issues a special
RPC (for internal use only) to every domain controller in the forest requesting execution of the
directory updates that are encoded in the action component of the script in msDS-UpdateScript.
 Rendom issues the RPC to multiple domain controllers at a time with a high degree of
concurrency, while ensuring that resource limits on the computer that is executing the command
are not exceeded. The RPC request and response are signed and sealed for integrity and privacy.
 In response to the RPC, each domain controller first verifies the test component of the domain
rename script in msDS-UpdateScript (just as in the previous step that checks for domain
controller readiness). The domain controller then performs the action component of the script in
an update transaction, as described in “Update Transaction” earlier in this section. If any check
fails on a domain controller or if the update transaction cannot be successfully committed, the
RPC returns an error for that specific domain controller.
 Rendom updates the state file with the state of each domain controller that was successfully
contacted. For each domain controller that successfully completed the update, Rendom changes
the state from Prepared to the final state of Done. If a domain controller cannot be contacted or if
it fails any of the checks, its corresponding state in the state file remains Prepared, with an
appropriate error code and message to indicate the cause of failure. If the RPC returns with an
error that is deemed irrecoverable, the corresponding state for the domain controller is updated to
the final state of Error, with an appropriate error code and message to indicate the cause of
failure.

Determining Domain Rename Completion

In a large forest, some number of domain controllers might prove impossible to contact during the domain
rename process. These domain controllers never reach the final state of Done. You must decide how long
to continue to try to reach domain controllers that are unreachable and how long to retry failed update
attempts on domain controllers that have reached the Error state. When further progress in the forest is not
possible, declare the domain rename process to be complete. All domain controllers that did not reach the
final Done state, because they were either unreachable or finished in the Error state, must be demoted (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 Rename

When the DNS name of a domain changes, any references to Group Policy objects (GPOs) in the renamed
domain through Group Policy links (the gpLink attribute) on sites, domains, and OUs are rendered
invalid because they are based on the old domain name. Further, the optional attribute gpcFileSysPath on
a GPO that holds a uniform naming convention (UNC) path to a Group Policy templates folder located in
the SYSVOL of the renamed domain is also rendered invalid because the path uses the old domain DNS
name. To correct the severed Group Policy links and the invalid UNC paths in GPOs in the renamed
domain, you can use a Group Policy tool, Gpfixup.exe, to refresh the Group Policy links and the UNC
paths in GPOs that are based on the new domain name. The Gpfixup tool is available for download in
Windows Server 2003 Domain Rename Tools on the Microsoft Web site. Run Gpfixup once for every
renamed domain soon after the actual domain rename operation is complete and before another domain
rename operation is performed.

Note

 Gpfixup refreshes all intradomain GPO references or links (that is, where the link and the target
GPO are in the same domain) in the renamed domain. However, cross-domain references to
GPOs in the renamed domain (that is, where the link is in a different domain from the domain
containing the GPO) are not rebuilt automatically by this tool. For these cross-domain references
to work, you must repair the cross-domain links manually by deleting the old Group Policy links
and re-establishing new links.

Removing Old Domain Names After a Domain Rename

Following completion of the domain rename process for a forest, you use the rendom /clean command to
remove the old domain names from 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.
What Are Domains and Forests?
The Active Directory directory service is a distributed database that stores and manages information about
network resources, as well as application-specific data from directory-enabled applications. Active
Directory allows administrators to organize objects of a network (such as users, computers, and devices)
into a hierarchical collection of containers known as the logical structure. The top-level logical container
in this hierarchy is the forest. Within a forest are domain containers, and within domains are
organizational units.

Understanding domains and forests requires understanding the possible relationships they might have in
Active Directory. The relationships between these logical containers might be based on administrative
requirements, such as delegation of authority, or they might be defined by operational requirements, such
as the need to provide for data isolation. Service administrators can use domain and forest containers to
meet a number of specific requirements, including:

 Implementing an authentication and authorization strategy for sharing resources across a network
 Providing a mechanism for centralizing management of multiple domains and forests
 Providing an information repository and services to make information available to users and
applications
 Organizing objects of a network (such as users, computers, devices, resources, and application
specific data from directory-enabled applications) into a non-physical hierarchical structure

To learn more about domains and forests, you must first understand the logical and physical structures of
Active Directory. This section describes how those structures differ, and defines domains and forests in
terms of the logical structure.

The Logical Structure of Active Directory

Active Directory stores network object information and implements the services that make this
information available and usable to users. Active Directory presents this information through a
standardized, logical structure that helps you establish and understand the organization of domains and
domain resources in a useful way. This presentation of object information is referred to as the logical
structure because it is independent of the physical aspects of the Active Directory infrastructure, such as
the domain controllers required for each domain in the network.
Benefits of the Logical Structure

The logical structure provides a number of benefits for deploying, managing, and securing network
services and resources. These benefits include:

 Increased network security. The logical structure can provide security measures such as
autonomy for individual groups or complete isolation of specific resources.
 Simplified network management. The hierarchical nature of the logical structure simplifies
configuration, control, and administration of the network, including managing user and group
accounts and all network resources.
 Simplified resource sharing. The logical structure of domains and forests and the relationships
established between them can simplify the sharing of resources across an organization.
 Low total cost of ownership. The reduced administration costs for network management and the
reduced load on network resources that can be achieved with the Active Directory logical
structure can significantly lower the total cost of ownership.

An efficient Active Directory logical structure also facilitates the system integration of features such as
Group Policy, enabling desktop lockdown, software distribution, and administration of users, groups,
workstations, and servers. In addition, the logical structure can facilitate the integration of services such
as Exchange 2000, public key infrastructure (PKI), and domain-based distributed file system (DFS).

Components of the Logical Structure

The logical structure consists of leaf object and container object components that must conform to the
hierarchical structure of an Active Directory forest. Leaf objects are objects that have no child objects,
and are the most basic component of the logical structure. Container objects store other objects and
occupy a specific level within the forest hierarchy.

The relationships among the components of the logical structure control access to stored data and
determine how that data is managed across one or more domains within a single forest. The components
that make up the Active Directory logical structure are described in the following table.

Components of the Active Directory Logical Structure

Component Description
 Organizational units are container objects. You use these container objects to arrange
other objects in a manner that supports your administrative purposes. By arranging
objects in organizational units, you make it easier to locate and manage them. You can
also delegate the authority to manage an organizational unit. Organizational units can
be nested in other organizational units.
Organizational
Units
You can arrange objects that have similar administrative and security requirements into
organizational units. Organizational units provide multiple levels of administrative
authority, so that you can apply Group Policy settings and delegate administrative
control. This delegation simplifies the task of managing these objects and enables you
to structure Active Directory to fit your organization’s requirements.

Domains are container objects. Domains are a collection of administratively defined

objects that share a common directory database, security policies, and trust
Domains relationships with other domains. In this way, each domain is an administrative
boundary for objects. A single domain can span multiple physical locations or sites and
can contain millions of objects.

Domain trees are collections of domains that are grouped together in hierarchical
structures. When you add a domain to a tree, it becomes a child of the tree root domain.
The domain to which a child domain is attached is called the parent domain.

Domain Trees
A child domain might in turn have its own child domain. The name of a child domain is
combined with the name of its parent domain to form its own unique Domain Name
System (DNS) name such as Corp.nwtraders.msft. In this manner, a tree has a
contiguous namespace.

A forest is a complete instance of Active Directory. Each forest acts as a top-level

container in that it houses all domain containers for that particular Active Directory
instance. A forest can contain one or more domain container objects, all of which share
a common logical structure, global catalog, directory schema, and directory
Forests configuration, as well as automatic two-way transitive trust relationships. The first
domain in the forest is called the forest root domain. The name of that domain refers to
the forest, such as Nwtraders.msft. By default, information in Active Directory is
shared only within the forest. In this way, the forest is a security boundary for the
information that is contained in that instance of Active Directory.
 Sites are leaf and container objects. The sites container is the topmost object in the
hierarchy of objects that are used to manage and implement Active Directory
replication. The sites container stores the hierarchy of objects that are used by the
Knowledge Consistency Checker (KCC) to effect the replication topology. Some of the
Site Objects
objects located in the sites container include NTDS Site Settings objects, subnet
objects, connection objects, server objects, and site objects (one site object for each site
in the forest). The hierarchy is displayed as the contents of the Sites container, which is
a child of the Configuration container.

By understanding the purpose and hierarchical structure of these components, you can complete a variety
of tasks, including installing, configuring, managing, and troubleshooting Active Directory. Although the
logical structure of Active Directory is a hierarchical organization of all users, computers, and other
physical resources, the forest and domain form the basis of the logical structure.

Forests, which are the security boundaries of the logical structure, can be structured to provide data and
service autonomy and isolation in an organization in ways that can both reflect site and group identities
and remove dependencies on the physical topology. Domains can be structured within a forest to provide
data and service autonomy (but not isolation) and to optimize replication with a given region.

This separation of logical and physical structures improves manageability and reduces administrative
costs because the logical structure is not impacted by changes in the physical structure, such as the
addition, removal, or reorganization of users and groups.

Note

 You can view and manage components of the logical structure by using the Active Directory
Users and Computers, Active Directory Domains and Trusts, and Active Directory Schema
Microsoft Management Console (MMC) snap-ins, and other tools.

The Physical Structure of Active Directory

The physical structure of Active Directory is represented by a set of physical components which, when
configured correctly, can help optimize the transmission of network replication and authentication in
ways specifically tailored to fit your physical network. Physical network components, such as domain
controllers and physical subnets, are used to facilitate network communication and to set physical
boundaries around network resources. More specifically, the physical structure of Active Directory
represents all of the physical subnets in your enterprise network, the domain controllers in those physical
subnets (commonly referred to as Sites in Active Directory) and the replication connections between the
domain controllers.

Sites and subnets are represented in Active Directory by site and subnet objects. Computers on TCP/IP
networks are assigned to site objects based on their location in a physical subnet or a set of physical
subnets. Physical subnets group computers in a way that identifies their physical proximity on the
network. Each site object is associated with one or more subnet objects. Subnet objects are used during
the process of domain controller location to find a domain controller in the same site as the computer that
is logging on. This information also is used during Active Directory replication to determine the best
routes between domain controllers. This enables you to use network bandwidth more efficiently. For
example, it ensures that when users log on to the network they are authenticated by the authentication
authority nearest to the user, thus reducing the amount of network traffic.

The physical domain controller contains the directory partitions that are replicated. Although the logical
and physical structures are defined and configured independently, they have interdependencies that affect
replication.

Note

 You can view the physical structure of Active Directory by using Active Directory Sites and
Services.

For more information about the network components associated with the physical structure of Active
Directory, see the “Active Directory Replication Topology Technical Reference.”

What Are Domains?

Domains are logical directory components that you create to manage the administrative requirements of
your organization. The logical structure is based on the administrative requirements of an organization,
such as the delegation of administrative authority, and operational requirements, such as the need to
control replication. In general, domains are used to control where in the forest replication of domain data
occurs and organizational units are used to further organize network objects into a logical hierarchy and
delegate control to appropriate administrative support personnel.
A domain is a partition in an Active Directory forest. Partitioning data enables organizations to replicate
data only to where it is needed. In this way, the directory can scale globally over a network that has
limited available bandwidth. Domains can also be defined as:

 Containers within a forest

 Units of Policy
 Units of Replication
 Authentication and Authorization Boundaries
 Units of Trust

Each domain has a domain administrators group. Domain administrators have full control over every
object in the domain. These administrative rights are valid within the domain only and do not propagate to
other domains.

Domains as Containers Within a Forest

Within the scope of a forest, a domain is a container. Objects in that container inherently trust each other
and the security services located in that same container. Each time you create a new domain container in a
forest, a two-way, transitive trust relationship is automatically created between the new domain and its
parent domain. Trusts are logical relationships established between domains to allow pass-through
authentication in which a trusting domain honors the logon authentications of a trusted domain. Because
all domain containers within a forest are joined together by two-way transitive trusts, objects within one
domain container also inherently trust all other objects and security services located in every domain
container located in that forest.

Domain containers are used to store and manage Active Directory objects, some of which have a physical
representation. All of the objects within the domain container are stored in a central database that stores
only objects created within that domain. Some objects represent people or groups of people, while others
represent computers or network servers. Examples of Active Directory objects that have a physical
representation are user, computer, and group objects.

While domains contain objects that represent physical things, they also contain objects that are used to
help self-regulate domain operations such as trusted domain objects (TDOs) and site link objects. Domain
containers can also hold subordinate containers such as organizational units. The following figure shows
where objects are stored within the logical structure of a domain.
Domain Containment Structure Within a Forest

Organizational Units and Objects

Organizational units are used to group objects, including accounts and resources in a domain, for
administrative purposes, such as the application of Group Policy or delegation of authority. Control over
an organizational unit, including the objects within it, is determined by the access control lists (ACLs) on
the organizational unit and on the objects in the organizational unit.

Organizational Units

The organizational unit is a particularly useful type of directory object contained within domains. Each
organizational unit is an Active Directory container within a domain into which users, groups, computers,
and other organizational units of the domain can be placed. An organizational unit cannot contain objects
from other domains.

An organizational unit is the smallest scope or unit to which Group Policy settings can be assigned or to
which administrative authority can be delegated. A hierarchy of organizational units can be extended as
necessary to model the hierarchy of an organization within a domain. The administrative model of the
organizational unit can be scaled to any size. For more information about Group Policy, see “How Core
Group Policy Works.”

Administrative authority can be delegated for individual organizational units or for multiple
organizational units. Organizational units can be nested to create a hierarchy within a domain and form
logical administrative units for users, groups, and resource objects, such as printers, computers,
applications, and file shares. The organizational unit hierarchy within a domain is independent of the
structure of other domains: Each domain can implement its own hierarchy. Likewise, domains that are
managed by the central authority can implement similar organizational unit hierarchies. The structure is
flexible, which allows organizations to create an environment that mirrors the administrative model,
whether it is centralized or decentralized.

Objects

Active Directory objects represent the physical entities that make up a network. An object stores an
instance of a class. A class is defined in the Active Directory schema as a specific set of mandatory and
optional attributes — that is, an attribute can be present in an object in Active Directory only when that
attribute is permitted by the object’s class. Classes also contain rules that determine which classes of
objects can be superior to (parents of) a particular object of the class. Each attribute is also defined in the
directory schema. The attribute definitions determine the syntax for the values the attribute can have.

Creation of an Active Directory object requires specification of values for the attributes of the object in its
particular class, consistent with the rules of the directory schema. For example, creating a user object
requires specification of alphanumeric values for the user’s first and last names and the logon identifier,
which are mandatory according to the directory schema. Other non-mandatory values can also be
specified, such as telephone number and address.

Applications that create or modify objects in Active Directory use the directory schema to determine what
attributes the object must and might have, and what those attributes can look like in terms of data
structures and syntax constraints. The directory schema is maintained forest-wide so that all objects
created in the directory conform to the same values.

Objects are either container objects or leaf objects. A container object stores other objects, and as such
occupies a specific level in a subtree hierarchy. An object class is a container if at least one other class
specifies it as a possible superior, so any object class defined in the schema can become a container. A
leaf object does not store other objects, so it occupies the endpoint of a subtree. For more information
about Active Directory Objects, see “How Domains and Forests Work” and “How the Active Directory
Schema Works.”

Domains as Units of Policy

A domain defines a scope or unit of policy within a forest. Some policy settings apply only to the scope of
a domain, that is, the policy settings are domain-wide. Account policies, for example, apply uniformly to
all user accounts in the domain. Although a domain is not the smallest unit of policy that can be assigned
(policies can be assigned to organizational units) it is the most commonly used unit when splitting
administrative duties between departments and subsidiaries located in different geographical locations. As
shown in the following figure, you might need to create multiple domains to provide for policy variance
among domains throughout a forest. A domain is also considered a unit of access control, in that it can be
used for business groups requiring general autonomy.

Delegation of Domains to Domain Admins that Require Different Policies or Autonomy

You cannot define different account policies for different organizational units in the same domain. Policy
settings are stored as Group Policy objects (GPOs) in Active Directory. A GPO establishes how domain
resources can be accessed, configured, and used. The policies associated with a GPO are applied only
within the domain and not across domains. A GPO can be associated with one or more Active Directory
containers, such as a site, domain, or organizational unit.

Account policies and Public Key policies have domain-wide scope and are set at the domain GPO level.
All other policies can be specified at the level of the organizational unit. Some policies that can be applied
only at the domain container level include:

 Password policy. Determines the rules, such as password length, that must be met when a user
sets a password.
 Account lockout policy. Defines rules for intruder detection and account deactivation.
 Kerberosticket policy. Determines the lifetime of a Kerberos ticket. A Kerberos ticket is obtained
during the logon process and is used for network authentication. A particular ticket is only valid
for the lifetime specified in the policy.

Because organizational units provide multiple levels of administrative authority, you can use them to
systematically apply Group Policy settings and delegate administrative control. Delegation simplifies the
task of managing these objects and enables you to structure Active Directory to fit the requirements of
your organization. Using delegated authority in conjunction with GPOs and group memberships allows
one or more administrators to be assigned rights and permissions to manage objects in an entire domain or
in one or more organizational units within the domain.

For more information about Group Policy, see “How Core Group Policy Works.”

Domains as Units of Replication

The physical significance of a domain is that it is a unit of replication. In fact, with the exception of
application partitions, which replicate only non-security principal objects, the domain is the smallest unit
of replication that can be administered within an Active Directory forest. This is because all objects that
are located within a domain container, also referred to as domain data, are replicated to other domain
controllers within that same domain, regardless of whether those domain controllers are located over a
local area network (LAN) or wide area network (WAN) connection.
As shown in the following figure, Active Directory multi-master replication manages the transfer of
domain objects to the appropriate domain controllers automatically, keeping domain data up-to-date
among all domain controllers in the domain, regardless of location.

Replication of Domain Data Within Each Domain in the Forest

All domain controllers in the forest are also updated with changes to forest-wide data. For more
information about replication at the Forest level, see “Forests as Units of Replication” later in this section
Domain-wide replication relies on three components of the Active Directory physical structure to be in
place for optimal performance, these include:

Domain Controllers
The physical domain controller contains the domain partition data that is replicated to other domain
controllers in that same domain. A domain partition stores only the information about objects located in
that domain. All domain controllers in a domain receive changes and replicate those changes to the
domain partition stored on all other domain controllers in the domain. In this way, all domain controllers
are peers in the domain and manage replication as a unit.

Domain controllers also have two non-domain directory partitions that store forest-wide data, which
includes the directory schema and configuration data. Optionally, on Windows Server 2003 domain
controllers, application partitions can be configured to be located on designated domain controllers
anywhere in a forest. Unlike the schema and configuration partitions, application partitions are not located
on every domain controller in a forest. For more information about the replication of forest-wide data, see
“Forests as Units of Replication” later in this section.

Partitioning Active Directory data into three physical partitions on each domain controller helps to control
replication so that data is replicated only to where it is needed. In this way, Active Directory can scale
globally over a network that has limited available bandwidth.

Sites

Within the scope of a forest, sites are a representation of the physical network topology. This includes
physical subnet and site definitions. Replication of updates to domain data occurs between multiple
domain controllers to keep replicas synchronized. Multiple domains are common in large organizations,
as are multiple sites in disparate locations. In addition, domain controllers for the same domain are
commonly placed in more than one site.

Therefore, replication must often occur both within sites and between sites to keep domain and forest data
consistent among domain controllers that store the same directory partitions. Replication within sites
generally occurs at typical LAN speeds between domain controllers that are on the same network
segment. Replication between sites usually occurs over WAN links that might be costly in terms of
bandwidth. To accommodate the differences in distance and cost of replication within a site and between
sites, the intrasite replication topology is used to optimize speed, and the intersite replication topology is
used to minimize cost based on a configurable replication schedule.

The Knowledge Consistency Checker (KCC) is a distributed application that runs on every domain
controller and is responsible for creating the connections between domain controllers that collectively
form the replication topology. The KCC uses Active Directory data to determine where to create
connections between source domain controllers and destination domain controllers.

Intersite replication is optimized for bandwidth efficiency, and directory updates between sites occur
automatically based on a configurable schedule.

Domain-Wide Operations Masters

Active Directory supports multi-master replication of the directory data store between all domain
controllers in the domain. However, some changes are impractical to perform in multi-master fashion, so
only a single domain controller, called the operations master, accepts requests for such changes. Because
these roles can be transferred to other domain controllers within the domain or forest, they are sometimes
referred to as operations master roles.

There are three operations master roles per domain. These include the Relative Identifier (RID) Master,
Primary Domain Controller (PDC) emulator, and Infrastructure Master. These three roles must be unique
in each domain, so each domain can have only one RID master, one PDC emulator, and one Infrastructure
Master. For information about forest-wide roles, see “Forest-Wide Operations Master Roles” later in this
section. For more information about replication, see “How Active Directory Replication Topology
Works.”

Domains as Authentication and Authorization Boundaries

By default, a domain provides authentication and authorization services for all its accounts in order to
facilitate logons and single sign-on access control to shared resources within the boundaries of the
domain. The process of authentication ensures that users are who they claim to be. Once identified, the
user can be authorized access to a specific set of network resources based on permissions.Authorization
takes place through the mechanism of access control, using access control lists (ACLs) that define
permissions on file systems, network file and print shares, and entries in Active Directory.

Authorization is determined not only by the identity of the user but also the membership of the user in one
or more security groups. In fact, the preferred method of controlling domain-wide resources is to grant
access to groups rather than to individuals, adjusting the level of authorization for a group according to
the needs of its members. This method of controlling access makes it easier to keep ACLs up-to-date on
domains that have thousands of users and objects. Group membership can be managed centrally by
anyone with the appropriate administrative credentials. You can change the level of authorization a
particular user has to many resources simply by adding or removing the user from a group. The following
figure shows when authentication and authorization for a user in a given domain occur.

Authentication and Authorization of a User Within the Same Domain

Authentication is not limited to users. Computers and services are also authenticated when they make
network connections to other servers. For example, Windows Server 2003–based servers and client
computers connect Active Directory in their domain for policy information during startup. Computers and
services also prove their identity to clients that request mutual authentication. Mutual authentication
prevents an intruder from adding another computer as an imposter between the client and the real network
server. The Kerberos version 5 authentication protocol is a technology for single sign-on to network
resources. Windows Server 2003 uses the Kerberos V5 protocol to provide single sign-on to network
services within a domain, and to services residing in trusted domains. The Kerberos V5 protocol verifies
both the identity of the user and of the network services, providing mutual authentication.

Authentication and authorization services in one domain can be extended to accounts that are located in
trusted domains. This can be done by using trusts. Trusts are logical relationships established between
domains to allow pass-through authentication in which a trusting domain honors the logon authentications
of a trusted domain. Consequently, trust relationships inherently allow domain-specific authentication and
authorization services to be extended, thereby enabling single sign-on access control capabilities
throughout a forest. Because the domain trust relationships between all domains in the forest are
bidirectional by default, authentication in one domain is sufficient for referral or pass-through
authentication to resources in other domains in the forest.

Domains as Units of Trust

A domain is the smallest container within Active Directory that can be used in a trust relationship. All
domains within a forest are connected by Kerberos-based trusts. Kerberos-based trusts are two-way and
transitive in nature. Trusts act as authentication pipelines that must be present in order for users in one
domain to access resources in another domain. All authentication requests made between domains located
inside or outside of a forest must occur over trusts. Trust relationships within a forest are created as
implicit two-way transitive trusts.

Note

 “Access to resources” in any discussion of trust relationships always assumes the limitations of
access control.

Within a forest, trust relationships are automatically created between the forest root domain and any tree
root domains on the one hand, and all child domains that are subordinate to the forest root domain on the
other. Because trust relationships are two-way and transitive by default, users and computers can be
authenticated between any domain containers in the forest, as shown in the following figure.

Domains as Units of Trust and the Authentication Paths they Provide

In accordance with DNS naming standards, Active Directory domains within a single forest are created in
an inverted tree structure, with the forest root domain at the top. This tree structure requires that trusts
exist between domains to facilitate security of communications. Adding a domain tree to a forest requires
specification of the forest root domain, which results in the establishment of a trust relationship between
the root domain of the new tree and the forest root domain. For more information about trusts and root
domains, see “Forests as Collections of Domain Containers that Trust Each Other” later in this section.

What Domains Are Not

Domains are not security boundaries within the scope of Active Directory and do not provide complete
isolation in the face of possible attacks by malicious service administrators who might manage that forest.
This is because a malicious service administrator, such as a member of the Domain Admins group, can
use nonstandard tools and procedures to gain full access to any domain in the forest or to any computer in
the forest. For example, service administrators in a non-root domain can make themselves members of the
Enterprise Admins or Schema Admins group.

However, administrative rights do not flow across domain boundaries, nor do they flow down through a
domain tree. For example, if you have a domain tree with domains A, B, and C, where A is the parent
domain of B and B is the parent domain of C, users with administrative rights in domain A do not have
administrative rights in B, nor do users with administrative rights in domain B have administrative rights
in domain C. For a user to obtain administrative rights in a given domain, a higher authority must grant
them. This does not mean, however, that an administrator cannot have administrative rights in multiple
domains; it simply means that all rights must be explicitly defined.

For more information about isolation, see “Forests as Security Boundaries” later in this section.

What Are Forests?

At its highest level, a forest is a single instance of Active Directory. Therefore, a forest is synonymous
with Active Directory, meaning that the set of all directory partitions in a particular Active Directory
instance (which includes all domain, configuration, schema and optional application information) makes
up a forest. This means that when you have multiple forests in an enterprise they will, by default, act
separately from each other as if they were the only directory service in your organization.

This behavior, however, is easily be modified so that multiple forests can share Active Directory
responsibilities across an enterprise. This is done by creating external or forest trust relationships between
the forests. In this way, each forest can be connected with every other forest to form a collaborative
directory service solution for any enterprise with business needs that include multiple forest collaboration.

Forests can also be defined as:

 Collections of Domain Containers that Trust Each Other

 Units of Replication
 Security Boundaries
 Units of Delegation

Forests as Collections of Domain Containers that Trust Each Other

Within the scope of Active Directory, a forest is a collection of domain containers that inherently trust
each other and other security services that are located in that same forest. All domain containers in a
forest share a common global catalog, directory schema, and directory configuration, as well as automatic
two-way transitive trust relationships. Because all of the domain containers are inherently joined through
two-way transitive trusts, all authentication requests made from any domain in the forest to any other
domain in the same forest will be granted. In this way, all security principals that are located in domain
containers within a forest inherently trust each other.

Forests can be used to segregate domain containers into one or more unique DNS namespace hierarchies
known as domain trees. Although each domain tree consists of a unique namespace the schema and
configuration data for the forest are shared throughout all the domain containers in a forest irrespective of
namespace. Each domain container in a forest must adhere to DNS naming schemes and all domains are
organized in a root and subordinate domain hierarchy. Root domains, such as forest root and tree root
domains, define the DNS namespace for their subordinate domains. Although a forest can consist of
multiple domain trees, it represents one organization. However, an organization can have multiple forests.
For more information about multiple forests, see “Forests as Units of Delegation” later in this section. As
shown in the following figure, the namespace for each root domain must be unique.

Domain Containers, Root Domains and DNS Namespaces Within a Forest

Forest Root Domain

Although trees in a forest do not share the same DNS namespace, a forest does have a single root domain,
called the forest root domain. The forest root domain is, by definition, the first domain created in the
forest. The Enterprise Admins and Schema Admins groups are located in this domain. By default,
members of these two groups have forest-wide administrative credentials. In Windows 2000 Active
Directory, the forest root domain cannot be deleted, changed, or renamed. In Windows Server 2003
Active Directory, the forest root domain cannot be deleted, but it can be restructured or renamed.

Objects are located within Active Directory domains according to a hierarchical path, which includes the
labels of the Active Directory domain name and each level of container objects. The full path to the object
is defined by the distinguished name (also known as a DN). The distinguished name is unambiguous
(identifies one object only) and unique (no other object in the directory has this name). By using the full
path to an object, including the object name and all parent objects to the root of the domain, the
distinguished name uniquely and unambiguously identifies an object within a domain hierarchy.
The distinguished name of the forest root domain is used to locate the configuration and schema directory
partitions in the namespace. The distinguished names for the Configuration and Schema containers in
Active Directory always show these containers as child objects in the forest root domain. For example, in
the child domain Noam.wingtiptoys.com (where Wingtiptoys.com is the name of the forest root domain),
the distinguished name of the Configuration container is cn=configuration,dc=wingtiptoys,dc=com. The
distinguished name of the Schema container is cn=schema,cn=configuration,dc=wingtiptoys,dc=com.
However, this naming convention provides only a logical location for these containers.

These containers do not exist as child objects of the forest root domain, nor is the schema directory
partition actually a part of the configuration directory partition: They are separate directory partitions.
Every domain controller in a forest stores a copy of the configuration and schema directory partitions, and
every copy of these partitions has the same distinguished name on every domain controller.

Tree Root Domain

A domain tree represents a unique DNS namespace: it has a single root domain, known as the tree root
domain, and is built as a strict hierarchy: Each domain above the tree root domain has exactly one
superior, or parent, domain (the forest root domain). The namespace created by this hierarchy, therefore,
is contiguous — each level of the hierarchy is directly related to the level above it and to the level below
it. In other words, the names of domains created beneath the tree root domain (child domains) are always
contiguous with the name of the tree root domain. The DNS names of the child domains of the root
domain of a tree reflect this organization; therefore, the children of a root domain called Somedomain are
always children of that domain in the DNS namespace (for example, Child1.somedomain,
Child2.somedomain, and so forth).

Multiple domain trees can belong to a single forest and do not form a contiguous namespace; that is, they
have noncontiguous DNS domain names. Although the roots of the separate trees have names that are not
contiguous with each other, the trees share a single overall namespace because names of objects can still
be resolved by the same Active Directory instance. A forest exists as a set of cross-reference objects and
trust relationships that are known to the member trees. Transitive trusts at the root domain of each
namespace provide mutual access to resources.

The domain hierarchy in a forest determines the transitive trust links that connect each domain. Each
domain has a direct trust link with its parent and each of its children. If there are multiple trees in a forest,
the forest root domain is at the top of the trust tree and, from a trust perspective, all other tree roots are
children. That means authentication traffic between any two domains in different trees must pass through
the forest root.

Forests as Units of Replication

Unlike domains, forests are the largest unit of replication that can be administered in an Active Directory
environment. To efficiently synchronize data between domain controllers throughout a forest, Active
Directory replication transfers updates according to directory partition. Directory partitions are used to
help organize how replication occurs within a forest. Active Directory uses four distinct directory
partition types to store and copy four different types of data.

One directory partition contains domain data; the other three are forest-wide partitions, and contain
configuration, schema, and application data. This storage and replication design provides directory
information to users and administrators throughout the domain. Each domain controller receives directory
updates to the data stored in its domain only, as well as updates to the data in the two directory partitions
that store configuration and schema data for the forest. As shown in the following figure, schema and
configuration data must be replicated to all domain controllers that exist in a forest, while optional
Application data is replicated only to domain controllers within the same forest running Windows
Server 2003 that are specified as replication partners.

Forest-Wide Replication Scope

The following table describes each of the three forest-wide partitions in more detail.

Forest-Wide Directory Partitions

Partition Description

The schema partition contains the forest-wide schema. Each forest has one schema so that
Schema
the definition of each object class is consistent. The schema is the formal definition of all
 object and attribute data that can be stored in the directory. Active Directory domain
controllers include a default schema that defines many object types, such as user and
computer accounts, groups, domains, organization units, and security policies.
Administrators and programmers can extend the schema by defining new object types
and attributes or by adding new attributes for existing objects. Schema objects are
protected by access control lists, ensuring that only authorized users can alter the schema.
The schema partition is replicated to each domain controller in the forest.

The configuration partition describes the topology of the forest as well as other forest,
domain and domain controller settings. This configuration data includes a list of all
Configuration
domains, trees, and forests and the locations of the domain controllers and global
catalogs. The configuration partition is replicated to each domain controller in the forest.

Applications and services can use application directory partitions to store application-
specific data. Data stored in the application directory partition is intended to satisfy cases
where information needs to be replicated but not necessarily on a global scale.
Application directory partitions can contain any type of object, except security principals.
Application directory partitions are usually created by the applications that will use them
to store and replicate data. One of the benefits of an application directory partition is that,
for redundancy, availability, or fault tolerance, the data in it can be replicated to different
Application
domain controllers in a forest. The data can be replicated to a specific domain controller
or any set of domain controllers anywhere in the forest. This differs from a domain
directory partition in which data is replicated to all domain controllers in that domain.

Only domain controllers running Windows Server 2003 can host a replica of an
application directory partition. Application directory partitions are created, configured,
and managed by the administrator.

All forest replication is Multi-Master with the exception of the three domain-wide and two forest-wide
operations master roles. Forest-wide replication requires domain controllers and three other components
of the Active Directory physical structure to be in place for optimal performance. These components are
forest-wide operations master roles, sites, and global catalogs.

Forest-Wide Operations Master Roles

There are two operations master roles assigned for the entire forest. These include the domain naming
master and the schema master. Each forest must have one and only one schema master and one domain
naming master, so these two roles must remain in the forest root domain. The other three operations
master roles are assigned to each domain in the forest. These three roles must be unique in each domain,
so each domain can have only one relative ID master, one PDC emulator, and one infrastructure master.

In an Active Directory forest with only one domain and one domain controller, that domain controller has
all the operations master roles. For more information about operations master roles, see “How Operations
Masters Work.”

Sites

Sites in Active Directory represent the physical structure, or topology, of the network. Within the scope of
a forest, sites are a representation of the physical network topology, including physical subnet and site
definitions. When you establish sites, domain controllers within a single site communicate frequently.
This communication minimizes the latency within the site; that is, the time required for a change that is
made on one domain controller to be replicated to other domain controllers. You create sites to optimize
use of the bandwidth between domain controllers in different locations. For more information about sites,
see “How Active Directory Replication Topology Works.”

Global Catalogs

The global catalog stores a full copy of all Active Directory objects in the directory for its host domain
and a partial copy of all objects for all other domains in the forest. Users in a forest do not need to be
aware of directory structure because all users see a single directory through the global catalog.
Applications and clients can query the global catalog to locate any object in a forest. The global catalog is
hosted on one or more domain controllers in the forest. It contains a partial replica of every domain
directory partition in the forest. These partial replicas include replicas of every object in the forest,
including the attributes most frequently used in search operations and the attributes required to locate a
full replica of the object. A global catalog is created automatically on the first domain controller in the
forest. Optionally, other domain controllers can be configured to serve as global catalogs.

A global catalog serves the following roles:

 Enables user searches for directory information about objects throughout all domains in the forest
  Resolves user principal names (UPNs) during authentication, when the authenticating domain
controller does not have information about the account
 Supplies universal group membership information in a multiple domain environment
 Validates references to objects in other domains in the forest

For more information about global catalogs and their roles, see “How the Global Catalog Works.”

Forests as Security Boundaries

Each forest is a single instance of the directory, the top-level Active Directory container, and a security
boundary for all objects that are located in the forest. This security boundary defines the scope of
authority of the administrators. In general, a security boundary is defined by the top-level container for
which no administrator external to the container can take control away from administrators within the
container. As shown in the following figure, no administrators from outside a forest can control access to
information inside the forest unless first given permission to do so by the administrators within the forest.

Enterprise Administrators Outside of a Forest Can Administer Only Within Their Own
Forest

A forest is the only component of the Active Directory logical structure that is a security boundary. By
contrast, a domain is not a security boundary because it is not possible for administrators from one
domain to prevent a malicious administrator from another domain within the forest from accessing data in
their domain. A domain is, however, the administrative boundary for managing objects, such as users,
groups, and computers. In addition, each domain has its own individual security policies and trust
relationships with other domains.

Forests as Units of Delegation

The forest is the largest management unit of Active Directory as well as the ultimate unit of autonomy
and isolation of authority. Members of the Enterprise Admins and forest root Domain Admins security
groups are known as enterprise administrators. Enterprise administrators control the Active Directory
objects in the configuration container that do not belong to any one domain, including Enterprise
Certification Authority objects and other configuration data that affects all domains in the forest.

Because enterprise administrators have authority over all domains in the forest, the domain administrators
in each domain must trust the enterprise administrators. You cannot truly restrict enterprise administrators
from managing objects in any domain in the forest. Enterprise administrators can always regain control
over objects. Some organizations with political challenges, such as those frequently encountered in
mergers and acquisitions, might find the scope of this enterprise authority too great and require more than
one forest. If your organization requires strict isolation of authority between domains, you must deploy
multiple forests with manually created trusts between domains in the different forests.

Because each forest is administered separately, adding additional forests to your organization increases
the management overhead of the organization. The number of forests that you need to deploy is based on
the autonomy and isolation requirements of each group within your organization. Reasons to create
multiple forests in your organization include:

 To secure data within each forest. Sensitive data can be protected so that only users within that
forest can access it.
 To isolate directory replication within each forest. Schema changes, configuration changes, and
the addition of new domains to a forest have forest-wide impact only within that forest, not on a
trusting forest.

Because the forest is a security boundary, each forest does not trust or allow access from any other forest
by default. However, in Windows Server 2003 Active Directory, transitive trust relationships can be
manually established between forests to establish cross-forest access to resources, so that users in one
forest can access resources in another forest.
Forest trusts help you to manage a segmented Active Directory infrastructure within your organization by
providing support for accessing resources and other objects across multiple forests. By using forest trusts,
you can link two different Windows Server 2003 forests to form a one-way or two-way transitive trust
relationship. A forest trust allows administrators to federate two Active Directory forests with a single
trust relationship to provide a seamless authentication and authorization experience across the forests.

When two forests are connected by a forest trust, authentication requests made using the Kerberos V5 or
NTLM protocols can be routed between forests to provide access to resources in both forests. Trust
security settings and firewalls can be configured between domains in different forests that are joined by
trust relationships to limit cross-forest connectivity to specific users or applications. For more information
about trust security settings, see “Security Considerations for Trusts.”

A forest trust can be created only between a forest root domain in one Windows Server 2003 forest and a
forest root domain in another Windows Server 2003 forest. Forest trusts can be created between two
forests only and cannot be implicitly extended to a third forest. This means that if a forest trust is created
between Forest 1 and Forest 2, and another forest trust is created between Forest 2 and Forest 3, Forest 1
does not have an implicit trust with Forest 3. The following figure shows two separate forest trust
relationships between three Windows Server 2003 forests in a single organization.

Two Forest Trusts Between Three Windows Server 2003 Forests

What is DNS Support for Active Directory?

DNS is the primary name resolution service for Windows Server 2003. Active Directory depends on DNS
for domain controller location, and DNS influences Active Directory domain naming. Thus, to fully
understand Active Directory, it helps to understand how DNS acts as an integral component in the design
of Active Directory.
Active Directory requires:
 A name resolution service that enables network hosts and services to locate Active Directory domain
controllers.
 A naming structure that enables an enterprise to reflect its organizational structure in the names of its
directory service domains.
DNS provides Active Directory with both a name resolution service for domain controller location and a
hierarchical design that Active Directory leverages to provide a naming convention that can reflect
organizational structure.
Typically, a DNS domain namespace deployed to accommodate the Active Directory mirrors the Active
Directory domain namespace. In cases where there is an existing DNS namespace prior to Active
Directory deployment, the DNS namespace is typically partitioned for Active Directory, and a DNS
subdomain and delegation for the Active Directory forest root is created. Additional DNS domain names
are then added for each Active Directory child domain.
DNS data is used to support the location of Active Directory domain controllers also. During or after the
creation of the DNS zones used to support Active Directory domains, the zones are populated with DNS
resource records that enable network hosts and services to locate Active Directory domain controllers.

What Is Core Group Policy?

Group Policy is an infrastructure used to deliver and apply one or more desired configurations or policy
settings to a set of targeted users and computers within an Active Directory environment. This
infrastructure consists of a Group Policy engine and multiple client-side extensions (CSEs) responsible
for writing specific policy settings on target client computers.
Group Policy settings are contained in Group Policy objects (GPOs), which live in the domain and can be
linked to the following Active Directory containers: sites, domains, or organizational units (OUs). The
settings within GPOs are then evaluated by the affected targets, using the hierarchical nature of Active
Directory. Consequently, Group Policy is one of the top reasons to deploy Active Directory.
Group Policy is one of a group of management technologies, collectively known as IntelliMirror, that
provides users with consistent access to their applications, application settings, roaming user profiles, and
user data, from any managed computer — even when they are disconnected from the network.
IntelliMirror is implemented through a set of Windows features, including Active Directory, Group
Policy, Group Policy-based Software Installation, Windows Installer, Folder Redirection, Offline Folders,
and Roaming User Profiles.
 Core Group Policy or the Group Policy engine is the framework that handles common functionalities
across Administrative Template settings and other client-side extensions. The following figure shows how
the Group Policy engine interacts with other components as part of processing policy settings. You use
Group Policy Management Console (GPMC) to create, view, and manage GPOs and use Group Policy
Object Editor to set and configure the policy settings in GPOs.
Group Policy Components

Change and Configuration Management

Administrators face increasingly complex challenges in managing their IT infrastructures. You must
deliver and maintain customized desktop configurations for many types of workers, including mobile
users, information workers, or others assigned to strictly defined tasks, such as data entry. Changes to
standard operating system images might be required on an ongoing basis. Security settings and updates
must be delivered efficiently to all the computers and devices in the organization. New users need to be
productive quickly without costly training. In the event of a computer failure or disaster, service must be
restored with a minimum of data loss and interruption.
Specifically, an IT department must respond to various factors that require change in an IT environment
including:

 New operating systems and applications.

 Updates to operating systems and applications.
 New hardware.
 New business requirements that require configuration changes.
 Security influences that require configuration changes.
 New users.
Managing this change can be viewed as a continuous cycle, in which new business requirements demand
changes that must first be tested before they can be deployed as a standard configuration. This cycle is
shown in the following figure.
Change and Configuration Management Process

These roles, known collectively as Change and Configuration Management, enable administrators to
implement change quickly and affect large numbers of users and computers at the lowest possible cost.
You can use Group Policy to maintain standard operating environments for specific groups of users, such
as developers or information workers. As software changes and policies change over time, Group Policy
can be used to update the already-deployed standard operating environment until the image can be
updated. Group Policy can also enforce rules, if necessary, by restricting the programs that can be run on
company computers. For example, it can prevent access to games or other programs unrelated to the
workplace.
Group Policy is a key enabling technology that allows you to implement Change and Configuration
Management along with other technologies in IntelliMirror. For example, you can deploy new operating
systems with Remote Installation Services or other imaging technology. You can deliver updates to
computers throughout the network using Software Update Services (SUS). Although you can deploy
software using Group Policy, larger organizations might want to use Microsoft Systems Management
Server (SMS) to take advantage of the scalability that SMS provides.
In summary, Group Policy is the delivery mechanism that allows you to implement change and
configuration for users and computers on the object level in Active Directory. Because you can target
Group Policy settings to individual objects throughout the Active Directory hierarchy, Group Policy is the
central enabling technology that allows organizations to effectively use Active Directory as a
management tool. In addition, the Group Policy Management Console simplifies implementation and
management of Group Policy.
Core Group Policy Infrastructure
 Group policy is an infrastructure with pluggable extensions. Extensions that exist on client computers
include Administrative Templates (also known as registry-based policy), Security Settings, Software
Installation, Folder Redirection, Scripts, and Wireless Network Policies.
The policy settings exist in a GPO. A GPO is a virtual object that lives in the domain; part of the GPO is
located in Active Directory and is called the Group Policy container. The other part of a GPO is located in
the Sysvol and is called the Group Policy template. When policy settings need to be applied, the
framework calls each extension and the extension then applies the necessary settings.
Each Group Policy extension has two extensions — a client extension that is called by the Group Policy
engine to apply policy, and a server-side extension that plugs into Group Policy Object Editor to define
and set the policy settings that need to be applied to client computers.
Although you can configure Local Group Policy objects (Local GPOs) on individual computers, the full
power of Group Policy can only be realized in a Windows 2000 or Windows Server 2003-based network
with Active Directory installed. In addition, some features and policy settings require client computers
running Windows XP.
Group Policy and Active Directory
Active Directory organizes objects by sites, domains, and OUs. Domains and OUs are organized
hierarchically, making the containers and the objects within them easy to manage. The settings defined in
a GPO can only be applied when the GPO is linked to one or more of these containers.
By linking GPOs to sites, domains, and OUs, you can implement Group Policy settings for as broad or as
narrow a portion of the organization as you want. GPO links affect users and computers in the following
ways:

 A GPO linked to a site applies to all users and computers in the site.
 A GPO linked to a domain applies directly to all users and computers in the domain and by inheritance to
all users and computers in child OUs. Note that policy is not inherited across domains.
 A GPO linked to an OU applies directly to all users and computers in the OU and by inheritance to all
users and computers in child OUs.
When a GPO is created, it is stored in the domain. When the GPO is linked to an Active Directory
container, such as an OU, the link is a component of that container, not a component of the GPO.
An example of how GPOs can be linked to sites, domains, and OUs is shown in the following figure.
Sample Active Directory Organizational Structure
 In this configuration, the Servers OUs have the following GPOs applied: A1, A2, A3, A4, A6. The
Marketing OUs have the following GPOs applied: A1, A2, A3, A5.
Loopback processing with merge or replace
Loopback is an advanced Group Policy setting that is useful on computers in certain closely managed
environments, such as servers, kiosks, laboratories, classrooms, and reception areas. Setting loopback
causes the User Configuration settings in GPOs that apply to the computer to be applied to every user
logging on to that computer, instead of, or in addition to, the User Configuration settings of the user. This
allows you to ensure that a consistent set of policies is applied to any user logging on to a particular
computer, regardless of their location in Active Directory. Loopback is controlled by the setting, User
Group Policy loopback processing mode, which is located in Computer Configuration\Administrative
Templates\System\Group Policy. Loopback only works when both the user account and the computer
account are in a Windows 2000 or later domain. Loopback does not work for computers joined to a
workgroup. Loopback is not enabled if the computer or user is not in an Active Directory domain.
Filtering the Scope of the Group Policy Object
Group Policy is a powerful tool for managing the Windows Server 2003 environment. The value of
Group Policy can only be realized through properly applying the GPOs to the Active Directory containers
you want to manage. Determining which users and computers will receive the settings in a GPO is
referred to as “scoping the GPO.” Scoping a GPO is based on three factors:

 The site(s), domain(s), or organization unit(s) where the GPO is linked.

 The security filtering on the GPO.
 The WMI filter on the GPO.
 You can use the site, domain, and OU links from a GPO as the primary targeting principle for defining
which computers and users should receive a GPO. You can then use security filtering and WMI filtering
to further reduce the set of computers and users to which the GPO will apply.
Scoping or targeting of a GPO allows you to apply or deny an entire GPO; you cannot choose to filter
settings within a GPO.
Group Policy Inheritance
In addition to the ability to filter the scope of GPOs, you can change the way GPOs are applied by
managing Group Policy inheritance. In most environments, the actual settings for a given user and
computer are the result of the combination of GPOs that are applied at a site, domain, or OU. When
multiple GPOs apply to these users and computers, the settings in the GPOs are aggregated. The settings
deployed by GPOs linked to higher containers (parent containers) in Active Directory are inherited by
default to child containers and combine with any settings deployed in GPOs linked to child containers. If
multiple GPOs attempt to set a setting to conflicting values, the GPO with the highest precedence sets the
setting. GPO processing is based on a “last writer wins” model, and GPOs that are processed later have
precedence over GPOs that are processed earlier.
Viewing and Reporting of Policy Settings
In order to properly implement, troubleshoot, and plan Group Policy, administrators need to be able to
quickly view the settings in a GPO. When multiple GPOs apply to a given user or computer, they can
contain conflicting policy settings. For most policy settings, the final value of the policy setting is set only
by the highest precedent GPO that contains that setting. Resultant Set of Policy (RSoP) helps you
understand and identify the final set of policy that is applied as well as settings that did not apply as a
result of policy inheritance.
Specifically, Resultant Set of Policy helps you determine:

 The final value of the setting that is applied as a result of all the GPOs.
 The final GPO that set the value of this setting (also known as the winning GPO).
 Precedence details that show any other GPOs that attempted to set this setting and the value that each
GPO attempted to set for that policy setting.
Group Policy Management Console, available as a separate download from the Microsoft Web site,
addresses some common reporting requirements including the ability to document all the settings in a
GPO to a file for printing or viewing. Users can either print the reports, or save them to a file as either
HTML or XML.
Delegating Administration of Group Policy
 Organizations need to be able to delegate administration of Group Policy to other administrators who can
take responsibility for a given OU, domain, or other container. Active Directory is designed to allow you
to delegate control of portions of the directory service in managing aspects of Group Policy. The
following areas can be delegated:

 GPO delegation. This includes permission to create GPOs in a domain or permission to edit an existing
GPO. Note that having permission to edit a GPO does not include any delegated rights on the GPO links.
 Link delegation. This includes permission to add, delete, or change links to GPOs. Note that having link
delegation does not include any delegated rights on the GPO itself.
 RSOP delegation. This includes permission to run RSoP (in either planning or logging mode) on objects
under a container.
 WMI filter delegation. This includes permission to create WMI filters or permission to edit an existing
filter.
In GPMC, delegation is simplified because it manages the various Access Control Entries (ACEs)
required for a task as a single bundle of permissions for the task. You can also use the Access Control List
(ACL) editor to view or manage these permissions manually.
The underlying mechanism for achieving delegation is the application of the appropriate DACLs to GPOs
and other objects in Active Directory. This mechanism is identical to using security groups to filter the
application of GPOs to various users. You can also specify Group Policy to control who can use MMC
snap-ins. For example, you can use Group Policy to manage the rights to create, configure, and use MMC
consoles, and to control access to individual snap-ins.
Core Group Policy Scenarios
The Group Policy engine is designed to apply policy configurations to individual computers and users
through Group Policy objects. Settings within a GPO are configured by individual client-side extensions
and are applied to individual computers and users by the client-side extension. This section summarizes
the core scenarios for the Group Policy engine.

 Scheduling of Group Policy application. Group Policy starts each time the computer starts or a user
logs in, a process called foreground policy application. Group Policy is also applied in the background at
regular refresh intervals. In addition, it can be forced to apply through command line tools such as
Gpupdate.
 Obtaining GPOs from the relevant configuration locations. The Group Policy engine obtains GPOs
from the appropriate site, domain, and OU containers, known collectively as Scope of Management
(SOM).
 Handling special cases affecting all CSEs. The Group Policy engine implements additional changes
specified by the administrator such as changing the link order in which GPOs should be applied. In
addition, the Group Policy engine handles any loopback processing that has been set by an administrator.
Loopback processing, typically used for public workstations or kiosks, specifies that the user settings
defined in the computer’s GPOs replace or are merged with the user settings normally applied to the user.
 Filtering and ordering of GPOs. The Group Policy engine checks for any conditions set by the
administrator to filter GPOs or specify the order in which GPOs should be applied.
 Configuring CSEs. CSEs can be configured to run only in some conditions, as specified in the registry.
 Maintaining version numbers and histories for all CSEs. A history list is maintained for each CSE in
the Registry, showing when the CSE last applied policy. A status is also maintained to figure out whether
the client-side extension applied policy successfully last time the policy was applied by the CSE.
 Calling into the CSE. When the Group Policy engine has determined that a particular CSE needs to be
executed, it loads the dynamic link library (DLL) associated with the CSE and loads up the entry point.
 Notifying various components of any changes made by Group Policy. After all the extensions have
been called, the Group Policy engine updates the registry information to specify what the next policy
foreground application should be, as well as schedule the next background refresh time.
 Processing RSoP data. The Group Policy engine periodically refreshes the RSoP data, ensuring that
actual policy application is updated and stored in the WMI namespace on each computer.
Group Policy Dependencies
Group Policy has several key dependencies. Domain-based Group Policy requires an Active Directory
environment with DNS properly configured.
Active Directory
Active Directory is the Windows 2000 Server and Windows Server 2003 directory service that stores
information about all objects on the computer network and makes this information easy for administrators
and users to find and apply. With Active Directory, users can gain access to resources anywhere on the
network with a single logon. Similarly, administrators have a single point of administration for all objects
on the network, which can be viewed in a hierarchical structure. In a network environment, Group Policy
depends on Active Directory as the targeting framework that allows you to link GPOs to specific Active
Directory containers such as sites, domains, or OUs.
In a stand-alone environment without Active Directory, you can use Local Group Policy objects to
configure settings on individual computers.
Domain Name System (DNS)
DNS is a hierarchical, distributed database that contains mappings of DNS domain names to various types
of data, such as IP addresses. DNS enables the location of computers and services by user-friendly names,
and it also enables the discovery of other information stored in the database.
Group Policy application requires clients to access specified servers, including domain controllers and
other servers such as share points and install points. Group Policy management also requires access to
domain controllers. DNS is used to locate and identify these servers. In Windows 2000 Server and later
Active Directory requires DNS support. If the network is functioning, but clients or consoles such as the
Group Policy Object Editor or GPMC are unable to locate the servers, there might be a problem with your
network's DNS system.
Replication
Group Policy depends on other technologies in order to properly replicate between domain controllers in
a network environment. A GPO is a virtual object stored in both Active Directory and the Sysvol of a
domain controller. Property settings, stored in the Group Policy container, are replicated through Active
Directory replication. Replication automatically copies the changes that originate on a writable directory
partition replica to all other domain controllers that hold the same directory partition replica. More
specifically, a destination domain controller pulls these changes from the source domain controller. Data
settings, stored in the Sysvol as the Group Policy template, are replicated through the File Replication
Service (FRS), which provides multi-master file replication for designated directory trees between
designated servers running Windows Server 2003. The Group Policy container stores GPO properties,
including information about version, GPO status, and a list of components that have settings in the GPO.
The Group Policy template is a directory structure within the file system that stores Administrative
Template-based policy settings, security settings, script files, and information regarding applications that
are available for software installation. The Group Policy template is located in Sysvol in the \Policies sub-
directory for its domain. GPOs are identified by their globally unique identifiers (GUIDs) and stored at
the domain level. The settings from a GPO are only applied when the Group Policy container and Group
Policy template are synchronized.
DFS publishing
The Sysvol folder is shared on each domain controller and is accessible through the UNC path
\\dcname.domainname\sysvol.
The Sysvol is also published as a domain-based Distributed File System (DFS) share. This allows clients
to access the Sysvol by using the generic path \\domainname\sysvol. A request for a DFS referral for
\\domainname\sysvol will always return a replica in the same Active Directory site as the client if one is
available. This is the mechanism that the Group Policy client-side extensions use to retrieve a local copy
of the Group Policy template information.
 What Is Folder Redirection Extension?
The Folder Redirection extension, a feature of IntelliMirror, enables an administrator to redirect the
location of certain folders in the user profile to different path, such as a shared network location. When
these redirected folders are accessed, either by the operating system or by applications, the operating
system automatically redirects to the location on a network share specified by the administrator. From a
user perspective, this feature is similar to a roaming profile because users have the same folder settings
regardless of which computers they use. These settings remain on the network share and enable users to
access their files from any computer they use to logon on to the network. The following figure illustrates
the relationships and interactions of the Folder Redirection extension with other networking components
and Group Policy features.
Folder Redirection Extension Relationships and Interactions

The following special folders can be redirected:

 Application Data
 Desktop
 My Documents
 o My Pictures
 Start Menu
Note
o My Pictures folder is no longer shown in the Folder Redirection Node. To simplify the user
interface and to help support the best practice that the My Pictures folder should always follow
the My Documents folder, the My Pictures folder is not shown in the Folder Redirection node for
new GPO’s. If you have previously redirected the My Pictures folder separately, the My Pictures
node will still appear.
Benefits of Folder Redirection
When fully deployed, IntelliMirror uses Active Directory and Group Policy for policy-based management
of user desktops. A Windows XP or Windows 2000 Professional desktop can be automatically configured
to meet specific requirements of a user’s business roles, group memberships, and location. Group Policy
and the Active Directory are not necessary for every IntelliMirror feature. Some of the features can be set
on the local level or through local polices. An organization can tailor IntelliMirror to meet its needs.
When planning to use IntelliMirror, an organization should assess which features it needs and then
implement the technology required.
By using IntelliMirror on both the server and client, administrators can protect and manage user data and
settings. Non-recoverable data from local workstations can be copied to servers, where it can be easily
backed up and centrally managed. Personalized data, applications, and settings can follow each user to
different computers throughout the network. Administrators can easily replace faulty computers and
restore all user data and settings on a new computer.
Previously, administrators who wanted to redirect folders to the network had to use logon scripts to
change registry values. In Windows Server 2003 and Windows XP, the same task can be accomplished by
using the Folder Redirection extension of Group Policy. For example, you could redirect a user’s My
Documents directory to \\Server\Share\%username%.
Folder Redirection provides the following benefits:

 Improved Roaming User Profile performance. You can use Folder Redirection to reduce the time it
takes to log on to and log off from the network. The My Documents folder is part of the Roaming User
Profile (RUP), which means that the My Documents folder and its contents are copied back and forth
between the client computer and the server each time users log on and log off. Redirecting the My
Documents folder to a location outside of the user profile can significantly decrease the amount of time it
takes to log on and log off because not all of the data in the user profile is transferred to the desktop each
time the user logs on — only the data that user requires is transferred.
 User documents available from any computer. To ensure that users’ documents are available when
they roam from one computer to another, you can use Folder Redirection to redirect user documents to a
server location accessible from any computer connected to the domain.
 User documents available when not connected to the corporate network. Folder Redirection can be
used with Offline Files technologies to make users’ network-based My Documents folder available when
they are disconnected from the corporate network. By default in Windows XP and Windows Server 2003,
any redirected shell folders such as My Documents, Desktop, Start Menu, and Application Data are
automatically made available Offline.
Note
o Offline Files are disabled by default in Windows Server 2003.
 Increased security and availability of user data. When you use Folder Redirection to redirect user data
to a network location, the data stored on a shared network server can be backed up as part of routine
system administration. This protects user data and requires no action on the part of the user.
 Reduced support costs and user down-time. If there are multiple hard disk drives in a user’s computer,
user data and files can be redirected to a hard disk on the user’s local computer other than the one on
which the operating system is installed. This protects the user’s data if the operating system needs to be
reinstalled or if computer hardware needs to be replaced.
 Control allocation of disk space. Administrators can use Group Policy to set disk quotas, which limit the
amount of space taken up by users’ folders.
Common Folder Redirection Scenarios
This section presents sample scenarios that illustrate some of the practical uses of Folder Redirection.
Each of the scenarios fits into an entire picture or can be seen as a separate event. Each scenario also
shows how the components of IntelliMirror benefit the entire organization by reducing the time and effort
associated with maintaining the computing environment.
The new hire
One of the most critical and time consuming IT tasks is setting up a computer for a new hire. In an
organization that uses IntelliMirror, the new hire logs on to a new computer and finds documents and
shortcuts already on the desktop. There are shortcuts to common files, URLs, and folders that are useful
to all employees (for example, the employee handbook, shortcuts to the departmental shared documents
store, and the user’s departmental guidelines and procedures). Desktop options, application
configurations, Internet settings, and so on, are all configured to the corporate standard, ensuring that if
the user needs to call the help desk, the support staff knows what configuration the user started with.
In this example, the user gets a pre-configured user profile that was set up for all new users, and was
configured before the new hire logged on to the network. The administrator configured a computer to
look and behave according to the corporate standard, and then, using the User Profile utility built into the
System Control Panel application, copied the user profile to a Default User folder on the domain
controller’s Netlogon share. When the new hire logged onto the network for the first time, Windows
copied this default profile to the local computer and used this profile as the basis for the new hire’s
profile. In addition to configuring the default profile the user received, the administrator also used Group
Policy to redirect the user’s My Documents folder to a network location, so that the user’s documents are
safely stored on a network server and can be backed up regularly.
The laptop user
In this scenario, a laptop user working at the office creates several documents and saves them to his or her
My Documents folder. After saving documents, the user logs off, unplugs the laptop computer from the
network and takes it home. While at home and off the network, the user continues to edit the documents
saved earlier in the My Documents folder.
The user returns to the office and logs on to the network. Since the user has worked offline, a dialog box
appears advising the user that data in My Documents has changed and is being synchronized with the
network copy.
In this scenario, the user’s My documents folder has been redirected to a network server, the documents
are transparently saved to the network location and also saved in the local computer’s cache (because the
network folder is setup to be available offline), so that they are available when the computer is
disconnected from the network.
The whole process can be transparent to the user; the experience is no different than saving documents to
the local hard disk.
As soon as the user reconnects to the network, IntelliMirror attempts to reconnect to the network location
of the redirected folders. When IntelliMirror reconnects, it determines if there are differences in the data
between the local copy of the folder and the network copy. In this scenario, the user has made
modifications to a document on the local computer. IntelliMirror identifies this change and prompts the
user to update the version stored on the network.
Computer replacement
In this scenario the computer that a user is working on suddenly stops working because of a complete
hardware failure. The user calls the support line, and receives a new computer, loaded with only the
Windows XP Professional operating system. Without waiting for technical assistance, the user plugs in
the new computer, connects it to the network, and starts it. When the user logs on to the corporate
network, he or she will find that the desktop has the same appearance as the original computer that it
replaced. It will have the same color scheme, the user’s preferred background picture on the screensaver,
and all the application icons, shortcuts, and favorites. More importantly, all the user’s data files will have
been restored.
In a disaster recovery scenario, IntelliMirror assists in getting the user’s computer replaced and running
quickly with the minimum of support. In this example, because the user was configured to use roaming
user profiles, a copy of the user’s working environment was safely stored on a network server. When the
new computer arrived, the user was able to log on and the server copy of the user’s profile was
downloaded to the new computer. An administrator could also have used Folder Redirection to redirect
the user’s key folders such as My Documents and Application Data, to ensure that the user’s documents
were safely stored on the server.
A shared computer environment
In this scenario, a user works in a department where the computer he or she uses might change from day
to day—a call center or IT support environment, for example. The user is working on an important
document late one night when the shift ends. The user saves the document and logs off the computer.
When the user returns to work the next day, he or she logs onto the first available computer—a different
computer from the one used the previous night. The user logs onto the network, and sees that the desktop
has the same look and feel as the original computer. The user opens the My Documents folder on the
desktop and finds the document exactly where he or she saved it and continues the work started the
previous night.
In this example, the user was configured to use roaming user profiles, so that a copy of the user’s working
environment was stored on a network server. When the user logged onto the computer, the user’s existing
preferences, shortcuts and documents were copied to the local computer, so that the user could continue
working as if using the original computer. A variation on this scenario is using roaming profiles in
conjunction with Folder Redirection. Users can have the same work environment and have access to the
same documents on any computer. Changes made on one computer are synchronized with the other
computer the next time the user logs on.
Folder Redirection Dependencies
The Folder Redirection extension is used most effectively when combined with other related Group
Policy and Windows Server technologies, such as Roaming User Profiles, Offline Files, and
Synchronization Manager.
Folder Redirection with Roaming User Profiles
You can also combine Folder Redirection and roaming user profiles to decrease logon and logoff times
for roaming and mobile users. A common scenario is to redirect the My Documents and My Pictures
folders, and allow the Application Data, Desktop, and Start Menu folders to roam with the profile. In
addition to improved availability and administrative benefits from storing the data on the network, users
 also realize performance gains when using low-speed network connections and in subsequent logon
sessions. Not all of the data in the user profile is transferred to the desktop each time the user logs on —
only the data that user accesses during a session is transferred. Because only some documents are copied,
performance is improved when the user’s’ profiles are copied from the server.
When you combine the use of Folder Redirection and roaming user profiles, you can also provide fast
computer replacement. If a user’s computer needs to be replaced, the user’s data can quickly be copied
from the server locations to a replacement computer. Combining Folder Redirection with roaming profiles
gives the benefits of roaming profiles, while minimizing network traffic caused by synchronization of the
profile.
Note

 To decrease initial logon time to a new computer, you should redirect the location of the My Documents
folder outside of the user’s roaming profile.
Local profiles
Using Folder Redirection with local profiles can provide some of the benefits of roaming profiles (such as
having a user’s data available at any computer or maintaining data on the server) without the need to
implement roaming profiles. Remember though, using Folder Redirection with a local profile would only
result in the user’s documents and files being available from all computers. To have settings and
configurations move with the user, you would need to use roaming profiles.
Folder Redirection with Offline Files
By using Offline Files, users can continue to work with a cached copy of files stored on a network
location, even when they are not connected to a network. If your organization has mobile users with
portable computers, Offline Files gives them access to their files when they are not connected to the
network, and ensures that they are always working with the current version of network files. Offline Files
technology stores the data in the computer’s cache to make network files available offline. The view of
shared network items that you have made available offline remains as it is when connected, even if users
lose a connection to or manually disconnect from the network. Users can continue to work with the
Offline Files as they normally do when online. Users have the same access permissions to those files and
folders as when they are connected to the network. When the network connection is restored, any changes
they made while working offline are updated to the network so that both locations are synchronized.
Offline Files is a stand-alone technology, which means that you do not need to use it with Folder
Redirection. However, using Offline Files with Folder Redirection allows for greater flexibility and
availability of user files. For example, if a shortcut to a file is available offline, that file is made available
offline, but if a shortcut to a folder is available offline, the contents of that folder are not available offline.
 If you pair the two technologies, Offline Files and Folder Redirection, both the shortcut and the folder are
available offline.
Shared files or folders on a Windows Server 2003 or Windows XP-based network can be available
offline. By default in Windows XP and Windows Server 2003, any redirected shell folders such as My
Documents, Desktop, Start Menu, and Application Data are automatically made available offline. You
can also make files available for offline use from any computer that is sharing files using server message
block-based file and printer sharing, including Windows 2000, Windows 95, Windows 98, and Windows
NT 4.0.
Note

 Make sure that you turn off Offline Folders for shares where roaming user profiles are stored. If you do
not turn off Offline Folders for a user’s profile, you might experience synchronization problems since
both Offline Folders and Roaming Profiles will try to synchronize the files in a user’s profile.
Synchronization Manager
When using Offline Files and folders, users can synchronize all network resources by using the
Synchronization Manager. The Synchronization Manager can be set to automatically synchronize some or
all resources. For example, users can set certain files and folders to be synchronized every time they log
on or off the network. The Synchronization Manager quickly scans the system for any changes, and if it
detects changes, the resources are automatically updated. Only resources that have changed are updated—
vastly speeding up the synchronization process.

What Is DFS?
One of the goals of most information technology (IT) groups is to manage file server resources efficiently
while keeping them available and secure for users. As networks expand to include more users and
servers—whether they are located in one site or in geographically distributed sites—administrators find it
increasingly difficult to keep users connected to the files they need. On one hand, distributing resources
across a network makes them more available to more people and promotes cross-organizational efforts.
On the other hand, storing files on different file servers located throughout an organization makes it
difficult for users to know where to look for information. Administrators also find it difficult to keep track
of all the servers and all of the people who use those servers. The task of swapping out an old server
becomes a major communication chore when users across an organization must be notified to update links
and file paths.
To help administrators address these problems, Windows Server 2003 includes Distributed File System
(DFS). DFS allows administrators to group shared folders located on different servers by transparently
connecting them to one or more DFS namespaces. A DFS namespace is a virtual view of shared folders in
an organization. Using the DFS tools, an administrator selects which shared folders to present in the
namespace, designs the hierarchy in which those folders appear, and determines the names that the shared
folders show in the namespace. When a user views the namespace, the folders appear to reside on a
single, high-capacity hard disk. Users can navigate the namespace without needing to know the server
names or shared folders hosting the data. DFS also provides other benefits, including the following:
Simplified data migration
DFS simplifies the process of moving data from one file server to another. Because users do not need to
know the name of each physical server or shared folder that contains the data, administrators can
physically move data to another server without needing to reconfigure applications and shortcuts and
without needing to reeducate users about where they can find their data. This minimizes the impact of
server consolidation on users. It also allows administrators to deploy additional file servers and present
the folders on those new servers as new folders within an existing namespace.
Increased availability of file server data
In the event of a server failure, DFS refers client computers to the next available server, so users can
always access shared folders without interruption.
Load sharing
DFS provides a degree of load sharing by mapping a given logical name to shared folders on multiple file
servers. For example, suppose that \\Company\StockInfo is a heavily used shared folder. Administrators
can use DFS to associate this location with multiple shared folders on different servers, even if the servers
are located in different sites.
Security integration
Administrators do not need to configure additional security for DFS namespaces because file and folder
security is enforced by existing the NTFS file system and shared folder permissions on each target. For
example, a user navigating a DFS namespace is permitted to access only the files or folders for which he
or she has appropriate NTFS or shared folder permissions.
Common DFS Scenarios
DFS is commonly used in the following scenarios:
Server Consolidation
Many organizations today are consolidating older file servers throughout the organization into fewer,
larger, more powerful file servers. Consolidation reduces the cost of managing multiple file servers and
increases the efficiency of storage allocation and backup tasks. Organizations that have implemented DFS
can perform server consolidations without impacting the way users’ access data. The following figure
illustrates this benefit.
How DFS Eliminates the Impact of Server Consolidation on Users

Publishing Applications
DFS is commonly used to publish applications to users throughout the organization. Using DFS in this
scenario provides a number of benefits, such as the ability to use multiple servers to host application data
and distribute the load across servers. A feature in DFS known as “least expensive target selection”
ensures that users are connected to the closest server. The following figure illustrates a DFS namespace
used to publish applications in an organization based in San Francisco with offices in Miami and Dallas.
Using DFS to Publish Applications
 This organization has three types of software:

 Business-critical software and operating systems that must be available at all times.
 Previous versions of software that are still in use in the Dallas branch office.
 Multimedia software used primarily in San Francisco.
The organization uses four servers to host the business-critical software and operating systems, including
two servers in the San Francisco site. Using two servers to host the applications ensures that a failure on
one server does not cause the data to become unavailable. All users can access this software at
\\Software\Public\Applications, and users are automatically directed to the server in their site (San
Francisco, Dallas, or Miami).
Because the archived software is used only in the Dallas office and the data is not business-critical, only a
single server hosts that data. The multimedia software is not business-critical, but the organization uses
two servers for this software to improve server response times because the client portion of the
multimedia software accesses files from the server.
Increasing Data Availability
As described in the scenario for publishing applications, administrators can use DFS to increase the
availability of data by storing the data on multiple servers. DFS makes this process transparent by
 presenting to users what appears to be a single folder in the namespace. Administrators can use File
Replication service (FRS) or some other replication method, such as the Windows Resource Kit Tool
Robocopy, to keep the data synchronized on the servers. If one of the servers hosting data is unavailable,
clients are referred to another server that hosts the data.
Technologies Related to DFS
File Replication service (FRS) can be used to keep data in DFS shared folders synchronized among
servers. However, DFS and FRS are two separate technologies, and DFS does not require FRS. You can
use other replication methods, such as manual copying, the Resource Kit Tool Robocopy, or other
replication tools to keep DFS shared folders synchronized. Conversely, if you want to use FRS to keep
data in shared folders synchronized, you must use DFS.
DFS Dependencies
DFS has the following dependencies:

 Active Directory replication. Domain-based DFS requires that Active Directory replication is working
properly so that the DFS object resides on all domain controllers in the domain.
 Server Message Block (SMB). Clients must access DFS root servers by using the SMB protocol.
 Remote Procedure Call (RPC) service and Remote Procedure Call Locater service. The DFS tools
use RPC to communicate with the DFS service running on DFS root servers.
 Distributed File System service dependencies. The Distributed File System service must be running on
all DFS root servers and domain controllers so that DFS can work properly. This service depends on the
following services:
o The Server service, Workstation service, and Security Accounts Manager (SAM) service on DFS
root servers. The Distributed File System service also requires an NTFS volume to store the
physical components of DFS on root servers.
o The Server service and Workstation service on domain controllers.