Point 8: Designing a Windows Server 2003 Active Directory

Shaila Singh

In Windows Server 2003, you can arrange the Active Directory domains in a hierarchical model, also called the domain design model. Windows Server 2003 provides various types of domain design models, such as single domain model, multiple subdomain model, and federated forest model. Designing domains in a hierarchical model allows you to specify a boundary in a network. You can also change the position of domains in Active Directory by renaming the domains.

This ReferencePoint explains how to design Windows Server 2003 Active Directory. It also describes various Active Directory domain models available in Windows Server 2003. In addition, the ReferencePoint explains how to rename an Active Directory domain.

Introducing Domain Design

A domain is a collection of computers, users, and groups. The hierarchical structure of the domains in Windows Server 2003 Active Directory represents a domain design. When designing Active Directory, you need to define the trust relationship between the domains.

A domain trust relationship permits the domain users of one domain to share the resources of another domain. You also need to specify the domain namespace of a domain, which identifies a domain on a network. There are two types of domain namespaces - external domain namespace and internal domain namespace.

Windows Server 2003 provides various new features, such as domain renaming and global catalog media, you use to create a domain design for the domains in Active Directory.

Selecting the Type of Domain Trust Relationship

To design a domain, you first need to select a type of domain trust relationship. There are various types of domain trust relationships in Active Directory;

• Transitive: Represents a two-way trust relationship that automatically exists between the domains in Active Directory.

• Explicit: Establishes trust relationships with the external and down-level domains.

• Shortcut: Represents a trust relationship that exists between low level domains in two different domain trees.

• Cross-forest: Represents a trust relationship that exists between domains of two forests.

A transitive trust relationship flows from one domain to another domain, which reduces the need for multiple trust relationship between the domains to share the network resources.

For example, in a transitive trust relationship, if the domA domain trusts the domB domain and the domB domain trusts the domC domain, the domA domain also trusts the domC domain.

Figure 14-4-1 shows a model of transitive trust relationship:

Figure 14-4-1: Transitive Trust Relationship

You can set up an explicit trust relationship to share the resources between the domains in different domain trees.

For example, suppose there are two domain trees, domtreeA and domtreeB. The domtreeA domain tree contains the ABC.com domain, which contains the Canada.ABC.com and Europe.ABC.com down-level domains. The domtreeB domain tree contains the XYZ.com domain, which contains the Asia.XYZ.com down-level domain. A two-way explicit trust relationship exists between the ABC.com domain and the XYZ.com domain.

Figure 14-4-2 shows this model of an explicit trust relationship:

Figure 14-4-2: Explicit Trust Relationship

Note

A domain tree is a hierarchical structure of domains in Active Directory.

In explicit trust relationship, the trust relationship can be either one-way or two-way. For example, you can set up an explicit trust relationship in a network, which contains computers running Windows NT 4.0. In the two-way explicit trust relationship, you can transfer the permission of sharing the resources between the domains, but in the one-way explicit trust relationship, you cannot do so.

Note

External domains represent the domains that are part of another domain tree. Down-level domains exist under a domain in a domain tree.

A shortcut trust relationship is a type of explicit trust relationship exists between two down-level domains in different domain trees. For example, if a domain tree consists of multiple down-level domains, a shortcut trust relationship can exist between the two domains at the lower level in the domain tree, as shown in Figure 14-4-3:

Figure 14-4-3: Shortcut Trust Between Two Domains

A cross-forest trust relationship is a two-way transitive trust relationship between two separate Active Directory forests. An Active Directory forest is a collection of domains that have common class and attribute definitions, site and replication information, and search capabilities. A cross-forest trust relationship authorizes the domain users of a forest to access the resources of other forests in Active Directory.

In a cross-forest trust relationship, a transitive trust relationship exists between the all domains of the two forests. For example, suppose the ABC and the XYZ organizations enter into a partnership agreement. A cross-forest trust relationship can be established between the forests in the ABC and XYZ organizations, as shown in Figure 14-4-4:

Figure 14-4-4: Cross-forest Trust Relationship Between Two Forests

Selecting Domain Namespace

After selecting the type of trust relationship that you need to set between the domains in Active Directory, you need to select a domain namespace to identify the domains on a network. The domain namespace also represents the location of a domain in the domain tree hierarchy. Before selecting a namespace, you need to identify whether or not you want to register the domain namespace on the Internet to access the domains globally.

You can identify the domains in Active Directory using two types of domain namespace, external namespace and internal namespace. An external namespace represents the name of a company and is registered on the Internet.

For example, ABC.com is an external namespace registered on the Internet. The advantage of an external namespace is that you can access the domain over the Internet. The external namespace also helps you to identify your user account location on the Internet and any other network. For example, the ABC organization uses the User Principal Name (UPN), MaryJones@ABC.com, to represent Mary Jones, who is an employee of ABC. The UPN helps you to identify the location of the user account of Mary Jones on the network and the Internet.

Note

A UPN contains a user account name and a domain name, and identifies the domain in which a user account is located.

An external namespace is not secure because you need to register the external domain namespace on the Internet. As a result, it is possible for hackers to access the domain namespace and the user account login and password information.

If the current domain namespace is the same as the domain namespace registered on the Internet, it will be difficult to block DNS queries to administer the firewall security of an organization. An external namespace is also not useful when an organization uses multiple domain namespaces to identify the domains and all the domains need to be joined to design a single forest.

For example, ABC uses the Canada.ABC.com and Europe.ABC.com domain namespaces to identify the domains in its branch offices in Canada and Europe. The external namespace is not useful for the ABC organization when it wants to join the Canada.ABC.com and Europe.ABC.com domains to create a single forest, ForestA.

Note

An external namespace is also referred to as published namespace.

An internal domain namespace is not registered on the Internet. In an internal domain namespace, the UPN of the end users is different from their e-mail addresses. The internal namespace provides security to the domain because hackers are not able to access the internal namespace for a domain. In the internal domain namespace, you can create a namespace for the domain without using the standard namespaces, such as .com or .net. For example, you can provide ABC.ts as the internal domain namespace instead of ABC.com.

You need to register an internal domain namespace on a local network because a naming conflict may occur if the internal domain namespace is registered on the Internet. For example, if two organizations register their internal domain namespaces on the Internet with interdomain.net domain name then a naming conflict occurs between the applications and computer systems that perform DNS lookups to search for a domain in the forests that exist in the two organizations.

Domain Design Features

Windows Server 2003 provides various new features in Active Directory that helps you to design the domain models in Active Directory. Using the new features, you can perform the following functions when designing Active Directory:

• Rename a domain to change the position of the domains in Active Directory.

• Create cross-forest transitive trust relationships between the domains when designing Active Directory.

• Create the global catalog media.

• Administer the remote sites using the Terminal Services.

Note

The Terminal services feature provides administrative enhancement because it helps you to administer remote sites locally.

The renaming domain feature helps you to rename a domain in a Windows Server 2003 forest. You need to change the domain namespace while renaming a domain. As a result, renaming helps you to redesign Active Directory in Windows Server 2003 by repositioning the domains in Active Directory. You can make changes in the design of Active Directory by renaming the domains, after implementing the design.

The cross-forest transitive trust relationship is a two-way trust relationship between two separate forests. You can join multiple forests in Active Directory using the cross-forest transitive trust relationship. The collection of the forests joined by cross-forest transitive trust relationship is called federated forests.

The global catalog media allows the remote servers to function as the domain controllers by using a copy of the global catalog image available on a specific CD. The global catalog media feature of Windows Server 2003 also helps you to reduce the time required to set up remote domain controllers. In Windows 2000, the process of promoting the remote servers to domain controllers and replicating global catalog information is time consuming.

In Windows Server 2003, you can save the global catalog image to a media, such as a CD, transfer the image from the CD to remote sites, and run the dcpromo command to promote the remote servers to domain controllers. You need to insert the data disk with Active Directory on a remote server to restore Active Directory. You can save time and bandwidth by replicating only those changes made in Active Directory, which were made at the time of creating the global catalog media.

The Terminal services administrative enhancement feature of Windows Server 2003 helps you to remotely administer Windows Server 2003 installed on remote sites. A local administrator need not be present at each remote site. For example, you can use the Terminal services feature to change the desktop settings of remote sites running Windows Server 2003.

Selecting a Domain Design Model

You need to select a domain design model to arrange the domains when designing Active Directory. Windows Server 2003 provides the following domain design models:

• Single domain: Represents a domain model that consists of a single domain.

• Multiple subdomain: Represents a domain model that consists of a multiple domain below a domain.

• Multiple trees in a single forest: Represents a domain model that consists of multiple domain trees integrated to each other using trust relationship to form a single forest.

• Federated forest: Represents a domain model that consists of two separate forests integrated to each other using cross-forest trust relationship.

• Peer-root: Represents a domain design model that consists of a forest with two domains. The first domain in the forest contains of a domain controller with schema master and the second domain in the forest consists of user accounts.

• Placeholder: Represents a domain model that consists of a two domains. The first domain called the forest root domain contains the domain controller with schema master and the second domain consists of Active Directory objects

In the initial stage of designing Active Directory, you can use the single domain design model. Based on the requirements of the organization, you can design other domain models, such as federated forest, by adding new domains to the single domain design model. You can also use a hybrid model to design the domains in Active Directory. A hybrid model combines two domain models and is required when you want to use more than one design model in a single forest model.

Single Domain Model

A single domain model contains a domain in a forest present in Active Directory. This domain is the forest root domain and contains all the user and group accounts in the forest. The single domain model is simple to implement because it contains only one domain in Active Directory. For example, suppose the ABC organization has 500 employees and has its central office at Los Angeles. ABC also has branch offices in Canada and Europe, and their administration is managed from the central office. ABC has a single NT user domain and multiple resource domains in the branch offices.

ABC uses the single domain model to manage the administration, such as granting the access rights to the employees in the branch offices, from the central office.

Figure 14-4-5 shows the single domain model:

Figure 14-4-5: Single Domain Model

A security boundary defines the borders of the domain in a single domain model. The Active directory objects, such as users, exist within the security boundary of the domain.

Note

You do not need to set up a trust relationship in a single domain model, because it contains only one domain.

Some single domain model advantages include:

• A simple domain structure because only a single domain exists.

• Easier troubleshooting process of Windows Server 2003 because you need to troubleshoot the errors of the computers that exist in one domain.

• Reduced cost of administration.

• A centralized administration.

• The authority to assign various tasks to the lower level administrators because of a centralized administration.

In a single domain model, any domain controller can authenticate a user in a forest. All domain controllers in a single domain model can also act as global catalog servers, which store information related to the Active Directory objects. As a result, you need to decide, which domain controller in the single domain model should be a global catalog server.

A single domain model has the following disadvantages:

• Provides a single security boundary, which may not be suitable for all organizations. For example, suppose the research department of an organization wants to restrict the access of the network resources, such as the network printer, from the other employees of the organization. To do this, you need to create a separate domain for the research department.

• Makes the schema master insecure. A single domain model consists of one domain, which contains the schema master and the domain user accounts. The domain users in a single domain model can easily access the information contained in the schema master. As a result, the information contained in the schema master remains insecure.

Note

The schema master is a domain controller that controls the updates and modifications to a schema. The schema contains the definitions for all the Active Directory objects.

Multiple Subdomain Model

In a multiple subdomain model, you can add additional domains under a domain in a single forest. For example, suppose the ABC organization requires separate domains to provide separate administrative controls for its branch offices in Canada and Europe. ABC creates a multiple subdomain model by adding the subdomains for the Canada and Europe branch offices under the ABC.com domain.

Figure 14-4-6 shows the multiple subdomain model:

Figure 14-4-6: Multiple Subdomain Model

Some reasons that you may want to create a multiple subdomain model include:

• Decentralized administration

• Geographical restrictions

• Unique domain namespace considerations

• Separate password policies

• Organizational security issues

You can add multiple subdomains in a domain to provide decentralized administration. If different branches of an organization administer their own IT structure separately, the organization can add separate domains for its branch offices. The separate domains provide a security boundary for the network activities, such as accessing the printers in the branch offices.

There are various geographical restrictions that can compel an organization to add the subdomains under a domain. You can add the domains under an existing domain when your organization:

• Uses a slow and unreliable network link between the branch offices and the head office of an organization.

• Has greater geographical distance between the branch offices and the head office of an organization.

• Needs to control the replication activity between the domains.

• Needs to provide support to branch offices during working hours.

• Needs to provide a decentralized administrative control of a network. For example, in the ABC organization, the administrator for the Canada branch office has more administrative control on the network, which exists in the Canada branch office, when a separate subdomain is created.

You can also add multiple subdomains to a domain when two organizations, which have a common forest, need to use their Internet registered namespace for Active Directory. For example, the Canada and Europe branch offices of ABC use a common forest, ABC.com. ABC can add separate domains for the Canada and Europe branch offices, so that unique domain namespaces can be provided to these branch offices.

Different organizations might need to have separate password policies to due to the following reasons:

• Provide separate password policies for different branch offices. You can differentiate the password policies for the different branch offices of an organization when you add separate domains. As a result, you may need to create separate domains for the branch offices of the organization.

• Ensure security of the data available in the organization. An administrator can provide separate passwords to different employees to protect the data.

Organizational security issues can also compel you to add multiple subdomains under a domain. For example, to protect the schema master from unauthorized access, you need to place the domain controller, which contains the schema master, in a domain separate from the domain that contains the domain user accounts. As a result, you need to create a separate domain to place the schema master domain controller.

The benefits of using a multiple subdomain model are:

• Delegates separate administrative control and access permissions for separate domains of a forest.

• Controls the process of data replication separately within a forest.

The disadvantages of the multiple subdomain model are:

• Increases the cost of setting up the domains in a forest.

• Makes data access difficult, because the multiple subdomain model has a number of domains added to a domain. These domains contain various computers that store data. As a result, it becomes difficult to find the computer that contains the required data.

Multiple Trees in a Single Forest Model

In the multiple trees in a single forest model, you can integrate the domain trees with different domain namespaces. For example, suppose ABC acquires two small organizations, XYZ Web Solutions Inc. and XYZ Internet Solutions Inc. These two organizations have their own IT departments. XYZ Web Solutions has a domain tree that contains XYZWeb.com as the domain namespace. XYZ Internet Solutions Inc. has its own domain tree, which has XYZNet.com as the domain namespace. ABC uses the multiple trees in a single forest domain model to integrate the domain trees of the two acquired organizations.

Figure 14-4-7 shows the multiple trees in a single forest model:

Figure 14-4-7: Multiple Trees in a Single Forest Model

You can select multiple trees in a single forest model for an organization that has multiple branch offices and separate domain namespaces operating under it. The multiple trees in a single forest model is also suitable if an organization uses its separate domain namespaces. The administrators of the domain trees can control the corresponding domains when multiple trees in a single forest model is selected to design Active Directory.

Federated Forest Design Model

The federated forest design model helps you to establish a cross-forest transitive trust relationship between two different forests. The two forests are different when their domain controllers have different operating systems installed.

For example, there are two forests in the ABC organization, forestA and forestB. The forestA forest contains the domain controllers running on Windows 2000. The forestB forest contains domain controllers running on Windows Server 2003. The domain controllers of forestA have to be upgraded to Windows Server 2003 to establish a cross-forest transitive trust between the two forests. A one-way cross-forest trust relationship between the two Active Directory forests facilitates the sharing of resources among the domain users in the Active Directory forests.

You can also use the federated forest design model to design the domains when an organization acquires small organizations, which contain domain controllers with different operating systems. The federated forest domain design model establishes a two-way transitive trust relationship between the different forests of the merged organization.

Figure 14-4-8 shows the federated forest design model:

Figure 14-4-8: Federated Forest Design Model

You can also use the federated forest domain design model to secure the IT structures of different divisions of an organization. For example, suppose an aeronautics organization designs two different Active Directory forests, one for its civilian branch and the other for its military branch. The design of the Active Directory forests can separate the network of the two branches. The administrators of the civilian and military branches obtain the administrative control on the corresponding networks when the networks are separated.

Figure 14-4-9 shows the federated forest domain design model for the civilian and military branches of the aeronautics organization:

Figure 14-4-9: Federated Forest Design Model with One-Way Trust Relationship

Peer-Root Domain Model

In the peer-root domain model, you create a separate domain for the domain controller that is located in an unpopulated domain. An unpopulated domain controller contains the schema master but does not contain user accounts.

You use the peer-root domain model to protect the schema master from unauthorized access. For example, if ABC wants to restrict the access to the domain controller from all its employees, you can use the peer-root domain model. Using the peer-root domain model, ABC creates two domains. The first domain in the peer-root domain model contains the domain user accounts and computer accounts. The second domain in the peer-root model contains the domain controller with the schema master. The access to the domain, which contains the domain controller with schema master, is restricted to the administrator of the domain only.

Figure 14-4-10 shows the peer-root domain model:

Figure 14-4-10: Peer-root Domain Model

In the peer-root domain model, working with the domains is easy because you can rename and add new domains. For example, suppose ABC has arranged its domain in the peer-root domain model. The root domain that contains the schema master has the ABCSchema.root domain namespace. The domain, which contains the Active Directory objects, has the domain namespace, ABC.com. ABC has separate domains for its branch offices located in Europe and Asia. ABC can add the domains for its Europe and Asia branch offices by joining them to the ABCSchema.root domain.

A disadvantage of the peer-root domain model is that it increases the expenses of an organization, because the organization needs a separate domain controller, which contains the schema master.

Placeholder Domain Model

The placeholder domain model consists of a forest root domain and a subdomain, which contains the Active Directory objects. The root domain in the placeholder domain model is an unpopulated domain, which does not contain the Active Directory objects. The domain controller containing the schema master is placed in the root domain. The placeholder domain model also helps you to protect the schema master.

Figure 14-4-11 shows the placeholder domain model:

Figure 14-4-11: Placeholder Domain Model

For example, suppose ABC wants to protect the schema master from being accessed by the employees working in its branch offices in Europe and Asia. ABC uses the placeholder domain model to protect the schema master. The domains for the branch offices in Europe and Asia are placed under a common forest root in the placeholder domain model.

Figure 14-4-12 shows the placeholder domain model, which the ABC organization uses:

Figure 14-4-12: Placeholder Domain Model for ABC Organization

The placeholder domain model has a single domain namespace with multiple domains. The advantages of the placeholder domain model are:

• Protects the schema. The domain controller that contains the schema master is placed in a separate domain called the forest root domain.

• Provides consistency in the namespace for the domains that contain the user accounts. This is because domains that contain the user accounts can use the domain namespace of the other domain, which contains the domain controller with the schema.

Note

The placeholder domain model is also called the sterile parent domain model.

Renaming Active Directory Domain

Active Directory of Windows Server 2003 provides a new feature to rename the domains. This feature also helps you to position the domains at different locations within a forest.

You can redesign the domains in Active Directory by using the renaming feature. Using this feature, you can:

• Rename a domain namespace. For example, you can rename the ABC.com domain namespace to GlobalABC.com.

• Rename a NetBIOS domain name.

• Rename both the NetBIOS domain name and the domain namespace.

Limitations of Renaming Domains

There are limitations that exist in the process of renaming the domains in Windows Server 2003. These limitations restrict you from performing certain tasks while renaming domains. These limitations:

• Restrict you from adding new domains in a forest after a specific limit.

• Restrict you from demoting the current root domain.

• Allow you to transfer the current domain names one at a time only.

• Restrict you from renaming the forests that contain the domain controllers with the Exchange 2000 applications.

While renaming the domains using the domain rename tool, you cannot reduce the number of domains that exist in a forest. The number of domains, which were present in Active Directory before renaming the domains, has to correspond to the number of domains after the renaming of the domains. For example, if you are renaming four domains of a forest, the number of renamed domains should also be four.

You cannot change the position of the root domain when renaming the domains of an Active Directory. You can change the positions of other domains in Active Directory when renaming the domains.

You cannot rename a domain, which has the same name as another domain in a forest. For example, if you need to rename domA to domB, when another domain, domB, already exists in the same forest, you need to change the name of domB to some other name, such as domX, and then rename domA to domB.

Windows Server 2003 provides a tool to rename the domains. You cannot use this tool to rename the domains that have the Exchange 2000 application integrated into the schema present in the domain controllers. This is the primary limitation of renaming the domain in Windows Server 2003.

Requirements for Renaming Domains

There are certain tasks that you need to perform before renaming the domains in Windows Server 2003 as follows:

• Upgrade the operating systems of the domain controllers in the forest to Windows Server 2003. You need to upgrade all the domain controllers in a domain to Windows Server 2003 before renaming the domains. You also need to upgrade all the computers present in the forest to Windows Server 2003.

• Create new DNS (Domain Name System) zones for the domains that are renamed. A new zone for the domain namespace can be created on a DNS server. You do not need to create a new DNS zone when you are renaming the NetBIOS domain name of a domain.

• Run the domain rename process from a console server. A member computer, with Windows Server 2003 operating system installed on it, should be a console server to run the renaming domain process. A domain controller cannot be a console server.

• Create the shortcut trust relationships. You also need to create a shortcut trust relationship after you have changed the position of a domain, to place it in a new location. The shortcut trust relationship exists between the parent domain and the domain that you have placed in a new location.

Rules and Conditions for Renaming Domains

The renaming domain feature of Windows Server 2003 helps to rename and reposition the domains in a forest. The repositioning of the domains in a forest helps you to restructure a forest in Active Directory, which in turn, lets you change the DNS and NetBIOS names of the domains. The forest, which you are restructuring, has to be a well-formed forest. The characteristics of a well-formed forest include:

• One or more domain trees, which use the DNS name of the domains in the forest.

• The forest root as the root domain for one of the domain trees designed using the DNS names of the domains in the forest.

• Restriction of the domain directory partition to be a child partition for an application directory domain in a forest.

There are various conditions that exist in the renaming domain process. In the domain renaming process, you need to implement a headless management of the domain controllers. The headless management of the domain controllers means that you need to separately make changes, which arise due to the renaming of a domain, on each domain controller in the forest. The Active Directory replication does not automatically make changes on the domain controllers.

After the domain rename process, the forest remains out of operation for the duration between the time when you make the changes based on the renaming of the domains, and the rebooting of the domain controllers.

You also need to rename all the domain controllers before renaming the domains in a forest. If all the domain controllers are not renamed, the domain controllers that cannot be renamed have to be removed from the forest. You need to rename the domain controllers so that the DNS host names of the domain controllers match with the new domain name. The domain rename process is complete only when all the domain controllers are renamed. You can perform the task of renaming the domain controllers as a post domain rename task.

After renaming the domains, you also need to reboot each member server, which joins the renamed domain twice after all the changes have been made to the domain controllers. The computers running on Windows NT 4.0 need to disjoin from the renamed domain and rejoin the renamed domain again.

After renaming domain the DNS suffix of the member server host names does not match with the DNS name of the renamed domain for a specific period of time. Windows Server 2003 updates the DNS suffix of the member server host name when there is a change in the domain that is joined to the member server. Rebooting the member servers help you to match the DNS suffix of the member server host names with the DNS name of the renamed domain.

Effects of Renaming Domains

Renaming domains changes the position of the domains in a forest. For example, renaming of a child domain can change its position in the forest, and the child domain can exist under a different parent domain after renaming the child domain. The changes that you can make to the domains in a forest are:

• Rename the domains in a forest without changing the position of the domains.

• Create a new domain structure by repositioning the domains within a domain tree.

• Create a new tree root.

• Rename the domains and repositioning them to a different domain tree.

Note

You cannot use the renaming domain feature when you need to merge two forests or position a domain from one forest to another.

When you rename the parent domain, you also need to rename the child domains so that there is no change in the position of the domains. For example in the ABC organization, the domain namespace of a parent domain is ABC.com.

This ABC.com parent domain has various child domains, such as eu.ABC.com, hr.ABC.com, and research.ABC.com. ABC has to rename the child domains when it changes the ABC.com parent domain namespace to GlobalABC.com because of the changes in the organizational policies.

The child domains have the domain namespaces, such as eu.GlobalABC.com, hr.GlobalABC.com, and research.Global.ABC.com, after renaming.

Figure 14-4-13 shows the renamed domains without repositioning the domains:

Figure 14-4-13: Renaming Domain Without Repositioning

You can create a new domain structure in a forest by renaming a domain, such that it appears at a different location in a domain tree. For example, in the forest for ABC, the training.research.GlobalABC.com domain appears under the research.GlobalABC.com domain. If ABC wants to position the training.GlobalABC.com domain under the GlobalABC.com forest root domain, it can rename the training.research.GlobalABC.com domain to the training.GlobalABC.com domain namespace.

Figure 14-4-14 shows the renamed domain repositioned in the same forest:

Figure 14-4-14: Renaming Domain with Repositioning in the Same Forest

You can also create a new tree root in a forest by renaming the domain and repositioning it. For example, before renaming, the eu.GlobalABC.com domain is under the GlobalABC.com forest root. ABC wants to make the eu.GlobalABC.com domain a new tree root, with the europeGlobalABC.com domain namespace.

Figure 14-4-15 shows the renamed and repositioned domains to create a new tree root:

Figure 14-4-15: Creating a New Tree Root in a Forest

You can reposition a domain to a different domain tree by renaming the domains and positioning the child domains under a different parent domain. For example, the ABC organization contains the hr.GlobalABC domain under the GlobalABC.com parent domain.

The organization needs to move the human resource department to Europe because of changes in the organization. ABC can rename the hr.GlobalABC.com domain to the hr.europeGlobalABC.com domain namespace and reposition the domain under the europeGlobalABC.com parent domain.

Figure 14-4-16 shows renaming and repositioning of the domains to a different tree:

Figure 14-4-16: Repositioning to a Different Tree

How to Rename Domains

You can rename a domain after fulfilling the requirements for the domain renaming process. You need to perform the following tasks to rename a domain:

• View the current forest description.

• Change the forest description in the Domainlist.xml document to reflect the new domain names. The Domainlist.xml document contains the domain naming information for a forest. This domain naming information is called forest description.

• Upload the Domainlist.xml document to the domain controllers.

• Prepare the domain controllers for renaming the domains.

• Perform the domain rename process.

• Perform the post-rename tasks, such as renaming the domain controller.

You can view the current forest description as an XML file. Windows Server 2003 provides the random tool to rename a domain. The rendom tool has various flags, such as /list and /upload. You run the rendom /list command, which is the first command that searches for the domain controllers in a domain and parses the domain naming information into the Domainlist.xml document. The rendom /list command also displays the current forest description contained in the Domainlist.xml document. You can also change the contents of the Domainlist.xml document using a text editor, such as Notepad.

You also need to change the forest description in the Domainlist.xml file to reflect the new domain renaming information. For example, if ABC changes its name to GlobalABC, then all references to ABC have to be changed to GlobalABC. You also need to change the NetBIOS and DNS names for ABC.

The Domainlist.xml document needs to be uploaded on all the domain controllers of a domain after you have changed the forest description. This process of uploading the Domainlist.xml document to all the domain controllers ensures that the domain controllers have updated the information related to the domain before renaming the domain.

You can use the rendom /upload command to upload the Domainlist.xml document on all the domain controllers in a domain. After uploading the Domainlist.xml document to all the domain controllers in the domain, the rendom tool copies the instructions and the new domain information provided in the Domainlist.xml document, on all the domain controllers within a forest.

You run the rendom /prepare command to set the domain controllers to the rename the domains. The rendom /prepare command initiates a process of setting the domain controllers for renaming, which verifies if all the domain controllers listed for the domain in Active Directory are responding to the rendom command. If all the domain controllers do not respond to the rendom command, the rendom /prepare command fails and needs to be restarted.

You can perform the domain rename process after all the domain controllers respond to the rendom /prepare command. Run the rendom /execute command on the console server to perform the renaming process. The domain controllers reboot to reflect the domain rename change after you run the rendom /execute command.

You need to reboot all the member server and workstation computers in a domain. You may also need to reboot the member servers and workstation computers in the domain twice to ensure that the services running on them reflect the new domain with the renamed domain namespace.

There are two post rename tasks that you need to perform after renaming the domains. The first task is to remove the temporary files from the domain controllers. The second task is to rename each domain controller in the domain.

You can remove the temporary files, which are created on the domain controller while renaming the domains, by using the random /clean command. The task of removing the temporary files is called the cleanup operation. The domain becomes operational after you have performed the cleanup operation.

You need to rename each domain controller in the domain to change its primary DNS suffix. The primary DNS suffix of a domain controller does not match with the new DNS name of the domain after renaming the domain. As a result, you need to change the primary DNS suffix. You can rename the domain controller in a domain using the netdom command-line utility.

To rename the domain controller in the domain:

1. Select Start ->Run to display the Run dialog box.

2. Type cmd.exe or command prompt in the Open text box.

3. Click the OK button to open the Command Prompt window.

4. Type netdom compname olddcname /add:newdcname on the command line in the command prompt window.

5. Type netdom compname olddcname /makeprimary:newdcname.

6. Restart the domain controller.

7. Type netdom compname newdcname on the command line in the command prompt window.

To rename a domain controller, you need to replace the olddcname and newdcname parameters with the DNS names of the old and new domain controllers. For example, you can replace the olddcname parameter with server1.ABC.com, and the newdcname parameter with server1.GlobalABC.com.