Best Practice Active Directory Deployment for Managing Windows Networks

Article
12/09/2009

This guide assists architects, project managers, and consultants in deploying an Active Directory® service in a network operating system (NOS) infrastructure. The best practices deployment methodology encapsulates technical expertise from the Microsoft Windows Product Group with lessons learned from customers have implemented Active Directory in their organizations.

Overview of Active Directory Deployment
Testing And Verifying the Deployment Process
Configuring DNS for the Forest Root
Creating the Forest Root
Deploying Regional Domains
Creating a New Regional Domain
In-Place Upgrading of Account Domain
Restructuring Account Domains
Restructuring Resource Domains
Decommissioning the Windows NT 4.0 Domains
Importing Accounts and Data From Other Sources

Overview of Active Directory Deployment

Many organizations are migrating from Microsoft® Windows NT® version 4.0 to Microsoft® Windows 2000 and the Active Directory. The Windows 2000 and Active Directory deployment process must:

Allow the organization to continue normal business operations while migrating the network.
Minimize any modifications to the existing network infrastructure.
Allow existing user accounts and resource permissions to be migrated.
Include the migration of services and applications running on existing servers.

This document describes the deployment of Windows 2000 and Active Directory. Specifically, you will learn the best practices for deploying your Active Directory design by:

Testing your design assumptions and deployment processes in a lab environment.
Verifying your deployment process in a pilot deployment.
Deploying Active Directory to your production environment.

Prior to performing the tasks in this document, create an Active Directory design for your organization. For more information about creating an Active Directory design for your organization, see Best Practice Active Directory Design for Managing Windows Networks at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx.

Note: All references to Windows 2000 include both Microsoft® Windows® 2000 Server and Microsoft® Windows® 2000 Advanced Server, unless otherwise specified.

Active Directory Deployment Process

Figure 1 illustrates a flowchart of the Active Directory deployment process presented in this document. You can follow this as a model for your Active Directory deployment

Figure 1: Flowchart of the Active Directory deployment process

This document presents the deployment process for existing networks based on Windows NT 4.0 and other network operating systems.

Windows NT 4.0

Use this document to guide your migration from Windows NT 4.0 to Windows 2000 and Active Directory by reading the following sections:

"Testing and Verifying the Deployment Process"
"Configuring DNS for the Forest Root"
"Creating the Forest Root"
"In-Place Upgrading Account Domain" or "Create a New Regional Domain"
"Restructuring Related Account Domains"
"Restructuring Related Resource Domains"
"Decommissioning Windows NT 4.0 Domains"

Other Network Operating Systems

Use this document to guide your migration from other network operating systems to Windows 2000 and Active Directory by reading the following sections:

"Testing and Verifying the Deployment Process"
"Configuring DNS for the Forest Root"
"Creating the Forest Root"
"Creating a New Regional Domain"
"Importing Accounts and Data from Other Sources"

Deployment Tools Used in This Document

The Active Directory deployment process described in this document uses tools that are not a part of the Windows 2000 operating system. Table 1 lists the tools incorporated in the deployment process, where the tools are found, and a brief description of the purpose of the tool.

Table 1 Tools Used In The Active Directory Deployment Process

Tool	Location	Use
Active Directory Migration Tool (ADMT)	https://www.microsoft.com/downloads/details.aspx?FamilyID=788975b1-5849-4707-9817-8c9773c25c6c&DisplayLang=en	Migration of account and resource domains
Dcdiag.exe	Support folder on the operating system CD	Verification of successful domain controller deployment
Lbridge.cmd	Microsoft® Windows® 2000 Server Resource Kit	Replication of logon scripts and profiles between Windows 2000 domain controllers and Windows NT 4.0 domain controllers

Recommended Reading

Table 2 lists additional resources to help improve your understanding of topics related to Active Directory deployment.

Table 2 Recommended Reading

Title	Source
Windows 2000 DNS	TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit
Active Directory Branch Office Planning Guide	https://www.microsoft.com/technet/archive/windows2000serv/technologies/activedirectory/deploy/adguide/default.mspx

Introduction to Contoso Pharmaceuticals Example

This document provides an example of each Windows 2000 Active Directory deployment process step of a fictitious company named Contoso Pharmaceuticals. Throughout this document, references are made to the geographic locations, business units, and existing network infrastructure of Contoso.

Note: The Contoso example includes enough detail so that you can reproduce the entire example deployment in your lab.

Business Units

Contoso is comprised of the following business units:

Contoso Pharmaceuticals

Contoso Pharmaceuticals is a bioelectronics design and manufacturing firm headquartered in Seattle, Washington. Contoso provides bioelectronics devices (such as pacemakers, defibrillators, and heart-assist devices). Contoso distributes these devices throughout the world.
Trey Research

Trey Research is a research and development firm that specializes in radio frequency (RF) designs. Trey Research provides outsourced engineering consulting for organizations that manufacture RF devices used in the aviation industry (such as radio transceivers, global positioning systems (GPSs), or transponders). Contoso acquired Trey Research to design RF electronic devices (such as in-home critical-care monitoring systems and mobile electrocardiogram (EKG) and vital statistic monitoring systems). Trey Research continues to operate as a separate business unit with customers other than Contoso.
Fabrikam, Inc.

Fabrikam, Inc. is an electronics manufacturing firm located in Asia. Fabrikam provides printed circuit board fabrication, sheet metal fabrication, injection molding, and electronics assembly services. Contoso acquired Fabrikam to reduce the manufacturing cost associated with bioelectronics devices designed and marketed through Contoso and Trey Research. Fabrikam's entire manufacturing capacity is totally consumed by Contoso and Trey Research. As a result, Fabrikam, Inc. is integrated with the Contoso business unit.

The characteristics of the business model that exists among the Contoso business units include the following:

Contoso is the "parent" organization that determines any standards that apply to all business units.
The research and development teams within Contoso work closely with the manufacturing teams in Fabrikam, Inc.
The network infrastructure is provided by (or through) Contoso and provides wide area network (WAN) connections between locations in the business units.
Contoso has standardized on Microsoft® Exchange Server version 5.5 for the messaging infrastructure in all business units.
Trey Research just completed a migration of all clients to Windows 2000 Professional.
The other business units are comprised of clients running a variety of including, Microsoft® Windows NT® Workstation version 4.0, Microsoft® Windows® 95, and Microsoft® Windows® 98.

Geographic Locations

Figure 2 presents a map of the world that includes the business locations of Contoso, Fabrikam, Inc., and Trey Research.

Figure 2: Contoso, Fabrikam, and Trey Research locations

Table 3 lists the Contoso, Fabrikam, and Trey Research locations and business functions performed at each location. Windows NT 4.0 is currently deployed at all geographic locations.

Table 3 Contoso Locations and Business Functions

Location	Business Functions
Contoso
Seattle	Headquarters for Contoso where all accounting and administration is performed. A research and development facility is located in the same building.
Boston	Legal department and specialist that obtain government approvals, such as from the Food and Drug Administration (FDA), for all products. Domestic marketing and sales offices are located in the same building.
Vancouver	Research and development facility that designs new products. Headquarters for Canadian engineering and product support (responsible for assisting customers in using Contoso products).
Montreal	Canadian marketing and sales office.
Milan	European marketing and sales headquarters.
Seville	Headquarters for European engineering and product support (responsible for assisting customers in using Contoso products).
Trey Research
Renton	Headquarters for Trey Research where all accounting and administration is performed. A research and development facility is located in the same building.
Atlanta	Research and development facility that designs new products. Headquarters for domestic engineering and product support (responsible for assisting customers in using Contoso products).
Fabrikam, Inc.
Hong Kong SAR	Headquarters for Fabrikam where all accounting and administration is performed. A manufacturing and testing facility is located in the same building, which is used for small production runs of products or for prototype development.
Tokyo	Manufacturing and testing facility used for high-volume production runs.

Testing And Verifying the Deployment Process

As you are creating the first draft of your Active Directory design, begin the testing and verification phase. Figure 3 illustrates when testing and verifying occurs in your deployment process. The testing and verification phase begins during the design phase and continues through the deployment phase.

For more information about the design phase, see Best Practice Active Directory Design for Managing Windows Networks at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx.

Figure 3: Testing and verifying in the deployment process

In any Active Directory deployment, you can minimize the impact on normal business operations by including:

Preliminary testing of the deployment process in a lab environment. Preliminary testing includes:
- Design assumption tests.
- Deployment process tests.
Verification of the deployment process in a pilot program.

Figure 4 illustrates the life cycle of the design, lab testing, pilot deployment, and production deployment phases of your deployment project. Lab testing overlaps the design and pilot deployment phase. The pilot deployment begins as the design process nears completion and continues on indefinitely.

Figure 4: Lifecycle of design, lab testing, pilot deployment, and production deployment.

Note: The deployment process that you are testing and verifying is the same deployment process discussed in the remainder of this document.

Testing in a Lab Environment

Lab testing is the first evaluation of the Active Directory design. During lab testing, you are confirming the assumptions made by the design architects. When any of the assumptions that you test prove to be incorrect, the design architects must modify their design to reflect the outcome of the lab tests.

As the first draft of the Active Directory design approaches completion, begin testing specific design assumptions in the deployment process in a lab environment. Your primary objectives for testing the deployment process in your lab are to:

Discover any potential design problems that affect the deployment process.
Provide feedback to the design team, prior to the deployment, to correct any problems discovered during testing.

Ensure that the test lab environment is:

Isolated from the rest of your organization's production network.
Includes user and group accounts and resources that are exclusively designated for testing (no production accounts or resources).
Represents, on a small scale, the hardware and operating system configuration of the computers in your organization.
Retained permanently as a training tool and to test new procedures.

The deployment team can use the lab environment to learn the specifics of your deployment process and to gain familiarity with the deployment and migration tools used during Active Directory deployment.

As previously mentioned, lab testing provides validation for the design assumption and for the deployment process. Typically, the design assumption tests and deployment process tests are performed by different teams. Table 4 lists the lab tests and team members that perform the tests in the lab.

Table 4 Lab Tests and Corresponding Team Members

Lab Tests	Team Members
Testing Design Assumptions
Analyze Active Directory replication and site topology	· Design team · Site topology owner · Deployment team
Test application and desktop compatibility	· Design team

Testing Deployment Process
Test disaster recovery	· Domain owner · Deployment team
Test account and resource migration	· Domain owner · Deployment team
Evaluate delegation, administration, and management	· Domain owner

Testing Design Assumptions

During the design process, the design team makes assumptions that are incorporated into the Active Directory design (such as Active Directory replication and application compatibility). After a preliminary draft of the design is complete, the design team must prove these assumptions in the lab environment.

To test the design assumptions in the lab environment:

Analyze Active Directory replication and site topology.
Verify application and desktop compatibility.

Analyze Active Directory Replication Site Topology

As part of the Active Directory design, the design team specifies the maximum replication latency between hubs in the replication site topology. Replication latency is the length of time required to replicate changes within the forest.

To analyze Active Directory replication site topology:

Ensure that forest-wide replication latency is less than or equal to the maximum replication latency specified in the design.
Ensure you test from furthest point to furthest point, or a worst-case test, based on the maximum number of hops assumed in the design.

Observe the time required for replication convergence when a domain controller or communications link fails by completing the following steps:
1. Identify the domain controllers that are responsible for intersite replication by using the Active Directory Sites and Services snap-in of Microsoft Management Console (MMC).
2. Disconnect domain controllers or disable communications links that are used in intersite replication.
3. Allow the Knowledge Consistency Checker (KCC) to automatically configure new replication topology.
4. Identify the domain controllers that are now responsible for intersite replication.
5. Reconnect the domain controllers or enable communications links.
6. Verify that the intersite replication topology returns to the original state, as identified in the first step.
  
  Note: Replication convergence can take hours to complete, based on the number of replication changes and the intersite communications links.

For more information about replication convergence and latency design considerations, see Best Practice Active Directory Design for Managing Windows Networks at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx.

Verify Application and Desktop Compatibility

As part of the Active Directory design, the design team must determine the compatibility between applications, desktop operating systems, and Active Directory. Typically, the aspects of application testing that are affected by an Active Directory migration include applications that run on:

Servers
Desktop computers
Laptop computers
Remote access users

Verify the application and desktop compatibility design assumptions by:

Creating a list of all critical applications.
Ensuring that each application is assigned an individual responsible for testing the application.
Testing that each application operates properly in a migrated environment.

When verifying application and desktop compatibility, ensure that:

Existing server applications, currently running on a Windows NT 4.0 backup domain controller (BDC), can run on Windows 2000 domain controllers.

For example, some server applications running on BDCs take advantage of Shared Local Groups. To run these server applications on Windows 2000, verify that the applications run properly by using Active Directory domain local groups.
Existing server applications can run on Windows 2000 member servers.
Server applications running on a mixture of Windows 2000 and Windows NT 4.0 servers can interoperate with one another.

For example, make sure a Microsoft® SQL Server running on Windows 2000 can interact with a SQL Server running on Windows NT 4.0.
Existing desktop applications run correctly when the domain infrastructure is migrated to Windows 2000 and Active Directory.
Existing applications that use integrated Windows security run correctly when the domain infrastructure is migrated to Windows 2000 and Active Directory.

If you find that a server application cannot be migrated to Windows 2000 domain controller, do one of the following:

Leave the application running on the Windows NT 4.0 domain controller.
Run the application on a Windows 2000 member server.
Run the application on a Windows NT 4.0 member server.
Provide feedback to the design team that the server application's domain cannot be in-place upgraded or consolidated.

The Windows NT 4.0 domain must remain until a version of the application that can run on a Windows 2000 domain controller is available.

As a long-term deployment goal, transition any applications currently running on domain controllers to member servers.

Testing Deployment Processes

During the deployment process, the deployment team must perform specific tasks that are essential to ensure success (such as testing account and resource migration from Windows NT 4.0 to Windows 2000 and Active Directory). Before starting the production deployment, the deployment team must verify these tasks in the lab environment.

To verify the deployment process in the lab environment:

Test disaster recovery.
Test account and resource migration.
Evaluate delegation, administration, and management.

Test Disaster Recovery

Test disaster recovery in your lab environment to validate:

The time required to restore a domain controller in the event of a failure.
Users can log on within an acceptable response time until a failed domain controller is restored.

To implement a disaster recovery process in your Active Directory deployment:

Back up the Active Directory database of at least two domain controllers.

Restore the Active Directory database from backup when:
- A domain controller is the only domain controller in a site connected with a data rate of 128 kilobits per second (Kbps) or less
- A domain contains more than 20,000 user accounts.
Restore the Active Directory database on a failed domain controller by installing a new domain controller and letting Active Directory replication repopulate the Active Directory database when the domain controller is connected to other domain controllers with a data rate equal to or greater than 128 kilobits per second (Kbps).

Test the following disaster recovery scenarios in the lab environment:

Restoring a domain controller after any hardware failure.
Restoring a domain controller after any operating system failure.
Recovering a domain controller when the directory services database contains corrupted data.
Recovering data inadvertently deleted from the directory service by performing an authoritative restore.

Test Account and Resource Migration

Prior to starting the pilot deployment program, test the deployment process for account and resource migration by using the complete set of procedures outlined in this document.

To test migration of Windows NT 4.0 account and resource domains:

In two or more production Windows NT 4.0 account domains, create a new backup domain controllers (BDCs).
Remove the new BDCs from the production network.
Install the new BDCs in the lab environment.
Promote the new BDCs to primary domain controllers (PDCs).
Perform in-place upgrades and restructuring of the account domains in your lab
Verify migrated accounts have access to resources and retain user profiles.

For more information about the migration of Windows NT 4.0 account and resource domains see the following sections in this document:

Creating a New Regional Domain
In-place Upgrading of Account Domains
Restructuring Account Domains
Restructuring Resource Domains

Evaluate Delegation, Administration, and Management

After you have successfully tested the migration of users and resources in your lab environment, but prior to starting the pilot deployment program, evaluate the delegation, administration, and management processes by:

Creating an organizational unit (OU) structure that reflects the Active Directory design best practices.

For more information about creating an OU structure, see Best Practice Active Directory Design for Managing Windows Networks at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx.
Delegating permissions on OUs to specific group accounts used for administration.

Verifying the success of the delegation by:
1. Logging on as a user that belongs to the group account to which you delegated permissions.
2. Performing administration tasks on objects within the OU (such as modifying the properties of a user in an account OU).
3. Attempting, and subsequently failing, to perform administrative tasks on OUs to which the administration group does not have delegated permissions.

Verifying in a Pilot Deployment Program

After you complete the testing in the lab environment phase of your deployment process, you can start the pilot deployment program. In the lab environment, you ensured that the deployment process worked outside your production environment on accounts and resources that approximated your production environment. In the pilot deployment program, you:

Identify a controlled subset of the accounts (users, groups, and services) and resources that exist in the production environment.
Perform the deployment process on the identified accounts and resources.

Deployment Best Practice

In your pilot deployment, begin with users who are involved in the deployment project and then include users who are representative of your user population.

Use the pilot deployment environment to:

Extend testing into a subset of the production environment.
Provide a test environment for other design and deployment groups.
Verify process and procedures for network and operating system infrastructure updates.
Verify proper operation of application updates.
Evaluate the impact of monitoring solutions on the network infrastructure and the servers being monitored.
Discover any potential problems in the deployment process that are caused by complexities that could not be modeled in the lab environment.
Revise the deployment process to correct any problems you discovered prior to the production deployment.

To create a pilot deployment program in your environment

Create forest_root_domain (where forest_root_domain is the name of an empty Active Directory forest root domain created by appending "-test" to the same name of the production forest root domain).
Create regional_domain (where regional_domain is the name of an Active regional domain created by appending "-test" to the same name of a production regional domain).
Establish the appropriate trust relationships between regional_domain (where regional_domain is the name of a regional domain in the pilot program) and winnt_domain (where winnt_domain is an account or resource domain for migration from Windows NT 4.0-based networks).
Migrate selected accounts and resources from winnt_domain (where winnt_domain is an account or resource domain for migration from Windows NT 4.0–based networks), or other data sources, to regional_domain (where regional_domain is the name of a regional domain in the pilot program) by using the procedures in this document.
Verify that users and administrators can minimally perform the same tasks as they did prior to migration (resource access, account administration, resource administration, etc.).

Note: When you migrate production users to the pilot, leave the user accounts enabled in the production and the pilot environments. By leaving the user accounts enabled in the production environment you provide a fallback plan in the event of any issues in the pilot environment.

Contoso example: Crating a pilot deployment program

Create the Contoso pilot deployment program by using the process described in the previous section and the information in Table 5.

Table 5 Information For Creating a Pilot Deployment Program

When Prompted For	Use
forest_root_domain	concorp-test.contoso.com
regional_domain	noam-test.concorp-test.contoso.com
winnt_domain	USA for account domains SEATTLE for resource domains

Figure 5 illustrates the pilot deployment configuration.

Figure 5: Pilot deployment configuration.

Completing the Pilot Deployment Program

After you complete the pilot deployment program, retain the pilot deployment environment. Continue to use the pilot forest to verify new deployment processes, such as adding new applications or schema extensions, installing operating systems, creating Group Policy settings, or OU restructuring.

Deployment Best Practice

During the production deployment process, always migrate accounts from the production environment. Never migrate accounts from the pilot environment.

To complete the pilot deployment program in your environment

After you complete the pilot deployment process, users can do one of the following:

Continue to log on to the pilot domain until their account is migrated during the production deployment process.
Return to the production environment immediately by logging on to their Windows NT 4.0 domain.

Contoso example: Completing the pilot deployment program

Figure 6 illustrates the Active Directory pilot program forest after production deployment.

Figure 6: Comparison of the pilot forest and the production forest

After the completion of the pilot deployment program, you can start the deployment of Windows 2000 and Active Directory into your production environment.

Configuring DNS for the Forest Root

The first step in the production deployment process is to configure the DNS domain for the forest root, as shown in Figure 7.

Figure 7: Configuring DNS for the forest root in the deployment process

The DNS administrator of your organization is responsible for delegating the DNS domain used by the forest root domain.

Important: When no DNS infrastructure exists, skip this step in the deployment process and proceed to the next step, "Creating the Forest Root." The remainder of this step describes the process of configuring and delegating a domain in the existing DNS internal namespace.

To configure DNS for the forest root:

Review the DNS design worksheet created by the forest root owner and directory architect.
Review the existing internal DNS namespace.
Delegate the DNS domain name from the existing DNS internal namespace.

Review the DNS Design Worksheet

Before you review the existing DNS infrastructure in your design, review the DNS design worksheet prepared by the forest root owner and the directory architect.

The DNS design worksheet describes:

DNS domains that must be delegated.
DNS servers that must be modified for the delegation.

Review the Existing DNS Infrastructure

After you review the DNS design worksheet prepared by the forest root owner and the directory architect, review the existing DNS infrastructure.

To review the existing DNS infrastructure in your environment

Review the existing DNS infrastructure by examining current:

Network diagrams.
DNS domain hierarchy diagrams.
DNS zone configuration.
DNS resource records for delegation and forwarding.
DNS replication.

Contoso example: Reviewing the existing DNS infrastructure

Review the existing DNS infrastructure for the Contoso and Trey Research business units. The existing DNS infrastructure for Contoso provides name resolution for:

Any servers (such as Web or mail servers) that reside in the perimeter network and are accessed by Internet users.
Any computers (or other network devices) that reside in the private network and run an operating system other than Windows NT 4.0 (such as UNIX or Macintosh operating systems).

Note: Windows NT 4.0–based computers in the private network use Windows Internet Name Service (WINS) to provide name resolution.

After Fabrikam, Inc and Trey Research were acquired by Contoso, their existing DNS infrastructure was integrated into the DNS infrastructure for Contoso. Each business unit in Contoso continues to use its respective registered DNS domain name. These DNS domain names are:

Used by each business unit to provide DNS naming for computers that are accessed by Internet users.
Represent the external DNS namespace for each business unit.
Hosted by the Berkeley Internet Name Domain (BIND) DNS servers (SEA-CON-DNS-01 and SEA-CON-DNS-02) that are placed in the perimeter network.

Table 6 lists each business unit and the corresponding registered DNS domain name.

Table 6 Registered DNS Domain Names of Contoso Business Units

Business Unit	Registered DNS Domain Names
Contoso	contoso.com
Trey Research	treyresearch.net
Fabrikam, Inc.	fabrikam.com

Contoso, Trey Research, and Fabrikam, Inc. also maintain a separate DNS namespace (with the same name as the external namespace) to resolve internal names. Each geographic location maintains a delegated domain beneath the corresponding business unit.

These DNS domain names are:

Used by each business unit to provide DNS naming for computers within the private network.
Represent the internal DNS namespace for each business unit (and subsequently each geographic location).
Hosted by a combination of DNS servers running BIND and Windows NT 4.0 DNS.
Placed within the private network at each geographic location.

Table 7 lists each geographic location and the corresponding internal DNS domain names for each location.

Table 7 Internal DNS Domain Names of Contoso Locations

Location	Internal DNS Domain Name
Contoso	contoso.com
Seattle	seattle.contoso.com
Boston	boston.contoso.com
Vancouver	vancouver.contoso.com
Montreal	montreal.contoso.com
Milan	milan.contoso.com
Seville	seville.contoso.com
Trey Research	treyresearch.net
Renton	renton.treyresearch.net
Atlanta	atlanta.treyresearch.net
Fabrikam, Inc.	fabrikam.com
Hong Kong SAR	hongkong.fabrikam.com
Tokyo	tokyo.fabrikam.com

Each of the location-specific subdomains contains only the resource records for its location. The DNS servers within each respective location:

Are delegated authority for their domains from the top-level internal DNS servers (SEA-CON-DNS-01 and SEA-CON-DNS-02)
Forward unresolved queries to the top-level internal DNS servers (SEA-CON-DNS-01 and SEA-CON-DNS-02)

Note: The DNS servers (SEA-CON-DNS-01 and SEA-CON-DNS-02) in Seattle host the top-level internal domain names and secondary copies of the domain names from all locations.

Delegate the DNS Domain for the Forest Root

After you identify the DNS domain names that must be delegated in the existing DNS namespace, you are ready to delegate the DNS domain for the forest root.

Note: The delegation that occurs in this step references the first forest root domain controller, which does not currently exist. The DNS service is installed and configured on the first forest root domain controllers in a subsequent step.

To update the DNS delegation records for the additional domain controller in your environment

Create a name server (NS) resource record in the parent_domain zone file (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).

forest_root_domain IN NS computer_name . forest_root_domain . parent_domain

(where forest\_root\_domain is the name of the forest root domain, computer\_name is the computer name of the additional domain controller, and parent\_domain is the fully qualified domain name of the forest root domain's parent domain).

Create a host address (A) resource record in the parent_domain zone file (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).

computer_name . forest_root_domain . parent_domain IN A ip_address

(where *computer\_name* is the computer name of the additional domain controller, *forest\_root\_domain* is the name of the forest root domain, *parent\_domain* is the fully qualified domain name of the forest root domain's parent domain, and *ip\_address* is the IP address of the additional domain controller).

Contoso example: Updating the DNS delegation records for the additional domain controller

Update the DNS delegation records for the additional forest root domain controller in the Contoso example by using the process described above and the information provided in Table 8.

Table 8 Information for Updating DNS Delegation in the Contoso Example

When Prompted For	In Contoso use	In Trey Research use
parent_domain	contoso.com	treyresearch.net
forest_root_domain	concorp.contoso.com	trccorp.treyresearch.net
computer_name	SEA-CON-DC-01	REN-TRC-DC-01
ip_address	172.16.16.21	172.16.20.13

Creating the Forest Root

After you delegate the DNS domain for the forest root on the existing DNS servers, you are ready to start the production deployment of Active Directory. The first step in the production deployment of Active Directory is the creation of each forest root. Figure 8 illustrates when creating the forest root occurs in your deployment process.

Figure 8: Creating the forest root in the deployment process

The forest owner is responsible for deploying the forest root domain. The forest owner notifies the domain owners of the regional domains when the deployment of the forest root domain is complete.

To create the forest root:

Deploy the first domain controller.
Deploy an additional domain controller in the same site.
Configure site topology.
Configure operations master roles.
Deploy additional domain controllers in other sites.

Deploying the First Forest Root Domain Controller

After you delegate the DNS zone for the forest root on the existing DNS servers, you are ready to deploy the first forest root domain controller.

To deploy the first forest root domain controller:

Install Windows 2000.
Install Active Directory.
Verify the Active Directory installation.
Configure DNS server recursive name resolution.
Delegate the _msdcs zone.

After completing the deployment of the first forest root domain controller, you are ready to deploy additional forest root domain controllers.

Install Windows 2000

The first step in deploying the first forest root domain controller is to install Windows 2000 on the computer that you want to make the domain controller.

Note: You can automate the installation of Windows 2000 by using Sysprep.exe, unattended installation, or any disk imaging method.

To install Windows 2000 on the first forest root domain controller in your environment

Install Windows 2000 on the first domain controller in the primary site of your forest root domain by using the information listed in Table 9.

Table 9 Information for Installing Windows 2000 on the First Domain Controller in the Forest Root

When Prompted For	Use
Format partitions	NTFS
Computer name	*computer_name* (where computer_name is the computer name of the first forest root domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the first forest root domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the first forest root domain controller).
Administrator password	*strong_password* (where strong_password is any strong password).
Networking components	DNS Internet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of another existing WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of an existing DNS server or leave blank if there is no existing DNS infrastructure).

Contoso example: Installing Windows 2000 on the first forest root domain controller

Install Windows 2000 on the first forest root domain controller for Contoso by using the process described above and the information provided in Table 12.

Table 10 Information for Installing Windows 2000 in the Contoso Example

When Prompted For	In Contoso use	In Trey Research use
computer_name	SEA-CON-DC-01	REN-TRC-DC-01
ip_address	172.16.16.21	172.16.20.13
subnet_mask	255.255.252.0	255.255.252.0
strong_password	Y7#Es-3t	OJ2-1Yz8
primary_wins_server	172.16.12.15	172.16.48.15
preferred_dns_server	172.16.4.10	172.16.4.10

Install Active Directory

Install Active Directory on the computer that you want to make the first forest root domain controller by running the Active Directory Installation Wizard (Dcpromo.exe).

The Active Directory Installation Wizard:

Creates the Active Directory database.
Initializes the directory data in the database.
Creates an Active Directory–integrated zone for the forest root domain.

Note: When your organization has no existing DNS infrastructure, the Active Directory Installation Wizard automatically creates an internal root zone (expressed as "."). The new root zone acts as the authoritative root for your organization.

You can run the Active Directory Installation Wizard in an unattended scripted mode to automate the installation of Active Directory.

To install Active Directory on the first forest root domain controller in your environment

From a command prompt, type nslookup parent _ domain (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).
Install Active Directory on the first forest root domain controller by running the Active Directory Installation Wizard and by using the information provided in Table 11 to complete the wizard. Accept default settings when no information is specified.

Table 11 Information for Installing Active Directory on the Domain Controller

Wizard Page	Action
Domain Controller Type	Click Domain controller for new domain.
Create Tree or Child Domain	Verify that Create a new domain tree is selected.
Create of Join Forest	Verify that Create a new forest of domain trees is selected.
New Domain Name	In the Full DNS name for new domain box, type *forest_root_domain* (where forest_root_domain is the fully qualified domain name of the forest root domain)
Configure DNS	Click Yes, install and configure DNS on this computer.
Permissions	Click Permissions compatible only with Windows 2000 servers.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type *strong_password* (where strong_password is any strong password)

Note: When prompted by a message box indicating that the wizard cannot contact the DNS server that handles the domain, click OK. The Active Directory installation process will install and configure DNS as a part of the process.

Contoso example: Installing Active Directory on the first forest root domain controller

Install Active Directory on the first forest root domain controller in the Contoso example by using the process described above and the information provided in Table 12.

Table 12 Information for Installing Active Directory in the Contoso Example

When Prompted For	In Contoso use	In Trey Research use
parent_domain	contoso.com	treyresearch.net
forest_root_domain	concorp.contoso.com	trccorp.treyresearch.net
strong_password	Y7#Es-3t	OJ2-1Yz8

Verify the Active Directory Installation

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To verify the Active Directory installation on the first forest root domain controller in your environment

Review the Windows 2000 event log for any errors.
From a command prompt, run Dcdiag.exe and review any errors that are reported.
Run Task Manager to examine that the processor and memory system resources are within acceptable limits.

Contoso example: Verifying the Active Directory installation on the first forest root domain controller

Verify the Active Directory on the first forest root domain controller in the Contoso example by using the process described above on:

SEA-CON-DC-01.concorp.contoso.com
SEA-TRC-DC-01.trccorp.treyresearch.net

Configure DNS Server Recursive Name Resolution

Configure DNS server recursive name resolution based on the recursive name resolution method specified in the DNS design worksheet provided by your design team. Configure DNS server recursive name resolution by using the DNS snap-in of Microsoft Management Console (MMC) or Dnscmd.exe.

Note: While running the Active Directory Installation Wizard, if your organization has an existing DNS infrastructure, ensure that the Preferred DNS server setting is properly configured. When the Active Directory Installation Wizard finds no existing DNS infrastructure, the wizard automatically creates a new root zone. Subsequently, delete the new root zone, and manually configure a recursive name resolution method.

To configure DNS server recursive name resolution on the first forest root domain controller in your environment

Use the DNS snap-in to configure DNS server recursive name resolution based on the information in Table 13.

Table 13 Information to Configure DNS server Recursive Name Resolution

Method	Configuration
Recursive name resolution by root hints	No additional configuration is necessary. When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured. To verify the root hints by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the name of the domain controller), and then click Properties. In the *computer_name* Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.
Recursive name resolution by forwarding	Forward unresolved queries to *dns_server, (where dns_server* is the DNS server or nearest replica, from which the forest root domain is delegated). See the DNS worksheet provided by your design team for the DNS server. To configure forwarding by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the computer name of the domain controller), and then click Properties. In the *domain_controller* Properties dialog box (where domain_controller is the name of the domain controller), on the Forwarders page, select the Enable forwarders check box. In the IP address box, type *ip_address* (where ip_address is the IP address of the DNS server or nearest replica, from which the forest root domain is delegated), click Add, and then click OK
No existing DNS infrastructure	No additional configuration is necessary. When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

Recursive name resolution by root hints

No additional configuration is necessary.

When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured.

To verify the root hints by using the DNS snap-in:

In the console tree, right-click computer_name (where computer_name is the name of the domain controller), and then click Properties.

In the computer_name Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.

Recursive name resolution by forwarding

Forward unresolved queries to dns_server, (where dns_server is the DNS server or nearest replica, from which the forest root domain is delegated).

See the DNS worksheet provided by your design team for the DNS server.

To configure forwarding by using the DNS snap-in:

In the console tree, right-click computer_name (where computer_name is the computer name of the domain controller), and then click Properties.

In the domain_controller Properties dialog box (where domain_controller is the name of the domain controller), on the Forwarders page, select the Enable forwarders check box.

In the IP address box, type ip_address (where ip_address is the IP address of the DNS server or nearest replica, from which the forest root domain is delegated), click Add, and then click OK

No existing DNS infrastructure

No additional configuration is necessary.

When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

From a command prompt, type nslookup parent_domain (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).
From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).
From a command prompt, type nslookup computer_name . forest_root_domain (where computer_name is the computer name of the first forest root domain controller and forest_root_domain is the fully qualified domain name of the forest root domain).

Successful completion of the nslookup command verifies that the DNS forwarding is properly configured.

Contoso example: Configuring DNS server recursive name resolution on the first forest root domain controller

The existing DNS servers in Contoso perform DNS recursive name resolution by using DNS forwarding. Configure DNS server recursive name resolution on the first forest root domain controller in the Contoso example by using the process described above and the information provided in Table 14.

Table 14 Information for Configuring DNS server Recursive Name Resolution in the Contoso Example

When Prompted For	In Contoso use	In Trey Research use
computer_name	SEA-CON-DC-01	REN-TRC-DC-01
dns_server	172.16.4.10	172.16.4.10
parent_domain	contoso.com	treyresearch.net
forest_root_domain	concorp.contoso.com	trccorp.treyresearch.net

Delegate _msdcs Zone

After you configuring the DNS settings on the forest root domain controllers, you are ready to delegate the _msdcs zone. Delegate the _msdcs zone by using the DNS snap-in in the Microsoft Management Console (MMC) or Dnscmd.exe.

Deployment Best Practice

Replicate the _msdcs zone to the DNS servers running on every domain controller in the forest. The _msdcs zone contains the forest-wide locator records. The forest-wide locator records are used by domain controllers to find replication partners and by clients to find global catalog servers.

To delegate the _msdcs zone for the forest root domain in your environment

Start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, delete the _msdcs folder beneath the forest_root_domain zone (where forest_root_domain is the name of the forest root domain).
In the console tree, right-click the forest_root_domain zone (where forest_root_domain is the name of the forest root domain), and then click New Delegation.

Complete the New Delegation Wizard by using the information supplied in Table 15. Accept the default settings when no information is supplied.

Table 15 Information for Delegating a DNS Domain

Wizard Page	Action
Delegated Domain Name	In the Delegated Domain box, type _msdcs
Name Servers	Click Add. In the New Resource Record dialog box, in the Server name box, type *first_domain_controller.forest_root_domain (where forest_root_domain* is the name of the forest root domain and first_domain_controller is the name of the first forest root domain controller). In the New Resource Record dialog box, in the IP address box, type *first_ip_address* (where first_ip_address is the corresponding IP address of the first forest root domain controller), click Add, and then click OK.

Delegated Domain Name

In the Delegated Domain box, type _msdcs

Name Servers

Click Add.

In the New Resource Record dialog box, in the Server name box, type first_domain_controller.forest_root_domain (where forest_root_domain is the name of the forest root domain and first_domain_controller is the name of the first forest root domain controller).

In the New Resource Record dialog box, in the IP address box, type first_ip_address (where first_ip_address is the corresponding IP address of the first forest root domain controller), click Add, and then click OK.

In the console tree, right-click first_domain_controller (where first_domain_controller is the name of the first forest root domain controller), and then click New Zone.

Complete the New Zone Wizard by using the information supplied in Table 29. Accept the default settings when no information is supplied.

Table 29 Information for Creating _msdcs Zone

Wizard Page	Action
Zone Type	Click Active Directory-integrated.
Forward or Reverse Lookup Zone	Click Forward lookup zone.
Zone Name	In the Name box, type _msdcs.forest_root_domain (where forest_root_domain is the name of the forest root domain)

In the console tree, right-click the _msdcs. forest_root_domain zone (where forest_root_domain is the name of the forest root domain), and then click Properties.
In the _msdcs. forest_root_domain Properties dialog box (where forest_root_domain is the name of the forest root domain), on the General page, click Aging.
In the Zone Aging/Scavenging Properties dialog box, select the Scavenge stale resource records check box, and then click OK.
In the _msdcs. forest_root_domain Properties dialog box (where forest_root_domain is the name of the forest root domain), on the Zone Transfers page, select the Allow zone transfers check box.
In the _msdcs. forest_root_domain Properties dialog box (where forest_root_domain is the name of the forest root domain), click OK.
Restart the Netlogon service by using the Computer Management console.

Restarting the Netlogon service forces the domain controller to register in the _msdcs.forest_root_domain zone (where forest_root_domain is the name of the forest root domain).

Contoso example: Delegating the _msdcs zone for the forest root domain

Delegate the _msdcs zone for the first forest root domain controller in the Contoso example by using the process described above and the information provided in Table 16.

Table 16 Information for Delegating the _msdcs Zone in the Contoso Example

When Prompted For	In Contoso use	In Trey Research use
forest_root_domain	concorp.contoso.com	trccorp.treyresearch.net
first_domain_controller	SEA-CON-DC-01	REN-TRC-DC-01
first_ip_address	172.16.16.21	172.16.20.13

Deploying an Additional Domain Controller in the Same Site

After you deploy the first forest root domain controller, deploy an additional forest root domain controller in the same site in the event the first forest root domain controller fails.

To deploy an additional forest root domain controller in the same site:

Install Windows 2000.
Install Active Directory.
Verify the Active Directory installation.
Configure DNS server recursive name resolution.
Modify the DNS client settings on the first domain controller.
Update the DNS delegation.

Install Windows 2000

The first step in deploying and additional root domain controller in the same site is to install Windows 2000 on the computer that you want to make the domain controller.

Note: You can automate the installation of Windows 2000 by using Sysprep.exe, unattended installation, or any disk imaging method.

To install Windows 2000 on the additional domain controller in your environment

Install Windows 2000 on the additional domain controller in the primary site of your forest root domain by using the information listed in Table 17.

Table 17 Information for Installing Windows 2000 on the Additional Domain Controller in the Forest Root

When Prompted For	Use
Format partitions	NTFS
Computer name	*computer_name* (where computer_name is the computer name of the additional forest root domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the additional forest root domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the additional forest root domain controller).
Administrator password	*strong_password* (where strong_password is any strong password).
Networking components	DNS Internet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of another existing WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of the first forest root domain controller).
Alternate DNS server	*alternate_dns_server* (where alternate_dns_server is the IP address of this domain controller).

Note: Ensure that you configure the first forest root domain controller as the Preferred DNS server and the additional domain controller as the Alternate DNS server. For another forest root domain controller to receive its DNS registration, forest root domain controllers must point the Preferred DNS server setting to another forest root domain controller. Configuring DNS in this manner, you avoid the "Island of Isolation" problem. For more information about this topic, see Active Directory Branch Office Planning Guide at https://www.microsoft.com/technet/archive/windows2000serv/technologies/activedirectory/deploy/adguide/adplan/default.mspx - section10.

Contoso example: Installing Windows 2000 on the additional forest root domain controller

Install Windows 2000 on the additional forest root domain controller in the primary site for Contoso by using the process described above and the information provided in Table 18.

Table 18 Information for Installing Windows 2000 in the Contoso Example

When Prompted For	In Contoso use	In Trey Research use
computer_name	SEA-CON-DC-02	REN-TRC-DC-02
ip_address	172.16.16.22	172.16.20.14
subnet_mask	255.255.252.0	255.255.252.0
strong_password	Y7#Es-3t	OJ2-1Yz8
primary_wins_server	172.16.12.15	172.16.48.15
preferred_dns_server	172.16.16.21	172.16.20.13
alternate_dns_server	172.16.16.22	172.16.20.14

Install Active Directory

Install Active Directory on the computer that you want to make the additional forest root domain controller by running the Active Directory Installation Wizard (Dcpromo.exe).

The Active Directory Installation Wizard:

Creates the Active Directory database.
Initializes the directory data in the database.
Creates an Active Directory–integrated zone for the forest root domain.

To install Active Directory on the additional forest root domain controller in your environment

Install Active Directory on the additional domain controller in the primary site by running the Active Directory Installation Wizard and by using the information provided in Table 19 to complete the wizard. Accept default settings when no information is specified.

Table 19 Information for Installing Active Directory on the Additional Domain Controller

Wizard Page	Action
Domain Controller Type	Click Additional domain controller for an existing domain.
Network Credentials	In the User name box, type *user_name* (where user_name is the name of an account that is a member of the enterprise admins global group. In the Password box, type *password* (where password is the password of the user name). In the Domain box, type *forest_root_domain* (where forest_root_domain is the fully qualified domain name of the forest root domain).
Additional Domain Controller	Click Browse. In the Browse for Domain dialog box, click *forst_root_domain* (where forest_root_domain is the fully qualified domain name of the forest root domain), and then click OK.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type *strong_password* (where strong_password is any strong password)

Contoso example: Installing Active Directory on the additional domain controller

Install Active Directory on the additional forest root domain controller in the primary site for the Contoso example by using the process described above and the information provided in Table 20.

Table 20 Information for Installing Active Directory in the Contoso Example

When Prompted For	In Contoso use	In Trey Research use
parent_domain	contoso.com	treyresearch.net
forest_root_domain	concorp.contoso.com	trccorp.treyresearch.net
first_forest_domain_controller	SEA-CON-DC-01	REN-TRC-DC-01
user_name	Administrator	Administrator
password	U9#7Kp-	Rw36-R5
strong_password	Y7#Es-3t	OJ2-1Yz8

Verify the Active Directory Installation

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To verify the Active Directory installation on the additional forest root domain controller in your environment

Review the Windows 2000 event log for any errors.
From a command prompt, run Dcdiag.exe and review any errors that are reported.
Run Task Manager to examine that the processor and memory system resources are within acceptable limits.

Contoso example: Verifying the Active Directory installation on the additional forest root domain controller

Verify the Active Directory on the additional forest root domain controller in the Contoso example by using the process described above on:

SEA-CON-DC-02.concorp.contoso.com
SEA-TRC-DC-02.trccorp.treyresearch.net

Configure DNS Server Recursive Name Resolution

To configure DNS server recursive name resolution on the additional forest root domain controller in your environment

Use the DNS snap-in to configure DNS server recursive name resolution based on the information in Table 21.

Table 21 Information to Configure DNS server Recursive Name Resolution

Method	Configuration
Recursive name resolution by root hints	No additional configuration is necessary. When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured. To verify the root hints by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the name of the domain controller), and then click Properties. In the *computer_name* Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.
Recursive name resolution by forwarding	Forward unresolved queries to *ip_address, (where ip_address* is IP address of the DNS server, or nearest replica, from which the forest root domain is delegated). See the DNS worksheet provided by your design team for the DNS server. To configure forwarding by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the computer name of the domain controller), and then click Properties. In the *computer_name* Properties dialog box (where computer_name is the computer name of the domain controller), on the Forwarders page, select the Enable forwarders check box. In the IP address box, type *ip_address* (where ip_address is the IP address of the DNS server or nearest replica, from which the forest root domain is delegated), click Add, and then click OK
No existing DNS infrastructure	No additional configuration is necessary. When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

Contoso example: Configuring DNS server recursive name resolution on the additional forest root domain controller

Table 22 Information for Configuring DNS server Recursive Name Resolution in the Contoso Example

For	In Contoso Use	In Trey Research Use
computer_name	SEA-CON-DC-02	REN-TRC-DC-02
ip_address	172.16.4.10	172.16.4.10

Modifying the DNS Client Settings Of The First Domain Controller

After you configure DNS server recursive name resolution, you are ready to modify the DNS client settings on the first forest root domain controller. Since no other domain controllers were running when you deployed the first forest root domain controller, modify the DNS client settings on the first forest root domain controller to include the additional domain controller.

Deployment Best Practice

When a forest root domain controller is configured to use the DNS server on the domain controller as the Preferred DNS server, the domain controller can become isolated from other forest root domain controllers. The domain controller can become isolated from other domain controllers because the domain controller registers only with the DNS server on the domain controller.

To prevent forest root domain controllers from becoming isolated from the other forest root domain controllers, configure the Preferred DNS server setting to point to another forest root domain controller and the Alternate DNS server setting to the DNS server running locally on the domain controller.

The domain controller isolation problem, also known as the "Island of Isolation," can only occur on forest root domain controllers. For more information about this topic, see Active Directory Branch Office Planning Guide.

To configure the DNS client settings on the first domain controller in your environment

Configure the Preferred DNS server setting to another_domain_controller (where another_domain_controller is the IP address of another forest root domain controller).
Configure the Alternate DNS server setting to first_domain_controller (where first_domain_controller is the IP address of the first forest root domain controller).

Contoso example: Configuring the DNS client settings on the first domain controller

Configure the DNS client settings on the first forest root domain controller in the primary site for the Contoso example by using the process described above and the information provided in Table 23.

Table 23 Information for Configuring DNS Client Settings in the Contoso Example

When Prompted For	In Contoso use	In Trey Research use
another_domain_controller	172.16.16.22	172.16.20.14
first_domain_controller	172.16.16.21	172.16.20.13

Updating the DNS Delegation

After you modify the DNS Client settings on the first forest root domain controller in the primary site, you are ready to update the DNS delegation for the forest root domain.

To update the DNS delegation records for the additional domain controller in your environment

Create a name server (NS) resource record in the parent_domain zone file (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).

forest_root_domain IN NS computer_name .i. parent_domain

(where *forest\_root\_domain* is the name of the forest root domain, *computer\_name* is the computer name of the additional domain controller, and *parent\_domain* is the fully qualified domain name of the forest root domain's parent domain).

Create a host address (A) resource record in the parent_domain zone file (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).

computer_name . forest_root_domain . parent_domain IN A ip_address

(where *computer\_name* is the computer name of the additional domain controller, *forest\_root\_domain* is the name of the forest root domain, *parent\_domain* is the fully qualified domain name of the forest root domain's parent domain, and *ip\_address* is the IP address of the additional domain controller).

Contoso example: Updating the DNS delegation records for the additional domain controller

Update the DNS delegation records for the additional forest root domain controller in the Contoso example by using the process described above and the information provided in Table 24.

Table 24 Information for Updating DNS Delegation in the Contoso Example

When Prompted For	In Contoso use	In Trey Research use
parent_domain	contoso.com	treyresearch.net
forest_root_domain	concorp.contoso.com	trccorp.treyresearch.net
computer_name	SEA-CON-DC-02	REN-TRC-DC-02
ip_address	172.16.16.22	172.16.20.14

Configuring Site Topology

After deploying the additional domain controller in the forest root domains, you are ready to configure the site topology for each forest. The site topology owner configures the sites and site topology.

To configure the site topology:

Delegate Active Directory site topology administration.
Create the Active Directory sites.
Create and assign the subnets in Active Directory.
Create the Active Directory site links.

Delegate Active Directory Site Topology Administration

Configuring the sites and site topology for each forest starts when the forest owner delegates administration of the Active Directory sites and site topology to the site topology owner.

To delegate Active Directory site topology administration in your environment

Create a user named SiteTopologyOwner in the default Users container, in the forest root domain.
Create a global group named SiteAdmins in the default Users container, in the forest root domain.
Assign SiteTopologyOwner to the SiteAdmins global group.
In the Active Directory Sites and Services snap-in, right-click the Sites node, and then click Delegate Control.
Complete the Delegation of Control Wizard by using the information supplied in Table 25. Select the default configuration when no information is supplied.

Table 25 Information for Delegating the Administration of Site Topology

Wizard Page	Action
Users or Groups	Click Add. In the Select Users, Computers, or Groups dialog box, click SiteAdmins, click Add, and then click OK.
Permissions	Select the Full Control check box.

Contoso example: Delegating Active Directory site topology administration

Delegate Active Directory site topology administration by following the deployment process in the previous section for the following Active Directory forests:

concorp.contoso.com
trccorp.treyresearch.net

Create Active Directory Sites

The first step in configuring the sites and site topology for each forest is to create the Active Directory sites. The directory planner, site topology owner, and network group determine the sites to create. Create Active Directory sites by using the Active Directory Sites and Services snap-in.

To create the Active Directory sites in your environment

Review the site topology design worksheet provided by your design team, focusing on the sites section of the worksheet.
Create the sites specified in the site topology worksheet.

Contoso example: Creating the Active Directory sites

Identify the Contoso locations, Trey Research locations, and the primary communication links between locations as shown in Figure 9 and listed in Table 26.

Figure 9: Map Of Contoso locations and communications links

Table 26 Links Between Locations And The Available Data Rate

Location	Linked Location	Link Type	Available Data Rate
Seattle	Boston	ISDN (128.8 Kbps)	No more than 56 Kbps.
	Vancouver	T1 (1.544 megabits per second (Mbps))	No more than 44 Kbps.
	Montreal	ISDN (128.8 Kbps)	No more than 26 Kbps.
	Milan	T1 (1.544 Mbps)	No more than 150 Kbps, but with 450-millisecond latency.
	Renton	DSL (700 Kbps)	No more than 500 Kbps
	Atlanta	T1 (1.544 Mbps)	No more than 60 Kbps
	Hong Kong SAR	T1 (1.544 Mbps)	No more than 200 Kbps, but with 450-millisecond latency.
Milan	Seville	ISDN (128.8 Kbps)	No more than 56 Kbps
Hong Kong SAR	Tokyo	ISDN (128.8 Kbps)	No more than 56 Kbps

Create the sites based on the information in Table 27 and Table 28. The information in Table 27 and Table 28 were summarized from the site topology worksheet.

Table 27 Sites to Create and the Locations in the Contoso Forest

Create This Site	Which Includes This Location
Seattle	Seattle
Boston	Boston
Vancouver	Vancouver
Montreal	Montreal
Milan	Milan
Seville	Seville
HongKong	Hong Kong SAR
Tokyo	Tokyo

Table 28 Sites to Create and the Locations in the Trey Research Forest

Create This Site	Which Includes This Location
Renton	Renton
Atlanta	Atlanta

Create and Assign Active Directory Subnets

The next step in configuring the sites and site topology for each forest is to create the Active Directory subnets and assign them to Active Directory sites. The directory planner, site topology owner, and network group determine the subnets that you create. Create Active Directory subnets by using the Active Directory Sites and Services snap-in.

To create and assign Active Directory subnets in your environment

Review the site topology design worksheet provided by your design team, focusing on the subnets section of the worksheet.
Create the Active Directory subnets specified in the site topology worksheet and assign the Active Directory subnet to the appropriate site.

Contoso example: Creating and assigning Active Directory subnets

Identify the IP subnets that exist within each location based on the information in Table 29 and Table 30. The information in Table 29 and Table 30 were summarized from the site topology worksheet.

Table 29 Locations and IP Subnets Within Each Contoso Location

Location	IP Subnets Within the Location
Seattle	172.16.4.0/22172.16.8.0/22172.16.24.0/22172.16.28.0/22172.16.32.0/22172.16.36.0/22172.16.40.0/22
Boston	172.16.52.0/22172.16.56.0/22
Vancouver	172.16.44.0/22172.16.48.0/22
Montreal	172.16.60.0/22172.16.64.0/22
Milan	172.16.128.0/22172.16.132.0/22172.16.136.0/22
Seville	172.16.160.0/22172.16.164.0/22
Hong Kong SAR	172.16.84.0/22172.16.88.0/22172.16.92.0/22
Tokyo	172.16.76.0/22172.16.78.0/22

Table 30 Locations and IP Subnets Within Each Trey Research Location

Location	IP Subnets Within the Location
Renton	172.16.12.0/22172.16.16.0/22172.16.20.0/22
Atlanta	172.16.116.0/22172.16.120.0/22172.16.124.0/22

Create the Active Directory subnets in the Contoso forest and the Trey Research forest by using the Active Directory Sites and Services snap-in and the information listed in Table 31 and Table 32.

Table 31 Active Directory Subnets and IP Subnets in the Contoso Forest

Site	Active Directory Subnet	Address	Mask
Seattle	172.16.4.0/22	172.16.4.0	255.255.252.0
	172.16.8.0/22	172.16.8.0	255.255.252.0
	172.16.24.0/22	172.16.24.0	255.255.252.0
	172.16.28.0/22	172.16.28.0	255.255.252.0
	172.16.32.0/22	172.16.32.0	255.255.252.0
	172.16.36.0/22	172.16.36.0	255.255.252.0
	172.16.40.0/22	172.16.40.0	255.255.252.0
Boston	172.16.52.0/22	172.16.52.0	255.255.252.0
	172.16.56.0/22	172.16.56.0	255.255.252.0
Vancouver	172.16.44.0/22	172.16.44.0	255.255.252.0
	172.16.48.0/22	172.16.48.0	255.255.252.0
Montreal	172.16.60.0/22	172.16.60.0	255.255.252.0
	172.16.64.0/22	172.16.64.0	255.255.252.0
Milan	172.16.128.0/22	172.16.128.0	255.255.252.0
	172.16.132.0/22	172.16.132.0	255.255.252.0
	172.16.136.0/22	172.16.136.0	255.255.252.0
Seville	172.16.160.0/22	172.16.160.0	255.255.252.0
	172.16.164.0/22	172.16.164.0	255.255.252.0
HongKong	172.16.84.0/22	172.16.84.0	255.255.252.0
	172.16.88.0/22	172.16.88.0	255.255.252.0
	172.16.92.0/22	172.16.92.0	255.255.252.0
Tokyo	172.16.76.0/22	172.16.76.0	255.255.252.0

Table 32 Active Directory Subnets and IP Subnets in the Trey Research Forest

Site	Active Directory Subnet	Address	Mask
Renton	172.16.12.0/22	172.16.12.0	255.255.252.0
	172.16.16.0/22	172.16.16.0	255.255.252.0
	172.16.20.0/22	172.16.20.0	255.255.252.0
Atlanta	172.16.116.0/22	172.16.116.0	255.255.252.0
	172.16.120.0/22	172.16.120.0	255.255.252.0
	172.16.124.0/22	172.16.124.0	255.255.252.0

Create Active Directory Site Links

The next step in configuring the sites and site topology for each forest is to create the Active Directory site links. The directory planner, site topology owner, and network group determine the site links that you create. Create Active Directory site links by using the Active Directory Sites and Services snap-in.

To create Active Directory site links in your environment

Review the site topology design worksheet provided by your design team, focusing on the site link section of the worksheet.
Create the Active Directory site links specified in the site topology worksheet.

Contoso example: Creating Active Directory site links

Identify the Contoso locations, Trey Research locations, and the primary communication links between locations as shown in Figure 10 and listed in Table 33.

Figure 10: Map Of Contoso locations and communications links

Table 33 Links Between Locations And The Available Data Rate

Location	Linked Location	Link Type	Available Data Rate
Seattle	Boston	ISDN (128.8 Kbps)	No more than 56 Kbps.
	Vancouver	T1 (1.544 megabits per second (Mbps))	No more than 44 Kbps.
	Montreal	ISDN (128.8 Kbps)	No more than 26 Kbps.
	Milan	T1 (1.544 Mbps)	No more than 150 Kbps, but with 450-millisecond latency.
	Renton	DSL (700 Kbps)	No more than 500 Kbps
	Atlanta	T1 (1.544 Mbps)	No more than 60 Kbps
	Hong Kong SAR	T1 (1.544 Mbps)	No more than 200 Kbps, but with 450-millisecond latency.
Milan	Seville	ISDN (128.8 Kbps)	No more than 56 Kbps
Hong Kong SAR	Tokyo	ISDN (128.8 Kbps)	No more than 56 Kbps

Create the Active Directory site links in the Contoso forest and the Trey Research forest by using the Active Directory Sites and Services snap-in and the information listed in Table 34 and Table 35.

Table 34 Active Directory Site Links in the Contoso Forest

Link	Site	Site	Cost
SEA-BOS	Seattle	Boston	586
SEA-VAN	Seattle	Vancouver	644
SEA-MON	Seattle	Montreal	798
SEA-MIL	Seattle	Milan	486
SEA-HKG	Seattle	HongKong	486
MIL-SEV	Milan	Seville	586
HKG-TOK	HongKong	Tokyo	586

Table 35 Active Directory Site Links in the Trey Research Forest

Link	Site	Site	Cost
REN-ATL	Renton	Atlanta	567

Configuring Operations Master Roles

After creating the Active Directory site links, you are ready to configure the operations master roles for the domain controllers. By default, the first domain controller in the forest root is assigned all operations master roles. Transfer domain-wide operations master roles to the second domain controller in the forest root.

Deployment Best Practice

In Active Directory, the domain naming master operations master must be a global catalog server. However, the infrastructure master must not be a global catalog. As a result, it is not possible to have all operations master roles on the same domain controller. As a best practice, configure the forest-wide and domain-wide operations master roles for different domain controllers and monitor these domain controllers closely.

To configure the operations master roles for the domain controllers in your environment

Transfer the following domain-wide roles to second_domain_contoller (where second_domain_controller is the name of the second forest root domain controller in the primary site) by using the Active Directory Users and Computers snap-in of Microsoft Management Console (MMC):
- Primary domain controller (PDC) operations master
- Relative ID (RID) pool master
- Infrastructure master

Verify that the forest-wide roles listed in Table 36 are still on first_domain_controller (where first_domain_controller is the name of the first forest root domain controller in the primary site) by using the corresponding verification method.

Table 36 Forest-wide Operations Master Roles and Verification Methods

Operations Master Role	Verification Method
Schema master	Active Directory Schema snap-in of Microsoft Management Console (MMC)
Domain naming master	Active Directory Domains and Trusts snap-in of Microsoft Management Console (MMC)

For more information about verifying operations master roles, see Windows 2000 Server Help.

Contoso example: Configuring the operations master roles for the domain controllers

Configure the operations master roles for the domain controller in the Contoso example by using the process described above and the information provided in Table 37.

Table 37 Information for Configuring Operations Master Roles in the Contoso Example

When Prompted For	In Contoso Use	In Trey Research Use
first_domain_controller	SEA-CON-DC-01	REN-TRC-DC-01
second_domain_controller	SEA-CON-DC-02	REN-TRC-DC-02

Deploying Additional Domain Controllers in Other Sites

After you deploy the additional forest root domain controller in the same site, deploy additional forest root domain controllers in other sites.

To deploy additional forest root domain controllers in other sites:

Install Windows 2000.
Install Active Directory.
Verify the Active Directory installation.
Configure DNS server recursive name resolution.
Update the DNS delegation.

Install Windows 2000

The first step in deploying additional root domain controllers in other sites is to install Windows 2000 on the computers that you want to make the domain controllers.

To install Windows 2000 on the additional domain controllers in your environment

Install Windows 2000 on the additional domain controllers in other sites of your forest root domain by using the process listed in Table 38.

Table 38 Process for Installing Windows 2000 on the Additional Domain Controller in the Forest Root

When Prompted For	Use
Format partitions	NTFS
Computer name	*computer_name* (where computer_name is the computer name of the additional forest root domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the additional forest root domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the additional forest root domain controller).
Administrator password	*strong_password* (where strong_password is any strong password).
Networking components	DNS Internet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of another existing WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of another forest root domain controller that is connected through the minimum number of network segments).
Alternate DNS server	*alternate_dns_server* (where alternate_dns_server is the IP address of this domain controller).

Contoso example: Installing Windows 2000 on the additional domain controllers

Install Windows 2000 on additional forest root domain controllers in other sites for Contoso by using the process described above and the information provided in Table 39.

Table 39 Information for Installing Windows 2000 in the Contoso Example

When Prompted For	In Vancouver Use	In Milan Use	In Hong Kong SAR Use
computer_name	VAN-CON-DC-01	MIL-CON-DC-01	HKG-CON-DC-01
ip_address	172.16.48.14	172.16.132.21	172.16.88.13
subnet_mask	255.255.252.0	255.255.252.0	255.255.252.0
strong_password	Uj76-3R5	U75tGH#2	H6y-#4uK
primary_wins_server	172.16.48.15	172.16.132.15	172.16.88.15
preferred_dns_server	172.16.16.22	172.16.16.22	172.16.16.22
alternate_dns_server	172.16.48.14	172.16.132.21	172.16.88.13

Install Active Directory

Install Active Directory on the computer that you want to make the additional forest root domain controller by running the Active Directory Installation Wizard.

The Active Directory Installation Wizard:

Creates the Active Directory database.
Initializes the directory data in the database.
Creates an Active Directory–integrated zone for the forest root domain.

To install Active Directory on the additional forest root domain controller in your environment

From a command prompt, type nslookup parent_domain (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).
From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).
From a command prompt, type nslookup first_domain_controller . forest_root_domain (where first_domain_controller is the computer name of the first forest root domain controller and forest_root_domain is the fully qualified domain name of the forest root domain).

Successful completion of the nslookup command verifies that the DNS is properly configured.
Install Active Directory on the additional forest root domain controller in the primary site by running the Active Directory Installation Wizard and by using the information provided in Table 40 to complete the wizard. Accept default settings when no information is specified.

Table 40 Information for Installing Active Directory on the Additional Domain Controller

Wizard Page	Action
Domain Controller Type	Click Additional domain controller for an existing domain.
Network Credentials	In the User name box, type *user_name* (where user_name is the name of an account that is a member of the enterprise admins global group. In the Password box, type *password* (where password is the password of the user name). In the Domain box, type *forest_root_domain* (where forest_root_domain is the fully qualified domain name of the forest root domain).
Additional Domain Controller	Click Browse. In the Browse for Domain dialog box, click *forst_root_domain* (where forest_root_domain is the fully qualified domain name of the forest root domain), and then click OK.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type *strong_password* (where strong_password is any strong password)

Contoso example: Installing Active Directory on the additional domain controller

Install Active Directory on the additional forest root domain controller in the primary site for the Contoso example by using the process described above and the information provided in Table 41.

Table 41 Information for Installing Active Directory in the Contoso Example

When Prompted For	In Vancouver Use	In Milan Use	In Hong Kong SAR Use
parent_domain	contoso.com	contoso.com	contoso.com
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
first_forest_domain_controller	VAN-CON-DC-01	MIL-CON-DC-01	HKG-CON-DC-01
user_name	Administrator	Administrator	Administrator
password	U9#yKp-	U9#yKp-	U9#yKp-
strong_password	#32-UpYz	Re-3Y34a	P23#aR-4

Verify the Active Directory Installation

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To verify the Active Directory installation on the additional forest root domain controllers in your environment

Review the Windows 2000 event log for any errors.
From a command prompt, run Dcdiag.exe and review any errors that are reported.
Run Task Manager to examine that the processor and memory system resources are within acceptable limits.

Contoso example: Verifying the Active Directory installation on the additional forest root domain controllers

Verify the Active Directory on the additional forest root domain controller in the Contoso example by using the process described above on:

VAN-CON-DC-01.concorp.contoso.com
MIL-CON-DC-01.concorp.contoso.com
HKG-CON-DC-01.concorp.contoso.com

Configure DNS Server Recursive Name Resolution

To configure DNS server recursive name resolution on the additional forest root domain controllers in your environment

Use the DNS snap-in to configure DNS server recursive name resolution based on the information in Table 42.

Table 42 Information to Configure DNS server Recursive Name Resolution

Recursive name resolution by root hints

No additional configuration is necessary.

When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured.

To verify the root hints by using the DNS snap-in:

In the console tree, right-click computer_name (where computer_name is the name of the domain controller), and then click Properties.

In the computer_name Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.

Recursive name resolution by forwarding

Forward unresolved queries to ip_address, (where ip_address is IP address of the DNS server, or nearest replica, from which the forest root domain is delegated).

See the DNS worksheet provided by your design team for the DNS server.

To configure forwarding by using the DNS snap-in:

In the console tree, right-click computer_name (where computer_name is the computer name of the domain controller), and then click Properties.

In the i Properties dialog box (where computer_name is the computer name of the domain controller), on the Forwarders page, select the Enable forwarders check box.

No existing DNS infrastructure

No additional configuration is necessary.

When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

From a command prompt, type nslookup parent_domain (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).
From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).
From a command prompt, type nslookup computer_name . forest_root_domain (where computer_name is the computer name of the first forest root domain controller and forest_root_domain is the fully qualified domain name of the forest root domain).

Successful completion of the nslookup command verifies that the DNS forwarding is properly configured.

Contoso example: Configuring DNS server recursive name resolution on the additional forest root domain controllers

Table 43 Information for Configuring DNS server Recursive Name Resolution in the Contoso Example

When Prompted For	In Vancouver Use	In Milan Use	In Hong Kong SAR Use
computer_name	VAN-CON-DC-01	MIL-CON-DC-01	HKG-CON-DC-01
ip_address	172.16.4.10	172.16.4.10	172.16.4.10

Updating the DNS Delegation

After you configure DNS server recursive name resolution on the additional forest root domain controllers in other sites, you are ready to update the DNS delegation for the forest root domain.

To update the DNS delegation records for the additional domain controllers in your environment

Create a name server (NS) resource record in the parent_domain zone file (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).

forest_root_domain IN NS computer_name . forest_root_domain . parent_domain

(where *forest\_root\_domain* is the name of the forest root domain, *computer\_name* is the computer name of the additional domain controller, and *parent\_domain* is the fully qualified domain name of the forest root domain's parent domain).

Create a host address (A) resource record in the parent_domain zone file (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).

computer_name . forest_root_domain . parent_domain IN A ip_address

(where *computer\_name* is the computer name of the additional domain controller, *forest\_root\_domain* is the name of the forest root domain, *parent\_domain* is the fully qualified domain name of the forest root domain's parent domain, and *ip\_address* is the IP address of the additional domain controller).

Contoso example: Updating the DNS delegation records for the additional domain controller

Update the DNS delegation records for the additional forest root domain controller in the Contoso example by using the process described above and the information provided in Table 44.

Table 44 Information for Updating DNS Delegation in the Contoso Example

When Prompted For	In Vancouver Use	In Milan Use	In Hong Kong SAR Use
parent_domain	contoso.com	contoso.com	contoso.com
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
computer_name	VAN-CON-DC-01	MIL-CON-DC-01	HKG-CON-DC-01
ip_address	172.16.48.14	172.16.132.21	172.16.88.13

Deploying Regional Domains

After you complete the deployment of the forest root, you are ready to deploy regional Windows 2000 domains. Figure 11 illustrates where the deployment of regional domains occurs in your deployment process.

Figure 11: Deployment of regional domains in the deployment process.

The design team determines the regional domains that must be deployed. As specified by the design team, use the process described in the following sections later in this document:

"Creating a New Regional Domain" to create a new regional domain.
"In-place Upgrading of Account Domain" to perform an in-place upgrade a Windows NT 4.0 account domain to a regional domain.

Deployment Best Practice

You can create multiple regional domains and perform in-place upgrades of multiple Windows NT 4.0 domains simultaneously. You do not need to complete the deployment of one regional domain before proceeding to the next regional domain.

For more information about the Active Directory design process, see Best Practice Active Directory Design for Managing Windows Networks at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx.

Creating a New Regional Domain

When specified by the design team, create a new regional domain. Figure 12 illustrates where creating a new regional domain is in your deployment process.

Figure 12: Deploying a new regional domain in the deployment process.

The forest owner is responsible for the creation of the first regional domain controller. The domain owner is responsible for deploying additional regional domain controllers.

To create a new regional domain:

Delegate the DNS domain for the new regional domain.
Deploy the first domain controller in the new domain.
Deploy an additional domain controller in the primary site of the new domain.
Create trust relationships.
Deploy additional domain controllers in the new domain.

Delegating the DNS Domain for the New Regional Domain

Before you create the new regional domain, delegate the DNS domain for the new Windows 2000 regional domain:

In the forest root domain DNS zone.
On any forest root domain controller.

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To delegate the DNS domain for the new regional domain in your environment

On forest_root_domain_controller (where forest_root_domain_controller is any domain controller in the forest root domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, right-click the forest_root_domain zone (where forest_root_domain is the name of the forest root domain), and then click New Delegation.
Complete the New Delegation Wizard by using the information supplied in Table 45. Accept the default settings when no information is supplied.

Table 45 Information for Delegating a Regional Domain

Wizard Page	Action
Delegated Domain Name	In the Delegated Domain box, type *regional_domain_name* (where regional_domain_name is the name of the regional domain).
Name Servers	Click Add. In the New Resource Record dialog box, in the Server name box, type *first_domain_controller* (where first_domain_controller is the name of a domain controller in the regional domain). In the New Resource Record dialog box, in the IP address box, type *first_ip_address* (where first_ip_address is the corresponding IP address of the domain controller in the regional domain), click Add, and then click OK. Click Add. In the New Resource Record dialog box, in the Server name box, type *second_domain_controller* (where second_domain_controller is the name of another domain controller in the regional domain). In the New Resource Record dialog box, in the IP address box, type *ip_address* (where ip_address is the corresponding IP address of the other domain controller in the regional domain), click Add, and then click OK.

Delegated Domain Name

In the Delegated Domain box, type regional_domain_name (where regional_domain_name is the name of the regional domain).

Name Servers

Click Add.
In the New Resource Record dialog box, in the Server name box, type first_domain_controller (where first_domain_controller is the name of a domain controller in the regional domain).
In the New Resource Record dialog box, in the IP address box, type first_ip_address (where first_ip_address is the corresponding IP address of the domain controller in the regional domain), click Add, and then click OK.
Click Add.
In the New Resource Record dialog box, in the Server name box, type second_domain_controller (where second_domain_controller is the name of another domain controller in the regional domain).
In the New Resource Record dialog box, in the IP address box, type ip_address (where ip_address is the corresponding IP address of the other domain controller in the regional domain), click Add, and then click OK.

Contoso example: Delegating the DNS domain for the new regional domain

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process, because the design did not include the creation of new regional domains. In the Contoso example, all regional domains are created by in-place upgrading a Windows NT 4.0 account domain.

Deploying the First Domain Controller in a New Regional Domain

After you delegate the DNS zone for the regional domain, you are ready to deploy the first regional domain controller.

To deploy the first regional domain controller:

Install Windows 2000.
Install Active Directory.
Verify the Active Directory installation.
Configure DNS server recursive name resolution.
Configure a secondary copy of the forest root domain _msdcs zone.
Configure the regional domain to native mode.

Deployment Best Practice

Leave all domain-wide operations servers on the first domain controller. Ensure that the first domain controller is never a global catalog server.

Install Windows 2000

The first step in deploying the first regional domain controller is to install Windows 2000 on the computer that you want to make the domain controller.

Note: You can automate the installation of Windows 2000 by using Sysprep.exe, unattended installation, or any disk imaging method.

To install Windows 2000 on the first regional domain controller in your environment

Install Windows 2000 on the first domain controller in the primary site of your regional domain by using the information listed in Table 46.

Table 46 Information for Installing Windows 2000 on the First Domain Controller in the Regional Domain

When Prompted For	Use
Format partitions	NTFS
Computer name	*computer_name* (where computer_name is the computer name of the first forest root domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the first forest root domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the first forest root domain controller).
Administrator password	*strong_password* (where strong_password is any strong password).
Networking components	DNS Internet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of the existing secondary WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of this domain controller).
Alternate DNS server	*alternate_dns_server* (where alternate_dns_server is the IP address of another DNS server that is connected through a minimum number of network segments).

Contoso example: Installing Windows 2000 on the first regional domain controller

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Install Active Directory

Install Active Directory on the computer that you want to make the first regional domain controller by running the Active Directory Installation Wizard.

To install Active Directory on the first regional domain controller in your environment

Install Active Directory on the domain_controller (where domain_controller is the name of the regional domain controller) by running the Active Directory Installation Wizard and by using the information provided in Table 47 to complete the wizard. Accept default settings when no information is specified.

Table 47 Information for Installing Active Directory on the Domain Controller

Wizard Page	Action
Domain Controller Type	Click Domain controller for new domain.
Create Tree or Child Domain	Click Create a new child domain in an existing domain tree.
Network Credentials	In the User name box, type *user_name* (where user_name is the name of a user account that is a member of enterprise admins). In the Password box, type *password* (where password is the password of the user account). In the Domain box, type *forest_root_domain* (where forest_root_domain is the name of the forest root domain).
Child Domain Installation	Click Browse. In the Browse for Domain dialog box, click *forest_root_domain* (where forest_root_domain is the name of the forest root domain), and then click OK. In the Child domain box, type *regional_domain.forest_root_domain* (where regional_domain is the name of the new regional domain and forest_root_domain is the name of the forest root domain).
Configure DNS	Click Yes, install and configure DNS on this computer.
Permissions	Click Permissions compatible with pre-Windows 2000 servers.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type *strong_password* (where strong_password is any strong password)

Contoso example: Installing Active Directory on the first regional domain controller

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Verify the Active Directory Installation

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To verify the Active Directory installation on the first regional domain controller in your environment

Review the Windows 2000 event log for any errors.
From a command prompt, run Dcdiag.exe and review any errors that are reported.
Run Task Manager to examine that the processor and memory system resources are within acceptable limits.

Contoso example: Verifying the Active Directory installation on the first regional domain controller

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Configure DNS Server Recursive Name Resolution

To configure DNS server recursive name resolution on the first regional domain controller in your environment

Use the DNS snap-in to configure DNS server recursive name resolution based on the information in Table 48.

Table 48 Information to Configure DNS server Recursive Name Resolution

Recursive name resolution by root hints

No additional configuration is necessary.

When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured.

To verify the root hints by using the DNS snap-in:

In the console tree, right-click computer_name (where computer_name is the name of the domain controller), and then click Properties.

In the computer_name Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.

Recursive name resolution by forwarding

Forward unresolved queries to dns_server, (where dns_server is the DNS server or nearest replica, from which the forest root domain is delegated).

See the DNS worksheet provided by your design team for the DNS server.

To configure forwarding by using the DNS snap-in:

In the console tree, right-click computer_name (where computer_name is the computer name of the domain controller), and then click Properties.

In the domain_controller Properties dialog box (where domain_controller is the name of the domain controller), on the Forwarders page, select the Enable forwarders check box.

No existing DNS infrastructure

No additional configuration is necessary.

When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

From a command prompt, type nslookup parent_domain (where parent_domain is the fully qualified domain name of the forest root domain's parent domain).
From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).
From a command prompt, type nslookup computer_name . forest_root_domain (where computer_name is the computer name of the first forest root domain controller and forest_root_domain is the fully qualified domain name of the forest root domain).

Successful completion of the nslookup command verifies that the DNS forwarding is properly configured.

Contoso example: Configuring DNS server recursive name resolution on the first regional domain controller

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Configuring a Secondary Copy of the Forest Root _msdcs Zone

After you configuring the DNS settings on the first regional domain controller, you are ready to configure a secondary copy of the _msdcs zone in forest root domain. Configure the secondary copy of the _msdcs zone by using the DNS snap-in in the Microsoft Management Console (MMC) or Dnscmd.exe.

To configure a secondary copy of the forest root _msdcs zone in your environment

On domain_controller (where domain_controller is the domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.
Complete the New Zone Wizard by using the information supplied in Table 49. Accept the default settings when no information is supplied.

Table 49 Information for Creating Secondary Copy of the Forest Root _msdcs Zone

Wizard Page	Action
Zone Type	Click Standard secondary.
Zone Name	In the Name box, type _msdcs.forest_root_domain (where forest_root_domain is the name of the forest root domain).
Master DNS servers	In the IP address box, type *first_ip_address* (where first_ip_address is the IP address of a forest root domain controller), and then click Add. In the IP address box, type *second_ip_address* (where second_ip_address is the IP address of another forest root domain controller), and then click Add.

To Contoso example: Configuring a secondary copy of the forest root _msdcs zone

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Configuring Regional Domain to Run in Native Mode

After you configuring a secondary copy for the forest root _msdcs zone, you are ready to configure the regional domain controller to run in native mode. Configure the regional domain controller to run in native mode by using the Active Directory Users and Computers snap-in.

To configure the regional domain controller to run in native mode in your environment

On domain_controller (where domain_controller is the domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the Active Directory Users and Computers snap-in.
In the console tree, right-click regional_domain (where regional_domain is the domain controller in the regional domain), and then click Properties.
In the regional_domain Properties dialog box (where regional_domain is the domain controller in the regional domain), on the General page, click Change Mode.

A message box appears prompting you to confirm changing the domain to run in native mode.
Click Yes.
In the regional_domain Properties dialog box (where regional_domain is the domain controller in the regional domain), click OK.

Contoso example: Configuring the regional domain controller to run in native mode

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Deploying an Additional Domain Controller in the Primary Site

After you deploy the first domain controller in the new regional domain, you are ready to deploy an additional domain controller in the primary site of the new regional domain.

To install an additional domain controller in the primary site:

Install Windows 2000.
Install Active Directory.
Verify the Active Directory installation.
Configure DNS server recursive name resolution.
Modify the DNS delegation for the regional domain.
Configure a secondary copy of the forest root domain _msdcs zone.

Install Windows 2000

The first step in deploying the additional regional domain controller in the primary site is to install Windows 2000 on the computer that you want to make the domain controller.

Note: You can automate the installation of Windows 2000 by using Sysprep.exe, unattended installation, or any disk imaging method.

To install Windows 2000 on the additional regional domain controller in the primary site in your environment

Install Windows 2000 on the additional regional domain controller in the primary site of your regional domain by using the information listed in Table 50.

Table 50 Information for Installing Windows 2000 on the Additional Domain Controller in the Regional Domain

When Prompted For	Use
Format partitions	NTFS
Computer name	*computer_name* (where computer_name is the computer name of the regional domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the regional domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the regional domain controller).
Administrator password	*strong_password* (where strong_password is any strong password).
Networking components	DNS Internet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of the existing secondary WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of this domain controller).
Alternate DNS server	alternate_dns_server (where alternate_dns_server is the IP address of another DNS server that is connected through a minimum number of network segments).

Contoso example: Installing Windows 2000 on the additional regional domain controller in the primary site

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Install Active Directory

Install Active Directory on the computer that you want to make the additional regional domain controller in the same site by running the Active Directory Installation Wizard.

To install Active Directory on the additional regional domain controller in the same site in your environment

Install Active Directory on the additional domain controller in the primary site by running the Active Directory Installation Wizard and by using the information provided in Table 51 to complete the wizard. Accept default settings when no information is specified.

Table 51 Information for Installing Active Directory on the Additional Domain Controller

Wizard Page	Action
Domain Controller Type	Click Additional domain controller for an existing domain.
Network Credentials	In the User name box, type *user_name* (where user_name is the name of an account that is a member of the domain admins global group. In the Password box, type *password* (where password is the password of the user name). In the Domain box, type *regional_domain* (where regional_domain is the fully qualified domain name of the regional domain).
Additional Domain Controller	Click Browse. In the Browse for Domain dialog box, click *regional_domain* (where regional_domain is the fully qualified domain name of the regional domain), and then click OK.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type i (where strong_password is any strong password)

Contoso example: Installing Active Directory on the first forest root domain controller

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Verify the Active Directory Installation

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To verify the Active Directory installation on the additional regional domain controllers in your environment

Review the Windows 2000 event log for any errors.
From a command prompt, run Dcdiag.exe and review any errors that are reported.
Run Task Manager to examine that the processor and memory system resources are within acceptable limits.

Contoso example: Verifying the Active Directory installation on the additional regional domain controllers

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Configure DNS Server Recursive Name Resolution

To configure DNS server recursive name resolution on the additional regional domain controller in your environment

Use the DNS snap-in to configure DNS server recursive name resolution based on the information in Table 52.

Table 52 Information to Configure DNS server Recursive Name Resolution

Method	Configuration
Recursive name resolution by root hints	No additional configuration is necessary. When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured. To verify the root hints by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the name of the domain controller), and then click Properties. In the *computer_name* Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.
Recursive name resolution by forwarding	Forward unresolved queries to *dns_server, (where dns_server* is the DNS server or nearest replica, from which the forest root domain is delegated). See the DNS worksheet provided by your design team for the DNS server. To configure forwarding by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the computer name of the domain controller), and then click Properties. In the *computer_name* Properties dialog box (where computer_name is the computer name of the domain controller), on the Forwarders page, select the Enable forwarders check box. In the IP address box, type *ip_address* (where ip_address is the IP address of the DNS server or nearest replica, from which the forest root domain is delegated), click Add, and then click OK.
No existing DNS infrastructure	No additional configuration is necessary. When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

Contoso example: Configuring DNS server recursive name resolution on the additional domain controller

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Modifying the DNS Delegation for the Regional Domain

After you configure DNS server recursive name resolution on the additional regional domain controller, you are ready to update the DNS delegation of the regional domain to include the additional domain controller.

Make the modifications to the delegation entries on any forest root domain controller. Modify the DNS delegation of the regional domain by using the DNS snap-in in the Microsoft Management Console (MMC) or Dnscmd.exe.

To modify the DNS delegation for the regional domain in your environment

On domain_controller (where domain_controller is any domain controller in the forest root domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, navigate to regional_domain (where regional_domain is the name of the regional domain).
In the console tree, right-click regional_domain (where regional_domain is the name of the regional domain), and then click Properties.
In the i Properties dialog box (where regional_domain is the name of the regional domain), on the Name Servers page, click Add.
In the New Resource Record dialog box, in the Server name box, type i (where regional_dc is the fully qualified name of the regional domain controller, where regional_domain is the name of the regional domain, and forest_root_domain is the name of the forest root domain).
In the New Resource Record dialog box, in the IP address box, type ip_address (where ip_address is the IP address of the regional domain controller), click Add, and then click OK.

Contoso example: Modify the DNS delegation for the regional domain

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Configuring a Secondary Copy of the Forest Root _msdcs Zone

After you modify the DNS delegation for the new regional domain controller, you are ready to configure a secondary copy of the _msdcs zone in forest root domain. Configure the secondary copy of the _msdcs zone by using the DNS snap-in in the Microsoft Management Console (MMC) or Dnscmd.exe.

To configure a secondary copy of the forest root _msdcs zone in your environment

On domain_controller (where domain_controller is the domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.
Complete the New Zone Wizard by using the information supplied in Table 53. Accept the default settings when no information is supplied.

Table 53 Information for Creating Secondary Copy of the Forest Root _msdcs Zone

Wizard Page	Action
Zone Type	Click Standard secondary.
Zone Name	In the Name box, type _msdcs.forest_root_domain (where forest_root_domain is the name of the forest root domain)
Master DNS servers	In the IP address box, type *first_ip_address* (where first_ip_address is the IP address of a forest root domain controller), and then click Add. In the IP address box, type *second_ip_address* (where second_ip_address is the IP address of another forest root domain controller), and then click Add.

Contoso example: Configuring a secondary copy of the forest root _msdcs zone

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Create Trust Relationships

When you are migrating accounts and resources from Windows NT 4.0 domains, create:

Two one-way trusts between the Windows NT 4.0 account domains and the Windows 2000 regional domains. Create a one-way trust relationship from the:
- Account domain to the regional domain to allow Active Directory Migration Tool (ADMT) to migrate users from the account domain.
- Regional domain to the account domain to allow users in the regional domains to access resources in the account domains.
A one-way trust from the Windows NT 4.0 resource domains to the Windows 2000 regional domains so that users in the regional domains can access resources in the resource domains.

Create the trust relationships between the Windows NT 4.0 domains and target Windows 2000 domains by using the Active Directory Domains and Trusts snap-in of Microsoft Management Console (MMC) and Server Manager.

To create trust relationships in your environment

On winnt_domain_controller (where winnt_domain_controller is any domain controller in the Windows NT 4.0 domain), start User Manager for Domains.

Create the trust relationships for the Windows NT 4.0 domain based on the process described in Table 54.

Table 54 Establishing the Trust Relationships In the Windows NT 4.0 Domains

Account

In the Trusted Domains and Trusting Domains boxes, add regional_domain (where regional_domain is the name of the regional domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Resource

In the Trusted Domains box, add regional_domain (where regional_domain is the name of the regional domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

On win2k_domain_controller (where win2k_domain_controller is any domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the Active Directory Domains and Trusts snap-in.

Create the trust relationships for the Windows NT 4.0 domain based on the process described in Table 55. Confirm any message box that appears warning that the trust cannot be validated at this time.

Table 55 Establishing the Trust Relationships In the Windows 2000 Domains

Account

In the Trusted Domains and Trusting Domains boxes, add winnt_domain (where winnt_domain is the name of the Windows NT 4.0 domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Contoso example: Creating trust relationships

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Deploying Additional Domain Controller in Other Sites

After you deploy the regional domain controllers in primary site, you are ready to deploy an additional domain controller in other sites of the new regional domain.

To install additional domain controllers in other sites:

Install Windows 2000.
Install Active Directory.
Verify the Active Directory installation.
Configure DNS server recursive name resolution.
Modify the DNS delegation for the regional domain.
Configure a secondary copy of the forest root domain _msdcs zone.

Install Windows 2000

The first step in deploying the additional regional domain controller in the primary site is to install Windows 2000 on the computer that you want to make the domain controller.

Note: You can automate the installation of Windows 2000 by using Sysprep.exe, unattended installation, or any disk imaging method.

To install Windows 2000 on additional domain controllers in other sites in your environment

Install Windows 2000 on the additional regional domain controller in other sites of your regional domain by using the information listed in Table 56

Table 56 Information for Installing Windows 2000 on the Additional Domain Controller in the Regional Domain

When Prompted For	Use
Format partitions	NTFS
Computer name	*computer_name* (where computer_name is the computer name of the regional domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the regional domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the regional domain controller).
Administrator password	*strong_password* (where strong_password is any strong password).
Networking components	DNS Internet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of another existing WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of this domain controller).
Alternate DNS server	*alternate_dns_server* (where alternate_dns_server is the IP address of another DNS server that is connected through a minimum number of network segments).

Contoso example: Installing Windows 2000 on additional domain controllers in other sites

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Install Active Directory

Install Active Directory on the computer that you want to make the additional regional domain controller in the same site by running the Active Directory Installation Wizard.

To install Active Directory on the additional regional domain controller in the same site in your environment

From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).
From a command prompt, type nslookup regional_domain (where regional_domain is the fully qualified domain name of the regional domain).
From a command prompt, type nslookup first_domain_controller . regional_domain (where first_domain_controller is the computer name of the first regional domain controller and regional_domain is the fully qualified domain name of the regional domain).
Successful completion of the nslookup command verifies that the DNS is properly configured.
Install Active Directory on the additional domain controller in the primary site by running the Active Directory Installation Wizard and by using the information provided in Table 57 to complete the wizard. Accept default settings when no information is specified.

Table 57 Information for Installing Active Directory on the Additional Domain Controller

Wizard Page	Action
Domain Controller Type	Click Additional domain controller for an existing domain.
Network Credentials	In the User name box, type i (where user_name is the name of an account that is a member of the domain admins global group. In the Password box, type *user_password* (where user_password is the password of the user name). In the Domain box, type *regional_domain* (where regional_domain is the fully qualified domain name of the regional domain).
Additional Domain Controller	Click Browse. In the Browse for Domain dialog box, click *regional_domain* (where regional_domain is the fully qualified domain name of the regional domain), and then click OK.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type *restore_mode_password* (where *restore_mode_password* is any strong password)

Contoso example: Installing Active Directory on the additional regional domain controller in the same site

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Verify the Active Directory Installation

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To verify the Active Directory installation on the additional regional domain controllers in your environment

Review the Windows 2000 event log for any errors.
From a command prompt, run Dcdiag.exe and review any errors that are reported.
Run Task Manager to examine that the processor and memory system resources are within acceptable limits.

Contoso example: Verifying the Active Directory installation on the additional regional domain controllers

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Configure DNS Server Recursive Name Resolution

To configure DNS server recursive name resolution on the additional regional domain controller in your environment

Use the DNS snap-in to configure DNS server recursive name resolution based on the information in Table 58.

Table 58 Information to Configure DNS server Recursive Name Resolution

Recursive name resolution by root hints

No additional configuration is necessary.

When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured.

To verify the root hints by using the DNS snap-in:

In the console tree, right-click computer_name (where computer_name is the name of the domain controller), and then click Properties.

In the i Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.

Recursive name resolution by forwarding

Forward unresolved queries to dns_server, (where dns_server is the DNS server or nearest replica, from which the forest root domain is delegated).

See the DNS worksheet provided by your design team for the DNS server.

To configure forwarding by using the DNS snap-in:

In the console tree, right-click computer_name (where computer_name is the computer name of the domain controller), and then click Properties.

In the computer_name Properties dialog box (where computer_name is the computer name of the domain controller), on the Forwarders page, select the Enable forwarders check box.

No existing DNS infrastructure

No additional configuration is necessary.

When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).
From a command prompt, type nslookup regional_domain (where regional_domain is the fully qualified domain name of the regional domain).
From a command prompt, type nslookup computer_name . regional_domain (where computer_name is the computer name of the additional domain controller and regional_domain is the fully qualified domain name of the regional domain).

Successful completion of the nslookup command verifies that the DNS forwarding is properly configured.

Contoso example: Configuring DNS server recursive name resolution on the additional regional domain controller

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Modifying the DNS Delegation for the Regional Domain

To modify the DNS delegation for the regional domain in your environment

On domain_controller (where domain_controller is any domain controller in the forest root domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, navigate to regional_domain (where regional_domain is the name of the regional domain).
In the console tree, right-click regional_domain (where regional_domain is the name of the regional domain), and then click Properties.
In the i Properties dialog box (where regional_domain is the name of the regional domain), on the Name Servers page, click Add.
In the New Resource Record dialog box, in the Server name box, type regional_dc.regional_domain.forest_root_domain (where regional_dc is the fully qualified name of the regional domain controller, where regional_domain is the name of the regional domain, and forest_root_domain is the name of the forest root domain).
In the New Resource Record dialog box, in the IP address box, type i (where ip_address is the IP address of the regional domain controller), click Add, and then click OK.

Contoso example: Modifying the DNS delegation for the regional domain

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

Configuring a Secondary Copy of the Forest Root _msdcs Zone

To configure a secondary copy of the forest root _msdcs zone in your environment

On i (where domain_controller is the domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.
Complete the New Zone Wizard by using the information supplied in Table 59. Accept the default settings when no information is supplied.

Table 59 Information for Creating Secondary Copy of the Forest Root _msdcs Zone

Wizard Page	Action
Zone Type	Click Standard secondary.
Zone Name	In the Name box, type _msdcs
Master DNS servers	In the IP address box, type *first_ip_address* (where first_ip_address is the IP address of a forest root domain controller), and then click Add. In the IP address box, type *second_ip_address* (where second_ip_address is the IP address of another forest root domain controller), and then click Add.

Important: You have finished the process of creating a regional domain. If your existing environment is based on operating systems other than Windows NT 4.0, proceed to "Importing Accounts and Data from Other Sources" later in this document.

Contoso example: Configuring a secondary copy of the forest root _msdcs zone

The Contoso example does not require the creation of any new regional domains, and subsequently does not require this step in the deployment process.

In-Place Upgrading of Account Domain

When specified by the design team, perform an in-place upgrade from a Windows NT 4.0 account domain to a new Windows 2000 regional domain. Figure 13 illustrates when in-place upgrading of the account domain occurs in your deployment process.

Figure 13: In-place upgrading of the account domain in the deployment process

The forest owner is responsible for performing the in-place upgrade of the first regional domain controller. The domain owner is responsible for deploying additional regional domain controllers.

Deploy Windows 2000 and Active Directory into a network based on Windows NT 4.0 network by:

In-place upgrading a Windows NT 4.0 account domain into a Windows 2000 regional domain.

The process for performing an in-place upgrade of a Windows NT 4.0 account domain into a Windows 2000 regional domain is described in this section.
Restructuring any remaining Windows NT 4.0 account domains into the Windows 2000 regional domain from step 1.

The process for restructuring any remaining Windows NT 4.0 account domains into the Windows 2000 regional domain is described in the section titled "Restructuring Account Domains", later in this document.
Restructuring any remaining Windows NT 4.0 regional domains into the Windows 2000 regional domain from step 1.

The process for restructuring any remaining Windows NT 4.0 resource domains into the Windows 2000 regional domain is described in "Restructuring Resource Domains" later in this document.

Note: You can perform the migration of Windows NT 4.0 account and resource domains into Windows 2000 regional domains simultaneously.

To in-place upgrade a Windows NT 4.0 account domain into a new Windows 2000 regional domain:

Delegate the DNS domain for the new regional domain.
Configure Windows NT 4.0 replication of logon scripts and profiles
Deploy the first Windows 2000 domain controller in the domain.
Deploy an additional domain controller in the primary site of the domain.
Configure logon script and profile replication between Windows 2000 and Windows NT 4.0 domain controllers.
Configure the regional domain OU structure for administration.
Create and verify trust relationships.
Deploy domain controllers in other sites.
Complete domain deployment.

Delegating the DNS Domain for the New Regional Domain

Before you perform an in-place upgrade on a Windows NT 4.0 account domain to a new Windows 2000 regional domain, delegate the DNS domain name for the new Windows 2000 regional domain.

To delegate the DNS domain for the new regional domain in your environment

On forest_root_dc (where forest_root_dc is any domain controller in the forest root domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, right-click the forest_root_domain zone (where forest_root_domain is the name of the forest root domain), and then click New Delegation.
Complete the New Delegation Wizard by using the information supplied in Table 60. Accept the default settings when no information is supplied.

Table 60 Information for Delegating a Regional Domain

Delegated Domain Name

In the Delegated Domain box, type regional_domain (where regional_domain is the name of the regional domain).

Name Servers

Click Add.
In the New Resource Record dialog box, in the Server name box, type first_dc.regional_domain.forest_root_domain (where first_dc is the name of a domain controller in the regional domain, regional_domain is the name of the regional domain, and forest_root_domain is the name of the forest root domain).
In the New Resource Record dialog box, in the IP address box, type i (where ip_address is the corresponding IP address of the domain controller in the regional domain), click Add, and then click OK.

Contoso example: Delegating the DNS domain for the new regional domain

Delegate the DNS domain for the new regional domain in the Contoso example by using the information in Table 61 and Table 62.

Table 61 Information to Delegate Regional Domains in the Contoso Forest

When prompted for	For the NOAM Regional Domain	For the EMEA Regional Domain
*forest_root_dc*	SEA-CON-DC-01	MIL-CON-DC-01
*forest_root_domain*	concorp.contoso.com	concorp.contoso.com
*regional_domain*	Noam	emea
*first_dc*	SEA-NOAM-DC-01	MIL-EMEA-DC-01
*ip_address*	172.16.12.16	172.16.132.16

Table 62 Information to Delegate Regional Domains in the Trey Research Forest

When prompted for	For the NOAM Regional Domain
*forest_root_dc*	REN-TRC-DC-01
*forest_root_domain*	trccorp.treyresearch.net
*regional_domain*	Noam
*first_dc*	REN-NOAM-DC-01
*ip_address*	172.16.12.17

Configuring Windows NT 4.0 Replication of Logon Scripts and Profiles

When your existing Windows NT 4.0 network uses LAN Manager file system replication for logon scripts and profiles, the first step in deploying domain controllers in the primary site is to configure the Windows NT 4.0 replication of logon scripts and profiles. If your existing Windows NT 4.0 network uses other methods for the replication of logon scripts and profiles, proceed to the next section titled "Upgrading the Primary Domain Controller."

The first computer to be in-place upgraded in the Windows NT 4.0 account domain is the PDC. The PDC is also typically the export server for all logon script and profile replication. Windows 2000 and Active Directory do not support the LAN Manager file system replication for logon scripts and profiles. Instead, Active Directory replicates the Sysvol folder between all Windows 2000 domain controllers in the same domain.

To eliminate any changes to the LAN Manager file system replication configuration, promote another BDC to be the primary domain controller and keep the original PDC as export server. Ensure that the original PDC is the last Windows NT 4.0 domain controller to be in-place upgraded or decommissioned.

To configure Windows NT 4.0 replication of logon scripts and profiles in your environment

On primary_domain_controller (where primary_domain_controller is the current primary domain controller in the Windows NT 4.0 account domain), start Server Manager.
Promote backup_domain_controller (where backup_domain_controller is the backup domain controller that you selected to be the new PDC) to be the PDC.

Verify Windows NT 4.0 replication is performing correctly.
1. Copying a file into the <system root>\system32\repl\export\scripts folder on primary_domain_controller (where primary_domain_controller is the original primary domain controller that was the original replication export server).
2. Waiting for the file to appear in the <system root>\system32\repl\import\scripts folder on backup_domain_controller (where backup_domain_controller is the backup domain controller that you selected to be the new PDC).

Contoso example: Configuring Windows NT 4.0 replication of logon scripts and profiles

Configure the Windows NT 4.0 replication of logon scripts and profiles by completing the deployment process steps in the previous section and by using the information provided in Table 63.

Table 63 Information for Configuring Windows NT 4.0 Replication Of Logon Scripts and Profiles

When Prompted For	In USA use	In EMEA use	In TREYRESEARCH use
primary_domain_controller	SEA-USA-DC-01	MIL-EMA-DC-01	REN-TRE-DC-01
backup_domain_controller	SEA-USA-DC-02	MIL-EMA-DC-02	REN-TRE-DC-02

Deploying the First Domain Controller in the Primary Site

After you delegate the DNS zone for the regional domain, you are ready to deploy the first regional domain controller.

To deploy the first regional domain controller in the primary site:

Install a new Windows NT 4.0 PDC.
Install Windows 2000.
Install Active Directory.
Verify the Active Directory installation.
Configure DNS server recursive name resolution.
Configure a secondary copy of the forest root domain _msdcs zone.
Configure the regional domain to native mode.

Deployment Best Practice

Leave all domain-wide operations master roles on the first domain controller. Ensure that the first domain controller is never a global catalog server.

Installing a New Windows NT 4.0 PDC

When you cannot upgrade the existing Windows NT 4.0 PDC to Windows 2000, install a new Windows NT 4.0 PDC. If your existing PDC can be upgraded to Windows 2000, proceed to "Installing Windows 2000."

To install a new Windows NT 4.0 PDC in your environment

Install Windows NT 4.0 as a BDC in i (where account_domain is the Windows NT 4.0 account domain) by using the information supplied in Table 64. Accept the default settings when no information is supplied.

Table 64 Information For New Windows NT 4.0 BDC in Regional Domains

When Prompted For	Use
Computer name	*computer_name* (where computer_name is the name of the new domain controller)
Server Type	Select Backup Domain Controller.
IP address	*ip_address* (where ip_address is a fixed IP address from the range of IP addresses on the subnet where you want the domain controller installed).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask assigned to the subnet where you want the domain controller installed).
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of an existing nearby WINS server).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of another existing WINS server).
Administrator Name	*password* (where password is the password of the Administrator account in the Windows NT 4.0 account domain).
Administrator Password	*password* (where password is the password of the Administrator account in the Windows NT 4.0 account domain).
Domain	*account_domain* (where account_domain is the Windows NT 4.0 account domain).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of a this domain controller).
Alternate DNS server	*alternate_dns_server* (where alternate_dns_server is the IP address of another nearby DNS server).
Networking components	Internet Protocol (TCP/IP)

Note: Ensure that you format all partitions to NTFS.

Promote computer_name (where computer_name is the name of the new Windows NT 4.0 domain controller) to be the PDC of by using Server Manager
Verify the promotion occurred successfully by reviewing the Windows NT 4.0 event log.

Contoso example: Installing a new Windows NT 4.0 PDC

Install a new Windows NT 4.0 PDC by completing the deployment process steps in the previous section and by using the information provided in Table 65.

Table 65 Information for Installing a New Windows NT 4.0 PDC

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
computer_name	SEA-NOAM-DC-01	MIL-EMEA-DC-01	REN-NOAM-DC-01
ip_address	172.16.12.16	172.16.132.16	172.16.12.17
subnet_mask	255.255.252.0	255.255.252.0	255.255.252.0
password	B365-RoQ	Pr23#N4h	BbrO-64e
account_domain	USA	EMEA	TREYRESEARCH
primary_wins_server	172.16.12.15	172.16.132.15	172.16.20.15
secondary_wins_server	172.16.132.15	172.16.12.15	172.16.12.15
preferred_dns_server	172.16.12.16	172.16.132.16	172.16.12.17
alternate_dns_server	172.16.16.21	172.16.132.17	172.16.20.13

Install Windows 2000

The first step in deploying the first regional domain controller is to install Windows 2000 on the computer that you want to make the domain controller.

Note: You can automate the installation of Windows 2000 by using Sysprep.exe, unattended installation, or any disk imaging method.

To install Windows 2000 on the first regional domain controller in your environment

Install Windows 2000 on the first domain controller in the primary site of your regional domain by using the information listed in Table 66.

Table 66 Information for Installing Windows 2000 on the First Domain Controller in the Regional Domain

When Prompted For	Use
Convert partitions	NTFS
Computer name	*computer_name* (where computer_name is the computer name of the first regional domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the first regional domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the first regional domain controller).
Networking components	DNS Internet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of the existing secondary WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of this domain controller).
Alternate DNS server	*alternate_dns_server* (where alternate_dns_server is the IP address of another DNS server that is connected through a minimum number of network segments).

Note: At the completion of the Windows 2000 installation process, the computer restarts and automatically starts the Active Directory Migration Wizard. Do not start the Active Directory Migration Wizard until instructed to do so later in this document.

Contoso example: Installing Windows 2000 on the first regional domain controller

Install Windows 2000 on the first regional domain controller by completing the deployment process steps in the previous section and by using the information provided in Table 67.

Table 67 Information for Installing Windows 2000 in the Contoso Example

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
computer_name	SEA-NOAM-DC-01	MIL-EMEA-DC-01	REN-NOAM-DC-01
ip_address	172.16.12.16	172.16.132.16	172.16.12.17
subnet_mask	255.255.252.0	255.255.252.0	255.255.252.0
primary_wins_server	172.16.12.15	172.16.132.15	172.16.20.15
secondary_wins_server	172.16.132.15	172.16.12.15	172.16.12.15
preferred_dns_server	172.16.12.16	172.16.132.16	172.16.12.17
alternate_dns_server	172.16.16.21	172.16.132.17	172.16.20.13

Enabling Windows NT 4.0 Domain Controller Emulation

Enable Windows NT 4.0 domain controller emulation to prevent overwhelming of the new domain controller when the Windows NT 4.0 account domain provides authentication predominantly to:

Computers running Windows 2000 Professional
Member servers running Windows 2000 Server or Windows 2000 Advanced Server

If your domain provides authentication predominantly to computers running operating systems prior to Windows 2000, proceed to "Installing Windows 2000 and Active Directory on the PDC."

Windows NT 4.0 domain controller emulation is only supported on Windows 2000 servers running service pack 2.

Deployment Best Practice

Any computers running Windows 2000 will detect the new Windows 2000 domain controller and only authenticate by using the new domain controller, ignoring any existing Windows NT 4.0 BDCs. By enabling Windows NT 4.0 domain controller emulation, you force the new domain controller to advertise as a Windows NT 4.0 domain controller. The Windows 2000 workstations and member servers will then use all domain controllers for authentication.

To enable Windows NT 4.0 domain controller emulation on the first regional domain controller in your environment

To enable Windows NT 4.0 domain controller emulation:

Configure domain_controller (were domain_controller is the name of the domain controller) to emulate a Windows NT 4.0 domain controller by making the following registry entry:

HKLM/System/CCS/Services/Netlogon/Parameters/NT4Emulator = 0x1 (REG_DWORD)

Leave Windows NT 4.0 emulation enabled on all Windows 2000 domain controllers until enough Windows 2000 domain controllers exist to handle the authentication traffic of the Windows 2000 clients. Then disable the Windows NT 4.0 emulation on all Windows 2000 domain controllers.

Configure win2kp_desktop (were win2kp_desktop is the name of a computer running Windows 2000 Professional) that administers the Windows 2000 domain controller to bypass Windows NT 4.0 emulation by making the following registry entry:

HKLM/System/CCS/Services/Netlogon/Parameters/NeutralizeNT4Emulator = 0x1 (REG_DWORD)

There is no need to configure this registry key value on the Windows 2000 domain controller because the domain controllers always behave as if they are configured with this key.

Contoso example: Enabling Windows NT 4.0 domain controller emulation on the first regional domain controller

Enable Windows NT 4.0 domain controller emulation on the first regional domain controller in the Contoso example by using the process in the previous section and the information listed in Table 68.

Table 68 Information to Enable Windows NT 4.0 Domain Controller Emulation

When prompted for	For the NOAM Regional Domain
*domain_controller*	REN-TRC-DC-01
*win2kp_desktop*	REN-TRE-W2KP-01

Note: Enable Windows NT 4.0 emulation only on domain controllers in Trey Research because only Trey Research has computers running predominantly Windows 2000. All other business units are running other Microsoft operating systems earlier than Windows 2000.

Install Active Directory

Install Active Directory on the computer that you want to make the first regional domain controller by running the Active Directory Installation Wizard. To deploy the first domain controller in a domain supply enterprise administrator credentials during the Active Directory Installation Wizard. You can deploy subsequent domain controllers by using domain administrator credentials.

To install Active Directory on the first regional domain controller in your environment

From a command prompt, type forest_root _ domain (where forest_root_domain is the fully qualified domain name of the forest root domain).
Install Active Directory on the domain_controller (where domain_controller is the name of the regional domain controller) by running the Active Directory Installation Wizard and by using the information provided in Table 69 to complete the wizard. Accept default settings when no information is specified.

Table 69 Information for Installing Active Directory on the Domain Controller

Wizard Page	Action
Domain Controller Type	Click Domain controller for new domain.
Create Tree or Child Domain	Click Create a new child domain in an existing domain tree.
Network Credentials	In the User name box, type *user_name* (where user_name is the name of a user account that is a member of enterprise admins). In the Password box, type *password* (where password is the password of the user account). In the Domain box, type *forest_root_domain* (where forest_root_domain is the name of the forest root domain).
Child Domain Installation	Click Browse. In the Browse for Domain dialog box, click *forest_root_domain* (where forest_root_domain is the name of the forest root domain), and then click OK. In the Child domain box, type *regional_domain.forest_root_domain* (where regional_domain is the name of the new regional domain and forest_root_domain is the name of the forest root domain).
Configure DNS	Click Yes, install and configure DNS on this computer.
Permissions	Click Permissions compatible with pre-Windows 2000 servers.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type *strong_password* (where strong_password is any strong password)

Note: When prompted by a message box that indicates that the wizard cannot contact the DNS server that handles the domain, click OK. The Active Directory installation process will install and configure DNS as a part of the process

Contoso example: Installing Active Directory on the first regional domain controller

Install Active Directory on the first regional domain controller by completing the deployment process steps in the previous section and by using the information provided in Table 70.

Table 70 Information for Installing Active Directory in the Contoso Example

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
forest_root_domain	concorp.contoso.com	concorp.contoso.com	trccorp.treyresearch.net
domain_controller	SEA-NOAM-DC-01	MIL-EMEA-DC-01	REN-NOAM-DC-01
user_name	Administrator	Administrator	Administrator
password	B365-RoQ	Pr23#N4h	BbrO-64e
regional_domain	noam	emea	noam
strong_password	H2Y74e#u	Xy-ZZ-y-	T#23-Rwp2

Verify the Active Directory Installation

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To verify the Active Directory installation on the first regional domain controller in your environment

Review the Windows 2000 event log for any errors.
From a command prompt, run Dcdiag.exe and review any errors that are reported.
Run Task Manager to examine that the processor and memory system resources are within acceptable limits.

Contoso example: Verifying the Active Directory installation on the first regional domain controller

Verify the Active Directory on the first regional domain controller in the Contoso example by using the process described in the previous section on:

SEA-NOAM-DC-01.noam.concorp.contoso.com
MIL-EMEA-DC-01.emea.concorp.contoso.com
REN-NOAM-DC-01.noam.trccorp.treyresearch.net

Configure DNS Server Recursive Name Resolution

To configure DNS server recursive name resolution on the first regional domain controller in your environment

Use the DNS snap-in to configure DNS server recursive name resolution based on the information in Table 71.

Table 71 Information to Configure DNS server Recursive Name Resolution

Recursive name resolution by root hints

No additional configuration is necessary.

When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured.

To verify the root hints by using the DNS snap-in:

In the console tree, right-click i (where computer_name is the name of the domain controller), and then click Properties.

In the computer_name Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.

Recursive name resolution by forwarding

Forward unresolved queries to ip_address, (where ip_address is the IP address of the DNS server or nearest replica, from which the forest root domain is delegated).

See the DNS worksheet provided by your design team for the DNS server.

To configure forwarding by using the DNS snap-in:

In the console tree, right-click computer_name (where computer_name is the computer name of the domain controller), and then click Properties.

In the computer_name Properties dialog box (where computer_name is the computer name of the domain controller), on the Forwarders page, select the Enable forwarders check box.

In the IP address box, type ip_address (where ip_address is the IP address of the DNS server or nearest replica, from which the regional domain is delegated), click Add, and then click OK.

No existing DNS infrastructure

No additional configuration is necessary.

When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

From a command prompt, type nslookup parent_domain (where parent_domain is the fully qualified domain name of the forest root domain).
From a command prompt, type nslookup regional_domain.parent_domain (where regional_domain is the fully qualified domain name of the regional domain).
From a command prompt, type nslookup computer_name.regional_domain.parent_domain (where computer_name is the computer name of the first regional domain controller, regional_domain is the fully qualified domain name of the regional domain, and parent_domain is the fully qualified domain name of the forest root domain).

Successful completion of the nslookup command verifies that the DNS forwarding is properly configured.

Contoso example: Configuring DNS server recursive name resolution on the first regional domain controller

The existing DNS servers in Contoso perform DNS recursive name resolution by using DNS forwarding. Configure DNS server recursive name resolution on the first regional domain controller in the Contoso example by using the process described above and the information provided in Table 72.

Table 72 Information for Configuring DNS server Recursive Name Resolution in the Contoso Example

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
computer_name	SEA-NOAM-DC-01	MIL-EMEA-DC-01	REN-NOAM-DC-01
ip_address	172.16.4.10	172.16.4.10	172.16.4.10
parent_domain	concorp.contoso.com	concorp.contoso.com	trccorp.treyresearch.net
regional_domain	noam	emea	noam

Configuring a Secondary Copy of the Forest Root _msdcs Zone

To configure a secondary copy of the forest root _msdcs zone in your environment

On domain_controller (where domain_controller is the domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.
Complete the New Zone Wizard by using the information supplied in Table 73. Accept the default settings when no information is supplied.

Table 73 Information for Creating Secondary Copy of the Forest Root _msdcs Zone

Wizard Page	Action
Zone Type	Click Standard secondary.
Zone Name	In the Name box, type _msdcs.forest_root_domain (where forest_root_domain is the name of the forest root domain).
Master DNS servers	In the IP address box, type *first_ip_address* (where first_ip_address is the IP address of a forest root domain controller), and then click Add. In the IP address box, type *second_ip_address* (where second_ip_address is the IP address of another forest root domain controller), and then click Add.

Contoso example: Configuring a secondary copy of the forest root _msdcs zone

Configure a secondary copy of the forest root domain _msdcs zone by using the deployment process described in the previous section and the information in Table 74.

Table 74 Information For Configuring Secondary Copy Of The _msdcs For Regional Domain Controllers

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
domain_controller	SEA-NOAM-DC-01	MIL-EMEA-DC-01	REN-NOAM-DC-01
forest_root_domain	concorp.contoso.com	concorp.contoso.com	trccorp.treyresearch.net
first_ip_address	172.16.16.21	172.16.132.17	172.16.20.13
second_ip_address	172.16.16.22	172.16.16.21	172.16.20.14

Deploying an Additional Domain Controller in the Primary Site

After you deploy the first domain controller in the new regional domain, you are ready to deploy an additional domain controller in the primary site of the new regional domain.

To install an additional domain controller in the primary site:

Install Windows 2000.
Install Active Directory.
Verify the Active Directory installation.
Configure DNS server recursive name resolution.
Modify the DNS delegation for the regional domain.
Configure a secondary copy of the forest root domain _msdcs zone.

Install Windows 2000

The first step in deploying the additional regional domain controller in the primary site is to install Windows 2000 on the computer that you want to make the domain controller.

Note: You can automate the installation of Windows 2000 by using Sysprep.exe, unattended installation, or any disk imaging method.

To install Windows 2000 on the additional regional domain controller in the primary site in your environment

Install Windows 2000 on the additional regional domain controller in the primary site of your regional domain by using the information listed in Table 75.

Table 75 Information for Installing Windows 2000 on the Additional Domain Controller in the Regional Domain

When Prompted For	Use
Format partitions	NTFS
Computer name	*computer_name* (where computer_name is the computer name of the regional domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the regional domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the regional domain controller).
Administrator password	*strong_password* (where strong_password is any strong password).
Networking components	DNS Internet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of the existing secondary WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of this domain controller).
Alternate DNS server	*alternate_dns_server* (where alternate_dns_server is the IP address of another DNS server that is connected through a minimum number of network segments).

Contoso example: Installing Windows 2000 on the additional regional domain controller in the primary site

Install Windows 2000 on the additional regional domain controller in the primary site by completing the deployment process steps in the previous section and by using the information provided in Table 76

Table 76 Information for Installing Windows 2000 in the Contoso Example

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
computer_name	SEA-NOAM-DC-02	MIL-EMEA-DC-02	REN-NOAM-DC-02
ip_address	172.16.12.28	172.16.132.18	172.16.12.25
subnet_mask	255.255.252.0	255.255.252.0	255.255.252.0
primary_wins_server	172.16.12.15	172.16.132.15	172.16.20.15
secondary_wins_server	172.16.132.15	172.16.12.15	172.16.12.15
preferred_dns_server	172.16.12.28	172.16.132.18	172.16.12.25
alternate_dns_server	172.16.16.21	172.16.132.17	172.16.20.13

Install Active Directory

Install Active Directory on the computer that you want to make the additional regional domain controller in the same site by running the Active Directory Installation Wizard.

To install Active Directory on the additional regional domain controller in the same site in your environment

Install Active Directory on the additional domain controller in the primary site by running the Active Directory Installation Wizard. Accept default settings when no information is specified.

Table 77 Information for Installing Active Directory in the Contoso Example

Wizard Page	Action
Domain Controller Type	Click Additional domain controller for an existing domain.
Network Credentials	In the User name box, type *user_name* (where user_name is the name of an account that is a member of the domain admins global group. In the Password box, type *password* (where password is the password of the user name). In the Domain box, type *regional_domain.forest_root_domain (where regional_domain* is the fully qualified domain name of the regional domain and forest_root_domain is the fully qualified domain name of the forest root domain).
Additional Domain Controller	Click Browse. In the Browse for Domain dialog box, click *regional_domain.forest_root_domain (where regional_domain* is the fully qualified domain name of the regional domain and forest_root_domain is the fully qualified domain name of the forest root domain), and then click OK.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type *strong_password* (where strong_password is any strong password)

Contoso example: Installing Active Directory on the additional forest root domain controllers

Install Active Directory on the additional regional domain controllers in the primary site by completing the deployment process steps in the previous section and by using the information provided in Table 78.

Table 78 Information for Installing Active Directory in the Contoso Example

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
forest_root_domain	concorp.contoso.com	concorp.contoso.com	trccorp.treyresearch.net
domain_controller	SEA-NOAM-DC-01	MIL-EMEA-DC-01	REN-NOAM-DC-01
user_name	Administrator	Administrator	Administrator
password	B365-RoQ	Pr23#N4h	BbrO-64e
regional_domain	noam	emea	noam
strong_password	H2Y74e#u	Xy-ZZ-y-	T#23-Rwp2

Verify the Active Directory Installation

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To verify the Active Directory installation on the additional regional domain controllers in the primary site in your environment

Review the Windows 2000 event log for any errors.
From a command prompt, run Dcdiag.exe and review any errors that are reported.
Run Task Manager to examine that the processor and memory system resources are within acceptable limits.

Contoso example: Verifying the Active Directory installation on the additional regional domain controllers in the primary site

Verify the Active Directory on the first regional domain controller in the Contoso example by using the process described in the previous section on:

SEA-NOAM-DC-02.noam.concorp.contoso.com
MIL-EMEA-DC-02.emea.concorp.contoso.com
REN-NOAM-DC-02.noam.trccorp.treyresearch.net

Configure DNS Server Recursive Name Resolution

To configure DNS server recursive name resolution on the additional regional domain controller in your environment

Use the DNS snap-in to configure DNS server recursive name resolution based on the information in Table 79.

Table 79 Information to Configure DNS server Recursive Name Resolution

Method	Configuration
Recursive name resolution by root hints	No additional configuration is necessary. When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured. To verify the root hints by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the name of the domain controller), and then click Properties. In the *computer_name* Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.
Recursive name resolution by forwarding	Forward unresolved queries to *ip_address, (where ip_address* is the IP address of the DNS server or nearest replica, from which the forest root domain is delegated). See the DNS worksheet provided by your design team for the DNS server. To configure forwarding by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the computer name of the domain controller), and then click Properties. In the *computer_name* Properties dialog box (where computer_name is the computer name of the domain controller), on the Forwarders page, select the Enable forwarders check box. In the IP address box, type *ip_address* (where ip_address is the IP address of the DNS server or nearest replica, from which the forest root domain is delegated), click Add, and then click OK.
No existing DNS infrastructure	No additional configuration is necessary. When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

Contoso example: Configuring DNS server recursive name resolution on the additional domain controller

The existing DNS servers in Contoso perform DNS recursive name resolution by using DNS forwarding. Configure DNS server recursive name resolution on the additional regional domain controller in the Contoso example by using the process described above and the information provided in Table 80.

Table 80 Information for Configuring DNS server Recursive Name Resolution in the Contoso Example

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
computer_name	SEA-NOAM-DC-02	MIL-EMEA-DC-02	REN-NOAM-DC-02
ip_address	172.16.4.10	172.16.4.10	172.16.4.10
forest_root_domain	concorp.contoso.com	concorp.contoso.com	trccorp.treyresearch.net
regional_domain	noam	emea	noam

Modifying the DNS Delegation for the Regional Domain

To modify the DNS delegation for the regional domain in your environment

On forest_root_dc (where forest_root_dc is any domain controller in the forest root domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, navigate to regional_domain (where regional_domain is the name of the regional domain).
In the console tree, right-click regional_domain (where regional_domain is the name of the regional domain), and then click Properties.
In the regional_domain Properties dialog box (where regional_domain is the name of the regional domain), on the Name Servers page, click Add.
In the New Resource Record dialog box, in the Server name box, type regional_dc.regional_domain.forest_root_domain (where regional_dc is the fully qualified name of the regional domain controller, where regional_domain is the name of the regional domain, and forest_root_domain is the name of the forest root domain).
In the New Resource Record dialog box, in the IP address box, type ip_address (where ip_address is the IP address of the regional domain controller), click Add, and then click OK.

Contoso example: Modifying the DNS delegation for the regional domain

Modify the DNS delegation for the regional domain in the Contoso example by using the process described above and the information provided in Table 81.

Table 81 Information for Modifying DNS Delegation in the Contoso Example

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
forest_root_dc	SEA-CON-DC-01	MIL-CON-DC-01	REN-TRC-DC-01
regional_domain	noam	emea	noam
regional_dc	SEA-NOAM-DC-02	MIL-EMEA-DC-02	REN-NOAM-DC-02
forest_root_domain	concorp.contoso.com	concorp.contoso.com	trccorp.treyresearch.net
ip_address	172.16.16.28	172.16.132.18	172.16.16.25

Configuring a Secondary Copy of the Forest Root _msdcs Zone

To configure a secondary copy of the forest root _msdcs zone in your environment

On domain_controller (where domain_controller is the domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.
Complete the New Zone Wizard by using the information supplied in Table 82. Accept the default settings when no information is supplied.

Table 82 Information for Creating Secondary Copy of the Forest Root _msdcs Zone

Wizard Page	Action
Zone Type	Click Standard secondary.
Zone Name	In the Name box, type _msdcs.forest_root_domain (where forest_root_domain is the name of the forest root domain).
Master DNS servers	In the IP address box, type *first_ip_address* (where first_ip_address is the IP address of a forest root domain controller), and then click Add. In the IP address box, type *second_ip_address* (where second_ip_address is the IP address of another forest root domain controller), and then click Add.

Contoso example: Configuring a secondary copy of the forest root _msdcs zone

Configure a secondary copy of the forest root domain _msdcs zone by using the deployment process described in the previous section and the information in Table 83.

Table 83 Information For Configuring Secondary Copy Of The _msdcs For Regional Domain Controllers

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
domain_controller	SEA-NOAM-DC-02	MIL-EMEA-DC-02	REN-NOAM-DC-02
forest_root_domain	concorp.contoso.com	concorp.contoso.com	trccorp.treyresearch.net
first_ip_address	172.16.16.21	172.16.132.17	172.16.20.13
second_ip_address	172.16.16.22	172.16.16.21	172.16.20.14

Configuring Logon Script and Profile Replication Between Windows 2000 and Windows NT 4.0 Domain Controllers

When your existing Windows NT 4.0 network uses methods other than LAN Manager file system replication for the replication of logon scripts and profiles proceed to the next section titled "Configuring The Regional Domain OU Structure For Administration."

Deployment Best Practice

The process of completing the in-place upgrade is not an immediate process and takes place over a period of time. Before the completion of the in-place upgrade, ensure that the original Windows NT 4.0 domain controllers and new Windows 2000 domain controllers can support the existing domain.

To configure logon script and profile replication between Windows 2000 and Windows NT 4.0 domain controllers in your environment

Create a user account in regional_domain.forest_root_domain (where regional_domain is the name of the regional domain and forest_root_domain is the name of the forest root domain), to be used for replicating logon scripts and profiles, in the new regional domain by using the information in Table 84.

Table 84 Information For Creating User Account Used In Logon Script And Profile Replication

When Prompted For	Use
User name	LbridgeAcct
Description	Account used by lbridge.cmd for logon script and profile replication
Password	*password* (where password is any password that meets the security requirements of your organization).

Ensure the LbridgeAcct has the appropriate permissions to the shares, folders, and files described in Table 85.

Table 85 Information For Assigning Share, Folder, and File Permissions to LbridgeAcct

Ensure That The LbridgeAcct User Can	On This Folder
Read all files and folders	*\\win2k_dc\NETLOGON* (where win2k_dc is the name of the Windows 2000 domain controller in the regional domain).
Read, write, create, and delete files and folders	*\\winnt_dc\REPL$* (where winnt_dc is the name of the Windows 2000 domain controller in the regional domain).

Install the lbridge.cmd and robocopy.exe tools on win2k_dc (where win2k_dc is the Windows 2000 domain controller in the regional domain) in a directory in the path statement.

Note: You can obtain the lbridge.cmd and robocopy.exe tools from the Windows 2000 Server Resource Kit.

Modify the lbridge.cmd script on win2k_dc (where win2k_dc is a Windows 2000 domain controller in the regional domain) using the information in Table 86.

Table 86 Modifications To The lbridge.cmd Script

Change This Line	To
Set L-Destination=%1	Set L-Destination=*\\winnt_dc\REPL$* (where winnt_dc is name of the Windows NT 4.0 domain controller).
Call :Xcopy	@Rem Call :Xcopy
@Rem Call :Robocopy	Call :Robocopy
Echo Robocopy %L-Source% %L-Destination% /E /PURGE	Robocopy %L-Source% %L-Destination% /E /PURGE

Complete the Scheduled Task Wizard on win2k_dc (where win2k_dc is a Windows 2000 domain controller in the regional domain) by using the information in Table 87. Accept the default settings when no information in supplied.

Table 87 Information To Complete Scheduled Task Wizard for lbridge.cmd

Wizard Page	Action
Click the program you want Windows to run.	Click Browse. In the Select Program to Schedule dialog box, click lbridge.cmd
Type a name for this task.	Type FRS - LMRepl Replication Bridge
Perform this task.	Click Daily.
Start time.	Type *start_time* (where start_time is the time that you want the replication to occur).
Enter the user name.	Type LbridgeAcct
Enter the password.	Type *password* (where password is the password that corresponds to the LbridgeAcct account).
Confirm the password.	Type *password* (where password is the password that corresponds to the LbridgeAcct account).
Open advanced properties for this task when I click Finish.	Enable check box.

The FRS - LMRepl Replication Bridge dialog box opens.

In the FRS - LMRepl Replication Bridge dialog box, on the Schedule page, click Advanced.
In the Advanced Schedule Options dialog box, click Repeat task.
In the Advanced Schedule Options dialog box, in the Every box, type frequency (where frequency is how often you want the script to run).
In the Advanced Schedule Options dialog box, in the Duration box, type duration (where duration is how long you want the script to run), and then click OK.
In the FRS - LMRepl Replication Bridge dialog box, on the Schedule page, click OK.

Contoso example: Configuring logon script and profile replication between Windows 2000 and Windows NT 4.0 domain controllers

Configure logon script and profile replication between Windows 2000 and Windows NT 4.0 domain controllers by using the deployment process described in the previous section and the information in Table 88.

Table 88 Information For Configuring Secondary Copy Of The _msdcs For Regional Domain Controllers

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
regional_domain	noam	emea	noam
forest_root_domain	concorp.contoso.com	concorp.contoso.com	trccorp.treyresearch.net
winnt_dc	SEA-USA-DC-01	MIL-EMA-DC-01	REN-TRE-DC-01
win2k_dc	SEA-NOAM-DC-01	MIL-EMEA-DC-01	REN-NOAM-DC-01
Password	Up98-65W	wAl2t-WP	kE-Fby41
start_time	2:00 am	2:00 am	2:00 am
frequency	2 hours	2 hours	2 hours
duration	3 hours	3 hours	3 hours

Configuring The Regional Domain OU Structure For Administration

The final step in deploying domain controllers in the primary site is to configure the regional domain OU structure for administration. The OU structure in the regional domain is based on the OU design created by the design team. Configure the OU structure for administration by using the Active Directory Users and Computers snap-in

To configure the regional domain OU structure for administration in your environment

Create the OU structure, shown in Figure 14, in regional_domain.forest_root_domain (where regional_domain is the name of the regional domain and forest_root_domain is the name of the forest root domain).

Figure 14: Account OU Structure Within Each Regional Domain

Create the following groups in the account_domain\Admins OU (where account_domain is the name of the Windows NT 4.0 account domain):
1. account_domain _ou_admins
2. account_domain _users_admins
3. account_domain _group_admins
4. account_domain _computer_admins
Note: In the groups that you create in this step, remember to substitute account with the name of the Windows NT 4.0 account domain. For example, in the USA Windows NT 4.0 account domain, account _ou_admins would become USA_ou_admins.
Assign the appropriate administrative users to the groups created in step 2.

Delegate the administration of the OU structure to the respective groups by using the information described in Table 89 (where account_domain is the name of the Windows NT 4.0 account domain).

Table 89 Delegation of Administration To OU Administrative Groups

Delegate Administration Of	By Assigning Full Control To	On These Objects
account_domain	account_domain _ou_admins	All
account_domain \Users	account_domain _user_admins	User
account_domain \Service Accounts	account_domain _user_admins	User
account_domain \Groups	account_domain _group_admins	Group
account_domain \Computers	account_domain _computer_admins	Computer

Move all migrated user and group accounts from the Users default container to the appropriate OU.

Ensure that you leave the built-in users and groups in the Users default container.
Move the migrated computer accounts from the Computers default container to the appropriate OU.

Contoso example: Configuring the regional domain OU structure for administration

Configure the regional domain OU structure for administration by using the deployment process described in the previous section and the information in Table 90.

Table 90 Information for Configuring the Regional Domain OU Structure

When Prompted For	In USA Use	In EMA Use	In TREYRESEARCH Use
regional_domain	noam	emea	noam
forest_root_domain	concorp.contoso.com	concorp.contoso.com	trccorp.treyresearch.net
account_domain	USA	EMA	TREYRESEARCH

Creating and Verifying Trust Relationships

When you are migrating accounts and resources from Windows NT 4.0 domains, ensure that:

Two one-way trusts exist between the Windows NT 4.0 account domains and the Windows 2000 regional domains. Verify that a one-way trust relationship exists from the:
- Account domain to the regional domain to allow Active Directory Migration Tool (ADMT) to migrate users from the account domain.
- Regional domain to the account domain to allow users in the regional domains to access resources in the account domains.
A one-way trust exists from the Windows NT 4.0 resource domains to the Windows 2000 regional domains so that users in the regional domains can access resources in the resource domains.

Create and verify the trust relationships between the Windows NT 4.0 domains and target Windows 2000 domains by using the Active Directory Domains and Trusts snap-in of Microsoft Management Console (MMC) and Server Manager.

To create trust relationships that do not already exist in your environment

On winnt_dc (where winnt_dc is any domain controller in the Windows NT 4.0 domain), start User Manager for Domains.

Create the trust relationships for the Windows NT 4.0 domain based on the process described in Table 91.

Table 91 Establishing the Trust Relationships In the Windows NT 4.0 Domains

Account

In the Trusted Domains and Trusting Domains boxes, add win2k_domain (where win2k_domain is the name of the regional domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Resource

In the Trusted Domains box, add win2k_domain (where win2k_domain is the name of the regional domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

On win2k_dc (where win2k_dc is any domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the Active Directory Domains and Trusts snap-in.

Create the trust relationships for the Windows NT 4.0 domain based on the process described in Table 92. Confirm any message box that appears warning that the trust cannot be validated at this time.

Table 92 Establishing the Trust Relationships In the Windows 2000 Domains

Account

In the Trusted Domains and Trusting Domains boxes, add winnt_domain (where winnt_domain is the name of the Windows NT 4.0 account domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Resource

In the Trusting Domains box, add winnt_domain (where winnt_domain is the name of the Windows NT 4.0 account domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Contoso example: Creating trust relationships that do not already exist

Create trust relationships that do not already exist by using the deployment process described in the previous section and the information in Table 93, Table 94, Table 95, and Table 96.

Table 93 Trusts Relationships for the noam.concorp.contoso.com Domain (Part 1)

When Prompted For	For SEATTLE Use	For BOSTON Use
winnt_domain	SEATTLE	BOSTON
Domain type	Resource	Resource
winnt_dc	SEA-SEA-DC-01	BOS-BOS-DC-01
win2k_domain	USA	USA
win2k_dc	SEA-NOAM-DC-01	SEA-NOAM-DC-01
trust_password	N54-WeL8	N54-WeL8

Table 94 Trusts Relationships for the noam.concorp.contoso.com Domain (Part 2)

When Prompted For	For CANADA Use	For VANCOUVER Use	For MONTREAL Use
winnt_domain	CANADA	VANCOUVER	MONTREAL
Domain type	Account	Resource	Resource
winnt_dc	VAN-CAN-DC-01	VAN-VAN-DC-01	MON-MON-DC-01
win2k_domain	USA	USA	USA
win2k_dc	SEA-NOAM-DC-01	SEA-NOAM-DC-01	SEA-NOAM-DC-01
trust_password	N54-WeL8	N54-WeL8	N54-WeL8

Table 95 Trusts Relationships for the emea.concorp.contoso.com Domain (Part 1)

When Prompted For	For MILAN Use	For SEVILLE Use
winnt_domain	MILAN	SEVILLE
Domain type	Resource	Resource
winnt_dc	MIL-MIL-DC-01	SEV-SEV-DC-01
win2k_domain	EMEA	EMEA
win2k_dc	MIL-EMEA-DC-01	MIL-EMEA-DC-01
trust_password	N54-WeL8	N54-WeL8

Table 96 Trusts Relationships for the emea.concorp.contoso.com Domain (Part 2)

When Prompted For	For FABRIKAM Use	For HONGKONG Use	For TOKYO Use
winnt_domain	FABRIKAM	HONGKONG	TOKYO
Domain type	Account	Resource	Resource
winnt_dc	HKG-FAB-DC-01	HKG-HKG-DC-01	TOK-TOK-DC-01
win2k_domain	EMEA	EMEA	EMEA
win2k_dc	MIL-EMEA-DC-01	MIL-EMEA-DC-01	MIL-EMEA-DC-01
trust_password	N54-WeL8	N54-WeL8	N54-WeL8

Note: In the Contoso example, the same trust password was used in establishing all trust relationship. This does not compromise security because the trust password is only valid until the trust is established. After the trust is established, the trust password is discarded.

Deploying Additional Domain Controller in Other Sites

After you deploy the regional domain controllers, you are ready to deploy an additional domain controller in other sites of the new regional domain.

To install an additional domain controller in other sites:

Install Windows 2000.
Install Active Directory.
Verify the Active Directory installation.
Configure DNS server recursive name resolution.
Modify the DNS delegation for the regional domain.
Configure a secondary copy of the forest root domain _msdcs zone.

Install Windows 2000

The first step in deploying the additional regional domain controller in the other sites of the new regional domain is to install Windows 2000 on the computer that you want to make the domain controller.

Note: You can automate the installation of Windows 2000 by using Sysprep.exe, unattended installation, or any disk imaging method.

To install Windows 2000 on additional domain controllers in other sites in your environment

Install Windows 2000 on the additional regional domain controller in other sites of your regional domain by using the information listed in Table 97.

Table 97 Information for Installing Windows 2000 on the Additional Domain Controller in the Regional Domain

When Prompted For	Use
Format partitions	NTFS
Computer name	*computer_name* (where computer_name is the computer name of the regional domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the regional domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the regional domain controller).
Administrator password	*strong_password* (where strong_password is any strong password).
Networking components	DNS Internet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of the existing secondary WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of this domain controller).
Alternate DNS server	*alternate_dns_server* (where alternate_dns_server is the IP address of another DNS server that is connected through a minimum number of network segments).

Contoso example: Installing Windows 2000 on additional domain controllers in other sites

Install Windows 2000 on the additional regional domain controller in the other sites in the new regional domain by completing the deployment process steps in the previous section and by using the information provided in Table 98 and Table 99.

Table 98 Information for Installing Windows 2000 in noam.concorp.contoso.com

When Prompted For	In Boston Use	In Vancouver Use	In Montreal Use
computer_name	BOS-NOAM-DC-01	VAN-NOAM-DC-01	MON-NOMA-DC-01
ip_address	172.16.56.13	172.16.48.36	172.16.20.51
subnet_mask	255.255.252.0	255.255.252.0	255.255.252.0
primary_wins_server	172.16.12.15	172.16.48.15	172.16.48.15
secondary_wins_server	172.16.48.15	172.16.12.15	172.16.12.15
preferred_dns_server	172.16.56.13	172.16.48.36	172.16.20.51
alternate_dns_server	172.16.12.16	172.16.12.16	172.16.48.36

Table 99 Information for Installing Windows 2000 in emea.concorp.contoso.com

When Prompted For	In Seville Use	In Hong Kong SAR Use	In Tokyo Use
computer_name	SEV-EMEA-DC-01	HKG-EMEA-DC-01	TOK-EMEA-DC-01
ip_address	172.16.160.19	172.16.88.32	172.16.78.20
subnet_mask	255.255.252.0	255.255.252.0	255.255.252.0
primary_wins_server	172.16.132.15	172.16.88.15	172.16.88.15
secondary_wins_server	172.16.12.15	172.16.12.15	172.16.88.15
preferred_dns_server	172.16.160.19	172.16.88.32	172.16.78.20
alternate_dns_server	172.16.132.16	172.16.132.16	172.16.88.13

Install Active Directory

Install Active Directory on the computer that you want to make the additional regional domain controller in the other sites by running the Active Directory Installation Wizard.

To install Active Directory on the additional regional domain controller in other sites in your environment

Install Active Directory on the domain_controller (where domain_controller is the name of the additional domain controller) in the other site by running the Active Directory Installation Wizard and by using the information provided in Table 100 to complete the wizard. Accept default settings when no information is specified.

Table 100 Information for Installing Active Directory on the Additional Domain Controller

Wizard Page	Action
Domain Controller Type	Click Additional domain controller for an existing domain.
Network Credentials	In the User name box, type *user_name* (where user_name is the name of an account that is a member of the domain admins global group. In the Password box, type *password* (where password is the password of the user name). In the Domain box, type *regional_domain.forest_root_domain (where regional_domain* is the name of the regional domain and forest_root_domain is the name of the forest root domain).
Additional Domain Controller	Click Browse. In the Browse for Domain dialog box, click *regional_domain.forest_root_domain (where regional_domain* is the name of the regional domain and forest_root_domain is the name of the forest root domain), and then click OK.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type *strong_password* (where strong_password is any strong password)

Contoso example: Installing Active Directory on the additional forest root domain controllers

Install Active Directory on the additional regional domain controllers in the other sites in the new regional domain by completing the deployment process steps in the previous section and by using the information provided in Table 101 and Table 102.

Table 101 Information for Installing Active Directory in noam.concorp.contoso.com

When Prompted For	In Boston Use	In Vancouver Use	In Montreal Use
domain_controller	BOS-NOAM-DC-01	VAN-NOAM-DC-01	MON-NOAM-DC-01
first_dc	SEA-NOAM-DC-01	SEA-NOAM-DC-01	SEA-NOAM-DC-01
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
regional_domain	noam	noam	noam
user_name	Administrator	Administrator	Administrator
Password	B365-RoQ	B365-RoQ	B365-RoQ
strong_password	H2Y74e#u	Xy-ZZ-y-	T#23-Rwp2

Table 102 Information for Installing Active Directory in emea.concorp.contoso.com

When Prompted For	In Seville Use	In Hong Kong SAR Use	In Tokyo Use
domain_controller	SEV-EMEA-DC-01	HKG-EMEA-DC-01	TOK-EMEA-DC-01
first_dc	MIL-EMEA-DC-01	MIL-EMEA-DC-01	MIL-EMEA-DC-01
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
regional_domain	emea	emea	emea
user_name	Administrator	Administrator	Administrator
Password	Pr23#N4h	Pr23#N4h	Pr23#N4h
strong_password	H2Y74e#u	Xy-ZZ-y-	T#23-Rwp2

Verify the Active Directory Installation

After you run the Active Directory Installation Wizard to install Active Directory, verify the Active Directory installation.

To verify the Active Directory installation on the additional regional domain controllers in your environment

Review the Windows 2000 event log for any errors.
From a command prompt, run Dcdiag.exe and review any errors that are reported.
Run Task Manager to examine that the processor and memory system resources are within acceptable limits.

Contoso example: Verifying the Active Directory installation on the additional regional domain controllers

Verify the Active Directory on the additional regional domain controllers in the Contoso example by using the process described in the previous section on:

BOS-NOAM-DC-01.noam.concorp.contoso.com
VAN-NOAM-DC-01.noam.concorp.contoso.com
MON-NOAM-DC-01.noam.concorp.contoso.com
SEV-EMEA-DC-01.emea.concorp.contoso.com
HKG-EMEA-DC-01.emea.concorp.contoso.com
TOK-EMEA-DC-01.emea.concorp.contoso.com

Configure DNS Server Recursive Name Resolution

To configure DNS server recursive name resolution on the additional regional domain controller in your environment

Use the DNS snap-in to configure DNS server recursive name resolution based on the information in Table 103.

Table 103 Information to Configure DNS server Recursive Name Resolution

Method	Configuration
Recursive name resolution by root hints	No additional configuration is necessary. When the DNS server specified as the Preferred DNS server during the installation process is properly configured, the root hints are automatically configured. To verify the root hints by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the name of the domain controller), and then click Properties. In the *computer_name* Properties dialog box (where computer_name is the name of the domain controller), on the Root Hints page, view the root hints.
Recursive name resolution by forwarding	Forward unresolved queries to *dns_server, (where dns_server* is the DNS server or nearest replica, from which the forest root domain is delegated). See the DNS worksheet provided by your design team for the DNS server. To configure forwarding by using the DNS snap-in: In the console tree, right-click *computer_name* (where computer_name is the computer name of the domain controller), and then click Properties. In the *computer_name* Properties dialog box (where computer_name is the computer name of the domain controller), on the Forwarders page, select the Enable forwarders check box. In the IP address box, type *ip_address* (where ip_address is the IP address of the DNS server or nearest replica, from which the forest root domain is delegated), click Add, and then click OK
No existing DNS infrastructure	No additional configuration is necessary. When no DNS infrastructure exists previously, the forest root domain controllers are the root servers for DNS.

Contoso example: Configuring DNS server recursive name resolution on the additional regional domain controller

Table 104 Information for Recursive Name Resolution in noam.concorp.contoso.com

When Prompted For	In Boston Use	In Vancouver Use	In Montreal Use
computer_name	BOS-NOAM-DC-01	VAN-NOAM-DC-01	MON-NOAM-DC-01
ip_address	172.16.4.10	172.16.4.10	172.16.4.10
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
regional_domain	noam	noam	noam

Table 105 Information for Recursive Name Resolution in emea.concorp.contoso.com

When Prompted For	In Seville Use	In Hong Kong SAR Use	In Tokyo Use
computer_name	SEV-EMEA-DC-01	HKG-EMEA-DC-01	TOK-EMEA-DC-01
ip_address	172.16.4.10	172.16.4.10	172.16.4.10
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
regional_domain	emea	emea	emea

Modifying the DNS Delegation for the Regional Domain

To modify the DNS delegation for the regional domain in your environment

On domain_controller (where domain_controller is any domain controller in the forest root domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, navigate to regional_domain (where regional_domain is the name of the regional domain).
In the console tree, right-click regional_domain (where regional_domain is the name of the regional domain), and then click Properties.
In the regional_domain Properties dialog box (where regional_domain is the name of the regional domain), on the Name Servers page, click Add.
In the New Resource Record dialog box, in the Server name box, type regional_dc.regional_domain.forest_root_domain (where regional_dc is the fully qualified name of the regional domain controller, where regional_domain is the name of the regional domain, and forest_root_domain is the name of the forest root domain).
In the New Resource Record dialog box, in the IP address box, type ip_address (where ip_address is the IP address of the regional domain controller), click Add, and then click OK.

Contoso example: Modifying the DNS delegation for the regional domain

Modify the DNS delegation for the regional domain in the Contoso example by using the process described above and the information provided in Table 106 and Table 107.

Table 106 Information for Recursive Name Resolution in noam.concorp.contoso.com

When Prompted For	In Boston Use	In Vancouver Use	In Montreal Use
forest_root_dc	SEA-CON-DC-01	VAN-CON-DC-01	VAN-CON-DC-01
regional_domain	noam	noam	noam
regional_dc	BOS-NOAM-DC-01	VAN-NOAM-DC-01	MON-NOAM-DC-01
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
ip_address	172.16.4.10	172.16.4.10	172.16.4.10

Table 107 Information for Recursive Name Resolution in emea.concorp.contoso.com

When Prompted For	In Seville Use	In Hong Kong SAR Use	In Tokyo Use
forest_root_dc	MIL-CON-DC-01	HKG-CON-DC-01	HKG-CON-DC-01
regional_domain	emea	emea	emea
regional_dc	SEV-EMEA-DC-01	HKG-EMEA-DC-01	TOK-EMEA-DC-01
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
ip_address	172.16.4.10	172.16.4.10	172.16.4.10

Configuring a Secondary Copy of the Forest Root _msdcs Zone

To configure a secondary copy of the forest root _msdcs zone in your environment

On domain_controller (where domain_controller is the domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.
In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.
Complete the New Zone Wizard by using the information supplied in Table 108. Accept the default settings when no information is supplied.

Table 108 Information for Creating Secondary Copy of the Forest Root _msdcs Zone

Wizard Page	Action
Zone Type	Click Standard secondary.
Zone Name	In the Name box, type _msdcs.forest_root_domain (where forest_root_domain is the name of the forest root domain).
Master DNS servers	In the IP address box, type *first_ip_address* (where first_ip_address is the IP address of a forest root domain controller), and then click Add. In the IP address box, type *second_ip_address* (where second_ip_address is the IP address of another forest root domain controller), and then click Add.

Contoso example: Configuring a secondary copy of the forest root _msdcs zone

Configure a secondary copy of the forest root domain _msdcs zone by using the deployment process described in the previous section and the information in Table 109 and Table 110.

Table 109 Information for Secondary Copy Of _msdcs in noam.concorp.contoso.com

When Prompted For	In Boston Use	In Vancouver Use	In Montreal Use
domain_controller	BOS-NOAM-DC-01	VAN-NOAM-DC-01	MON-NOAM-DC-01
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
first_ip_address	172.16.16.21	172.16.48.14	172.16.48.14
second_ip_address	172.16.16.22	172.16.16.21	172.16.16.21

Table 110 Information for Secondary Copy Of _msdcs in emea.concorp.contoso.com

When Prompted For	In Seville Use	In Hong Kong SAR Use	In Tokyo Use
domain_controller	SEV-EMEA-DC-01	HKG-EMEA-DC-01	TOK-EMEA-DC-01
forest_root_domain	concorp.contoso.com	concorp.contoso.com	concorp.contoso.com
first_ip_address	172.16.132.17	172.16.88.13	172.16.88.13
second_ip_address	172.16.16.21	172.16.132.17	172.16.132.17

Completing Domain Deployment

As you are deploying domain controllers in the new Windows 2000 regional domains, complete the domain deployment process by:

Disabling Windows NT 4.0 domain controller emulation on all domain controllers when a sufficient number of domain controllers are running Windows 2000.
Configuring the regional domain to run in native mode when the deployment process is complete.

Disabling Windows NT 4.0 Domain Controller Emulation

Disable Windows NT 4.0 domain controller emulation as early in the deployment process to as possible facilitate Windows 2000 computers using Kerberos V5 authentication. Disable Windows NT 4.0 domain controller emulation when enough Windows 2000 domain controllers exist to support authentication for all workstations and member servers running Windows 2000.

To disable Windows NT 4.0 domain controller emulation on all domain controllers in your environment

Remove the following registry entry on win2kp_desktop (were win2kp_desktop is the name of a computer running Windows 2000 Professional) used to administer domain_controller (where domain_controller is any domain controller with Windows NT 4.0 emulation enabled):

HKLM/System/CCS/Services/Netlogon/Parameters/NeutralizeNT4Emulator

Remove the following registry entry on domain_controller (where domain_controller is any domain controller with Windows NT 4.0 emulation enabled):

HKLM/System/CCS/Services/Netlogon/Parameters/NT4Emulator

Contoso example: Disabling Windows NT 4.0 domain controller emulation on all domain controllers

The regional domain noam.trccorp.treyresearch.net is the only regional domain that required Windows NT 4.0 emulation enabled. Disable Windows NT 4.0 domain controller emulation on all domain controllers by:

Substituting win2kp_desktop in the deployment process in the previous section with REN-TRE-W2KP-01.

Substituting domain_controller in the deployment process in the previous section with each of the following domain controllers:
- REN-NOAM-DC-01.noam.trccorp.treyresearch.net
- REN-NOAM-DC-02.noam.trccorp.treyresearch.net
- ATL-NOAM-DC-01.noam.trccorp.treyresearch.net

Configuring the Regional Domain to Run in Native Mode

After the in-place upgrade of the Windows NT 4.0 account domain is complete, configure the regional domain to run in native mode.

To configure the regional domain to run in native mode in your environment

Start an instance of the Microsoft Management Console (MMC) and include the Active Directory Users and Computers snap-in.
In the console tree, right-click the regional_domain zone (where regional_domain is the name of the regional domain), and then click Properties.
In the regional_domain Properties dialog box (where regional_domain is the name of the regional domain), click Change Mode.
When prompted to confirm the change to native mode, click Yes.
In the regional_domain Properties dialog box (where regional_domain is the name of the regional domain), click OK.

Contoso example: Configuring the regional domain to run in native mode

Configure the regional domains to run in native mode in the Contoso example by substituting regional_domain in the deployment process in the previous section with each of the following regional domains:

noam.concorp.contoso.com
emea.concorp.contoso.com
noam.trccorp.treyresearch.net

Restructuring Account Domains

After creating a Windows 20000 regional domain or performing an in-place upgrade on a Windows NT 4.0 account domain, you can start restructuring other Windows NT 4.0 account domains to Windows 2000 regional domains. Figure 15 illustrates where the task of restructuring the account domains occurs in the deployment process.

Figure 15: Relationship of restructuring the account domains in the deployment process

The regional domain owner is responsible for the migration of the related Windows NT 4.0 account domains into the Windows 2000 domains.

The restructuring account domain process occurs over a period of time. The restructuring account domain process occurs in three phases:

pre-migration phase
migration phase
post-migration phase.

Pre-migration phase

Pre-migration is the first phase in the restructuring process. To complete the pre-migration phase:

Create and verify domain trust relationships.
Install and configure ADMT.
Identify service accounts.
Migrate all global groups.

Migration phase

Migration is the next phase in the restructuring process. To complete the migration phase:

Transition service accounts to Windows 2000 regional domain.
Phased transition of users to the Windows 2000 regional domain in batches.
Re-migrate all global groups.

Post-migration Phase

Post-migration cleanup is the last phase in the restructuring process. To complete the post-migration phase:

Re-migrate all global groups.
Complete account domain restructuring.

During post-migration cleanup, the target domain is updated with changes that might have occurred in the source domain since the start of the migration process, and account management is transferred to the target domain. Keep domain controllers in the source domain running and retire them after all Windows NT 4.0 domains are restructured.

Continue to make all changes to Global Group memberships in the source domain. Make changes to user accounts, such as RAS permissions, to the domain where the account is active. If you plan for fallback, changes on user accounts that have already been migrated must be applied in both the source and target domains.

Note: Even after users have been migrated to the target domain, management of user accounts and groups must be performed in the source domain. During the cut over phase, changes made in the source domain are propagated to the target domain through periodic re-migration operations. The only exception is user passwords, which are not migrated from the source domain to the target domain. Passwords for users who have cut over to the target domain must be managed in the target domain.

Maintaining User Productivity During Account Domain Restructuring

The primary goal in restructuring account domains is to minimize any loss of user productivity during the migration process. Minimize the loss of user productivity during the migration process by:

Establishing a fallback plan.
Restructuring account domains in a non-destructive process.
Preserving user access to resources.

Establishing a Fallback Plan

The first step in preparing for domain restructuring is to establish a fallback plan, in case you decide to discontinue the migration of Windows NT 4.0 domains to Windows 2000 in middle of the migration process.

Establish a fallback plan so that you can continue to use your existing environment in case the domain restructuring does not meet the acceptance criteria. Because the Windows NT 4.0 account domains remain intact, you can return to the existing environment.

To fallback and use the Windows NT 4.0 account domains:

Enable the user accounts in the Windows NT 4.0 account domain (if accounts were disabled during migration).
Notify the users to log off the Windows 2000 domain.
Notify the users to log on to the Windows NT 4.0 account domain with their old passwords.
Verify user access to resources.
Verify the users login script and user profile.

Restructuring Account Domain in a Non-destructive Process

The account domain restructuring process presented in this document is a non-destructive process. The user account in the Windows NT 4.0 domain remains in the Windows NT 4.0 domain and is disabled after the user migration is complete. As a fallback plan, you can enable the user account in the Windows NT 4.0 domain at any time.

Global group accounts are never disabled during the account domain restructuring process.

Preserve User Access to Resources

The account domain restructuring process that is presented in this document preserves user access to existing resources. Access to existing resources was assigned to Windows NT 4.0 users, local groups, and global groups. Each user, local group, and global group was assigned a SID. Access to the existing resources was assigned to the corresponding SID in the list of resource permissions.

The account domain restructuring process retains the Windows NT 4.0 SID in the SIDHistory attribute of the user or global group. When a migrated user accesses a resource, such as a shared folder or a user profile, the Windows 2000 and Windows NT 4.0 SIDs are presented to the resource server.

The resource server compares the resource permissions with the Windows 2000 and Windows NT 4.0 SIDs. Because resource access is granted based on the Windows 2000 SIDs and Windows NT 4.0 SIDs, re-assigning new permissions is not required.

For more information about account domain migration, SIDs, and SIDHistory, see the Domain Migration Cookbook at https://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/cookbook/cookindx.mspx.

Administration and Management During Account Domain Restructuring

Carefully plan for administration and management of the following aspects of Windows NT 4.0 account migration:

User accounts, including the user's SID
Membership in Global Groups
User profiles

User accounts

Because account domain migration is a non-destructive process, user accounts exist in both the Windows NT 4.0 source domain and the Windows 2000 target domain.

The deployment team and the operations team can enable or disable the user accounts in the source domain, target domain, or both. Using migrations tools, accounts can be enabled or disabled during a migration operation.

User migration has the following characteristics:

User migration can preserve group memberships. Users that are members in a Global Group in the source domain can be added to the corresponding Global Group in the target domain.
User and group migration is a repeatable process. If an account has already been migrated, it can be migrated again (using the replace conflicting accounts option in ADMT). The operation merges the existing account and the new account. For example, if a user is migrated and attributes on the new user object in the target domain are set (like a telephone number or office number), and the user is re-migrated using the replace conflicting accounts option in ADMT, the new information is retained. If group memberships had changed in the source domain, the changes are also reflected in the target domain as part of the merge operation.
As part of the migration process, new passwords are created for the users. Users must be notified of the new password. The notification must be integrated in the migration process.

Note that there are third party migration tools that allow migrating user passwords.

Global Groups

Like for user accounts, the original SID for the Global Group can be preserved in the SIDHistory of the target group. This is necessary if the Global Group was referenced on any Access Control List on a resource, or if the Global Group was a member in any local group. Group memberships are based on SIDs, and by migrating the SID to the SIDHistory, the Global Groups membership in any Local Group is preserved automatically.

User Profiles

User profiles are used to store the desktop state of users and user data. There are two different kinds of profiles, roaming profiles and local profiles. To preserve user profiles:

Migrate roaming profiles when you migrate users.
Migrate local profiles in a separate step if the user accounts and workstation accounts are in different domains.

Creating and Verifying Trust Relationships

When you are migrating accounts and resources from Windows NT 4.0 domains, ensure that:

Two one-way trusts exist between the Windows NT 4.0 account domains and the Windows 2000 regional domains. Verify that a one-way trust relationship exists from the:
- Account domain to the regional domain to allow Active Directory Migration Tool (ADMT) to migrate users from the account domain.
- Regional domain to the account domain to allow users in the regional domains to access resources in the account domains.
A one-way trust exists from the Windows NT 4.0 resource domains to the Windows 2000 regional domains so that users in the regional domains can access resources in the resource domains.

To create trust relationships that do not already exist in your environment

On winnt_dc (where winnt_dc is any domain controller in the Windows NT 4.0 domain), start User Manager for Domains.

Create the trust relationships for the Windows NT 4.0 domains based on the process described in Table 111.

Table 111 Establishing the Trust Relationships In the Windows NT 4.0 Domains

Account

In the Trusted Domains and Trusting Domains boxes, add win2k_domain (where win2k_domain is the name of the regional domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Resource

In the Trusted Domains box, add win2k_domain (where win2k_domain is the name of the regional domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

On win2k_dc (where win2k_dc is any domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the Active Directory Domains and Trusts snap-in.

Create the trust relationships between the Windows NT 4.0 domains based on the process described in Table 112. Confirm any message box that appears warning that the trust cannot be validated at this time.

Table 112 Establishing the Trust Relationships In the Windows 2000 Domains

Account

In the Domains trusted by this domain and Domains that trust this domain boxes, add winnt_domain (where winnt_domain is the name of the Windows NT 4.0 account domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Resource

In the Domains that trust this domain box, add winnt_domain (where winnt_domain is the name of the Windows NT 4.0 account domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Contoso example: Creating trust relationships that do not already exist

Create trust relationships that do not already exist by using the deployment process described in the previous section and the information in Table 113, Table 114, Table 115, and Table 116.

Table 113 Trusts Relationships for the noam.concorp.contoso.com Domain (Part 1)

When Prompted For	For SEATTLE Use	For BOSTON Use
winnt_domain	SEATTLE	BOSTON
Domain type	Resource	Resource
winnt_dc	SEA-SEA-DC-01	BOS-BOS-DC-01
win2k_domain	USA	USA
win2k_dc	SEA-NOAM-DC-01	SEA-NOAM-DC-01
trust_password	N54-WeL8	N54-WeL8

Table 114 Trusts Relationships for the noam.concorp.contoso.com Domain (Part 2)

When Prompted For	For CANADA Use	For VANCOUVER Use	For MONTREAL Use
winnt_domain	CANADA	VANCOUVER	MONTREAL
Domain type	Account	Resource	Resource
winnt_dc	VAN-CAN-DC-01	VAN-VAN-DC-01	MON-MON-DC-01
win2k_domain	USA	USA	USA
win2k_dc	SEA-NOAM-DC-01	SEA-NOAM-DC-01	SEA-NOAM-DC-01
trust_password	N54-WeL8	N54-WeL8	N54-WeL8

Table 115 Trusts Relationships for the emea.concorp.contoso.com Domain (Part 1)

When Prompted For	For MILAN Use	For SEVILLE Use
winnt_domain	MILAN	SEVILLE
Domain type	Resource	Resource
winnt_dc	MIL-MIL-DC-01	SEV-SEV-DC-01
win2k_domain	emea	emea
win2k_dc	MIL-EMEA-DC-01	MIL-EMEA-DC-01
trust_password	N54-WeL8	N54-WeL8

Table 116 Trusts Relationships for the emea.concorp.contoso.com Domain (Part 2)

When Prompted For	For FABRIKAM Use	For HONGKONG Use	For TOKYO Use
winnt_domain	FABRIKAM	HONGKONG	TOKYO
Domain type	Account	Resource	Resource
winnt_dc	HKG-FAB-DC-01	HKG-HKG-DC-01	TOK-TOK-DC-01
win2k_domain	emea	Emea	emea
win2k_dc	MIL-EMEA-DC-01	MIL-EMEA-DC-01	MIL-EMEA-DC-01
trust_password	N54-WeL8	N54-WeL8	N54-WeL8

Installing and Configuring ADMT

The first step in restructuring Windows NT 4.0 account domains is to install and configure ADMT. Run ADMT on a domain controller in the Windows 2000 target regional domain.

Note: ADMT requires that Windows NT 4.0 Service Pack 4 (or higher) be installed on the PDC in the source domain.

To install and configure ADMT:

Create an account to be used in user, group, and service account migration.
Create an account to be used in local user profile migration.
Install and run ADMT on a domain controller to initialize ADMT configuration.

Creating an Account Domain Migration Account

The first step in installing and configuring ADMT is to create an account used by ADMT for account domain migration.

To create an account domain migration account in your environment

Create a user account in regional_domain (where regional_domain is the fully qualified name of the regional domain) by using the information in Table 117.

Table 117 Information For Creating User Account Used In ADMT Migrations

When Prompted For	Use
User name	ADMTMigrationAcct
Description	Account used by ADMT for account domain migration
Password	*password* (where password is any password that meets the security requirements of your organization).

The migration of the Windows NT 4.0 account domains into the Windows 2000 regional domains is accomplished by using the ADMTMigrationAcct.

Add ADMTMigrationAcct to the Domain Admins group in regional_domain (where regional_domain is the name of the target regional domain).
To update SIDHistory in a migrated account, ADMTMigrationAcct must be a member of the Domain Admins group in the target domain.
Add ADMTMigrationAcct to the Administrators group in account_domain (where account_domain is the name of the source account domain).

Contoso example: Creating an account domain migration account

Create an account domain migration account by using the deployment process described in the previous section and the information in Table 118.

Table 118 Information for Creating an Account Domain Migration Account

When Prompted For	For CANADA Use	For FABRIKAM Use
account_domain	CANADA	FABRIKAM
regional_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	N78#87-k	Ct34-N#2

Creating an Local User Profile Migration Account

The next step in installing and configuring ADMT is to create an account used by ADMT for local user profile migration.

To create an account for local user profile migration in your environment

Create a user account in regional_domain (where regional_domain is the fully qualified name of the regional domain) by using the information in Table 119.

Table 119 Information For Creating User Account Used In ADMT Migrations

When Prompted For	Use
User name	ADMTLProfileAcct
Description	Account used by ADMT for local user profile migration
Password	*password* (where password is any password that meets the security requirements of your organization).

Add ADMTLProfileAcct to the Administrators group in regional_domain (where regional_domain is the name of the target regional domain).
Add ADMTLProfileAcct to the Domain Admins group in account_domain (where account_domain is the name of the source account domain).

To migrate local profiles on workstations requires administrator rights on the workstations. The Domain Admins global group belongs to the Administrators local group on all domain controllers, member servers, and workstations in a domain.

Contoso example: Creating an account for local user profile migration

Create a local user profile migration account by using the deployment process described in the previous section and the information in Table 120.

Table 120 Information for Creating a Local User Profile Migration Account

When Prompted For	For CANADA Use	For FABRIKAM Use
account_domain	CANADA	FABRIKAM
regional_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2

Initializing ADMT Configuration

The last step in installing and configuring ADMT is to initialize the ADMT configuration.

To initialize ADMT configuration in your environment

On win2k_dc.regional_domain (where win2k_dc is the computer name of a domain controller and regional_domain is the fully qualified name of the target regional domain), log on as ADMTMigrationAcct with a password of password (where password is the password of ADMTMigrationAcct).
On win2k_dc.regional_domain (where win2k_dc is the computer name of a domain controller and regional_domain is the fully qualified name of the target regional domain), install ADMT.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select Group Account Migration Wizard.

When prompted by the Group Account Migration Wizard, use the information provided in Table 121 to complete the wizard. Accept default settings when no information is specified.

Table 121 Migrating global groups by using the Group Account Migration Wizard in ADMT

Wizard Page	Action
Test or Make Changes	Select Test the migration settings and migrate later?
Domain Selection	In the Source domain box, type *source_domain* (where source_domain is the domain name of the Windows NT 4.0 account domain). In the Target domain box, type *target_domain. (where target_domain* is the fully qualified domain name of the Windows 2000 regional domain).
Group Selection	Click Add. In the Select Groups dialog box, select all groups (except built-in groups), click Add, and then click OK.
Organizational Unit Selection	Click Browse. In the Browse for Container dialog box, navigate Users, and then click OK.
Group Options	Select the Migrate Group SIDs to target domain check box. Click Do not rename accounts.
User Account	In the User name box, type ADMTMigrationAcct In the Password box, type password (where password is the password for ADMTMigrationAcct) In the Domain box, type *target_domain. (where target_domain* is the fully qualified domain name of the Windows 2000 regional domain).
Naming Conflicts	Click Ignore naming conflict accounts and don't migrate.

The Migration Progress dialog box appears.

In the Migration Progress dialog box, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.

Verify the test migration of group accounts by ensuring that the following occurred.
- A new local group account_domain$$$ (where account_domain is the name of the Windows NT 4.0 account domain) is created on the source domain for ADMT internal auditing purposes.
- The following registry entry is created on the source domain PDC:

HKLM\System\CCS\Control\Lsa\TcpipClientSupport:REG_DWORD = 0x01

  - The audit policy for account management is enabled in ***regional\_domain*** (*regional\_domain* is the fully qualified name of the target regional domain).

Contoso example: Initializing ADMT configuration

Initialize ADMT configuration by using the deployment process described in the previous section and the information in Table 122.

Table 122 Information for Initializing ADMT Configuration

When Prompted For	For CANADA Use	For FABRIKAM Use
account_domain	CANADA	FABRIKAM
regional_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2

Identifying Service Accounts

The next step in restructuring account domains is to identify the member servers and domain controllers that run applications, as services, by using a service account. A service account is a user account created explicitly to provide a security context for these applications. The service account is a standard user account that is granted the Log on as a service user right.

Note: After this step in the restructuring account domain process, identify any new service accounts that are configured on servers. Migrate the new service accounts later in the process, prior to completing the Windows NT 4.0 account domain restructuring.

To identify the service accounts in your environment

Manually create a list of servers that have applications that run as services by using service accounts.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select Service Account Migration Wizard.

When prompted by the Service Account Migration Wizard, use the information provided in Table 123 to complete the wizard. Accept default settings when no information is specified.

Table 123 Identify Service Accounts by Using the Service Account Migration Wizard

Wizard Page	Action
Domain Selection	In the Source domain box, type *source_domain* ((where source_domain is the name of the source domain). In the Target domain box, type *target_domain* ((where target_domain is the name of the target domain).
Update Information	Click Yes, update the information.
Service Account Selection	Click Add. In the Select Computers list box, select *server_names* (where server_names is the list of all servers that run applications by using service accounts), click Add, and then click OK.
User Account	In the User name box, type ADMTMigrationAcct In the Password box, type *password* (where password is the password for ADMTMigrationAcct) In the Domain box, type *target_domain* ((where target_domain is the name of the target domain).

The Active Directory Migration Tool Agent Monitor dialog box appears.

In the Active Directory Migration Tool Agent Monitor dialog box, on the Summary page, wait until all computers have finished or failed.
In the Active Directory Migration Tool Agent Monitor dialog box, on the Server List page, click View Dispatch Log.

Notepad opens and displays the contents of the dispatch log. Review the dispatch log for any errors.
Retain the list of servers that run applications by using service accounts. The list of servers is required to complete the next step in the domain restructuring process.

Note: This process does not migrate the accounts but only identifies them for later migration.

Contoso example: Identifying the service accounts

Identify the service accounts by using the deployment process described in the previous section and the information in Table 124.

Table 124 Information for Identifying the Service Accounts in the Contoso Example

When Prompted For	For CANADA Use	For FABRIKAM Use
source_domain	CANADA	FABRIKAM
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2
server_names	VAN-VAN-FP-01	MIL-MIL-FP-01

Migrating All Global Groups

After you complete identification of service accounts, you are ready to migrate all global groups in the Windows NT 4.0 account domain.

Note: Migrate global groups off hours because global group migration is resource intensive. Global group migration consumes system resource on the domain controller running ADMT and the network

To migrate all global groups from the Windows NT 4.0 account domain to the appropriate Windows 2000 regional domain:

Configure the regional domain organizational unit (OU) structure.
Migrate all global groups and users by using ADMT.
Verify that all global groups are migrated.

Configuring The Regional Domain OU Structure

The next step in restructuring account domains is to configure the regional domain OU structure. The OU structure in the regional domain is based on the OU design created by the design team. Configure the OU structure for administration by using the Active Directory Users and Computers snap-in

To configure the regional domain OU structure for administration in your environment

Create the OU structure, shown in Figure 16, in regional_domain.forest_root_domain (where regional_domain is the name of the regional domain and forest_root_domain is the name of the forest root domain).

Figure 16: Account OU Structure Within Each Regional Domain

Create the following groups in the account_domain\Admins OU (where account_domain is the name of the Windows NT 4.0 account domain):
1. account_domain _ou_admins
2. account_domain _users_admins
3. account_domain _group_admins
4. account_domain _computer_admins
Note: In the groups that you create in this step, remember to substitute account_domain with the name of the Windows NT 4.0 account domain. For example, in the USA Windows NT 4.0 account domain account_domain _ou_admins would become USA_ou_admins.
Assign the appropriate administrative users to the groups created in step 2.
Delegate the administration of the OU structure to the respective groups by using the information described in Table 125 (where account_domain is the name of the Windows NT 4.0 account domain).

Table 125 Delegation of Administration To OU Administrative Groups

Delegate Administration Of	By Assigning Full Control To	On These Objects
account_domain	account_domain _ou_admins	All
account_domain \Users	account_domain _user_admins	User
account_domain \Service Accounts	account_domain _user_admins	User
account_domain \Groups	account_domain _group_admins	Group
account_domain \Computers	account_domain _computer_admins	Computer

Contoso example: Configuring the regional domain OU structure for administration

Configure the regional domain OU structure for administration by using the deployment process described in the previous section and the information in Table 126.

Table 126 Information for Configuring the Regional Domain OU Structure

For	In CANADA Use	In FABRIKAM Use
regional_domain	noam	Emea
forest_root_domain	concorp.contoso.com	concorp.contoso.com
account_domain	Canada	Fabrikam

Migrating All Global Groups

After configuring the regional domain OU structure, you are ready to migrate global groups from the Windows NT 4.0 account domains.

To migrate the global group from Windows NT 4.0 account domains to Windows 2000 target domains in your environment

On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select Group Account Migration Wizard.

When prompted by the Group Account Migration Wizard, use the information provided in Table 127 to complete the wizard. Accept default settings when no information is specified.

Table 127 Migrating global groups by using the Group Account Migration Wizard in ADMT

Wizard Page	Action
Test or Make Changes	Select Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* (where source_domain is the domain name of the Windows NT 4.0 account domain). In the Target domain box, type *target_domain. (where target_domain* is the fully qualified domain name of the Windows 2000 regional domain).
Group Selection	Click Add. In the Select Groups dialog box, select all groups (except built-in groups), click Add, and then click OK.
Organizational Unit Selection	Click Browse. In the Browse for Container dialog box, navigate to *source_domain* \Groups (where source_domain is the domain name of the Windows NT 4.0 account domain), and then click OK.
Group Options	Select the Migrate Group SIDs to target domain check box. Click Do not rename accounts.
User Account	In the User name box, type ADMTMigrationAcct In the Password box, type password (where password is the password for ADMTMigrationAcct) In the Domain box, type *target_domain. (where target_domain* is the fully qualified domain name of the Windows 2000 regional domain).
Naming Conflicts	Click Ignore naming conflict accounts and don't migrate.

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start the Active Directory Users and Computers console.
Navigate to source_domain\Groups OU (where source_domain is the domain name of the Windows NT 4.0 account domain).
Verify global groups exist in the OU.

Contoso example: Migrating all global groups

Migrate all global groups by using the deployment process described in the previous section and the information in Table 128.

Table 128 Information for Migrating All Global Groups in the Contoso Example

When Prompted For	For CANADA Use	For FABRIKAM Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	CANADA	FABRIKAM
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2

Transitioning Service Accounts to Regional Domains

The next step in restructuring the Windows NT 4.0 account domains is to transition the service accounts, identified in a previous step, from the account domains to the Windows 2000 regional domains.

To transition service accounts to the regional domain:

Migrate the service accounts identified in a previous step.
Update the services, identified in a previous step, to log on by using the newly migrated service accounts.

Migrating Service Accounts

The next step in restructuring account domains is to migrate the service accounts identified earlier in the restructuring domain process. Because the service accounts are identified in the ADMT database, the ADMT User Account Migration Wizard:

Migrates the service account from the Windows NT 4.0 source domain to the Windows 2000 target domain.
Modifies the services on each server, identified in the previous step, to use the migrated service account instead of the service account in the Windows NT 4.0 source domain.

To migrate service accounts in your environment

Review the list of servers that have applications that run as services by using service accounts created earlier in the process.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select User Account Migration Wizard.

When prompted by the User Account Migration Wizard, use the information provided in Table 129 to complete the wizard. Accept default settings when no information is specified.

Table 129 Migrating Service Accounts By Using The User Account Migration Wizard In ADMT.

Wizard Page	Action
Test or Make Changes	Click Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* ((where source_domain is the name of the source domain). In the Target domain box, type *target_domain* ((where target_domain is the name of the target domain).
User Selection	Click Add. In the Select Users dialog box, select *service_accounts* (where service_accounts are all the service accounts identified in a previous step), click Add, and then click OK.
Organizational Unit Selection	Click Browse. In the Browse for Container dialog box, navigate to *source_domain* \Service Accounts (where source_domain is the domain name of the Windows NT 4.0 account domain), and then click OK.
Password Options	Click Complex passwords In the Location to store password file text box, type *file_name* (where file_name is the filename of the file that contains the passwords).
Account Transition Options	Click Disable source accounts. Select the Migrate user SIDs to target domains check box
User Account	In the User name box, type ADMTMigrationAcct In the Password box, type *password* (where password is the password for ADMTMigrationAcct) In the Domain box, type *target_domain* ((where target_domain is the name of the target domain).
User Options	Select the Update user rights check box. Clear Migrate associated user groups check box
Naming Conflicts	Click Replace conflicting accounts.
Service Account Information	Select Migrate all service accounts and update SCM for items marked include.

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start the Active Directory Users and Computers console.
Navigate to source_domain\Service Accounts OU (where source_domain is the domain name of the Windows NT 4.0 account domain).
Verify service accounts exist in the OU.

Contoso example: Migrating the service accounts

Migrate the service accounts by using the deployment process described in the previous section and the information in Table 130.

Table 130 Information for Migrating the Service Accounts in the Contoso Example

For	For CANADA Use	For FABRIKAM Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	CANADA	FABRIKAM
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2
file_names	C:\CanadaSvcPasswords	C:\FabrikamSvcPasswords

Update the Services with the Migrated Service Account

After migrating the service account to the regional domain, update the services, identified in an earlier step, to use the migrated service accounts.

During this process ADMT:

Grants the Log on as a service user right, to the migrated service accounts for each respective member server or domain controller.
Configures the applications running as services to log on by using the migrated service account

To update the services with the migrated service account in your environment

Review the list of servers that have applications that run as services by using service accounts created earlier in the process.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select Security Translation Wizard.

When prompted by the Security Translation Wizard, use the information provided in Table 131 to complete the wizard. Accept default settings when no information is specified.

Table 131 Updating the Services with the Migrated Service Account by using ADMT

Wizard Page	Action
Test or Make Changes	Select Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* ((where source_domain is the name of the source domain). In the Target domain box, type *target_domain* ((where target_domain is the name of the target domain).
Computer Selection	Click Add. In the Select Computers dialog box, select *servers* (where servers are all the servers identified in a previous step), click Add, and then click OK.
Translate Objects	Select Local groups and User rights
Security Translation Options	Select Add.
User Account	In the User name box, type ADMTMigrationAcct In the Password box, type *password* (where password is the password for ADMTMigrationAcct) In the Domain box, type *target_domain* ((where target_domain is the name of the target domain).

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On servers (where servers are all the servers identified in a previous step), verify that the Log on as a service user right is granted to the corresponding service account.

Contoso example: Updating the services with the migrated service account

Update the services with the migrated service account by using the deployment process described in the previous section and the information in Table 132.

Table 132 Information for Updating the Services in the Contoso Example

For	For CANADA Use	For FABRIKAM Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	CANADA	FABRIKAM
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2

Phased Transitioning of Users to Regional Domains

The next step in the restructuring of Windows NT 4.0 account domains is to perform a phased transition of user log on into the Windows 2000 regional domains. Transition small groups of users to the regional domain in batches so that the migration process is more manageable. Notify users in advance when the transitioning of their user log on is going to occur.

Perform the phased transition of users to regional domains in small batches until all users are migrated. Upon completion of each batch, ensure that the transition is successful before transitioning the next batch of users.

Until all user and group accounts are transitioned:

Continue to administer global group membership in the Window NT 4.0 account domains.
For each batch of migrated users, configure any users properties that are not translated from Windows NT 4.0 accounts to Windows 2000, such as dial-up remote access permissions. Upon completion of migrating the current batch of users, modify the newly migrated user accounts to provide the same network access.
Manually synchronize any changes you make to migrated users in the Windows NT 4.0 account domain to support a fall-back strategy.

To perform a phased transitioning of users to regional domains in manageable batches:

Create a test account to be used in verifying the success of the batch.
Migrate all the user accounts included in the batch.
Migrate any local user profiles for user accounts included in the batch.
Re-migrate all global groups to update any group membership changes.
Notify users to log on to the Windows 2000 regional domain.

Note: Perform all user and group administration in the Windows NT 4.0 account domain until all users are migrated.

Creating a Transition Test Account

The first step in transitioning the user logon to the new Windows 2000 domain is to create a test account to later verify the success of user account migrations.

To create an account to test user log on transitioning in your environment

Create a user account in source_domain (where source_domain is the Windows NT 4.0 account domain) by using the information in Table 133.

Table 133 Process For Creating User Account to Test Transition of User Log On

For	Use
User name	ADMTTransitionTest
Description	Account used to test transition of user log on
Password	*password* (where password is any password that meets the security requirements of your organization).

Add ADMTTransitionTest to global_group (where global_group is the name of a global group migrated in a previous step) in source_domain (where source_domain is the name of the Windows NT 4.0 account domain).
On desktop (where desktop is the name of a computer running Windows NT 4.0 Workstation), log on as ADMTTransitionTest.
Change the color scheme of the desktop to Eggplant.
On desktop (where desktop is the name of a computer running Windows NT 4.0 Workstation), log off as ADMTTransitionTest.

This will create a local user profile on desktop (where desktop is the name of a computer running Windows 2000 Professional or Windows NT 4.0 Workstation).

Contoso example: Creating an account to test user log on transitioning

Create an account to test user log on transitioning by using the deployment process described in the previous section and the information in Table 134.

Table 134 Information for Creating an Account to test User Log On Transitioning

When Prompted For	For CANADA Use	For FABRIKAM Use
account_domain	CANADA	FABRIKAM
win2kp_desktop	VAN-VAN-W2KP-01	HKG-HKG-NT4W-01
Password	6Y983-rT	Q12#76hg

Migrating the Current Batch of User Accounts

After creating an account to test user log on transitioning, you are ready to migrate the users in the current batch from the Windows NT 4.0 source domain to the Windows 2000 target regional domain.

To migrate the current batch of users in your environment

On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select User Account Migration Wizard.

When prompted by the User Account Migration Wizard, use the information provided in Table 135 to complete the wizard. Accept default settings when no information is specified.

Table 135 Process for Migrating User Account By Using ADMT

Wizard Page	Action
Test or Make Changes	Click Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* ((where source_domain is the name of the source domain). In the Target domain box, type *target_domain* ((where target_domain is the name of the target domain).
User Selection	Click Add. In the Select Users dialog box, select *user_accounts* (where user_accounts are all the user accounts included in the current batch), click Add, and then click OK.
Organizational Unit Selection	Click Browse. In the Browse for Container dialog box, navigate to *source_domain* \Users (where source_domain is the domain name of the Windows NT 4.0 account domain), and then click OK.
Password Options	Click Complex passwords In the Location to store password file text box, type *file_name* (where file_name is the filename of the file that contains the passwords).
Account Transition Options	Click Leave both accounts open. Select the Days until source account expires check box. In the Days until source account expires text box, type *num_days* (where num_days is the number of days until the account expires in the Windows NT 4.0 account domain). Select the Migrate user SIDs to target domains check box
User Account	In the User name box, type ADMTMigrationAcct In the Password box, type *password* (where password is the password for ADMTMigrationAcct) In the Domain box, type *target_domain* ((where target_domain is the name of the target domain).
User Options	Select the Translate roaming profiles check box. Select the Update user rights check box. Clear Migrate associated user groups check box
Naming Conflicts	Click Replace conflicting accounts.

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start the Active Directory Users and Computers console.
Navigate to source_domain \Users OU (where source_domain is the domain name of the Windows NT 4.0 account domain).
Verify the batch user accounts exist in the OU.

Contoso example: Migrating the user accounts

Migrate the service accounts by using the deployment process described in the previous section and the information in Table 130.

Table 136 Information for Migrating the User Accounts in the Contoso Example

For	For CANADA Use	For FABRIKAM Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	CANADA	FABRIKAM
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
num_days	7	7
password	U56-eR#w	A#34-1w2
file_names	C:\CanadaSvcPasswords	C:\FabrikamSvcPasswords

Migrating Local User Profiles

After migrating a batch of user accounts from the Windows NT 4.0 account domains, you are ready to migrate the local user profiles for the batch of users. The migration of local user profiles is only required on workstation computers running Windows NT 4.0. Other operating systems, such as Microsoft® Windows® 95, do not support local user profiles.

Table 137 lists the methods that organizations can use to manage user profiles, a brief description of the method, and the migration requirements for each method.

Table 137 Methods Used By Organizations to Manage User Profiles

Method	Description	Migration Requirements
Roaming profiles	User profiles are centrally stored on servers. The user's profile is available to the user, regardless of the workstation being used.	Migrated as an option during the user account migration. No additional steps are required.
Local profiles	User profiles are centrally locally on the workstation. When a user logs on to another workstation, a unique local user profile is created.	Migrated as a separate process from the user account migration. Migrate local user profiles for a batch of users immediately after migrating the batch of users.
Do not manage user profiles	User profiles, roaming or local, are considered unimportant by the organization.	Because the user profiles are unimportant to the organization, no migration is required.

Deployment Best Practice

Migrate the local profiles the night before you notify the users to log on to the Windows 2000 regional domains. Migrating the local user profiles the night before ensures that the new user profile reflects the most current user settings.

To migrate local user profiles in your environment

Create a list of workstations where local user profiles are stored.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select Security Translation Wizard.

When prompted by the Security Translation Wizard, use the information provided in Table 138 to complete the wizard. Accept default settings when no information is specified.

Table 138 Migrating the Local User Profiles by using ADMT

Wizard Page	Action
Test or Make Changes	Select Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* ((where source_domain is the name of the source domain). In the Target domain box, type *target_domain* ((where target_domain is the name of the target domain).
Computer Selection	Click Add. In the Select Computers dialog box, select *desktop* (where desktop is the name of a computer running Windows NT 4.0 Workstation), click Add, and then click OK.
Translate Objects	Select User profiles
Security Translation Options	Select Add.
User Account	In the User name box, type ADMTMigrationAcct In the Password box, type *password* (where password is the password for ADMTMigrationAcct) In the Domain box, type *target_domain* ((where target_domain is the name of the target domain).

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On desktop (where desktop is the name of a computer running Windows NT 4.0 Workstation), log on as ADMTTransitionTest.
Verify that the color scheme of the desktop is Eggplant.

Contoso example: Migrating local user profiles

Migrate the local user profile permissions by using the deployment process described in the previous section and the information in Table 139.

Table 139 Information for Updating the Local User Profile Permissions

For	For CANADA Use	For FABRIKAM Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	CANADA	FABRIKAM
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
desktop	VAN-VAN-NT4W-01	MIL-MIL-NT4W-01
password	U56-eR#w	A#34-1w2

Re-migrating All Global Groups

After you have migrated the most current batch of users, re-migrate all global groups from the Windows NT 4.0 account domains to the Windows 2000 regional domains. Re-migrate all global groups to ensure that any new global group, created since the previous migration, is included in the migration batch.

To re-migrate the global group from Windows NT 4.0 account domains to Windows 2000 target domains in your environment

On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select Group Account Migration Wizard.

When prompted by the Group Account Migration Wizard, use the information provided in Table 140 to complete the wizard. Accept default settings when no information is specified.

Table 140 Re-migrating Global Groups by using the Group Account Migration Wizard

Wizard Page	Action
Test or Make Changes	Select Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* (where source_domain is the domain name of the Windows NT 4.0 account domain). In the Target domain box, type *target_domain. (where target_domain* is the fully qualified domain name of the Windows 2000 regional domain).
Group Selection	Click Add. In the Select Groups dialog box, select all groups (except built-in groups), click Add, and then click OK.
Organizational Unit Selection	Click Browse. In the Browse for Container dialog box, navigate to *source_domain* \Groups (where source_domain is the domain name of the Windows NT 4.0 account domain), and then click OK.
Group Options	Select the Migrate Group SIDs to target domain check box. Click Do not rename accounts.
User Account	In the User name box, type ADMTMigrationAcct In the Password box, type password (where password is the password for ADMTMigrationAcct) In the Domain box, type *target_domain. (where target_domain* is the fully qualified domain name of the Windows 2000 regional domain).
Naming Conflicts	Click Replace conflicting accounts.

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start the Active Directory Users and Computers console.
Navigate to source_domain \Groups OU (where source_domain is the domain name of the Windows NT 4.0 account domain).
Verify that any new global groups exist in the OU.

Contoso example: Migrating all global groups

Re-migrate all global groups by using the deployment process described in the previous section and the information in Table 141.

Table 141 Information for Re-migrating All Global Groups in the Contoso Example

When Prompted For	For CANADA Use	For FABRIKAM Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	CANADA	FABRIKAM
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2

Notifying Users To Log On To The Target Domain

After migrating each batch of users, notify users:

That their account has been migrated.
Of their new password in the Windows 2000 resource domain.
That they should log on to the Windows 2000 resource domain.

Tip The user's new password in stored in the ADMT password file created during user account migration. To automate the notification process, create a script that enumerates the password file and automatically send mail to users with their new passwords.

To notify users to log on to the target domain in your environment

Through a manual or automatic process, enumerate through the ADMT password file and notify users of that their account is migrated and their new password.

Contoso example: Notifying users to log on to the target domain

Users were manually notified that their account was migrated and given their new password.

Re-migrating All Global Groups

After all users have been transitioned from the Windows NT 4.0 account domains to the Windows 2000 regional domains, re-migrate all global groups from the Windows NT 4.0 account domains to the Windows 2000 regional domains. Re-migrate all global groups to ensure that any new global group, created since the previous migration, is migrated.

To re-migrate the global group from Windows NT 4.0 account domains to Windows 2000 target domains in your environment

On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select Group Account Migration Wizard.

When prompted by the Group Account Migration Wizard, use the information provided in Table 142 to complete the wizard. Accept default settings when no information is specified.

Table 142 Re-migrating Global Groups by using the Group Account Migration Wizard

Wizard Page	Action
Test or Make Changes	Select Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* (where source_domain is the domain name of the Windows NT 4.0 account domain). In the Target domain box, type *target_domain. (where target_domain* is the fully qualified domain name of the Windows 2000 regional domain).
Group Selection	Click Add. In the Select Groups dialog box, select all groups (except built-in groups), click Add, and then click OK.
Organizational Unit Selection	Click Browse. In the Browse for Container dialog box, navigate to *source_domain* \Groups (where source_domain is the domain name of the Windows NT 4.0 account domain), and then click OK.
Group Options	Select the Migrate Group SIDs to target domain check box. Click Do not rename accounts.
User Account	In the User name box, type ADMTMigrationAcct In the Password box, type password (where password is the password for ADMTMigrationAcct) In the Domain box, type *target_domain. (where target_domain* is the fully qualified domain name of the Windows 2000 regional domain).
Naming Conflicts	Click Replace conflicting accounts.

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start the Active Directory Users and Computers console.
Navigate to source_domain\Groups OU (where source_domain is the domain name of the Windows NT 4.0 account domain).
Verify that any new global groups exist in the OU.

Contoso example: Migrating all global groups

Migrate all global groups by using the deployment process described in the previous section and the information in Table 143.

Table 143 Information for Migrating All Global Groups in the Contoso Example

When Prompted For	For CANADA Use	For FABRIKAM Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	CANADA	FABRIKAM
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2

Completing Account Domain Restructuring

After all groups, service accounts, and users are migrated from the Windows NT 4.0 account domains, complete the account domain restructuring.

To complete the account domain restructuring:

Administer user and group accounts exclusively in the Windows 2000 regional domains.
Ensure that two domain controllers in the Windows NT 4.0 account domain are operational until all resource domain restructuring is completed.
Retain tape backup of the two domain controllers in the Windows NT 4.0 account domain after all resource domain restructuring is completed.

For more information on restructuring Windows NT 4.0 resource domains, review the "Restructuring Resource Domains" section later in this document.

Restructuring Resource Domains

After restructuring Windows NT 4.0 account domains, you are ready to restructure Windows NT 4.0 resource domains. Figure 17 illustrates where restructuring resource domains occurs in your deployment process.

Figure 17: Relationship of restructuring resource domains in the deployment process

To restructure Windows NT 4.0 resource domains:

Create and verify the appropriate trust relationships exist.
Create a resource domain migration account.
Configure the regional domain OU structure.
Identify the servers that run services with service accounts.
Migrate all service accounts.
Migrate workstations and member servers.
Migrate domain controllers.

Administration and Management During Resource Domain Restructuring

Carefully plan for administration and management of the following aspects of resource account migration:

Workstations
Resources on member servers
Resources on domain controllers

Migrating Workstation and Member Servers

The migration of workstation accounts and member servers is straightforward. The local groups created to grant permissions are in the local SAM database and are moved with the server. No access control lists have to be manipulated to give users access to resources after the move. Besides the move itself, user access to resources is enabled without effort.

Migrating Domain Controllers

There are different strategies for using domain controllers in Windows NT 4.0 resource domains. In some domains, domain controllers are dedicated servers used for authentication only. In other domains, use of shared local groups allowed assigning permissions over all domain controllers. Resource domains that use domain controllers as dedicated domain controllers should migrate these domains first and then do the more labor intensive resource domains with resources on domain controllers next.

The migration of domain controllers is more labor intensive for the following reasons:

Windows NT 4.0 domain controllers cannot be demoted to member servers or moved between domains.
All access rights are based on shared local groups.

Migrate the shared local groups to the target domain first, upgrade the Windows NT 4.0 domain controllers to Windows 2000, and then move them to the new domain. Note that it is not necessary to change any Access Control Lists (ACLs) as part of this process. The ACLs will still reference the old Shared Local Groups in the resource domain. Because the Shared Local Groups were migrated to the target domain as Domain Local Groups (and have the old SID in the SIDHistory), users will still be able to access the resources as before. Group membership in the local groups was retained during the migration.

Creating and Verifying Trust Relationships

When you are migrating resources from Windows NT 4.0 domains, ensure that two one-way trusts exist between the Windows 2000 regional domains and the Windows NT 4.0:

Account domains.
Resource domains.

Note: In the restructuring of the Windows NT 4.0 account domains, all trusts exist except for an additional trust between the Windows 2000 regional domains and the Windows NT 4.0 resource domains.

To create and verify trust relationships in your environment

On winnt_dc (where winnt_dc is any domain controller in the Windows NT 4.0 domain), start User Manager for Domains.

Create the trust relationships for the Windows NT 4.0 domains based on the process described in Table 144.

Table 144 Establishing the Trust Relationships In the Windows NT 4.0 Domains

Account

In the Trusted Domains and Trusting Domains boxes, add win2k_domain (where win2k_domain is the name of the regional domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Resource

In the Trusted Domains box, add win2k_domain (where win2k_domain is the name of the regional domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

On win2k_dc (where win2k_dc is any domain controller in the regional domain), start an instance of the Microsoft Management Console (MMC) and include the Active Directory Domains and Trusts snap-in.

Create the trust relationships between the Windows NT 4.0 domains based on the process described in Table 145.

Table 145 Establishing the Trust Relationships In the Windows 2000 Domains

Account

In the Domains trusted by this domain and Domains that trust this domain boxes, add winnt_domain (where winnt_domain is the name of the Windows NT 4.0 account domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Resource

In the Domains that trust this domain box, add winnt_domain (where winnt_domain is the name of the Windows NT 4.0 account domain).

In the Password and Confirm password boxes, type trust_password (where trust_password is the password used to establish the trust relationship).

Contoso example: Creating and verifying trust relationships

Create and verify trust relationships by using the deployment process described in the previous section and the information in Table 146, Table 147, Table 148, and Table 149.

Table 146 Trusts Relationships for the noam.concorp.contoso.com Domain (Part 1)

When Prompted For	For SEATTLE Use	For BOSTON Use
winnt_domain	SEATTLE	BOSTON
Domain type	Resource	Resource
winnt_dc	SEA-SEA-DC-01	BOS-BOS-DC-01
win2k_domain	USA	USA
win2k_dc	SEA-NOAM-DC-01	SEA-NOAM-DC-01
trust_password	N54-WeL8	N54-WeL8

Table 147 Trusts Relationships for the noam.concorp.contoso.com Domain (Part 2)

When Prompted For	For CANADA Use	For VANCOUVER Use	For MONTREAL Use
winnt_domain	CANADA	VANCOUVER	MONTREAL
Domain type	Account	Resource	Resource
winnt_dc	VAN-CAN-DC-01	VAN-VAN-DC-01	MON-MON-DC-01
win2k_domain	USA	USA	USA
win2k_dc	SEA-NOAM-DC-01	SEA-NOAM-DC-01	SEA-NOAM-DC-01
trust_password	N54-WeL8	N54-WeL8	N54-WeL8

Table 148 Trusts Relationships for the emea.concorp.contoso.com Domain (Part 1)

When Prompted For	For MILAN Use	For SEVILLE Use
winnt_domain	MILAN	SEVILLE
Domain type	Resource	Resource
winnt_dc	MIL-MIL-DC-01	SEV-SEV-DC-01
win2k_domain	emea	emea
win2k_dc	MIL-EMEA-DC-01	MIL-EMEA-DC-01
trust_password	N54-WeL8	N54-WeL8

Table 149 Trusts Relationships for the emea.concorp.contoso.com Domain (Part 2)

When Prompted For	For FABRIKAM Use	For HONGKONG Use	For TOKYO Use
winnt_domain	FABRIKAM	HONGKONG	TOKYO
Domain type	Account	Resource	Resource
winnt_dc	HKG-FAB-DC-01	HKG-HKG-DC-01	TOK-TOK-DC-01
win2k_domain	emea	Emea	emea
win2k_dc	MIL-EMEA-DC-01	MIL-EMEA-DC-01	MIL-EMEA-DC-01
trust_password	N54-WeL8	N54-WeL8	N54-WeL8

Creating a Resource Domain Migration Account

The next step in installing and configuring ADMT is to create an account used by ADMT for local user profile migration.

To create an account for local user profile migration in your environment

Create a user account in resource_domain (where resource_domain is the name of the resource domain) by using the information in Table 150.

Table 150 Information For Creating User Account Used In ADMT Migrations

When Prompted For	Use
User name	ADMTResourceAcct
Description	Account used by ADMT for resource domain migration
Password	*password* (where password is any password that meets the security requirements of your organization).

Add ADMTResourceAcct to the Administrators group in regional_domain (where regional_domain is the name of the target regional domain).
Add ADMTResourceAcct to the Domain Admins group in resource_domain (where resource_domain is the name of the source resource domain).

Note: During the migration period, make ADMTResourceAcct a member of the local Administrators group in the target domain. Once you finish using the ADMT tool, remove the ADMTResourceAcct account from the local Adminstrators group in the target domain.

Contoso example: Creating an account for local user profile migration

Create a resource domain migration account by using the deployment process described in the previous section and the information in Table 151.a, Table 151.b, Table 151.c, Table 151.d, and Table 151.e.

Table 151.a Information for Creating the Vancouver Resource Domain Migration Account

When Prompted For	Type
resource_domain	VANCOUVER
regional_domain	noam.concorp.contoso.com
password	A#34-1w2

Table 152.b Information for Creating the Montreal Resource Domain Migration Account

When Prompted For	Type
resource_domain	MONTREAL
regional_domain	noam.concorp.contoso.com
password	A#34-1w2

Table 153.c Information for Creating the Hong Kong SAR Resource Domain Migration Account

When Prompted For	Type
resource_domain	HONGKONG
regional_domain	emea.concorp.contoso.com
password	A#34-1w2

Table 154.d Information for Creating the Tokyo Resource Domain Migration Account

When Prompted For	Type
resource_domain	TOKYO
regional_domain	emea.concorp.contoso.com
password	A#34-1w2

Table 155.e Information for Creating the Fabrikam Resource Domain Migration Account

When Prompted For	Type
resource_domain	FABRIKAM
regional_domain	emea.concorp.contoso.com
password	A#34-1w2

Configuring The Regional Domain OU Structure

The next step in restructuring resource domains is to configure the regional domain OU structure. The OU structure in the regional domain is based on the OU design created by the design team. Configure the OU structure for administration by using the Active Directory Users and Computers snap-in

To configure the regional domain OU structure for administration in your environment

Create the OU structure, shown in Figure 14, in regional_domain.forest_root_domain (where regional_domain is the name of the regional domain and forest_root_domain is the name of the forest root domain).

Figure 18: Resource OU Structure Within Each Regional Domain
Create the resouce_domain _ou_admins group in the resource_domain\Admins OU (where resource_domain is the name of the Windows NT 4.0 resource domain):

Note: In the groups that you create in this step, remember to substitute resource_domain with the name of the Windows NT 4.0 resource domain. For example, in the VANCOUVER Windows NT 4.0 resouce domain resouce_domaint _ou_admins would become VANCOUVER_ou_admins.
Assign the appropriate administrative users to the groups created in step 2.
Delegate the administration of the OU structure to the respective groups by using the information described in Table 156(where resource_domain is the name of the Windows NT 4.0 resourcce domain).

Table 156 Delegation of Administration To OU Administrative Groups

Delegate Administration Of	By Assigning Full Control To	On These Objects
resouce_domain	resource_domain _ou_admins	All

Contoso example: Configuring the regional domain OU structure for administration

Configure the regional domain OU structure for administration by using the deployment process described in the previous section and the information in Table 157, Table 158, Table 159, and Table 160.

Table 157 Regional Domain OU Structure for noam.concorp.contoso.com (Part 1)

When Prompted For	For SEATTLE Use	For BOSTON Use
regional_domain	noam	noam
forest_root_domain	concorp.contoso.com	concorp.contoso.com
resource_domain	Seattle	Boston

Table 158 Regional Domain OU Structure for noam.concorp.contoso.com (Part 2)

When Prompted For	For VANCOUVER Use	For MONTREAL Use
regional_domain	noam	noam
forest_root_domain	concorp.contoso.com	concorp.contoso.com
resource_domain	Vancouver	Montreal

Table 159 Regional Domain OU Structure for emea.concorp.contoso.com (Part 1)

When Prompted For	For Milan Use	For Seville Use
regional_domain	emea	emea
forest_root_domain	concorp.contoso.com	concorp.contoso.com
resource_domain	Milan	Seville

Table 160 Regional Domain OU Structure for emea.concorp.contoso.com (Part 2)

When Prompted For	For Hong Kong SAR Use	For Tokyo Use
regional_domain	emea	emea
forest_root_domain	concorp.contoso.com	concorp.contoso.com
resource_domain	HongKong	Tokyo

Identifying Service Accounts

The next step in restructuring resource domains is to identify the member servers and domain controllers that run applications, as services using a service account. A service account is a user account created explicitly to provide a security context for these applications. The service account is a standard user account that is granted the Log on as a service user right.

Note: After this step in the restructuring resource domain process, identify any new service accounts that are configured on servers. Migrate the new service accounts later in the process, prior to completing the Windows NT 4.0 resource domain restructuring.

To identify the service accounts in your environment

Manually create a list of servers that have applications that run as services by using service accounts.
Add the ADMTMigrationAcct to the local Administrators group in the source_domain .
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), logon with the ADMTMigrationAcct, start ADMT, and select Service Account Migration Wizard.

When prompted by the Service Account Migration Wizard, use the information provided in Table 161 to complete the wizard. Accept default settings when no information is specified.

Table 161 Identify Service Accounts by Using the Service Account Migration Wizard

Wizard Page	Action
Domain Selection	In the Source domain box, type *source_domain* ((where source_domain is the name of the resource domain). In the Target domain box, type *target_domain* ((where target_domain is the name of the regional domain).
Update Information	Clcik Yes, update the information.
Service Account Selection	Click Add. In the Select Computers list box, select *server_names* (where server_names is the list of all servers that run applications by using service accounts), click Add, and then click OK.
User Account	In the User name box, type ADMTResourceAcct In the Password box, type *password* (where password is the password for ADMTResourceAcct) In the Domain box, type *source_domain* ((where source_domain is the name of the resource domain).

The Active Directory Migration Tool Agent Monitor dialog box appears.

In the Active Directory Migration Tool Agent Monitor dialog box, on the Summary page, wait till all computers have finished or failed.
In the Active Directory Migration Tool Agent Monitor dialog box, on the Server List page, click View Dispatch Log.

Notepad opens and displays the contents of the dispatch log. Review the dispatch log for any errors.
Retain the list of servers that run applications by using service accounts. The list of servers is required to complete the next step in the domain restructuring process.

Note: This process does not migrate the accounts but only identifies them for later migration.

Contoso example: Identifying the service accounts

Identify the service accounts by using the deployment process described in the previous section and the information Table 162.

Table 162 Information for Identifying the Service Accounts in the Contoso Example

When Prompted For	For Vancouver Use	For Milan Use
source_domain	VANCOUVER	MILAN
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2
server_names	VAN-VAN-FP-01	MIL-MIL-FP-01

Transitioning Service Accounts to Regional Domains

The next step in restructuring the Windows NT 4.0 resource domains is to transition the service accounts, identified in a previous step, from the resource domains to the Windows 2000 regional domains.

To transition service accounts to the regional domain:

Migrate the service accounts identified in a previous step.
Update the services, identified in a previous step, to log on by using the newly migrated service accounts.

Migrating Service Accounts

The next step in restructuring resource domains is to migrate the service accounts identified earlier in the restructuring domain process. Because the service accounts are identified in the ADMT database, the ADMT User Account Migration Wizard:

Migrates the service account from the Windows NT 4.0 source domain to the Windows 2000 target domain.
Modifies the services on each server, identified in the previous step, to use the migrated service account instead of the service account in the Windows NT 4.0 source domain.

To migrate service accounts in your environment

Review the list of servers that have applications that run as services by using service accounts created earlier in the process.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select User Account Migration Wizard.

When prompted by the User Account Migration Wizard, use the information provided in Table 163 to complete the wizard. Accept default settings when no information is specified.

Table 163 Migrating Service Accounts By Using The User Account Migration Wizard In ADMT.

Wizard Page	Action
Test or Make Changes	Click Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* ((where source_domain is the name of the source domain). In the Target domain box, type *target_domain* ((where target_domain is the name of the target domain).
User Selection	Click Add. In the Select Users dialog box, select *service_accounts* (where service_accounts are all the service accounts identified in a previous step), click Add, and then click OK.
Organizational Unit Selection	Click Browse. In the Browse for Container dialog box, navigate to *source_domain* \Service Accounts (where source_domain is the domain name of the Windows NT 4.0 account domain), and then click OK.
Password Options	Click Complex passwords In the Location to store password file text box, type *file_name* (where file_name is the filename of the file that contains the passwords).
Account Transition Options	Click Disable source accounts. Select the Migrate user SIDs to target domains check box
User Account	In the User name box, type ADMTResourceAcct In the Password box, type *password* (where password is the password for ADMTResourceAcct) In the Domain box, type *target_domain* ((where target_domain is the name of the target domain).
User Options	Select the Update user rights check box. Clear Migrate associated user groups check box
Naming Conflicts	Click Replace conflicting accounts.
Service Account Information	Select Migrate all service accounts and update SCM for items marked include.

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start the Active Directory Users and Computers console.
Navigate to source_domain\Service Accounts OU (where source_domain is the domain name of the Windows NT 4.0 resource domain).
Verify service accounts exist in the OU.

Contoso example: Migrating the service accounts

Migrate the service accounts by using the deployment process described in the previous section and the information in Table 164.

Table 164 Information for Migrating the Service Accounts in the Contoso Example

For	For Vancouver Use	For Milan Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	VANCOUVER	MILAN
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
target_OU	VANCOUVER	MILAN
file_names	C:\VancouverSvcPasswords	C:\MilanSvcPasswords
user_name	ADMTResourceAcct	ADMTResourceAcct
password	U56-eR#w	A#34-1w2
domain	VANCOUVER	MILAN

Update the Services with the Migrated Service Account

After migrating the service account to the regional domain, update the services, identified in an earlier step, to use the migrated service accounts.

During this process ADMT:

Grants the Log on as a service user right, to the migrated service accounts for each respective member server or domain controller.
Configures the applications running as services to log on by using the migrated service account

To update the services with the migrated service account in your environment

Review the list of servers that have applications that run as services by using service accounts created earlier in the process.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select Security Translation Wizard.

When prompted by the Security Translation Wizard, use the information provided in Table 165 to complete the wizard. Accept default settings when no information is specified.

Table 165 Updating the Services with the Migrated Service Account by using ADMT

Wizard Page	Action
Test or Make Changes	Select Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* ((where source_domain is the name of the source domain). In the Target domain box, type *target_domain* ((where target_domain is the name of the target domain).
Computer Selection	Click Add. In the Select Computers dialog box, select *servers* (where servers are all the servers identified in a previous step), click Add, and then click OK.
Translate Objects	Select Local groups and User rights
Security Translation Options	Select Add.
User Account	In the User name box, type ADMTResourceAcct In the Password box, type *password* (where password is the password for ADMTResourceAcct) In the Domain box, type *target_domain* ((where target_domain is the name of the target domain).

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On servers (where servers are all the servers identified in a previous step), verify that the Log on as a service user right is granted to the corresponding service account.

Contoso example: Updating the services with the migrated service account

Update the services with the migrated service account by using the deployment process described in the previous section and the information in Table 166

Table 166 Information for Updating the Services in the Contoso Example

For	For Vancouver Use	For Milan Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	VANCOUVER	MILAN
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2

Migrating Windows NT 4.0 Workstations and Member Servers

After migrating service accounts, migrate all member workstations and servers. Migration of member workstations and servers is accomplished in small batches.

No additional steps are required for migrating local resources shared with other computers. The shared local resources get automatically migrated when you migrate the member workstation and server accounts.

Note: Member workstations and servers that have been joined to the target domain but not restarted immediately following the joining are in an indeterminate state. Force the workstation to restart immediately or as soon as possible.

To migrate Windows NT 4.0 workstations and member servers in your environment

On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), logon with the ADMTResourceAcct, start ADMT, and select Computer Migration Wizard.

When prompted by the Computer Migration Wizard, use the information provided in Table 167 to complete the wizard. Accept default settings when no information is specified.

Table 167 Migrating Workstations and Member Servers by using ADMT

Wizard Page	Action
Test or Make Changes	Select Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* ((where source_domain is the name of the source domain). In the Target domain box, type *target_domain* ((where target_domain is the name of the target domain).
Computer Selection	Click Add. In the Select Computers dialog box, select *computers* (where computers are all the workstations and member servers in the resource domain), click Add, and then click OK.
Organizational Unit Selection	Click Browse. In the Browse for Container dialog box, navigate to *source_domain* \Computers (where source_domain is the domain name of the Windows NT 4.0 resource domain), and then click OK.
Service Account Selection	Select Local groups and User rights
Transferable Objects	Select Add.
User Account	In the User name box, type ADMTResourceAcct In the Password box, type *password* (where password is the password for ADMTResourceAcct) In the Domain box, type *target_domain* ((where target_domain is the name of the target domain).
Computer Options	In the Minutes before computer restart after wizard completion, select 1
Naming Conflicts	Select Ignore conflicting accounts and don't migrate.

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the Migration log for any errors.

After migration, you need to see the migration log to see if any errors occurred during the migration process. If any errors are reported, then run the Retry Wizard. This will launch agents only to workstations and member servers that failed to migrate.
Close the Migration log and click Close.

This starts the installation of the migration agents
In the Active Directory Migration Tool Agent Monitor dialog monitor the status of the agents. When the status of all agents is Finished, click View Dispatch Log.

Notepad opens and displays the contents of the Dispatch log. Review the Dispatch log for any errors.
On computers (where computers are all the workstations and member servers in the resource domain), verify that the computers show up in the appropriate OU.

Contoso example: Migrating Windows NT 4.0 workstations and member servers

Migrate the Windows NT 4.0 workstations and member servers by using the deployment process described in the previous section and the information in Table 168.

Table 168 Information for Updating the Services in the Contoso Example

For	For Vancouver Use	For Milan Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	VANCOUVER	MILAN
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2

Migrating Windows NT 4.0 Domain Controllers

The final step in the restructuring resource domain process is to migrate the Windows NT 4.0 domains controllers from the Windows NT 4.0 domain to the Windows 2000 regional domain. Windows NT 4.0 does not support moving domain controllers between domains or demoting domain controllers to member servers.

To move the Windows NT 4.0 domain controllers to the regional domain:

Upgrade the operating system on the domain controller to Windows 2000.
Configure the domain controller as a Windows 2000 member server in the Windows 2000 regional domain.

Migrate domain controllers only when the domain controller has shared resources. Decommission any domain controllers without shared resources.

To migrate migrating Windows NT 4.0 domain controllers:

Migrate the shared local groups in the domain.
Migrate the Windows NT 4.0 domain controller to the Windows 2000 regional domain.

Migrating Shared Local Groups

Before migrating Windows NT 4.0 domain controllers to the Windows 2000 regional domain, migrate shared local groups. The group memberships of the shared local groups are preserved during migration by ADMT.

To migrate shared local groups in your environment

On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start ADMT, and select Group Account Migration Wizard.

When prompted by the Group Account Migration Wizard, use the information provided in Table 169 to complete the wizard. Accept default settings when no information is specified.

Table 169 Migrating Shared Global Groups by using ADMT

Wizard Page	Action
Test or Make Changes	Select Migrate Now?
Domain Selection	In the Source domain box, type *source_domain* (where source_domain is the domain name of the Windows NT 4.0 resource domain). In the Target domain box, type *target_domain* (where target_domain is the fully qualified domain name of the Windows 2000 regional domain).
Group Selection	Click Add. In the Select Groups dialog box, select all shared local groups, click Add, and then click OK.
Organizational Unit Selection	Click Browse. In the Browse for Container dialog box, navigate to *source_domain* (where source_domain is the domain name of the Windows NT 4.0 resource domain), and then click OK.
Group Options	Select the Migrate Group SIDs to target domain check box. Click Do not rename accounts.
User Account	In the User name box, type ADMTResourceAcct In the Password box, type password (where password is the password for ADMTResourceAcct) In the Domain box, type *target_domain. (where target_domain* is the fully qualified domain name of the Windows 2000 regional domain).
Naming Conflicts	Click Ignore naming conflict accounts and don't migrate.

The Migration Progress dialog box appears.

In the Migration Progress dialog box, when Status is Completed, click View Log.

Notepad opens and displays the contents of the migration log. Review the migration log for any errors.
On win2k_dc (where win2k_dc is the name of a Windows 2000 domain controller in the regional domain), start the Active Directory Users and Computers console.
Navigate to source_domain OU (where source_domain is the domain name of the Windows NT 4.0 resource domain).
Verify global groups exist in the OU.

Contoso example: Migrating all shared local groups

Migrate all shared local groups by using the deployment process described in the previous section and the information in Table 170.

Table 170 Information for Migrating All Shard Global Groups in the Contoso Example

When Prompted For	For Vancouver Use	For Milan Use
win2k_dc	VAN-NOAM-DC-01	MIL-EMEA-DC-01
source_domain	CANADA	FABRIKAM
target_domain	noam.concorp.contoso.com	emea.concorp.contoso.com
password	U56-eR#w	A#34-1w2

Migrating Windows NT 4.0 Domain Controllers To Windows 2000 Regional Domains

After migrating shared local groups to the Windows 2000 regional domains, you are ready to migrate Windows NT domain controllers to regional domains.

Perform the migration process:

First on all BDCs in the resource domain.
Last on the PDC in the resource domain.

To migrate Windows NT 4.0 domain controllers to Windows 2000 regional domains in your environment

Disconnect domain_controller (where domain_controler is the computer name of the domain controller) from the network.
Promote domain_controller (where domain_controler is the computer name of the domain controller) to a PDC.

Ugrade domain_controller (where domain_controler is the computer name of the domain controller) to Windows 2000 by using the information listed in Table 171.

Table 171 Information for Installing Windows 2000 on the Domain Controller

When Prompted For	Use
Convert partitions	NTFS
Computer name	*domain_controller* (where domain_controler is the computer name of the domain controller).
IP address	*ip_address* (where ip_address is the fixed IP address that you assign to the first regional domain controller).
Subnet mask	*subnet_mask* (where subnet_mask is the subnet mask that you assign to the first regional domain controller).
Networking components	DNSInternet Protocol (TCP/IP)
Primary WINS server	*primary_wins_server* (where primary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Secondary WINS server	*secondary_wins_server* (where secondary_wins_server is the IP address of the existing primary WINS server or leave blank if there is no existing WINS infrastructure).
Preferred DNS server	*preferred_dns_server* (where preferred_dns_server is the IP address of this domain controller).
Alternate DNS server	*alternate_dns_server* (where alternate_dns_server is the IP address of another DNS server that is connected through a minimum number of network segments).

Install Active Directory on the domain_controller (where domain_controller is the name of the domain controller) by running the Active Directory Installation Wizard and by using the information provided in Table 172 to complete the wizard. Accept default settings when no information is specified.

Table 172 Information for Installing Active Directory on the Domain Controller

Wizard Page	Action
Domain Controller Type	Click Domain controller for new domain.
Create Tree or Child Domain	Verify that Create a new domain tree is selected.
Create of Join Forest	Verify that Create a new forest of domain trees is selected.
New Domain Name	In the Full DNS name for new domain box, type Test
Configure DNS	Click Yes, install and configure DNS on this computer.
Permissions	Click Permissions compatible only with Windows 2000 servers.
Directory Services Restore Mode Administrator Password	In the Password and Confirm password boxes, type *strong_password* (where strong_password is any strong password)

Demote domain_controller (where domain_controller is the name of the domain controller) to a standalone server by running the Active Directory Installation Wizard and by using the information provided in Table 173 to complete the wizard. Accept default settings when no information is specified.

Table 173 Information for Installing Active Directory on the Domain Controller

Remove Active Directory

Select the This controller is the last controller in the domain check box.

Network Credentials

In the User name box, type user_name (where user_name is the name of an account that has administrator access).

In the Password box, type password (where password is the password for the account).

Administrator Password

In the Password and Confirm password boxes, type admin_assword (where admin_password is the password for the an administrator account).

Connect domain_controller (where domain_controller is the name of the domain controller) to the network.
Join domain_controller (where domain_controller is the name of the domain controller) to regional_domain (where regional_domain is the name of the Windows 2000 regional domain).
Join domain_controller (where domain_controller is the name of the domain controller) to regional_domain (where regional_domain is the name of the Windows 2000 regional domain).
Move domain_controller (where domain_controller is the name of the domain controller) from the Computer container in regional domain to the regional_domain\ Computers (where regional_domain is the name of the Windows 2000 regional domain) by using Active Directory Users and Computers snap-in.

Contoso example: Migrating Windows NT 4.0 domain controllers to Windows 2000 regional domains

Migrate Windows NT 4.0 domain controllers to Windows 2000 regional domains by completing the deployment process steps in the previous section and by using the information provided in Table 174.

Table 174 Information for Migrating to Windows 2000 Regional Domains

When Prompted For	In Vancouver Use	In Milan Use
computer_name	VAN-VAN-DC-02	MIL-MIL-DC-02
ip_address	172.16.48.12	172.16.132.22
subnet_mask	255.255.252.0	255.255.252.0
primary_wins_server	172.16.48.15	172.16.132.15
secondary_wins_server	172.16.12.15	172.16.12.15
preferred_dns_server	172.16.48.12	172.16.132.22
alternate_dns_server	172.16.48.14	172.16132.17
domain_controller	VAN-VAN-DC-02	MIL-MIL-DC-02
strong_password	Xy-ZZ-y-	T#23-Rwp2

Decommissioning the Windows NT 4.0 Domains

After you complete the restructuring of Windows NT 4.0 resource domains, you are ready to decommission the Windows NT 4.0 domains. Figure 19 illustrates where decommissioning the Windows NT 4.0 domains occurs in your deployment process.

Figure 19: Relationship Of Decommissioning The Windows NT 4.0 Domains In The Deployment Process

Note: Ensure that you retain a full system backup of the PDC for each account domain. If you retain a full system backup of each account domain, you can bring the account domain back online.

To decommission the Windows NT account domains:

Remove all trusts relationships between Windows NT 4.0 domains and target Windows 2000 domains.
Repurpose any remaining account domain controllers.

At the end of the deployment process, disable all accounts created in previous steps for migration, including those accounts to which you assigned administrative permissions.

Importing Accounts and Data From Other Sources

After deploying the regional domain, you are ready to import accounts and data from other sources into the regional domain. Figure 20 illustrates where importing accounts and data into the regional domain occurs in the deployment process.

Figure 20: Where Importing Accounts And Data From Other Sources Occurs In The Deployment Process

To import accounts and data from other sources:

Import accounts into the regional domain.
Import data into the regional domain

Importing Accounts into the Domain

To import accounts into the domain:

Create OU structure in the target domain.
Export account information.
Import account information.
Verify user account migration.

Configuring The Regional Domain OU Structure

The first step in importing accounts into regional domains is to configure the regional domain OU structure. The OU structure in the regional domain is based on the OU design created by the design team. Configure the OU structure for administration by using the Active Directory Users and Computers snap-in

To configure the regional domain OU structure for administration in your environment

Create the OU structure, shown in Figure 21, in regional_domain.forest_root_domain (where regional_domain is the name of the regional domain and forest_root_domain is the name of the forest root domain).

Figure 21: Account OU Structure Within Each Regional Domain

Create the following groups in the account\Admins OU (where account is the name of the organizational unit you are using to import your existing accounts):
1. account _ou_admins
2. account _users_admins
3. account_ _group_admins
4. account_ _computer_admins
Assign the appropriate administrative users to the groups created in step 2.
Delegate the administration of the OU structure to the respective groups by using the information described in Table 125 (where account_domain is the name of the Windows NT 4.0 account domain).

Table 175 Delegation of Administration To OU Administrative Groups

Delegate Administration Of	By Assigning Full Control To	On These Objects
account_domain	account_domain _ou_admins	All
account_domain \Users	account_domain _user_admins	User
account_domain \Service Accounts	account_domain _user_admins	User
account_domain \Groups	account_domain _group_admins	Group
account_domain \Computers	account_domain _computer_admins	Computer

Exporting Account Information

Now that you have prepared your Windows 2000 domain and the organizational unit structure, you can export accounts from your existing systems so that you can import them into the organizational unit structure you just created.

To export the account information:

Export the group accounts.
Export the user accounts.

Use the appropriate method available to create a comma separated variable (CSV) text file. The text file lists the user account information you need to migrate.

Note: You can use Microsoft® Excel® or Access® application to reformat the exported data prior to importing the account information.

If the group account is also a part of the user account information, you do not need to export the group account.

Importing Account Information

After exporting the user account information, you are ready to import the user account information.

To import the user account information:

Identify the target OU structure.
Import the group account information into the appropriate OUs by using Active Directory Users and Computers snap-in or by using Addusers.exe on the Windows 2000 Server Resource Kit companion CD.
Import the user account information into the appropriate OUs by using Active Directory Users and Computers snap-in or by using Addusers.exe.

Verifying Account Migration

After importing the accounts into their target OUs, you are ready to verify the migration of the user accounts.

To verify the user account information:

Verify group membership.
Verify extended user account information such as phone numbers, and office numbers.

After verifying the migration of user accounts, you are ready to migrate resources into the domain.

Importing Data into the Domain

After verifying the migration of user accounts, you are ready to import data into the domain.

To import data into the domain:

Install member server.
Create resources on the member server.
Transfer data from existing location to the member server.
Establish user access to resources.
Verify user access to resources.

Installing Member Server

The first step in importing data into the domain is to install a member server.

To install member server, install Windows 2000 on the computer that you want to make the member server using any method such a manual installation, Sysprep, Remote Installation Services, or unattended installation.

Creating Shared Folders on Member Server

After installing member servers, create shared folders on the member servers.

To create shared folders on the member server:

Create folders in file system.
Share the folders with the network.
Verify access to the shared folders for target domain owner (full control).

Transferring Data to Member Server

After creating resources on member servers, you need to transfer data from existing locations to member servers.

To transfer data from existing locations to member servers:

Copy folders, subfolders, and files to target folders.
Verify transfer of data.

To transfer data from operating systems other than Windows 2000, you can use:

FTP
Services for Macintosh
Services for UNIX

Establishing User Access to Shared Folders

After transferring data from existing location to member servers, establish user access to resources.

To establish user access to resources:

Establish share permissions.
Establish NTFS permissions.

Note: To assign permissions to a user, you can assign permissions to groups and make the user a member of the appropriate group.

Verifying User Access to Shared Folders

After establishing user access to resources, verify user access to resources.

To verify user access to resources:

Verify share permissions.
Log on as sample user.
Verify share permissions.
Verify NTFS permissions.

After verifying user access to resources your migration to Windows 2000 Active Directory is complete.

Acknowledgements

We would like to thank the following people for reviewing the guides and providing valuable feedback: (acknowledged individuals are employees of Microsoft Corporation unless otherwise noted)

Micky Balladelli (Avanade Inc.), Dung Hoang Khac (Compaq Global Services), Vic Gupta, Shaun Hayes, Michael Kostersitz, Doug Lindsey, Alain Lissoir (Compaq Global Services), Tony Mosunmade, Tony Redmond (Compaq Global Services), Matthijs ten Seldam, Paul Thompson (NetIQ Corporation), Ruud van Velsen, Eddie Hanif, Frank Plawetzki, Connie Shih, Steve Towle, Christopher Westpoint.

Lab Staff: Robert Thingwold and David Meyer

Lab Partners: Compaq, Inc. and Cisco Systems

Best Practice Active Directory Deployment for Managing Windows Networks

On This Page

Overview of Active Directory Deployment

Active Directory Deployment Process

Introduction to Contoso Pharmaceuticals Example

Testing And Verifying the Deployment Process

Testing in a Lab Environment

Verifying in a Pilot Deployment Program

Completing the Pilot Deployment Program

Configuring DNS for the Forest Root

Review the DNS Design Worksheet

Review the Existing DNS Infrastructure

Delegate the DNS Domain for the Forest Root

Creating the Forest Root

Deploying the First Forest Root Domain Controller

Deploying an Additional Domain Controller in the Same Site

Configuring Site Topology

Configuring Operations Master Roles

Deploying Additional Domain Controllers in Other Sites

Deploying Regional Domains

Creating a New Regional Domain

Delegating the DNS Domain for the New Regional Domain

Deploying the First Domain Controller in a New Regional Domain

Deploying an Additional Domain Controller in the Primary Site

Create Trust Relationships

Deploying Additional Domain Controller in Other Sites

In-Place Upgrading of Account Domain

Delegating the DNS Domain for the New Regional Domain

Configuring Windows NT 4.0 Replication of Logon Scripts and Profiles

Deploying the First Domain Controller in the Primary Site

Deploying an Additional Domain Controller in the Primary Site

Configuring Logon Script and Profile Replication Between Windows 2000 and Windows NT 4.0 Domain Controllers

Configuring The Regional Domain OU Structure For Administration

Creating and Verifying Trust Relationships

Deploying Additional Domain Controller in Other Sites

Completing Domain Deployment

Restructuring Account Domains

Pre-migration phase

Creating and Verifying Trust Relationships

Installing and Configuring ADMT

Identifying Service Accounts

Migrating All Global Groups

Transitioning Service Accounts to Regional Domains

Phased Transitioning of Users to Regional Domains

Re-migrating All Global Groups

Completing Account Domain Restructuring

Restructuring Resource Domains

Administration and Management During Resource Domain Restructuring

Creating and Verifying Trust Relationships

Creating a Resource Domain Migration Account

Configuring The Regional Domain OU Structure

Identifying Service Accounts

Transitioning Service Accounts to Regional Domains

Migrating Windows NT 4.0 Workstations and Member Servers

Migrating Windows NT 4.0 Domain Controllers

Decommissioning the Windows NT 4.0 Domains

Importing Accounts and Data From Other Sources

Importing Accounts into the Domain

Importing Data into the Domain

Additional resources