Export (0) Print
Expand All
Expand Minimize
4 out of 7 rated this helpful - Rate this topic

Best Practice Active Directory Deployment for Managing Windows Networks

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.

On This Page

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 http://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

Bb727084.dply0201(en-us,TechNet.10).gif

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)

http://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

http://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.

Bb727084.dply0202(en-us,TechNet.10).gif

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 http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx.

Bb727084.dply0203(en-us,TechNet.10).gif

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.

Bb727084.dply0204(en-us,TechNet.10).gif

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:

  1. Ensure that forest-wide replication latency is less than or equal to the maximum replication latency specified in the design.

  2. 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 http://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:

  1. Creating a list of all critical applications.

  2. Ensuring that each application is assigned an individual responsible for testing the application.

  3. 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:

  1. In two or more production Windows NT 4.0 account domains, create a new backup domain controllers (BDCs).

  2. Remove the new BDCs from the production network.

  3. Install the new BDCs in the lab environment.

  4. Promote the new BDCs to primary domain controllers (PDCs).

  5. Perform in-place upgrades and restructuring of the account domains in your lab

  6. 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:

  1. 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 http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx.

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

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

  2. 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).

  3. 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).

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

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

Bb727084.dply0205(en-us,TechNet.10).gif

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.

Bb727084.dply0206(en-us,TechNet.10).gif

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.

Bb727084.dply0207(en-us,TechNet.10).gif

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:

  1. Review the DNS design worksheet created by the forest root owner and directory architect.

  2. Review the existing internal DNS namespace.

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

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

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

Bb727084.dply0208(en-us,TechNet.10).gif

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:

  1. Deploy the first domain controller.

  2. Deploy an additional domain controller in the same site.

  3. Configure site topology.

  4. Configure operations master roles.

  5. 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:

  1. Install Windows 2000.

  2. Install Active Directory.

  3. Verify the Active Directory installation.

  4. Configure DNS server recursive name resolution.

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

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

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

  1. Review the Windows 2000 event log for any errors.

  2. From a command prompt, run Dcdiag.exe and review any errors that are reported.

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

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

  2. 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).

  3. From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).

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

  1. Start an instance of the Microsoft Management Console (MMC) and include the DNS snap-in.

  2. 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).

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

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

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

  6. 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)

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

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

  9. In the Zone Aging/Scavenging Properties dialog box, select the Scavenge stale resource records check box, and then click OK.

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

  11. In the _msdcs. forest_root_domain Properties dialog box (where forest_root_domain is the name of the forest root domain), click OK.

  12. 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:

  1. Install Windows 2000.

  2. Install Active Directory.

  3. Verify the Active Directory installation.

  4. Configure DNS server recursive name resolution.

  5. Modify the DNS client settings on the first domain controller.

  6. 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 http://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.

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.

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

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

  1. Review the Windows 2000 event log for any errors.

  2. From a command prompt, run Dcdiag.exe and review any errors that are reported.

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

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 additional forest root domain controller in your environment

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

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

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

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

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

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

  2. 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:

  1. Delegate Active Directory site topology administration.

  2. Create the Active Directory sites.

  3. Create and assign the subnets in Active Directory.

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

  1. Create a user named SiteTopologyOwner in the default Users container, in the forest root domain.

  2. Create a global group named SiteAdmins in the default Users container, in the forest root domain.

  3. Assign SiteTopologyOwner to the SiteAdmins global group.

  4. In the Active Directory Sites and Services snap-in, right-click the Sites node, and then click Delegate Control.

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

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

  2. Create the sites specified in the site topology worksheet.

Contoso example: Creating the Active Directory sites

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

    Bb727084.dply0209(en-us,TechNet.10).gif

    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

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

  1. Review the site topology design worksheet provided by your design team, focusing on the subnets section of the worksheet.

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

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

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

  1. Review the site topology design worksheet provided by your design team, focusing on the site link section of the worksheet.

  2. Create the Active Directory site links specified in the site topology worksheet.

Contoso example: Creating Active Directory site links

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

    Bb727084.dply0210(en-us,TechNet.10).gif

    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

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

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

  2. 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:

  1. Install Windows 2000.

  2. Install Active Directory.

  3. Verify the Active Directory installation.

  4. Configure DNS server recursive name resolution.

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

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.

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

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

  2. From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).

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

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

  1. Review the Windows 2000 event log for any errors.

  2. From a command prompt, run Dcdiag.exe and review any errors that are reported.

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

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.

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

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

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

    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.

  2. 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).

  3. From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).

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

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

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

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

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

Bb727084.dply0211(en-us,TechNet.10).gif

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 http://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.

Bb727084.dply0212(en-us,TechNet.10).gif

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:

  1. Delegate the DNS domain for the new regional domain.

  2. Deploy the first domain controller in the new domain.

  3. Deploy an additional domain controller in the primary site of the new domain.

  4. Create trust relationships.

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

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

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

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

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:

  1. Install Windows 2000.

  2. Install Active Directory.

  3. Verify the Active Directory installation.

  4. Configure DNS server recursive name resolution.

  5. Configure a secondary copy of the forest root domain _msdcs zone.

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

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

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

  1. Review the Windows 2000 event log for any errors.

  2. From a command prompt, run Dcdiag.exe and review any errors that are reported.

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

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.

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

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

    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.

  2. 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).

  3. From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).

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

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

  2. In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.

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

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

  2. In the console tree, right-click regional_domain (where regional_domain is the domain controller in the regional domain), and then click Properties.

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

  4. Click Yes.

  5. 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:

  1. Install Windows 2000.

  2. Install Active Directory.

  3. Verify the Active Directory installation.

  4. Configure DNS server recursive name resolution.

  5. Modify the DNS delegation for the regional domain.

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

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

  1. Review the Windows 2000 event log for any errors.

  2. From a command prompt, run Dcdiag.exe and review any errors that are reported.

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

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.

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

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

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

  2. In the console tree, navigate to regional_domain (where regional_domain is the name of the regional domain).

  3. In the console tree, right-click regional_domain (where regional_domain is the name of the regional domain), and then click Properties.

  4. In the i Properties dialog box (where regional_domain is the name of the regional domain), on the Name Servers page, click Add.

  5. 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).

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

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

  2. In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.

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

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

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

    For This Type Of Domain

    Action

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

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

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

    For This Type Of Domain

    Action

    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:

  1. Install Windows 2000.

  2. Install Active Directory.

  3. Verify the Active Directory installation.

  4. Configure DNS server recursive name resolution.

  5. Modify the DNS delegation for the regional domain.

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

  1. From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).

  2. From a command prompt, type nslookup regional_domain (where regional_domain is the fully qualified domain name of the regional domain).

  3. 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).

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

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

  1. Review the Windows 2000 event log for any errors.

  2. From a command prompt, run Dcdiag.exe and review any errors that are reported.

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

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.

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

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

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

    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.

  2. From a command prompt, type nslookup forest_root_domain (where forest_root_domain is the fully qualified domain name of the forest root domain).

  3. From a command prompt, type nslookup regional_domain (where regional_domain is the fully qualified domain name of the regional domain).

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

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

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

  2. In the console tree, navigate to regional_domain (where regional_domain is the name of the regional domain).

  3. In the console tree, right-click regional_domain (where regional_domain is the name of the regional domain), and then click Properties.

  4. In the i Properties dialog box (where regional_domain is the name of the regional domain), on the Name Servers page, click Add.

  5. 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).

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

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

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

  2. In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.

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

Bb727084.dply0213(en-us,TechNet.10).gif

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:

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

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

  3. 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:

  1. Delegate the DNS domain for the new regional domain.

  2. Configure Windows NT 4.0 replication of logon scripts and profiles

  3. Deploy the first Windows 2000 domain controller in the domain.

  4. Deploy an additional domain controller in the primary site of the domain.

  5. Configure logon script and profile replication between Windows 2000 and Windows NT 4.0 domain controllers.

  6. Configure the regional domain OU structure for administration.

  7. Create and verify trust relationships.

  8. Deploy domain controllers in other sites.

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

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

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

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

Wizard Page

Action

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

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

  2. 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:

  1. Install a new Windows NT 4.0 PDC.

  2. Install Windows 2000.

  3. Install Active Directory.

  4. Verify the Active Directory installation.

  5. Configure DNS server recursive name resolution.

  6. Configure a secondary copy of the forest root domain _msdcs zone.

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

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

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

  3. 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:

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

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

  1. From a command prompt, type forest_root _ domain (where forest_root_domain is the fully qualified domain name of the forest root domain).

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

  1. Review the Windows 2000 event log for any errors.

  2. From a command prompt, run Dcdiag.exe and review any errors that are reported.

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

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.

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

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

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

  2. From a command prompt, type nslookup parent_domain (where parent_domain is the fully qualified domain name of the forest root domain).

  3. From a command prompt, type nslookup regional_domain.parent_domain (where regional_domain is the fully qualified domain name of the regional domain).

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

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

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

  2. In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.

  3. 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:

  1. Install Windows 2000.

  2. Install Active Directory.

  3. Verify the Active Directory installation.

  4. Configure DNS server recursive name resolution.

  5. Modify the DNS delegation for the regional domain.

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

  1. Review the Windows 2000 event log for any errors.

  2. From a command prompt, run Dcdiag.exe and review any errors that are reported.

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

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.

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

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

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

  2. In the console tree, navigate to regional_domain (where regional_domain is the name of the regional domain).

  3. In the console tree, right-click regional_domain (where regional_domain is the name of the regional domain), and then click Properties.

  4. In the regional_domain Properties dialog box (where regional_domain is the name of the regional domain), on the Name Servers page, click Add.

  5. 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).

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

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

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

  2. In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.

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

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

  2. 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).

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

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

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

  6. In the FRS - LMRepl Replication Bridge dialog box, on the Schedule page, click Advanced.

  7. In the Advanced Schedule Options dialog box, click Repeat task.

  8. In the Advanced Schedule Options dialog box, in the Every box, type frequency (where frequency is how often you want the script to run).

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

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

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

    Bb727084.dply0214(en-us,TechNet.10).gif

    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.

  2. Assign the appropriate administrative users to the groups created in step 2.

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

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

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

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

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

    For This Type Of Domain

    Action

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

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

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

    For This Type Of Domain

    Action

    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:

  1. Install Windows 2000.

  2. Install Active Directory.

  3. Verify the Active Directory installation.

  4. Configure DNS server recursive name resolution.

  5. Modify the DNS delegation for the regional domain.

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

  1. Review the Windows 2000 event log for any errors.

  2. From a command prompt, run Dcdiag.exe and review any errors that are reported.

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

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.

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

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 104 and Table 105.

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

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

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

  2. In the console tree, navigate to regional_domain (where regional_domain is the name of the regional domain).

  3. In the console tree, right-click regional_domain (where regional_domain is the name of the regional domain), and then click Properties.

  4. In the regional_domain Properties dialog box (where regional_domain is the name of the regional domain), on the Name Servers page, click Add.

  5. 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).

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

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

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

  2. In the console tree, right-click domain_controller (where domain_controller is the domain controller in the regional domain), and then click New Zone.

  3. 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:

  1. Disabling Windows NT 4.0 domain controller emulation on all domain controllers when a sufficient number of domain controllers are running Windows 2000.

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

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

  1. Start an instance of the Microsoft Management Console (MMC) and include the Active Directory Users and Computers snap-in.

  2. In the console tree, right-click the regional_domain zone (where regional_domain is the name of the regional domain), and then click Properties.

  3. In the regional_domain Properties dialog box (where regional_domain is the name of the regional domain), click Change Mode.

  4. When prompted to confirm the change to native mode, click Yes.

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

Bb727084.dply0215(en-us,TechNet.10).gif

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:

  1. Create and verify domain trust relationships.

  2. Install and configure ADMT.

  3. Identify service accounts.

  4. Migrate all global groups.

Migration phase

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

  1. Transition service accounts to Windows 2000 regional domain.

  2. Phased transition of users to the Windows 2000 regional domain in batches.

  3. 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:

  1. Re-migrate all global groups.

  2. 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:

  1. Enable the user accounts in the Windows NT 4.0 account domain (if accounts were disabled during migration).

  2. Notify the users to log off the Windows 2000 domain.

  3. Notify the users to log on to the Windows NT 4.0 account domain with their old passwords.

  4. Verify user access to resources.

  5. 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 http://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.

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

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

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

    For This Type Of Domain

    Action

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

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

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

    For This Type Of Domain

    Action

    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

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.

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:

  1. Create an account to be used in user, group, and service account migration.

  2. Create an account to be used in local user profile migration.

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

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

  2. Add ADMTMigrationAcct to the Domain Admins group in regional_domain (where regional_domain is the name of the target regional domain).

  3. To update SIDHistory in a migrated account, ADMTMigrationAcct must be a member of the Domain Admins group in the target domain.

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

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

  2. Add ADMTLProfileAcct to the Administrators group in regional_domain (where regional_domain is the name of the target regional domain).

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

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

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

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

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

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

  1. Manually create a list of servers that have applications that run as services by using service accounts.

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

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

  4. In the Active Directory Migration Tool Agent Monitor dialog box, on the Summary page, wait until all computers have finished or failed.

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

  6. 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:

  1. Configure the regional domain organizational unit (OU) structure.

  2. Migrate all global groups and users by using ADMT.

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

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

    Bb727084.dply0216(en-us,TechNet.10).gif

    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.

  2. Assign the appropriate administrative users to the groups created in step 2.

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

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

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

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

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

  5. Navigate to source_domain \Groups OU (where source_domain is the domain name of the Windows NT 4.0 account domain).

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

  1. Review the list of servers that have applications that run as services by using service accounts created earlier in the process.

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

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

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

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

  6. Navigate to source_domain \Service Accounts OU (where source_domain is the domain name of the Windows NT 4.0 account domain).

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

  1. Review the list of servers that have applications that run as services by using service accounts created earlier in the process.

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

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

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

  5. 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:

  1. Create a test account to be used in verifying the success of the batch.

  2. Migrate all the user accounts included in the batch.

  3. Migrate any local user profiles for user accounts included in the batch.

  4. Re-migrate all global groups to update any group membership changes.

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

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

  2. 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).

  3. On desktop (where desktop is the name of a computer running Windows NT 4.0 Workstation), log on as ADMTTransitionTest.

  4. Change the color scheme of the desktop to Eggplant.

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

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

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

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

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

  5. Navigate to source_domain \Users OU (where source_domain is the domain name of the Windows NT 4.0 account domain).

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

  1. Create a list of workstations where local user profiles are stored.

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

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

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

  5. On desktop (where desktop is the name of a computer running Windows NT 4.0 Workstation), log on as ADMTTransitionTest.

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

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

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

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

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

  5. Navigate to source_domain \Groups OU (where source_domain is the domain name of the Windows NT 4.0 account domain).

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

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

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

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

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

  5. Navigate to source_domain \Groups OU (where source_domain is the domain name of the Windows NT 4.0 account domain).

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

Bb727084.dply0217(en-us,TechNet.10).gif

Figure 17: Relationship of restructuring resource domains in the deployment process

To restructure Windows NT 4.0 resource domains:

  1. Create and verify the appropriate trust relationships exist.

  2. Create a resource domain migration account.

  3. Configure the regional domain OU structure.

  4. Identify the servers that run services with service accounts.

  5. Migrate all service accounts.

  6. Migrate workstations and member servers.

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

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.

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

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

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

    For This Type Of Domain

    Action

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

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

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

    For This Type Of Domain

    Action

    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

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.

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

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

  2. Add ADMTResourceAcct to the Administrators group in regional_domain (where regional_domain is the name of the target regional domain).

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

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

    Bb727084.dply0218(en-us,TechNet.10).gif

    Figure 18: Resource OU Structure Within Each Regional Domain
  2. 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.

  3. Assign the appropriate administrative users to the groups created in step 2.

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

  1. Manually create a list of servers that have applications that run as services by using service accounts.

  2. Add the ADMTMigrationAcct to the local Administrators group in the source_domain .

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

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

  5. In the Active Directory Migration Tool Agent Monitor dialog box, on the Summary page, wait till all computers have finished or failed.

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

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

  1. Review the list of servers that have applications that run as services by using service accounts created earlier in the process.

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

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

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

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

  6. Navigate to source_domain \Service Accounts OU (where source_domain is the domain name of the Windows NT 4.0 resource domain).

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

  1. Review the list of servers that have applications that run as services by using service accounts created earlier in the process.

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

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

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

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

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

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

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

  4. Close the Migration log and click Close.

    This starts the installation of the migration agents

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

  6. 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:

  1. Upgrade the operating system on the domain controller to Windows 2000.

  2. 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:

  1. Migrate the shared local groups in the domain.

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

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

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

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

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

  5. Navigate to source_domain OU (where source_domain is the domain name of the Windows NT 4.0 resource domain).

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

  1. Disconnect domain_controller (where domain_controler is the computer name of the domain controller) from the network.

  2. Promote domain_controller (where domain_controler is the computer name of the domain controller) to a PDC.

  3. 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).

  4. 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)

    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

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

    Wizard Page

    Action

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

  6. Connect domain_controller (where domain_controller is the name of the domain controller) to the network.

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

  8. 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).

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

Bb727084.dply0219(en-us,TechNet.10).gif

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:

  1. Remove all trusts relationships between Windows NT 4.0 domains and target Windows 2000 domains.

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

Bb727084.dply0220(en-us,TechNet.10).gif

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:

  1. Create OU structure in the target domain.

  2. Export account information.

  3. Import account information.

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

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

    Bb727084.dply0221(en-us,TechNet.10).gif

    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

  2. Assign the appropriate administrative users to the groups created in step 2.

  3. 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:

  1. Export the group accounts.

  2. 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:

  1. Identify the target OU structure.

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

  3. 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:

  1. Verify group membership.

  2. 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:

  1. Install member server.

  2. Create resources on the member server.

  3. Transfer data from existing location to the member server.

  4. Establish user access to resources.

  5. 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:

  1. Create folders in file system.

  2. Share the folders with the network.

  3. 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:

  1. Copy folders, subfolders, and files to target folders.

  2. 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:

  1. Establish share permissions.

  2. 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:

  1. Verify share permissions.

  2. Log on as sample user.

  3. Verify share permissions.

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

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.