Anda di halaman 1dari 123

c  


        
   
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.

r  

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

r

  
     

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 c   

         at
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.
mspx.

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


       

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
     
       
This document presents the deployment process for existing networks based on Windows NT 4.0 and other
network operating systems.

  R

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

÷ rTesting and Verifying the Deployment Processr

÷ rConfiguring DNS for the Forest Rootr

÷ rCreating the Forest Rootr

÷ rIn-Place Upgrading Account Domainr or rCreate a New Regional Domainr

÷ rRestructuring Related Account Domainsr

÷ rRestructuring Related Resource Domainsr

÷ rDecommissioning Windows NT 4.0 Domainsr

r R  r    

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

÷ rTesting and Verifying the Deployment Processr

÷ rConfiguring DNS for the Forest Rootr

÷ rCreating the Forest Rootr

÷ rCreating a New Regional Domainr

÷ rImporting Accounts and Data from Other Sourcesr

    !    


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.

"  ! #  


       

  $   ! 

Active http://www.microsoft.com/downloads/details.aspx?FamilyID=788975b1- Migration of


Directory 5849-4707-9817-8c9773c25c6c&DisplayLang=en account and
Migration resource
Tool (ADMT) domains

Dcdiag.exe Support folder on the operating system CD Verification of


successful
domain
controller
deployment

Lbridge.cmd     


    Replication of
logon scripts
and profiles
between
Windows
2000 domain
controllers
and Windows
NT 4.0
domain
controllers

0    0  

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

" %0    0  

    

Windo TCP/IP Core Networking Guide of the Windows 2000 Server Resource Kit
ws
2000
DNS

Active http://www.microsoft.com/technet/archive/windows2000serv/technologies/activedirectory/deploy/
Directo adguide/default.mspx
ry
Branch
Office
Plannin
g
Guide

#    &     '( 

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.

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

) ! 

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

ð  $  

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

 %&   *" *  0     


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.

" +&   $   )   

$   )   

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 Headquarters for Fabrikam where all accounting and administration is performed. A
SAR 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.

Top of page

   ,         

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 c   
       
   at
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.
mspx.
 +   
        
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 testi ng, 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.

 $     *"  *    *      
R   The deployment process that you are testing and verifying is the same deployment process discussed in
the remainder of this document.

   $"'


  
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.

" $"  &    - " 

$"   - " 

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

     

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.

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

  . 
        

1. Ensure that forest-wide replication latency is less than or equal to the maximum r eplication 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:

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

b. Disconnect domain controllers or disable communications links that are used in intersite
replication.

c. Allow the Knowledge Consistency Checker (KCC) to automatically configure new replication
topology.

d. Identify the domain controllers that are now responsible for intersit e replication.

e. Reconnect the domain controllers or enable communications links.

f. Verify that the intersite replication topology returns to the original state, as identified in the
first step.

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

         at
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.
mspx.

,     & "

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.

        

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.

 
        "
  

÷ Test disaster recovery.

÷ Test account and resource migration.

÷ Evaluate delegation, administration, and management.

  0 


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

    0    - 

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.

       R         

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

'
    *   * -   

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 c   


      
    at
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/b
paddsgn.mspx.

2. Delegating permissions on OUs to specific group accounts used for administration.


Verifying the success of the delegation by:

a. Logging on as a user that belongs to the group account to which you delegated permissions.

b. Performing administration tasks on objects withi n the OU (such as modifying the properties
of a user in an account OU).

c. Attempting, and subsequently failing, to perform administrative tasks on OUs to which the
administration group does not have delegated permissions.

,         

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 
your production environment on accounts and resources that approximated your production environment. In
the pilot deployment program, you:

÷ Identify a     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.

   )  

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.

            


  

1. Create u   


(where      is the name of an empty Active Directory
forest root domain created by appending r-testr to the same name of the production forest root
domain).

2. Create 
  
(where     is the name of an Active regional domain created
by appending r-testr to the same name of a production regional domain).

3. Establish the appropriate trust relationships between 


  
(where     is the
name of a regional domain in the pilot program) and á

 
(where   is an
account or resource domain for migration from Windows NT 4.0-based networks).

4. Migrate selected accounts and resources from á

 
(where   is an account or
resource domain for migration from Windows NT 4.0±based networks), or other data sources, to

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

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

&    ( &        

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

" /#    &        

     ! 

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.

 /       

&          

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.

   )  

During the production deployment process, always migrate accounts from the production environment. Never
migrate accounts from the pilot 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.

&    ( &          

Figure 6 illustrates th e Active Directory pilot program forest after production deployment.
 0&            
After the completion of the pilot deployment program, you can start the deployment of Windows 2000 and
Active Directory into your production environment.

Top of page

&   R    0  

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

 1&   R            


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

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

   R     

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.

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

0
  '( R #    

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

 
   ( R        
  

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.

&    ( 0


    ( R    

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

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

" 00  R   R  &   ) ! 

) !  0  R   R 

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   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   DNS domain names for each location.

" 1#  R   R  &   $  

$   #  R   R 

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)

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

    R      0 

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.

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

   R                 


  

1. Create a name server (NS) resource record in the a


 
zone file (where a   is
the fully qualified domain name of the forest root domain's 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).

3. Create a host address (A)    record in the a


 
zone file (where a   is
the fully qualified domain name of the forest root domain's parent domain).

Π 
 

 
 


(where a  is the computer name of the additional domain controller,     
is the name of the forest root domain, a   is the fully qualified domain name of the forest
root domain's parent domain, and a  is the IP address of the additional domain controller).

&    ( !  R             

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.

" 2#    ! R      &   '(

     # &     #  0    

a             

                   

 a  '3&rR3&3 0'R30&3&3

a  1%00% 1%0%+

Top of page

&    0 

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

      

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.

      0   &   

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.

            

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.

#   %

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.
R   You can automate the installation of Windows 2000 by using Sysprep.exe, unattended installation, or
any disk imaging method.

    %             


  

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.

" 4#    #    %     &      0 

   
  ! 

Format partitions NTFS

Computer name ? a 


(where  a  is the computer name of the first forest
root domain controller).

IP address a(where a  is the fixed IP address that you assign to the first
forest root domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the first
forest root domain controller).

Administrator 
aá (where  a is any strong password).
password

Networking DNS
components Internet Protocol (TCP/IP)

Primary WINS a á


(where a   
is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of another
server existing WINS server or leave blank if there is no existing WINS infrastructure).

Preferred DNS au


(where a    
 is the IP address of an existing
server DNS server or leave blank if there is no existing DNS infrastructure).

&    ( #    %         

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.

" #    #    %  &   '(

     # &     #  0    

 a  '3&rR3&3 0'R30&3&3

a  1%00% 1%0%+

"   %//%//%/% %//%//%/%

 a  [15'3+ r6%3[.2

a   
 1%0%/ 1%02/

a    
 1%0 1%0

# 
  

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.

R   When your organization has no existing DNS infrastructure, the Active Directory Installation Wizard
automatically creates an internal root zone (expressed as r.r). 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.

  
               
  

1. From a command prompt, type  a


_  
(where a   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.

" #    #  


      &  

.    

Domain Controller Type Click          .

Create Tree or Child Domain Verify that &      is selected.

Create of Join Forest Verify that &         is selected.

New Domain Name In the R       box, type


u   
(where      is the fully qualified
domain name of the forest root domain)

Configure DNS Click [ *    R    .

Permissions Click    "     %


.

Directory Services Restore In the   &    boxes, type
Mode Administrator 
aá (where  a  is any strong password)
Password

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

&    ( #  


           

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

" %#    #  


    &   '(

     # &     #  0    

a             

                   

 a  [15'3+ r6%3[.2

,  
  # 

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

 
 
                 

  

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.

&    ( ,   


           
  

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

&  R 


0  
R 0  

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.

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

   R 
  
                  

  

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

" +#    &  R 


0  
R 0  

-   &   

Recursive name No additional configuration is necessary.


resolution by root When the DNS server specified as the Preferred DNS server during the
hints 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 ? a 
(where computer_name is the
name of the domain controller), and then click    .
In the ? a 
    dialog box (where computer_name is the
name of the domain controller), on the 0 7  page, view the root hints.

Recursive name Forward unresolved queries to 


, (where  
 is the DNS server
resolution by or nearest replica, from which the forest root domain is delegated).
forwarding 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 ? a 
(where  a  is the
computer name of the domain controller), and then click    .
In the  
?
     dialog box (where      is
the name of the domain controller), on the     page, select the Enable
forwarders check box.
In the #  box, type a(where a  is the IP address of
the DNS server or nearest replica, from which the forest root domain is
delegated), click , and then click r8

No existing DNS No additional configuration is necessary.


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

2. From a command prompt, type  a


 
(where a   is the fully qualified
domain name of the forest root domain's parent domain).

3. From a command prompt, type  u   


(where      is the
fully qualified domain name of the forest root domain).
4. From a command prompt, type  ? a 
.u   
(where
 a  is the computer name of the first forest root domain controller and
     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.

&    ( &   R 


  
            
  

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.

" #    &   R 


0  
R 0     &   
'(

     # &     #  0    

 a  '3&rR3&3 0'R30&3&3

 
 1%0 1%0

a             

                   

   9:

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.

   )  

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.

     9.          


  

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

2. In the console tree, delete the 9 folder beneath the u   
zone (where
u   
is the name of the forest root domain).

3. In the console tree, right-click the u   


zone (where u   
is the
name of the forest root domain), and then click R    .

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

" /#       R  

. 
   

Delegated In the      box, type9


Domain
Name

Name Click .


Servers In the R 0    0  dialog box, in the
  box, type
u  
?
 .u   
(where      is the name of
the forest root domain and      is the name of the first forest root
domain controller).
In the R 0    0  dialog box, in the #  box, type
u  a(where a  is the corresponding IP address of the first forest
root domain controller), click , and then click r8.

5. In the console tree, right-click u  


?
 (where      is the name
of the first forest root domain controller), and then click R : .

6. Complete the R : .  by using the information supplied in Table 29. Accept the default
settings when no information is supplied.

" %4#    &  9:

.    

:  Click 


  3    .

   0
  Click    . .
$ :

: R In the R box, type 9u   


(where
     is the name of the forest root domain)

7. In the console tree, right-click the 9. u   


zone (where      is
the name of the forest root domain), and then click    .

8. In the 9. u   


    dialog box (where      is the name
of the forest root domain), on the ð  page, click  .

9. In the :  ; 
     dialog box, select the 
      
  check box, and then click r8.

10. In the 9. u   


    dialog box (where      is the name
of the forest root domain), on the :     page, select the  .    check box.

11. In the 9. u   


    dialog box (where      is the name
of the forest root domain), click r8.

12. Restart the Netlogon service by using the Computer Management console.

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

&    (     9.      

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.

" 0#        9:   &   '(

     # &     #  0    

     concorp.contoso.com trccorp.treyresearch.net

     SEA-CON-DC-01 REN-TRC-DC-01

a  172.16.16.21 172.16.20.13

       &         

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.

                

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.

#   %

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.

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

    %           


  

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.

" 1#    #    %     &      
0 

   
  ! 

Format partitions NTFS

Computer name ? a 


(where  a  is the computer name of the additional
forest root domain controller).

IP address a(where a  is the fixed IP address that you assign to the additional
forest root domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the
additional forest root domain controller).

Administrator 
aá (where  a  is any strong password).
password

Networking DNS
components Internet Protocol (TCP/IP)

Primary WINS a á


(where a   
is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of another
server existing WINS server or leave blank if there is no existing WINS infrastructure).

Preferred DNS au


(where a    
 is the IP address of the first
server forest root domain controller).

Alternate DNS  



(where    
 is the IP address of this domain
server controller).

R   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 roo t 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 rIsland of Isolationr problem. For
more information about this topic, see 
    c#$ % at
http://www.microsoft.com/technet/archi ve/windows2000serv/technologies/activedirectory/deploy/adguide/adp
lan/default.mspx - section10.

&    ( #    %         

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.
" 2#    #    %  &   '(

     # &     #  0    

 a  '3&rR3&3% 0'R30&3&3%

a  1%00%% 1%0%

"   %//%//%/% %//%//%/%

 a  [15'3+ r6%3[.2

a   
 1%0%/ 1%02/

a    
 1%00% 1%0%+

   


 1%00%% 1%0%

# 
  

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.

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

  
               
  

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.

" 4#    #  


       &  

.    

Domain Controller Type Click          (   .

Network Credentials In the !   box, type 


(where   is the name of
an account that is a member of the enterprise admins global group.
In the   box, type aá (where a  is the password of
the user name).
In the   box, type u   
(where     
is the fully qualified domain name of the forest root domain).

Additional Domain Click )  .


Controller In the )     dialog box, click u   
(where
     is the fully qualified domain name of the forest root
domain), and then click r8.

Directory Services Restore In the  and&    boxes, type


Mode Administrator 
aá (where  a  is any strong password)
Password

&    ( #  


         

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.

" %#    #  


    &   '(
     # &     #  0    

a             

                   

       '3&rR3&3 0'R30&3&3

       

a  !45183 0 +030/

 a  [15'3+ r6%3[.2

,  
  # 

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

 
 
                 

  

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.

&    ( ,   


           
  

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

&  R 


0  
R 0  

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.

R   While running the Active Directory Installation Wizard, if your organization has an existing DNS
infrastructure, ensure that the Preferred DNS server setti ng 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.

   R 
  
               
   
  

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

" %#    &  R 


0  
R 0  

-   &   

Recursive name No additional configuration is necessary.


resolution by root When the DNS server specified as the Preferred DNS server during the
hints 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 ? a 
(where  a  is the
name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
name of the domain controller), on the 0 7  page, view the root hints.
Recursive name Forward unresolved queries to a, (where a  is IP address of
resolution by the DNS server, or nearest replica, from which the forest root domain is
forwarding 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 ? a 
(where  a  is the
computer name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
computer name of the domain controller), on the     page, select the
Enable forwarders check box.
In the #  box, type a(where a  is the IP address of
the DNS server or nearest replica, from which the forest root domain is
delegated), click , and then click r8

No existing DNS No additional configuration is necessary.


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

&    ( &   R 


  
          
    

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.

" %%#    &   R 


0  
R 0     &   
'(

  # &   !  #  0   ! 

 a  '3&rR3&3% 0'R30&3&3%

a  1%0 1%0

-   R &   r    &  

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.

   )  

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 rIsland of Isolation,r can only occur on forest root
domain controllers. For more information about this topic, see 
    c#$ % .

    R               
  

1. Configure the Preferred DNS server setting to 


 
?
 (where
 #      is the IP address of another forest root domain controller).

2. Configure the Alternate DNS server setting to u  


?
 (where
     is the IP address of the first forest root domain controller).

&    ( &    R           

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.

" %+#    &   R &     &   '(

     # &     #  0    


 #      172.16.16.22 172.16.20.14

     172.16.16.21 172.16.20.13

!  R   

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.

   R                 


  

1. Create a name server (NS) resource record in the a


 
zone file (where a   is
the fully qualified domain name of the forest root domain's parent domain).

º 
   
 
 

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

3. Create a host address (A) resource record in the a


 
zone file (where a   is
the fully qualified domain name of the forest root domain's parent domain).

Π 
 

 
 


(where a  is the computer name of the additional domain controller,     
is the name of the forest root domain, a   is the fully qualified domain name of the forest
root domain's parent domain, and a  is the IP address of the additional domain controller).

&    ( !  R             

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.

" %#    ! R      &   '(

     # &     #  0    

a             

                   

 a  '3&rR3&3% 0'R30&3&3%

a  1%00%% 1%0%

&        

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.

        

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.

   
         

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.
    
            
  

1. Create a user named     r in the default !  container, in the forest root domain.

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

3. Assign     r to the    global group.

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

5. Complete the     &  .  by using the information supplied in Table 25. Select
the default configuration when no information is supplied.

" %/#                 

.    

!   Click .
ð  In the  ! *&  * ð dialog box, click   , click ,
and then click r8.

   Select the &   check box.

&    (    


        

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

&  
    

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.

    
      
  

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.

&    ( &   


   

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.

 4-r&          


" %0$ )  $    
" 0
$  
$   $   $   
" 0 

Seattle Boston ISDN (128.8 Kbps) No more than 56 Kbps.

Vancouver T1 (1.544 megabits per No more than 44 Kbps.


second (Mbps))

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 T1 (1.544 Mbps) No more than 200 Kbps, but with 450-
SAR millisecond latency.

Milan Seville ISDN (128.8 Kbps) No more than 56 Kbps

Hong Kong Tokyo ISDN (128.8 Kbps) No more than 56 Kbps


SAR

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.

" %1   &    $    &    

&     #  $  

Seattle Seattle

Boston Boston

Vancouver Vancouver

Montreal Montreal

Milan Milan

Seville Seville

HongKong Hong Kong SAR

Tokyo Tokyo

" %2   &    $     0    

&     #  $  

Renton Renton

Atlanta Atlanta

&    


   " 

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.

     
  "    
  

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.

&    ( &     


  " 

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.

" %4$   # "  '&   $ 

$   # "   $  

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 172.16.84.0/22172.16.88.0/22172.16.92.0/22
Kong SAR

Tokyo 172.16.76.0/22172.16.78.0/22

" +$   # "  ' 0   $ 

$   # "   $  

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.

" +
   "  # "   &    

  
   "    -

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

" +%
   "  # "    0    

  
   "    -

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

&  
    $ 

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.

   
       
  

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.

&    ( &  


    

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.
 -r&          
" ++$ )  $    
" 0

$  
$   $   $   
" 0 

Seattle Boston ISDN (128.8 Kbps) No more than 56 Kbps.

Vancouver T1 (1.544 megabits per No more than 44 Kbps.


second (Mbps))

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 T1 (1.544 Mbps) No more than 200 Kbps, but with 450-
SAR millisecond latency.

Milan Seville ISDN (128.8 Kbps) No more than 56 Kbps

Hong Kong Tokyo ISDN (128.8 Kbps) No more than 56 Kbps


SAR

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.

" +
    $   &    

$      & 

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

" +/
    $    0    
$      & 

REN-ATL Renton Atlanta 567

&   r  - 0  

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.

   )  

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.

                    


  

1. Transfer the following domain-wide roles to ?


 
?
 (where
       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 " +0 are still on u  
?
 (where
     is the name of the first forest root domain controller in the primary site) by
using the corresponding verification method.

" +0 3  r  - 0   ,  -  

r  - 
0   ,  -  

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.

&    ( &                 

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.

" +1#    &   r  - 0    &   '(

     # &   !  #  0   ! 

     '3&rR3&3 0'R30&3&3

       '3&rR3&3% 0'R30&3&3%

      &    r   

After you deploy the additional forest root domain controller in the same site, 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.

#   %

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.

    %           


  

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

" +2   #    %     &      
0 

   
  ! 

Format partitions NTFS

Computer name ? a 


(where  a  is the computer name of the additional
forest root domain controller).

IP address a(where a  is the fixed IP address that you assign to the additional
forest root domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the
additional forest root domain controller).

Administrator 
aá (where  a is any strong password).
password

Networking DNS
components Internet Protocol (TCP/IP)

Primary WINS a á


(where a   
is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of another
server existing WINS server or leave blank if there is no existing WINS infrastructure).

Preferred DNS au


(where a    
 is the IP address of another
server forest root domain controller that is connected through the minimum number of
network segments).

Alternate DNS  



(where    
 is the IP address of this domain
server controller).

&    ( #    %        

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.

" +4#    #    %  &   '(

     # ,  


!  # - !  # 7 8  0! 

 a  ,R3&rR3&3 -#$3&rR3&3 78ð3&rR3&3

a  1%02 1%0+%% 1%022+

"   %//%//%/% %//%//%/% %//%//%/%


 a  !<103+0/ !1/ð75% 70358

a   
 1%02/ 1%0+%/ 1%022/

a    
 1%00%% 1%00%% 1%00%%

   


 1%02 1%0+%% 1%022+

# 
  

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.

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

  
               
  

1. From a command prompt, type  a


 
(where a   is the fully qualified
domain name of the forest root domain's parent domain).

2. From a command prompt, type  u   


(where      is the
fully qualified domain name of the forest root domain).

3. From a command prompt, type  u  


?
 .u   
(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 th e 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.

" #    #  


       &  

.    

Domain Controller Type Click          (   .

Network Credentials In the !   box, type 


(where   is the name of
an account that is a member of the enterprise admins global group.
In the   box, type aá (where a  is the password of
the user name).
In the   box, type u   
(where     
is the fully qualifi ed domain name of the forest root domain).

Additional Domain Click )  .


Controller In the )     dialog box, click u   
(where
     is the fully qualified domain name of the forest root
domain), and then click r8.

Directory Services Restore In the  and&    boxes, type


Mode Administrator 
aá (where  a  is any strong password)
Password

&    ( #  


         
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.

" #    #  


    &   '(

# 7 8  0
     # ,  
!  # - !  ! 

a                 

                         

       ,R3&rR3&3 -#$3&rR3&3 78ð3&rR3&3

          

a  !4583 !4583 !4583

 a  5+%3![. 0 3+[+ %+503

,  
  # 

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

 
 
                 

  

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.

&    ( ,   


           
   

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

&  R 


0  
R 0  

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.

   R 
  
               
   
  

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

" %#    &  R 


0  
R 0  

-   &   

Recursive name No additional configuration is necessary.


resolution by root When the DNS server specified as the Preferred DNS server during the
hints 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 ? a 
(where  a  is the
name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
name of the domain controller), on the 0 7  page, view the root hints.

Recursive name Forward unresolved queries to a, (where a  is IP address of


resolution by the DNS server, or nearest replica, from which the forest root domain is
forwarding 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 ? a 
(where  a  is the
computer name of the domain controller), and then click    .
In the     dialog box (where  a  is the computer name of
the domain controller), on the     page, select the ' "    
check box.
In the #  box, type a(where a  is the IP address of
the DNS server or nearest replica, from which the forest root domain is
delegated), click , and then click r8.

No existing DNS No additional configuration is necessary.


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

2. From a command prompt, type  a


 
(where parent_domain is the fully qualified
domain name of the forest root domain's parent domain).

3. From a command prompt, type  u   


(where forest_root_domain is the
fully qualified domain name of the forest root domain).

4. From a command prompt, type  ? a 


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

&    ( &   R 


  
          
     

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.

" +#    &   R 


0  
R 0     &   
'(

     # ,  


!  # - !  # 7 8  0! 

 a  ,R3&rR3&3 -#$3&rR3&3 78ð3&rR3&3

a  1%0 1%0 1%0

!  R   

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.

   R                 
  

1. Create a name server (NS) resource record in the a


 
zone file (where a   is
the fully qualified domain name of the forest root domain's parent domain).

º 
   
 


 

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

Π 
 

 
 


(where a  is the computer name of the additional domain controller,     
is the name of the forest root domain, a   is the fully qualified domain name of the forest
root domain's parent domain, and a  is the IP address of the additional domain controller).

&    ( !  R             

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.

" #    ! R      &   '(

     # ,  


!  # - !  # 7 8  0! 

a                 

                         

 a  ,R3&rR3&3 -#$3&rR3&3 78ð3&rR3&3

a  1%02 1%0+%% 1%022+

Top of page

   0    

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.

                


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:

÷ rCreating a New Regional Domainr to create a new regional domain.


÷ rIn-place Upgrading of Account Domainr to perform an in-place upgrade a Windows NT 4.0 account
domain to a regional domain.

   )  

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

Top of page

&  R 0    

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.

 %               


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.

        

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.

    R     R 0    

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.

     R             


  

1. On u   
?
 (where         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 u   


zone (where u   
is the
name of the forest root domain), and then click R    .

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

" /#       0   

.    

Delegated In the      box, type 


  

(where
Domain Name     is the name of the regional domain).

Name Servers Click .


In the R 0    0  dialog box, in the
  box, type
u  
?
 (where      is the name of a domain
controller in the regional domain).
In the R 0    0  dialog box, in the #  box, type
u  a(where a  is the corresponding IP address of the domain
controller in the regional domain), click , and then click r8.
Click .
In the R 0    0  dialog box, in the
  box, type
?
 
?
 (where        is the name of another
domain controller in the regional domain).
In the R 0    0  dialog box, in the #  box, type
a(where a  is the corresponding IP address of the other domain
controller in the regional domain), click , and then click r8.

&    (     R         

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.

       &    R 0    

After you delegate the DNS zone for the regional domain, you are ready 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.

   )  


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

#   %

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.

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

    %             


  

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

" 0#    #    %     &     0  
 

   
  ! 

Format partitions NTFS

Computer name ? a 


(where  a  is the computer name of the first forest root
domain controller).

IP address a(where a  is the fixed IP address that you assign to the first
forest root domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the first
forest root domain controller).

Administrator 
aá (where  a is any strong password).
password

Networking DNS
components Internet Protocol (TCP/IP)

Primary WINS a á


(where a   
is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of the
server existing secondary WINS server or leave blank if there is no existing WINS
infrastructure).

Preferred DNS au


(where a    
 is the IP address of this domain
server controller).

Alternate DNS  



(where    
 is the IP address of another DNS
server server that is connected through a minimum number of network segments).

&    ( #    %         

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 on the computer that you want to make the first regional domain controller by running
the Active Directory Installation Wizard.

  
               
  

1. Install Active Directory on the  


?
 (where      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.

" 1#    #  


      &  
.    

Domain Controller Click          .


Type

Create Tree or Child Click &        (    .
Domain

Network Credentials In the !   box, type 


(where   is the name of a
user account that is a member of enterprise admins).
In the   box, type aá (where a  is the password of the
user account).
In the   box, type u   
(where      is the
name of the forest root domain).

Child Domain Click )  .


Installation In the )     dialog box, click u   
(where
     is the name of the forest root domain), and then click r8.
In the &  box, type 
  
u   
(where
    is the name of the new regional domain and     
is the name of the forest root domain).

Configure DNS Click [ *    R    .

Permissions Click    "   3  %




Directory Services In the   &    boxes, type


Restore Mode 
aá (where  a  is any strong password)
Administrator
Password

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

&    ( #  


           

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

,  
  # 

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

 
 
                 

  

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.

&    ( ,   


             

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

&  R 


0  
R 0  

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.

   R 
  
                  

  

1. Use the DNS snap-in to configure DNS server recursive name resolution based on the information in
Table 48.
" 2#    &  R 
0  
R 0  

-   &   

Recursive name No additional configuration is necessary.


resolution by root When the DNS server specified as the Preferred DNS server during the
hints 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 ? a 
(where  a  is the
name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
name of the domain controller), on the 0 7  page, view the root hints.

Recursive name Forward unresolved queries to 


, (where  
 is the DNS server
resolution by or nearest replica, from which the forest root domain is delegated).
forwarding 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 ? a 
(where  a  is the
computer name of the domain controller), and then click    .
In the  
?
     dialog box (where      is
the name of the domain controller), on the     page, select the ' " 
    check box.
In the #  box, type a(where a  is the IP address of
the DNS server or nearest replica, from which the forest root domain is
delegated), click , and then click r8.

No existing DNS No additional configuration is necessary.


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

2. From a command prompt, type  a


 
(where parent_domain is the fully qualified
domain name of the forest root domain's parent domain).

3. From a command prompt, type  u   


(where forest_root_domain is the
fully qualified domain name of the forest root domain).

4. From a command prompt, type  ? a 


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

&    ( &   R 


  
            
  

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

&      &    0 9:

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.

           9.    


  

1. On  
?
 (where      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  


?
 (where      is the domain controller
in the regional domain), and then click R : .

3. Complete the R : .  by using the information supplied in Table 49. Accept the default
settings when no information is supplied.
" 4#    &     &    0 9:

.    

:  Click      .

: R In the R box, type 9u   


(where      is the
name of the forest root domain).

- R  In the #  box, type u  a(where a  is the IP address

 of a forest root domain controller), and then click .
In the #  box, type ?
 a(where   a  is the IP
address of another forest root domain controller), and then click .

 &    ( &           9.

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

&   0     0  R


- 

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.

                


     
  

1. On  
?
 (where      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 


  
(where     is the domain controller in
the regional domain), and then click    .

3. In the 
  
    dialog box (where     is the domain controller in
the regional domain), on the ð  page, click &  -  .

A message box appears prompting you to confirm changing the domain to run in native mode.

4. Click [ .

5. In the 
  
    dialog box (where     is the domain controller in
the regional domain), click r8.

&    ( &                


 

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

       &         

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.

              

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.


#   %

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.

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

    %                  

  

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.

" /#    #    %     &     
0   

   
  ! 

Format partitions NTFS

Computer name ? a 


(where  a  is the computer name of the regional
domain controller).

IP address a(where a  is the fixed IP address that you assign to the regional
domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the regional
domain controller).

Administrator 
aá (where  a is any strong password).
password

Networking DNS
components Internet Protocol (TCP/IP)

Primary WINS a á


(where a   
is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of the
server existing secondary WINS server or leave blank if there is no existing WINS
infrastructure).

Preferred DNS au


(where a    
 is the IP address of this domain
server controller).

Alternate DNS    


 (where    
 is the IP address of another DNS
server server that is connected through a minimum number of network segments).

&    ( #    %            
  

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 on the computer that you want to make the additiona l regional domain controller in the
same site by running the Active Directory Installation Wizard.

  
                   

  

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.

" /#    #  


       &  

.    


Domain Controller Type Click          (   .

Network Credentials In the !   box, type 


(where   is the name of
an account that is a member of the domain admins global group.
In the   box, type aá (where a  is the password of
the user name).
In the   box, type 
  
(where     is the
fully qualified domain name of the regional domain).

Additional Domain Controller Click )  .


In the )     dialog box, click 
  
(where
    is the fully qualified domain name of the regional
domain), and then click r8.

Directory Services Restore In the  and&    boxes, type  (where
Mode Administrator  a  is any strong password)
Password

&    ( #  


           

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

,  
  # 

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

 
 
                 

  

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.

&    ( ,   


           
   

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

&  R 


0  
R 0  

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.

   R 
  
                
  
  

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

" /%#    &  R 


0  
R 0  

-   &   

Recursive name No additional configuration is necessary.


resolution by root When the DNS server specified as the Preferred DNS server during the
hints 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 ? a 
(where  a  is the
name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
name of the domain controller), on the 0 7  page, view the root hints.
Recursive name Forward unresolved queries to 
, (where  
 is the DNS server
resolution by or nearest replica, from which the forest root domain is delegated).
forwarding 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 ? a 
(where  a  is the
computer name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
computer name of the domain controller), on the     page, select the
' "     check box.
In the #  box, type a(where a  is the IP address of
the DNS server or nearest replica, from which the forest root domain is
delegated), click , and then click r8.

No existing DNS No additional configuration is necessary.


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

&    ( &   R 


  
          
  

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

-   R      0   

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.

   R             


  

1. On  
?
 (where      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 


  
(where     is the name of the
regional domain).

3. In the console tree, right-click 


  
(where     is the name of the regional
domain), and then click    .

4. In the     dialog box (where     is the name of the regional domain), on the
R 
 page, click .

5. In the R 0    0   dialog box, in the


  box, type  (where    is the
fully qualified name of the regional domain controller, where     is the name of the
regional domain, and      is the name of the forest root domain).

6. In the R 0    0   dialog box, in the #  box, type a(where


a  is the IP address of the regional domain controller), click , and then click r8.

&    ( -  R         

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

&      &    0 9:

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.

           9.    


  

1. On  
?
 (where      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  
?
 (where      is the domain controller
in the regional domain), and then click R : .

3. Complete the R : .  by using the information supplied in Table 53. Accept the default
settings when no information is supplied.

" /+#    &     &    0 9:

.    

:  Click      .

: R In the R box, type 9u   


(where     is the
name of the forest root domain)

- R  In the #  box, type u  a(where a  is the IP address

 of a forest root domain controller), and then click .
In the #  box, type ?
 a(where   a  is the IP
address of another forest root domain controller), and then click .

&    ( &           9.

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

&   0  

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.

         


  

1. On á

 
?
 (where      is any domain controller in the
Windows NT 4.0 domain), start ! -     .

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

" /'"   0  #    R  

  r
    

Account In the Trusted Domains and Trusting Domains boxes, add 


  
(where
    is the name of the regional domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

Resource In the Trusted Domains box, add 


  
(where     is the
name of the regional domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

3. On á
  
?
 (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.

" //'"   0  #    %  

  
r    

Account In the Trusted Domains and Trusting Domains boxes, add á

 
(where
  is the name of the Windows NT 4.0 domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

&    ( &     

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

      &    r   

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

            

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.

#   %

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.

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

    %              


  

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

" /0#    #    %     &     
0   

   
  ! 

Format partitions NTFS

Computer name ? a 


(where  a  is the computer name of the regional
domain controller).
IP address a(where a  is the fixed IP address that you assign to the regional
domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the regional
domain controller).

Administrator 
aá (where  a is any strong password).
password

Networking DNS
components Internet Protocol (TCP/IP)

Primary WINS a á


(where a   
is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of another
server existing WINS server or leave blank if there is no existing WINS infrastructure).

Preferred DNS au


(where a    
 is the IP address of this domain
server controller).

Alternate DNS  



(where    
 is the IP address of another DNS
server server that is connected through a minimum number of network segments).

&    ( #    %           

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 on the computer that you want to make the additional regional domain controller in the
same site by running the Active Directory Installation Wizard.

  
                   

  

1. From a command prompt, type  u   


(where      is the
fully qualified domain name of the forest root domain).

2. From a command prompt, type  


  
(where     is the fully
qualified domain name of the regional domain).

3. From a command prompt, type  u  


?
 .
  
(where
     is the computer name of the first regional domain controller and
    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.

" /1#    #  


       &  

.    

Domain Controller Type Click          (   .

Network Credentials In the !   box, type  (where   is the name of an account
that is a member of the domain admins global group.
In the   box, type aá (where  a  is the
password of the user name).
In the   box, type 
  
(where     is the
fully qualified domain name of the regional domain).

Additional Domain Click )  .


Controller In the )     dialog box, click 
  
(where
    is the fully qualified domain name of the regional domain),
and then click r8.

Directory Services Restore In the  and&    boxes, type


Mode Administrator   aá (where   aá is any strong
Password password)

&    ( #  


              
 

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

,  
  # 

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

 
 
                 

  

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.

&    ( ,   


           
   

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

&  R 


0  
R 0  

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.

   R 
  
                
  
  

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

" /2#    &  R 


0  
R 0  

-   &   

Recursive name No additional configuration is necessary.


resolution by root When the DNS server specified as the Preferred DNS server during the
hints 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 ? a 
(where  a  is the
name of the domain controller), and then click    .
In the     dialog box (where  a  is the name of the
domain controller), on the 0 7  page, view the root hints.

Recursive name Forward unresolved queries to 


, (where  
 is the DNS server
resolution by or nearest replica, from which the forest root domain is delegated).
forwarding 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 ? a 
(where  a  is the
computer name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
computer name of the domain controller), on the     page, select the
' "     check box.
In the #  box, type a(where a  is the IP address of
the DNS server or nearest replica, from which the forest root domain is
delegated), click , and then click r8.

No existing DNS No additional configuration is necessary.


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

2. From a command prompt, type  u   


(where forest_root_domain is the
fully qualified domain name of the forest root domain).

3. From a command prompt, type  


  
(where regional_domain is the fully
qualified domain name of the regional domain).

4. From a command prompt, type  ? a 


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

&    ( &   R 


  
          
    

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

-   R      0   

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.

   R             


  

1. On  
?
 (where      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 


  
(where     is the name of the
regional domain).

3. In the console tree, right-click 


  
(where     is the name of the regional
domain), and then click    .

4. In the     dialog box (where     is the name of the regional domain), on the
R 
 page, click .

5. In the R 0    0   dialog box, in the


  box, type

 ?
  
u   
(where    is the fully qualified name
of the regional domain controller, where     is the name of the regional domain, and
     is the name of the forest root domain).

6. In the R 0    0   dialog box, in the #  box, type  (where a  is the IP
address of the regional domain controller), click , and then click r8.

&    ( -   R         

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

&      &    0 9:


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.

           9.    


  

1. On  (where      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  


?
 (where      is the domain controller
in the regional domain), and then click R : .

3. Complete the R : .  by using the information supplied in Table 59. Accept the default
settings when no information is supplied.

" /4#    &     &    0 9:

.    

:  Click      .

: R In the R box, type 9

- R  In the #  box, type u  a(where a  is the IP address

 of a forest root domain controller), and then click .
In the #  box, type ?
 a(where   a  is the IP
address of another forest root domain controller), and then click .

#   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 rImporting Accounts and Data from Other
Sourcesr later in this document.

&    ( &           9.

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

Top of page

# 3 !       

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.
 +# 3                
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 rRestructuring Account Domainsr, 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 rRestructuring Resource Domainsr later in this document.

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

  3     R         %    

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.

    R     R 0    

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.

     R             


  

1. On u  ?(where     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 u   


zone (where      is the name
of the forest root domain), and then click R    .

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

" 0#       0   

. 
   

Delegated In the      box, type 


  
(where     is the
Domain name of the regional domain).
Name

Name Click .


Servers In the R 0    0  dialog box, in the
  box, type
u ?
  
u   
(where  is the name of a domain
controller in the regional domain,     is the name of the regional domain, and
forest_root_domain is the name of the forest root domain).
In the R 0    0  dialog box, in the #  box, type  (where a 
is the corresponding IP address of the domain controller in the regional domain), click ,
and then click r8.

&    (     R         

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

" 0#       0      &    

       Rr-0       '-'0    

u  ? SEA-CON-DC-01 MIL-CON-DC-01

u   
concorp.contoso.com concorp.contoso.com


  
Noam emea

u ? SEA-NOAM-DC-01 MIL-EMEA-DC-01

a 172.16.12.16 172.16.132.16

" 0%#       0       0    
       Rr-0    

u  ? REN-TRC-DC-01

u   
trccorp.treyresearch.net


  
Noam

u ? REN-NOAM-DC-01

a 172.16.12.17

&     R0   $       

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 rUpgrading the Primary Domain
Controller.r

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.

     R            
  

1. On a  
?
 (where a       is the current primary domain
controller in the Windows NT 4.0 account domain), start
-  .

2. Promote ? a 


?
 (where "a     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.

a. Copying a file into the <system root>\system32\repl\export\scripts folder on


a  
?
 (where a       is the original primary
domain controller that was the original replication export server).

b. Waiting for the file to appear in the <system root> \system32\repl\import\scripts folder on
? a 
?
 (where "a     is the backup domain
controller that you selected to be the new PDC).

&    ( &     R         

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.

" 0+#    &     R0  r$       

     # !   # '-'  # 0'[0' '0&7 

a       SEA-USA-DC-01 MIL-EMA-DC-01 REN-TRE-DC-01

"a     SEA-USA-DC-02 MIL-EMA-DC-02 REN-TRE-DC-02

       &         

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

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.

   )  

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

#  R   R&

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 rInstalling Windows 2000.r

     R&   


  

1. Install Windows NT 4.0 as a BDC in  (where    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.

" 0#    R   R)& 0    

   
  ! 

Computer name ? a 


(where  a  is the name of the new domain controller)

Server Type Select )  &   .

IP address a(where a  is a fixed IP address from the range of IP addresses


on the subnet where you want the domain controller installed).

Subnet mask  
 (where "  is the subnet mask assigned to the subnet
where you want the domain controller installed).

Primary WINS a á


(where a   
 is the IP address of an existing
server nearby WINS server).

Secondary WINS ?


á
(where     
 is the IP address of another
server existing WINS server).

Administrator aá (where a  is the password of the Administrator account in the
Name Windows NT 4.0 account domain).

Administrator aá (where a  is the password of the Administrator account in the
Password Windows NT 4.0 account domain).

Domain ??
 
(where    is the Windows NT 4.0 account domain).

Preferred DNS au


(where a    
 is the IP address of a this
server domain controller).

Alternate DNS  



(where    
 is the IP address of another
server nearby DNS server).

Networking Internet Protocol (TCP/IP)


components

R   Ensure that you format all partitions to NTFS.

2. Promote ? a 
(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.

&    ( #     R&

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.

" 0/#    #  R   R&

     # ! !  # '-!  # 0'[0' '0&7! 

 a  SEA-NOAM-DC-01 MIL-EMEA-DC-01 REN-NOAM-DC-01

a  172.16.12.16 172.16.132.16 172.16.12.17

"   255.255.252.0 255.255.252.0 255.255.252.0

a  B365-RoQ Pr23#N4h BbrO-64e

   USA EMEA TREYRESEARCH

a   
 172.16.12.15 172.16.132.15 172.16.20.15

    
 172.16.132.15 172.16.12.15 172.16.12.15

a    
 172.16.12.16 172.16.132.16 172.16.12.17

   


 172.16.16.21 172.16.132.17 172.16.20.13

#   %

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.

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

    %             


  

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

" 00#    #    %     &     0  
 

 
    ! 

Convert NTFS
partitions

Computer name ? a 


(where  a  is the computer name of the first regional
domain controller).

IP address a(where a  is the fixed IP address that you assign to the first
regional domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the first
regional domain controller).

Networking DNS
components Internet Protocol (TCP/IP)
Primary WINS a á
(where a   
is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of the
server existing secondary WINS server or leave blank if there is no existin g WINS
infrastructure).

Preferred DNS au


(where a    
 is the IP address of this domain
server controller).

Alternate DNS  



(where    
 is the IP address of another DNS
server server that is connected through a minimum number of network segments).

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

&    ( #    %         

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.

" 01#    #    %  &   '(

     # ! !  # '-!  # 0'[0' '0&7! 

 a  SEA-NOAM-DC-01 MIL-EMEA-DC-01 REN-NOAM-DC-01

a  172.16.12.16 172.16.132.16 172.16.12.17

"   255.255.252.0 255.255.252.0 255.255.252.0

a   
 172.16.12.15 172.16.132.15 172.16.20.15

    
 172.16.132.15 172.16.12.15 172.16.12.15

a    
 172.16.12.16 172.16.132.16 172.16.12.17

   


 172.16.16.21 172.16.132.17 172.16.20.13

' "   R  &   '

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 rInstalling Windows 2000 and Active Directory on the PDC.r

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

   )  

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.

  "   R                  
  
  

To enable Windows NT 4.0 domain controller emulation:

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

  Π
 ! "#$
%& '()&'*
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.

3. Configure á
 a  a(were a  a 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:

Π   




 + Π
 !
"#$ %& '()&'*
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.

&    ( ' "   R            
    

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.

" 02#    ' "   R  &   '

       Rr-0    

 
?
  REN-TRC-DC-01

á
 a  a REN-TRE-W2KP-01

R   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 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 do main supply enterprise
administrator credentials during the Active Directory Installation Wizard. You can deploy subsequent domain
controllers by using domain administrator credentials.

  
               
  

1. From a command prompt, type u  _  


(where      is the fully qualified
domain name of the forest root domain).

2. Install Active Directory on the  


?
 (where      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.

" 04#    #  


      &  

.    

Domain Controller Click          .


Type

Create Tree or Child Click &        (    .
Domain

Network Credentials In the !   box, type 


(where   is the name of a
user account that is a member of enterprise admins).
In the   box, type aá (where a  is the password of the
user account).
In the   box, type u   
(where      is the
name of the forest root domain).

Child Domain Click )  .


Installation In the )     dialog box, click u   
(where
     is the name of the forest root domain), and then click r8.
In the &  box, type 
  
u   
(where
    is the name of the new regional domain and     
is the name of the forest root domain).

Configure DNS Click [ *    R    .

Permissions Click    "   3  %




Directory Services In the   &    boxes, type


Restore Mode 
aá (where  a  is any strong password)
Administrator
Password

R   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

&    ( #  


           

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.

" 1#    #  


    &   '(

     # ! !  # '-!  # 0'[0' '0&7! 

     concorp.contoso.com concorp.contoso.com trccorp.treyresearch.net

     SEA-NOAM-DC-01 MIL-EMEA-DC-01 REN-NOAM-DC-01

  Administrator Administrator Administrator

a  B365-RoQ Pr23#N4h BbrO-64e

    noam emea noam

 a  H2Y74e#u Xy-ZZ-y- T#23-Rwp2

,  
  # 

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

 
 
                 

  

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.

&    ( ,   


             

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
&  R 
0  
R 0  

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.

   R 
  
                  

  

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

" 1#    &  R 


0  
R 0  

-   &   

Recursive name No additional configuration is necessary.


resolution by root When the DNS server specified as the Preferred DNS server during the
hints 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  (where computer_name is the name of the
domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
name of the domain controller), on the 0 7  page, view the root hints.

Recursive name Forward unresolved queries to a, (where a  is the IP address
resolution by of the DNS server or nearest replica, from which the forest root domain is
forwarding 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 ? a 
(where  a  is the
computer name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
computer name of the domain controller), on the     page, select the
' "     check box.
In the #  box, type a(where a  is the IP address of
the DNS server or nearest replica, from which the regional domain is delegated),
click , and then click r8.

No existing DNS No additional configuration is necessary.


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

2. From a command prompt, type  a


 
(where parent_domain is the fully qualified
domain name of the forest root domain).

3. From a command prompt, type  


  
a
 
(where
regional_domain is the fully qualified domain name of the regional domain).

4. From a command prompt, type  ? a 




  
a
 
(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 i s properly
configured.

&    ( &   R 


  
            
  

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.

" 1%#    &   R 


0  
R 0     &   
'(
     # ! !  # '-!  # 0'[0' '0&7! 

 a  SEA-NOAM-DC-01 MIL-EMEA-DC-01 REN-NOAM-DC-01

a  172.16.4.10 172.16.4.10 172.16.4.10

a   concorp.contoso.com concorp.contoso.com trccorp.treyresearch.net

    noam emea noam

&      &    0 9:

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.

           9.    


  

1. On  
?
 (where      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  


?
 (where      is the domain controller
in the regional domain), and then click R : .

3. Complete the R : .  by using the information supplied in Table 73. Accept the default
settings when no information is supplied.

" 1+#    &     &    0 9:

.    

:  Click      .

: R In the R box, type 9u   


(where      is the
name of the forest root domain).

- R  In the #  box, type u  a(where a  is the IP address

 of a forest root domain controller), and then click .
In the #  box, type ?
 a(where   a  is the IP
address of another forest root domain controller), and then click .

&    ( &           9.

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.

" 1#    &      & r 9 0    
&   

     # ! !  # '-!  # 0'[0' '0&7! 

     SEA-NOAM-DC-01 MIL-EMEA-DC-01 REN-NOAM-DC-01

     concorp.contoso.com concorp.contoso.com trccorp.treyresearch.net

a  172.16.16.21 172.16.132.17 172.16.20.13

  a  172.16.16.22 172.16.16.21 172.16.20.14

       &         

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.

              

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.

#   %

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.

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

    %                  

  

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

" 1/#    #    %     &     
0   

   
  ! 

Format partitions NTFS

Computer name ? a 


(where  a  is the computer name of the regional
domain controller).

IP address a(where a  is the fixed IP address that you assign to the regional
domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the regional
domain controller).

Administrator 
aá (where  a is any strong password).
password

Networking DNS
components Internet Protocol (TCP/IP)

Primary WINS a á


(where a   
is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of the
server existing secondary WINS server or leave blank if there is no existing WINS
infrastructure).

Preferred DNS au


(where a    
 is the IP address of this domain
server controller).

Alternate DNS  



(where    
 is the IP address of another DNS
server server that is connected through a minimum number of network segments).

&    ( #    %            
  

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

" 10#    #    %  &   '(

     # ! !  # '-!  # 0'[0' '0&7! 


 a  SEA-NOAM-DC-02 MIL-EMEA-DC-02 REN-NOAM-DC-02

a  172.16.12.28 172.16.132.18 172.16.12.25

"   255.255.252.0 255.255.252.0 255.255.252.0

a   
 172.16.12.15 172.16.132.15 172.16.20.15

    
 172.16.132.15 172.16.12.15 172.16.12.15

a    
 172.16.12.28 172.16.132.18 172.16.12.25

   


 172.16.16.21 172.16.132.17 172.16.20.13

# 
  

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.

  
                   

  

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.

" 11#    #  


    &   '(

.    

Domain Controller Click          (   .


Type

Network Credentials In the !   box, type 


(where   is the name of an
account that is a member of the domain admins global group.
In the   box, type aá (where a  is the password of the user
name).
In the   box, type 
  
.u   
(where
    is the fully qualified domain name of the regional domain and
     is the fully qualified domain name of the forest root domain).

Additional Domain Click )  .


Controller In the )     dialog box, click

  
.     (where     is the fully qualified
domain name of the regional domain and      is the fully qualified
domain name of the forest root domain), and then click r8.

Directory Services In the  and&    boxes, type 


aá (where
Restore Mode  a  is any strong password)
Administrator
Password

&    ( #  


            

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.

" 12#    #  


    &   '(

     # ! !  # '-!  # 0'[0' '0&7! 

     concorp.contoso.com concorp.contoso.com trccorp.treyresearch.net

     SEA-NOAM-DC-01 MIL-EMEA-DC-01 REN-NOAM-DC-01

  Administrator Administrator Administrator

a  B365-RoQ Pr23#N4h BbrO-64e

    noam emea noam


 a  H2Y74e#u Xy-ZZ-y- T#23-Rwp2

,  
  # 

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

 
 
                
      
  

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.

&    ( ,   


           
       

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

&  R 


0  
R 0  

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.

   R 
  
                
  
  

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

" 14#    &  R 


0  
R 0  

-   &   

Recursive name No additional configuration is necessary.


resolution by root When the DNS server specified as the Preferred DNS server during the
hints 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 ? a 
(where  a  is the
name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
name of the domain controller), on the 0 7  page, view the root hints.

Recursive name Forward unresolved queries to a, (where a  is the IP address
resolution by of the DNS server or nearest replica, from which the forest root domain is
forwarding 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 ? a 
(where  a  is the
computer name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
computer name of the domain controller), on the     page, select the
' "     check box.
In the #  box, type a(where a  is the IP address of
the DNS server or nearest replica, from which the forest ro ot domain is
delegated), click , and then click r8.

No existing DNS No additional configuration is necessary.


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

&    ( &   R 


  
          
  

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.

" 2#    &   R 


Recursive Name Resolution in the Contoso Example

     # ! !  # '-!  # 0'[0' '0&7! 

 a  SEA-NOAM-DC-02 MIL-EMEA-DC-02 REN-NOAM-DC-02

a  172.16.4.10 172.16.4.10 172.16.4.10

     concorp.contoso.com concorp.contoso.com trccorp.treyresearch.net

    noam emea noam

-   R      0   

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.

   R             


  

1. On u  ?(where     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 


  
(where     is the name of the
regional domain).

3. In the console tree, right-click 


  
(where     is the name of the regional
domain), and then click    .

4. In the 
  
    dialog box (where     is the name of the regional
domain), on the R 
 page, click .

5. In the R 0    0   dialog box, in the


  box, type

 ?
  
u   
(where    is the fully qualified name
of the regional domain controller, where     is the name of the regional domain, and
     is the name of the forest root domain).

6. In the R 0    0   dialog box, in the #  box, type a(where


a  is the IP address of the regional domain controller), click , and then click r8.

&    ( -   R         

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.

" 2#    -  R      &   '(

     # ! !  # '-!  # 0'[0' '0&7! 

    SEA-CON-DC-01 MIL-CON-DC-01 REN-TRC-DC-01

    noam emea noam

   SEA-NOAM-DC-02 MIL-EMEA-DC-02 REN-NOAM-DC-02


     concorp.contoso.com concorp.contoso.com trccorp.treyresearch.net

a  172.16.16.28 172.16.132.18 172.16.16.25

&      &    0 9:

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.

           9.    


  

1. On  
?
 (where      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  


?
 (where      is the domain controller
in the regional domain), and then click R : .

3. Complete the R : .  by using the information supplied in Table 82. Accept the default
settings when no information is supplied.

" 2%#    &     &    0 9:

.    

:  Click      .

: R In the R box, type 9u   


(where      is the
name of the forest root domain).

- R  In the #  box, type u  a(where a  is the IP address

 of a forest root domain controller), and then click .
In the #  box, type ?
 a(where   a  is the IP
address of another forest root domain controller), and then click .

&    ( &           9.

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.

" 2+#    &      & r 9 0    
&   

     # ! !  # '-!  # 0'[0' '0&7! 

     SEA-NOAM-DC-02 MIL-EMEA-DC-02 REN-NOAM-DC-02

     concorp.contoso.com concorp.contoso.com trccorp.treyresearch.net

a  172.16.16.21 172.16.132.17 172.16.20.13

  a  172.16.16.22 172.16.16.21 172.16.20.14

&   $       0  )    %   R
  &   

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 rConfiguring The Regional Domain
OU Structure For Administration.r

   )  

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.

           "    %   R
        
  
1. Create a user account in 
  
u   
(where     is the
name of the regional domain and      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.

" 2#    &  !   ! # $       
0 

   
  ! 

User name $"  

Description    ""          

Password aá (where a  is any password that meets the security requirements of
your organization).

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

" 2/#        *  *     $"  

'   $"  


! &  r   

Read all files and folders ==á


 ?=R'$rðrR (where  is the name of the
Windows 2000 domain controller in the regional domain).

Read, write, create, and delete ==á

?=0'$> (where  is the name of the Windows


files and folders 2000 domain controller in the regional domain).

3. Install the "   and "   ( tools on á


 ?(where  is the Windows 2000
domain controller in the regional domain) in a directory in the path statement.

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

4. Modify the "   script on á


 ?(where win2k_dc is a Windows 2000 domain controller in
the regional domain) using the information in Table 86.

" 20-    "    

&  $   

Set L-Destination=%1 Set L-Destination===á

?=0'$> (where  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- Robocopy %L-Source% %L-Destination% /E /PURGE


Destination% /E /PURGE

5. Complete the Scheduled Task Wizard on á


 ?(where  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.

" 21#    &      .  "  

.    


Click the program you want Windows Click )  .
to run. In the        dialog box, click
lbridge.cmd

Type a name for this task. Type 0 3$-0 0  ) 

Perform this task. Click .

Start time. Type  (where  is the time that you want the
replication to occur).

Enter the user name. Type $"  

Enter the password. Type aá (where a  is the password that
corresponds to the LbridgeAcct account).

Confirm the password. Type aá (where a  is the password that
corresponds to the LbridgeAcct account).

Open advanced properties for this task Enable check box.


when I click Finish.

The FRS - LMRepl Replication Bridge dialog box opens.

6. In the 0 3$-0 0  )  dialog box, on the   page, click 
  .

7. In the 
     r dialog box, click 0  .

8. In the 
     r dialog box, in the '
 box, type u 
?(where frequency
is how often you want the script to run).

9. In the 
     r dialog box, in the   box, type  
(where duration
is how long you want the script to run), and then click r8.

10. In the 0 3$-0 0  )  dialog box, on the   page, click r8.

&    ( &           "    % 
  R     

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.

" 22#    &      & r 9 0    
&   

     # ! !  # '-!  # 0'[0' '0&7! 

    noam emea noam

     concorp.contoso.com concorp.contoso.com trccorp.treyresearch.net

 SEA-USA-DC-01 MIL-EMA-DC-01 REN-TRE-DC-01

 SEA-NOAM-DC-01 MIL-EMEA-DC-01 REN-NOAM-DC-01

  Up98-65W wAl2t-WP kE-Fby41

 2:00 am 2:00 am 2:00 am

 &  2 hours 2 hours 2 hours

  3 hours 3 hours 3 hours

&    0    r!       
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

        r!         


  

1. Create the OU structure, shown in Figure 14, in 


  
u   
(where
    is the name of the regional domain and      is the name of the forest
root domain).

   r!    '0   


Create the following groups in the ??
 
=  OU (where    is the
name of the Windows NT 4.0 account domain):

a. ??
 
_ou_admins

b. ??
 
_users_admins

c. ??
 
_group_admins

d. ??
 
_computer_admins

R   In the groups that you create in this step, remember to substitute   with the name of
the Windows NT 4.0 account domain. For example, in the USA Windows NT 4.0 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 89 (where    is the name of the Windows NT 4.0 account domain).

" 24        r!  


ð 

      r )  &    r   r"< 

     ou_admins All

   \Users    _user_admins User

   \Service Accounts    _user_admins User

   \Groups    _group_admins Group

   \Computers    _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.
&    ( &        r!     

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

" 4#    &    0    r!  

     # ! !  # '-!  # 0'[0' '0&7! 

    noam emea noam

     concorp.contoso.com concorp.contoso.com trccorp.treyresearch.net

   USA EMA TREYRESEARCH

&   ,   0  

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.

          (   


  

1. On á

?(where  is any domain controller in the Windows NT 4.0 domain), start ! 
-     .

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

" 4'"   0  #    R  

  r
    

Account In the Trusted Domains and Trusting Domains boxes, add á


  
(where
  is the name of the regional domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

Resource In the Trusted Domains box, add á


  
(where   is the name
of the regional domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

3. On á
 ?(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.
" 4%'"   0  #    %  

  r
    

Account In the Trusted Domains and Trusting Domains boxes, add á

 
(where
  is the name of the Windows NT 4.0 account domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

Resource In the Trusting Domains box, add á

 
(where   is the name
of the Windows NT 4.0 account domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

&    ( &         (

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.

" 4+ 0             ? @

       '$'!   )r rR! 

  SEATTLE BOSTON

Domain type Resource Resource

 SEA-SEA-DC-01 BOS-BOS-DC-01

  USA USA

 SEA-NOAM-DC-01 SEA-NOAM-DC-01

a  N54-WeL8 N54-WeL8

" 4 0             ? %@

      &R!   ,R&r!,'0!   -rR0'$! 

  CANADA VANCOUVER MONTREAL

Domain type Account Resource Resource

 VAN-CAN-DC-01 VAN-VAN-DC-01 MON-MON-DC-01

  USA USA USA

 SEA-NOAM-DC-01 SEA-NOAM-DC-01 SEA-NOAM-DC-01

a  N54-WeL8 N54-WeL8 N54-WeL8

" 4/ 0              ? @

      -#$R!    ',#$$'! 

  MILAN SEVILLE

Domain type Resource Resource

 MIL-MIL-DC-01 SEV-SEV-DC-01

  EMEA EMEA

 MIL-EMEA-DC-01 MIL-EMEA-DC-01

a  N54-WeL8 N54-WeL8

" 40 0              ? %@
      )0#8-!   7rRð8rRð!   r8[r! 

  FABRIKAM HONGKONG TOKYO

Domain type Account Resource Resource

 HKG-FAB-DC-01 HKG-HKG-DC-01 TOK-TOK-DC-01

  EMEA EMEA EMEA

 MIL-EMEA-DC-01 MIL-EMEA-DC-01 MIL-EMEA-DC-01

a  N54-WeL8 N54-WeL8 N54-WeL8

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

      &    r   

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

             

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.

#   %

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.

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

    %              


  

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

" 41#    #    %     &     
0   

   
  ! 

Format partitions NTFS

Computer name ? a 


(where  a  is the computer name of the regional
domain controller).

IP address a(where a  is the fixed IP address that you assign to the regional
domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the regional
domain controller).

Administrator 
aá (where  a is any strong password).
password
Networking DNS
components Internet Protocol (TCP/IP)

Primary WINS a á


(where a   
is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of the
server existing secondary WINS server or leave blank if there is no existing WINS
infrastructure).

Preferred DNS au


(where a    
 is the IP address of this domain
server controller).

Alternate DNS  



(where    
 is the IP address of another DNS
server server that is connected through a minimum number of network segments).

&    ( #    %           

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.

" 42#    #    %        

     # )  !  # ,  


!  # -  ! 

 a  BOS-NOAM-DC-01 VAN-NOAM-DC-01 MON-NOMA-DC-01

a  172.16.56.13 172.16.48.36 172.16.20.51

"   255.255.252.0 255.255.252.0 255.255.252.0

a   
 172.16.12.15 172.16.48.15 172.16.48.15

    
 172.16.48.15 172.16.12.15 172.16.12.15

a    
 172.16.56.13 172.16.48.36 172.16.20.51

   


 172.16.12.16 172.16.12.16 172.16.48.36

" 44#    #    %         

     # 
 !  # 7 8  0!  #   ! 

 a  SEV-EMEA-DC-01 HKG-EMEA-DC-01 TOK-EMEA-DC-01

a  172.16.160.19 172.16.88.32 172.16.78.20

"   255.255.252.0 255.255.252.0 255.255.252.0

a   
 172.16.132.15 172.16.88.15 172.16.88.15

    
 172.16.12.15 172.16.12.15 172.16.88.15

a    
 172.16.160.19 172.16.88.32 172.16.78.20

   


 172.16.132.16 172.16.132.16 172.16.88.13

# 
  

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.

  
                   

  

Install Active Directory on the  


?
 (where      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.
" #    #  
       &  

.    

Domain Controller Click          (   .


Type

Network Credentials In the !   box, type 


(where   is the name of an
account that is a member of the domain admins global group.
In the   box, type aá (where a  is the password of the
user name).
In the   box, type 
  
.u   
(where
    is the name of the regional domain and      is
the name of the forest root domain).

Additional Domain Click )  .


Controller In the )     dialog box, click

  
.u   
(where     is the name of
the regional domain and      is the name of the forest root
domain), and then click r8.

Directory Services In the  and&    boxes, type 


aá (where
Restore Mode  a  is any strong password)
Administrator
Password

&    ( #  


            

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.

" #    #  


          

     # )  !  # ,  


!  # -  ! 

     BOS-NOAM-DC-01 VAN-NOAM-DC-01 MON-NOAM-DC-01

 SEA-NOAM-DC-01 SEA-NOAM-DC-01 SEA-NOAM-DC-01

     concorp.contoso.com concorp.contoso.com concorp.contoso.com

    noam noam noam

  Administrator Administrator Administrator

  B365-RoQ B365-RoQ B365-RoQ

 a  H2Y74e#u Xy-ZZ-y- T#23-Rwp2

" %#    #  


           

     # 
 !  # 7 8  0!  #   ! 

     SEV-EMEA-DC-01 HKG-EMEA-DC-01 TOK-EMEA-DC-01

 MIL-EMEA-DC-01 MIL-EMEA-DC-01 MIL-EMEA-DC-01

     concorp.contoso.com concorp.contoso.com concorp.contoso.com

    emea emea emea

  Administrator Administrator Administrator

  Pr23#N4h Pr23#N4h Pr23#N4h

 a  H2Y74e#u Xy-ZZ-y- T#23-Rwp2

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

 
 
                 

  

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.

&    ( ,   


           
   

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

&  R 


0  
R 0  

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.

   R 
  
                
  
  

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

" +#    &  R 


0  
R 0  

-   &   

Recursive name No additional configuration is necessary.


resolution by root When the DNS server specified as the Preferred DNS server during the
hints 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 ? a 
(where  a  is the
name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
name of the domain controller), on the 0 7  page, view the root hints.

Recursive name Forward unresolved queries to 


, (where  
 is the DNS server
resolution by or nearest replica, from which the forest root domain is delegated).
forwarding 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 ? a 
(where  a  is the
computer name of the domain controller), and then click    .
In the ? a 
    dialog box (where  a  is the
computer name of the domain controller), on the     page, select the
' "     check box.
In the #  box, type a(where a  is the IP address of
the DNS server or nearest replica, from which the forest root domain is
delegated), click , and then click r8

No existing DNS No additional configuration is necessary.


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

&    ( &   R 


  
          
    

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.

" #    0  


R 0           

     # )  !  # ,  


!  # -  ! 

 a  BOS-NOAM-DC-01 VAN-NOAM-DC-01 MON-NOAM-DC-01

a  172.16.4.10 172.16.4.10 172.16.4.10

     concorp.contoso.com concorp.contoso.com concorp.contoso.com

    noam noam noam

" /#    0  


R 0            

     # 
 !  # 7 8  0!  #   ! 

 a  SEV-EMEA-DC-01 HKG-EMEA-DC-01 TOK-EMEA-DC-01

a  172.16.4.10 172.16.4.10 172.16.4.10

     concorp.contoso.com concorp.contoso.com concorp.contoso.com

    emea emea emea

-   R      0   

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.

   R             


  

1. On  
?
 (where      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 


  
(where     is the name of the
regional domain).

3. In the console tree, right-click 


  
(where     is the name of the regional
domain), and then click    .

4. In the 
  
    dialog box (where     is the name of the regional
domain), on the R 
 page, click .

5. In the R 0    0   dialog box, in the


  box, type

 ?
  
u   
(where    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 R 0    0   dialog box, in the #  box, type a(where


ip_address is the IP address of the regional domain controller), click , and then click r8.

&    ( -   R         
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.

" 0#    0  


R 0           

     # )  !  # ,  


!  # -  ! 

    SEA-CON-DC-01 VAN-CON-DC-01 VAN-CON-DC-01

    noam noam noam

   BOS-NOAM-DC-01 VAN-NOAM-DC-01 MON-NOAM-DC-01

     concorp.contoso.com concorp.contoso.com concorp.contoso.com

a  172.16.4.10 172.16.4.10 172.16.4.10

" 1#    0  


R 0            

     # 
 !  # 7 8  0!  #   ! 

    MIL-CON-DC-01 HKG-CON-DC-01 HKG-CON-DC-01

    emea emea emea

   SEV-EMEA-DC-01 HKG-EMEA-DC-01 TOK-EMEA-DC-01

     concorp.contoso.com concorp.contoso.com concorp.contoso.com

a  172.16.4.10 172.16.4.10 172.16.4.10

&      &    0 9:

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.

           9.    


  

1. On  
?
 (where      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  


?
 (where      is the domain controller
in the regional domain), and then click R : .

3. Complete the R : .  by using the information supplied in Table 108. Accept the default
settings when no information is supplied.

" 2#    &     &    0 9:

.    

:  Click      .

: R In the R box, type 9u   


(where      is the
name of the forest root domain).

- R  In the #  box, type u  a(where a  is the IP address

 of a forest root domain controller), and then click .
In the #  box, type ?
 a(where   a  is the IP
address of another forest root domain controller), and then click .

&    ( &           9.

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.

" 4#       & r9        


     # )  !  # ,  
!  # -  ! 

     BOS-NOAM-DC-01 VAN-NOAM-DC-01 MON-NOAM-DC-01

     concorp.contoso.com concorp.contoso.com concorp.contoso.com

a  172.16.16.21 172.16.48.14 172.16.48.14

  a  172.16.16.22 172.16.16.21 172.16.16.21

" #       & r9         

     # 
 !  # 7 8  0!  #   ! 

     SEV-EMEA-DC-01 HKG-EMEA-DC-01 TOK-EMEA-DC-01

     concorp.contoso.com concorp.contoso.com concorp.contoso.com

a  172.16.132.17 172.16.88.13 172.16.88.13

  a  172.16.16.21 172.16.132.17 172.16.132.17

&        

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.

"   R  &   '

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.

 "   R                



  

1. Remove the following registry entry on á


 a  a(were a  a is the name of a
computer running Windows 2000 Professional) used to administer      (where
     is any domain controller with Windows NT 4.0 emulation enabled):

º    




 + Π

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

Π   



 Π

&    ( "   R             

The regional domain         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 a  a in the deployment process in the previous section with REN-TRE-W2KP-
01.

Substituting      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

&    0     0  R


- 

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

             


     
  

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 


  
zone (where 
  
is the name of
the regional domain), and then click    .

3. In the 
  
    dialog box (where 
  
is the name of the regional
domain), click &  -  .

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

5. In the 
  
    dialog box (where 
  
is the name of the regional
domain), click r8.

&    ( &             


  

Configure the regional domains to run in native mode in the Contoso example by substituting    
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

Top of page

0        

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

 3   

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

 3  

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.

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

-   !  


      0    

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.

'" "

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.

 "     R    

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.

0         R 3  


  

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.

 
!   0    

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.

    -         0    

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

!   

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

ð "ð 

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 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 th e user accounts and workstation accounts are in different
domains.

&   ,   0  

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.

          (   


  

1. On á

?(where  is any domain controller in the Windows NT 4.0 domain), start ! 
-     .

2. Create the trust relationships for the Windows NT 4.0 domains based on the process described in
Table 111.

" '"   0  #    R  

  r
    

Account In the Trusted Domains and Trusting Domains boxes, add á


  
(where
  is the name of the regional domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

Resource In the Trusted Domains box, add á


  
(where   is the name
of the regional domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

3. On á
 ?(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.

" %'"   0  #    %  

  
r    

Account In the     "  and     
boxes, add á

 
(where   is the name of the Windows NT 4.0
account domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

Resource In the      box, add á

 
(where
  is the name of the Windows NT 4.0 account domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

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

" + 0             ? @

       '$'!   )r rR! 

  SEATTLE BOSTON

Domain type Resource Resource

 SEA-SEA-DC-01 BOS-BOS-DC-01

  USA USA

 SEA-NOAM-DC-01 SEA-NOAM-DC-01

a  N54-WeL8 N54-WeL8

"  0             ? %@

      &R!   ,R&r!,'0!   -rR0'$! 

  CANADA VANCOUVER MONTREAL

Domain type Account Resource Resource

 VAN-CAN-DC-01 VAN-VAN-DC-01 MON-MON-DC-01

  USA USA USA

 SEA-NOAM-DC-01 SEA-NOAM-DC-01 SEA-NOAM-DC-01

a  N54-WeL8 N54-WeL8 N54-WeL8

" / 0              ? @

      -#$R!    ',#$$'! 

  MILAN SEVILLE

Domain type Resource Resource

 MIL-MIL-DC-01 SEV-SEV-DC-01

  emea emea

 MIL-EMEA-DC-01 MIL-EMEA-DC-01

a  N54-WeL8 N54-WeL8

" 0 0              ? %@

      )0#8-!   7rRð8rRð!   r8[r! 

  FABRIKAM HONGKONG TOKYO

Domain type Account Resource Resource

 HKG-FAB-DC-01 HKG-HKG-DC-01 TOK-TOK-DC-01

  emea Emea emea

 MIL-EMEA-DC-01 MIL-EMEA-DC-01 MIL-EMEA-DC-01

a  N54-WeL8 N54-WeL8 N54-WeL8


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

#   &   -

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.

R   ADMT requires that Windows NT 4.0 Service Pack 4 (or higher) be installed on the PDC in the source
domain.

     -

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.

&       -    

The first step in installing and configuring ADMT is to create an account used by ADMT for account domain
migration.

               


  

1. Create a user account in 


  
(where     is the fully qualified name of the
regional domain) by using the information in Table 117.

" 1#    &  !   ! # --  

   
  ! 

User name --  

Description    "-      

Password aá (where a  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 --   to the     group in 


  
(where

  
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 --   to the     group in ??


 
(where
??
 
is the name of the source account domain).

&    ( &           

Create an account domain migration account by using the deployment process described in the previous
section and the information in Table 118.

" 2#    &       -    

      &R!   )0#8-! 

   CANADA FABRIKAM

    noam.concorp.contoso.com emea.concorp.contoso.com


a  N78#87-k Ct34-N#2

&   $ !   -    

The next step in installing and configuring ADMT is to create an account used by ADMT for local user profile
migration.

                


  

1. Create a user account in 


  
(where     is the fully qualified name of the
regional domain) by using the information in Table 119.

" 4#    &  !   ! # --  

   
  ! 

User name -$  

Description    "-      

Password aá (where a  is any password that meets the security requirements of
your organization).

2. Add -$   to the     group in 


  
(where

  
is the name of the target regional domain).

3. Add -$   to the     group in ??


 
(where
??
 
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.

&    ( &           

Create a local user profile migration account by using the deployment process described in the previous section
and the information in Table 120.

" %#    &  $ !   -    

      &R!   )0#8-! 

   CANADA FABRIKAM

    noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2

# . -&  

The last step in installing and configuring ADMT is to initialize the ADMT configuration.

  . -      


  

1. On á
 ?
  
(where  is the computer name of a domain controller and
    is the fully qualified name of the target regional domain), log on as
--  with a password of aá (where a  is the password of
ADMTMigrationAcct).

2. On á
 ?
  
(where  is the computer name of a domain controller and
    is the fully qualified name of the target regional domain), install ADMT.

3. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select ð   -  . .
4. When prompted by the ð   -  . , use the information provided in Table
121 to complete the wizard. Accept default settings when no information is specified.

" %-   " "  ð   -  .  -

.    

Test or Make Select           A
Changes

Domain Selection In the     box, type  ? 


(where     is the
domain name of the Windows NT 4.0 account domain).
In the     box, type   
. (where   is the
fully qualified domain name of the Windows 2000 regional domain).

Group Selection Click 


In the  ð  dialog box, select all groups (except built-in groups), click
, and then click r8.

Organizational Unit Click )  .


Selection In the )   &  dialog box, navigate ! , and then click r8.

Group Options Select the -  ð  #     check box.
Click       .

User Account In the !   box, type --  


In the   box, type a  (where password is the password for
ADMTMigrationAcct)
In the   box, type   
. (where   is the fully
qualified domain name of the Windows 2000 regional domain).

Naming Conflicts Click #        B  .

The Migration Progress dialog box appears.

5. In the -     dialog box, click , $ .

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   $$$ (where    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:

÷ , ,, ,


,    -& '()&' !
"#"$
÷ The audit policy for account management is enabled in 
  
(   
is the fully qualified name of the target regional domain).

&    ( # . -  

Initialize ADMT configuration by using the deployment process described in the previous section and the
information in Table 122.

" %%#    # . -&  

      &R!   )0#8-! 

   CANADA FABRIKAM

    noam.concorp.contoso.com emea.concorp.contoso.com


a  U56-eR#w A#34-1w2

#  
   

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.

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

   
      
  

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

2. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select
   -  . .

3. When prompted by the


   -  . , use the information provided in Table
123 to complete the wizard. Accept default settings when no information is specified.

" %+# 


   "!  
   -  . 

.    

Domain In the     box, type  ? 


((where     is the name
Selection of the source domain).
In the     box, type   
((where    is the name
of the target domain).

Update Click [ *     .


Information

Service Account Click .


Selection In the  &   list box, select 
(where  
  is the
list of all servers that run applications by using service accounts), click , and then
click r8.

User Account In the !   box, type --  


In the Password box, type aá (where a  is the password for
ADMTMigrationAcct)
In the   box, type   
((where    is the name of the
target domain).

The Active Directory Migration Tool Agent Monitor dialog box appears.

4. In the 
  -    -  dialog box, on the   page, wait
until all computers have finished or failed.

5. In the 
  -    -  dialog box, on the
$ page, click
, $ .

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.

R   This process does not migrate the accounts but only identifies them for later migration.

&    ( #   


   

Identify the service accounts by using the deployment process described in the previous section and the
information in Table 124.
" %#    #   
     &   '(

      &R!   )0#8-! 

    CANADA FABRIKAM

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

   noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2

 
  VAN-VAN-FP-01 MIL-MIL-FP-01

-  ð "ð 

After you complete identification of service accounts, you are ready to migrate all global groups in the Windows
NT 4.0 account domain.

R  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

    "     R           
%    

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.

&    0    r!  

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

        r!         


  

1. Create the OU structure, shown in Figure 16, in 


  
u   
(where
    is the name of the regional domain and      is the name of the forest
root domain).

 0  r!    '0   


Create the following groups in the ??
 
=  OU (where    is the
name of the Windows NT 4.0 account domain):

a. ??
 
_ou_admins

b. ??
 
_users_admins

c. ??
 
_group_admins
d. ??
 
_computer_admins

R   In the groups that you create in this step, remember to substitute    with the
name of the Windows NT 4.0 account domain. For example, in the USA Windows NT 4.0 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    is the name of the Windows NT 4.0 account domain).

" %/        r!  


ð 

      r )  &    r   r"< 

        All

  '(       User

  ' 


         User

  '% a    a  Group

  ') a     a   Computer

&    ( &        r!     

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

" %0#    &    0    r!  

  # &R!  # )0#8-! 

    noam Emea

     concorp.contoso.com concorp.contoso.com

   Canada Fabrikam

-  ð "ð 

After configuring the regional domain OU structure, you are ready to migrate global groups from the Windows
NT 4.0 account domains.

     "    R       %  
     
  

1. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select ð   -  . .

2. When prompted by the ð   -  . , use the information provided in Table
127 to complete the wizard. Accept default settings when no information is specified.

" %1-   " "  ð   -  .  -

.    

Test or Make Select -  R A


Changes

Domain Selection In the     box, type  ? 


(where     is the
domain name of the Windows NT 4.0 account domain).
In the     box, type   
. (where   is the fully
qualified domain name of the Windows 2000 regional domain).

Group Selection Click 


In the  ð  dialog box, select all groups (except built-in groups), click
, and then click r8.

Organizational Unit Click )  .


Selection In the )   &  dialog box, navigate to  ? 
=ð 
(where     is the domain name of the Windows NT 4.0 account domain),
and then click r8.

Group Options Select the -  ð  #     check box.
Click       .

User Account In the !   box, type --  


In the   box, type a  (where password is the password for
ADMTMigrationAcct)
In the   box, type   
. (where   is the fully
qualified domain name of the Windows 2000 regional domain).

Naming Conflicts Click #        B  .

The Migration Progress dialog box appears.

3. In the -     dialog box, when  is &   , click , $ .

Notepad opens and displays the contents of the migration log. Review the migration log for any
errors.

4. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start the 
  !  &   console.

5. Navigate to  ? 
=ð  OU (where     is the domain name of the
Windows NT 4.0 account domain).

6. Verify global groups exist in the OU.

&    ( -   " 

Migrate all global groups by using the deployment process described in the previous section and the
information in Table 128.

" %2#    -  ð "ð   &   '(

      &R!   )0#8-! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    CANADA FABRIKAM

   noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2

    
    0    

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.

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

   
      
  

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

2. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select !   -  . .

3. When prompted by the !   -  . , use the information provided in Table 129
to complete the wizard. Accept default settings when no information is specified.

" %4-  


   )!  !   -  . # 
-

.    

Test or Make Click -  R A


Changes

Domain Selection In the     box, type  ? 


((where     is the
name of the source domain).
In the     box, type   
((where    is the
name of the target domain).

User Selection Click 


In the  !  dialog box, select  ???
(where  
  
are all the service accounts identified in a previous step), click , and then click
r8.

Organizational Unit Click )  .


Selection In the )   &  dialog box, navigate to  ? 
=
 
  (where     is the domain name of the Windows NT 4.0
account domain), and then click r8.

Password Options Click &  ( 


In the $      text box, type u 
(where  
is the filename of the file that contains the passwords).

Account Transition Click "      .


Options Select the -    #      check box

User Account In the !   box, type --  


In the   box, type aá (where a  is the password for
ADMTMigrationAcct)
In the   box, type   
((where    is the name of the
target domain).

User Options Select the !    check box.


Clear -       check box

Naming Conflicts Click 0      .

Service Account Select -  


      &-    
Information   .

The Migration Progress dialog box appears.


4. In the -     dialog box, when  is &   , click , $ .

Notepad opens and displays the contents of the migration log. Review the migration log for any
errors.

5. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start the 
  !  &   console.

6. Navigate to  ? 
=
    OU (where     is the domain name of
the Windows NT 4.0 account domain).

7. Verify service accounts exist in the OU.

&    ( -   


   

Migrate the service accounts by using the deployment process described in the previous section and the
information in Table 130.

" +#    -   


     &   '(

   &R!   )0#8-! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    CANADA FABRIKAM

   noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2

   C:\CanadaSvcPasswords C:\FabrikamSvcPasswords

!  
   -  
   

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

   
     
      
  

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

2. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select     . .

3. When prompted by the     . , use the information provided in Table 131 to
complete the wizard. Accept default settings when no information is specified.

" +!  


   -  
   " -

.    

Test or Make Select -  R A


Changes

Domain Selection In the     box, type  ? 


((where     is the
name of the source domain).
In the     box, type   
((where    is the
name of the target domain).
Computer Click 
Selection In the  &   dialog box, select (where  
 are all the
servers identified in a previous step), click , and then click r8.

Translate Objects Select $   !  

Security Select .


Translation Options

User Account In the !   box, type --  


In the   box, type aá (where a  is the password for
ADMTMigrationAcct)
In the   box, type   
((where    is the name of the
target domain).

The Migration Progress dialog box appears.

4. In the -     dialog box, when  is &   , click , $ .

Notepad opens and displays the contents of the migration log. Review the migration log for any
errors.

5. On (where  
 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.

&    ( !  


     
   

Update the services with the migrated service account by using the deployment process described in the
previous section and the information in Table 132.

" +%#    !  


   &   '(

   &R!   )0#8-! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    CANADA FABRIKAM

   noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2

      !  0    

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

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

R   Perform all user and group administration in the Windows NT 4.0 account domain until all users are
migrated.

&        

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.

                  


  

1. Create a user account in  ? 


(where     is the Windows NT 4.0 account
domain) by using the information in Table 133.

" ++   &  !         ! $ r

  ! 

User name -    

Description            

Password aá (where a  is any password that meets the security requirements of your
organization).

2. Add -     to    a(where global_group is the name of a global group


migrated in a previous step) in  ? 
(where     is the name of the Windows
NT 4.0 account domain).

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

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

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

This will create a local user profile on   a (where   a is the name of a computer running
Windows 2000 Professional or Windows NT 4.0 Workstation).

&    ( &              

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.

" +#    &       ! $ r     

      &R!   )0#8-! 

   CANADA FABRIKAM

a  a VAN-VAN-W2KP-01 HKG-HKG-NT4W-01

  6Y983-rT Q12#76hg

-   & ) !   


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.

     "     


  

1. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select !   -  . .

2. When prompted by the !   -  . , use the information provided in Table 135
to complete the wizard. Accept default settings when no information is specified.

" +/   -  !   )! -

.    

Test or Make Click -  R A


Changes

Domain Selection In the     box, type  ? 


((where     is the
name of the source domain).
In the     box, type   
((where    is the
name of the target domain).

User Selection Click 


In the  !  dialog box, select ??
(where    are all
the user accounts included in the current batch), click , and then click r8.

Organizational Unit Click )  .


Selection In the )   &  dialog box, navigate to  ? 
=! 
(where     is the domain name of the Windows NT 4.0 account domain),
and then click r8.

Password Options Click &  ( 


In the $      text box, type u 
(where
  is the filename of the file that contains the passwords).

Account Transition Click $ 


"     .
Options Select the        (  check box.
In the        (  text box, type
(where
   is the number of days until the account expires in the Windows NT 4.0
account domain).
Select the -    #      check box

User Account In the !   box, type --  


In the Password box, type aá (where a  is the password for
ADMTMigrationAcct)
In the   box, type   
((where    is the name of the
target domain).

User Options Select the         check box.
Select the !    check box.
Clear -       check box

Naming Conflicts Click 0      .

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 á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start the Active Directory Users and Computers console.

5. Navigate to  ? 
\Users OU (where     is the domain name of the Windows NT
4.0 account domain).
6. Verify the batch user accounts exist in the OU.

&    ( -      

Migrate the service accounts by using the deployment process described in the previous section and the
information in Table 130.

" +0#    -   !     &   '(

   &R!   )0#8-! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    CANADA FABRIKAM

   noam.concorp.contoso.com emea.concorp.contoso.com

   7 7

a  U56-eR#w A#34-1w2

   C:\CanadaSvcPasswords C:\FabrikamSvcPasswords

-  $ !   

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.

" +1-  ! )r  .  -  !   

-       -  0 C  

Roaming User profiles are centrally stored on Migrated as an option during the user account
profiles servers. The user's profile is available to migration. No additional steps are required.
the user, regardless of the workstation
being used.

Local profiles User profiles are centrally locally on the Migrated as a separate process from the user
workstation. When a user logs on to account migration. Migrate local user profiles
another workstation, a unique local user for a batch of users immediately after
profile is created. migrating the batch of users.

Do not User profiles, roaming or local, are Because the user profiles are unimportant to
manage user considered unimportant by the the organization, no migration is required.
profiles organization.

   )  

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.

          


  

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

2. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select     . .

3. When prompted by the     . , use the information provided in Table 138 to
complete the wizard. Accept default settings when no information is specified.

" +2-   $ !   " -


.    

Test or Make Select -  R A


Changes

Domain Selection In the     box, type  ? 


((where     is the
name of the source domain).
In the     box, type   
((where    is the name
of the target domain).

Computer Click 


Selection In the  &   dialog box, select   a(where   a is the name of
a computer running Windows NT 4.0 Workstation), click , and then click r8.

Translate Objects Select !   

Security Select .


Translation
Options

User Account In the !   box, type --  


In the   box, type aá (where a  is the password for
ADMTMigrationAcct)
In the   box, type   
((where    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   a(where   a 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.

&    ( -      

Migrate the local user profile permissions by using the de ployment process described in the previous section
and the information in Table 139.

" +4#    !  $ !     

   &R!   )0#8-! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    CANADA FABRIKAM

   noam.concorp.contoso.com emea.concorp.contoso.com

  a VAN-VAN-NT4W-01 MIL-MIL-NT4W-01

a  U56-eR#w A#34-1w2

0 3  ð "ð 

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.

  3    "    R       %  
     
  

1. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select ð   -  . .
2. When prompted by the ð   -  . , use the information provided in Table
140 to complete the wizard. Accept default settings when no information is specified.

" 0 3  ð "ð "  ð   -  . 

.    

Test or Make Select -  R A


Changes

Domain Selection In the     box, type  ? 


(where     is the
domain name of the Windows NT 4.0 account domain).
In the     box, type   
. (where   is the fully
qualified domain name of the Windows 2000 regional domain).

Group Selection Click 


In the  ð  dialog box, select all groups (except built-in groups), click
, and then click r8.

Organizational Unit Click )  .


Selection In the )   &  dialog box, navigate to  ? 
=ð 
(where     is the domain name of the Windows NT 4.0 account domain),
and then click r8.

Group Options Select the -  ð  #     check box.
Click       .

User Account In the !   box, type --  


In the   box, type a  (where password is the password for
ADMTMigrationAcct)
In the   box, type   
. (where   is the fully
qualified domain name of the Windows 2000 regional domain).

Naming Conflicts Click 0      .

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 á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start the Active Directory Users and Computers console.

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

6. Verify that any new global groups exist in the OU.

&    ( -   " 

Re-migrate all global groups by using the deployment process described in the previous section and the
information in Table 141.

" #    0 3  ð "ð   &   '(

      &R!   )0#8-! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    CANADA FABRIKAM

   noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2


R  !  $ r      

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.

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.

               


  

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.

&    ( R           

Users were manually notified that their account was migrated and given their new password.

0 3  ð "ð 

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.

  3    "    R       %  
     
  

1. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select ð   -  . .

2. When prompted by the ð   -  . , use the information provided in Table
142 to complete the wizard. Accept default settings when no information is specified.

" %0 3  ð "ð "  ð   -  . 

.    

Test or Make Select -  R A


Changes

Domain Selection In the     box, type  ? 


(where     is the
domain name of the Windows NT 4.0 account domain).
In the     box, type   
. (where   is the fully
qualified domain name of the Windows 2000 regional domain).

Group Selection Click 


In the  ð  dialog box, select all groups (except built-in groups), click
, and then click r8.

Organizational Unit Click )  .


Selection In the )   &  dialog box, navigate to  ? 
=ð 
(where     is the domain name of the Windows NT 4.0 account domain),
and then click r8.

Group Options Select the -  ð  #     check box.
Click       .

User Account In the !   box, type --  


In the   box, type a  (where password is the password for
ADMTMigrationAcct)
In the   box, type   
. (where   is the fully
qualified domain name of the Windows 2000 regional domain).

Naming Conflicts Click 0      .

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 á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start the 
  !  &   console.

5. Navigate to  ? 
=ð  OU (where     is the domain name of the
Windows NT 4.0 account domain).

6. Verify that any new global groups exist in the OU.

&    ( -   " 

Migrate all global groups by using the deployment process described in the previous section and the
information in Table 143.

" +#    -  ð "ð   &   '(

      &R!   )0#8-! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    CANADA FABRIKAM

   noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2

&       0    

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 rRestructuring Resource
Domainsr section later in this document.

Top of page

0    0      

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

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.

    -     0      0    

Carefully plan for administration and management of the following aspects of resource account migration:

÷ Workstations

÷ Resources on member servers

÷ Resources on domain controllers

-     - " 




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.

-    &   

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

&   ,   0  

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.

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

    
      
  

1. On á

?(where  is any domain controller in the Windows NT 4.0 domain), start ! 
-     .

2. Create the trust relationships for the Windows NT 4.0 domains based on the process described in
Table 144.

" '"   0  #    R  

  r
    

Account In the Trusted Domains and Trusting Domains boxes, add á


  
(where
  is the name of the regional domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

Resource In the Trusted Domains box, add á


  
(where   is the name
of the regional domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

3. On á
 ?(where _ is any domain controller in the regional domain), start an instance of
the Microsoft Management Console (MMC) and include the Active Directory Domai ns and Trusts snap-
in.

4. Create the trust relationships between the Windows NT 4.0 domains based on the process described in
Table 145.

" /'"   0  #    %  

    
r  

Account In the     "  and     
boxes, add á

 
(where   is the name of the Windows NT 4.0
account domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

Resource In the      box, add á

 
(where
  is the name of the Windows NT 4.0 account domain).
In the   and &    boxes, type  aá (where
a  is the password used to establish the trust relationship).

&    ( &   


    

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.

" 0 0             ? @

       '$'!   )r rR! 

  SEATTLE BOSTON

Domain type Resource Resource

 SEA-SEA-DC-01 BOS-BOS-DC-01

  USA USA

 SEA-NOAM-DC-01 SEA-NOAM-DC-01

a  N54-WeL8 N54-WeL8

" 1 0             ? %@

      &R!   ,R&r!,'0!   -rR0'$! 

  CANADA VANCOUVER MONTREAL

Domain type Account Resource Resource

 VAN-CAN-DC-01 VAN-VAN-DC-01 MON-MON-DC-01

  USA USA USA

 SEA-NOAM-DC-01 SEA-NOAM-DC-01 SEA-NOAM-DC-01

a  N54-WeL8 N54-WeL8 N54-WeL8

" 2 0              ? @

      -#$R!    ',#$$'! 

  MILAN SEVILLE

Domain type Resource Resource

 MIL-MIL-DC-01 SEV-SEV-DC-01

  emea emea

 MIL-EMEA-DC-01 MIL-EMEA-DC-01

a  N54-WeL8 N54-WeL8

" 4 0              ? %@
      )0#8-!   7rRð8rRð!   r8[r! 

  FABRIKAM HONGKONG TOKYO

Domain type Account Resource Resource

 HKG-FAB-DC-01 HKG-HKG-DC-01 TOK-TOK-DC-01

  emea Emea emea

 MIL-EMEA-DC-01 MIL-EMEA-DC-01 MIL-EMEA-DC-01

a  N54-WeL8 N54-WeL8 N54-WeL8

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

&  0      -    

The next step in installing and configuring ADMT is to create an account used by ADMT for local user profile
migration.

                


  

1. Create a user account in  ? 


(where      is the name of the resource
domain) by using the information in Table 150.

" /#    &  !   ! # --  

   
  ! 

User name -0    

Description    "-        

Password aá (where a  is any password that meets the security requirements of
your organization).

2. Add -0     to the     group in 


  
(where

  
is the name of the target regional domain).

3. Add -0     to the     group in  ? 


(where
 ? 
is the name of the source resource domain).

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

&    ( &           

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.

" /#    &   ,  


0      -    

      

     VANCOUVER

    noam.concorp.contoso.com

a  A#34-1w2

" /%"#    &   -  0      -    
      

     MONTREAL

    noam.concorp.contoso.com

a  A#34-1w2

" /+#    &   7 8  00      -    

      

     HONGKONG

    emea.concorp.contoso.com

a  A#34-1w2

" /#    &     0      -    

      

     TOKYO

    emea.concorp.contoso.com

a  A#34-1w2

" // #    &   " 0      -    

      

     FABRIKAM

    emea.concorp.contoso.com

a  A#34-1w2

&    0    r!   

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

        r!         


  

1. Create the OU structure, shown in Figure 14, in 


  
u   
(where
    is the name of the regional domain and      is the name of the forest
root domain).

 20    r!    '0   


2. Create the  ? 
_ou_admins group in the  ? 
=  OU (where
     is the name of the Windows NT 4.0 resource domain):

R   In the groups that you create in this step, remember to substitute      with the
name of the Windows NT 4.0 resource domain. For example, in the VANCOUVER Windows NT 4.0
resouce domain      _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 informa tion
described in Table 156(where      is the name of the Windows NT 4.0 resourcce
domain).

" /0        r!  


ð 

      r )  &    r   r"< 

     resource_domain _ou_admins All

&    ( &        r!     

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.

" /10    r!           ? @

       '$'!   )r rR! 

    noam noam

     concorp.contoso.com concorp.contoso.com

     Seattle Boston

" /20    r!           ? %@

      ,R&r!,'0!   -rR0'$! 

    noam noam

     concorp.contoso.com concorp.contoso.com

     Vancouver Montreal

" /40    r!            ? @

      - !   


 ! 

    emea emea

     concorp.contoso.com concorp.contoso.com

     Milan Seville

" 00    r!            ? %@

      7 8  0!     ! 

    emea emea

     concorp.contoso.com concorp.contoso.com

     HongKong Tokyo

#  
   

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.

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

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  ? 


.

3. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), logon with the ADMTMigrationAcct, start -* and select
   -  
. .

4. When prompted by the


   -  . , use the information provided in Table
161 to complete the wizard. Accept default settings when no information is specified.

" 0# 


   "!  
   -  . 

.    

Domain In the     box, type  ? 


((where     is the name
Selection of the resource domain).
In the     box, type   
((where    is the name
of the regional domain).

Update Clcik [ *     .


Information

Service Account Click .


Selection In the  &   list box, select 
(where  
  is the
list of all servers that run applications by using service accounts), click , and then
click r8.

User Account In the !   box, type -0    


In the Password box, type aá (where a  is the password for
ADMTResourceAcct)
In the   box, type  ? 
((where     is the name of the
resource domain).

The Active Directory Migration Tool Agent Monitor dialog box appears.

5. In the 
  -    -  dialog box, on the   page, wait till
all computers have finished or failed.

6. In the 
  -    -  dialog box, on the
$ page, click
, $ .

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.

R   This process does not migrate the accounts but only identifies them for later migration.

&    ( #   


   

Identify the service accounts by using the deployment process described in the previous section and the
information Table 162.

" 0%#    #   


     &   '(

      ,  


!   - ! 

    VANCOUVER MILAN

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

   noam.concorp.contoso.com emea.concorp.contoso.com


a  U56-eR#w A#34-1w2

 
  VAN-VAN-FP-01 MIL-MIL-FP-01

    
    0    

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.

-  
   

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 us e the migrated service
account instead of the service account in the Windows NT 4.0 source domain.

   
      
  

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

2. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select !   -  . .

3. When prompted by the !   -  . , use the information provided in Table 163
to complete the wizard. Accept default settings when no information is specified.

" 0+-  


   )!  !   -  . # 
-

.    

Test or Make Click -  R A


Changes

Domain Selection In the     box, type  ? 


((where     is the
name of the source domain).
In the     box, type   
((where    is the
name of the target domain).

User Selection Click 


In the  !  dialog box, select  ???
(where  
  
are all the service accounts identified in a previous step), click , and then click
r8.

Organizational Unit Click )  .


Selection In the )   &  dialog box, navigate to  ? 
=
 
  (where     is the domain name of the Windows NT 4.0
account domain), and then click r8.

Password Options Click &  ( 


In the $      text box, type u 
(where  
is the filename of the file that contains the passwords).

Account Transition Click "      .


Options Select the -    #      check box

User Account In the !   box, type -0    


In the   box, type aá (where a  is the password for
ADMTResourceAcct)
In the   box, type   
((where    is the name of the
target domain).

User Options Select the !    check box.


Clear -       check box

Naming Conflicts Click 0      .

Service Account Select -  


      &-    
Information   .

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 á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start the 
  !  &   console.

6. Navigate to  ? 
=
    OU (where     is the domain name of
the Windows NT 4.0 resource domain).

7. Verify service accounts exist in the OU.

&    ( -   


   

Migrate the service accounts by using the deployment process described in the previous section and the
information in Table 164.

" 0#    -   


     &   '(

   ,  
!   - ! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    VANCOUVER MILAN

   noam.concorp.contoso.com emea.concorp.contoso.com

 $( VANCOUVER MILAN

   C:\VancouverSvcPasswords C:\MilanSvcPasswords

  -0     -0    

a  U56-eR#w A#34-1w2

  VANCOUVER MILAN

!  
   -  
   

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

   
     
      
  

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

2. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select     . .

3. When prompted by the     . , use the information provided in Table 165 to
complete the wizard. Accept default settings when no information is specified.

" 0/!  


   -  
   " -

.    

Test or Make Select -  R A


Changes

Domain Selection In the     box, type  ? 


((where     is the
name of the source domain).
In the     box, type   
((where    is the name
of the target domain).

Computer Click 


Selection In the  &   dialog box, select (where  
 are all the
servers identified in a previous step), click , and then click r8.

Translate Objects Select $   !  

Security Select .


Translation Options

User Account In the !   box, type -0    


In the   box, type aá (where a  is the password for
ADMTResourceAcct)
In the   box, type   
((where    is the name of the
target domain).

The Migration Progress dialog box appears.

4. In the -     dialog box, when  is &   , click , $ .

Notepad opens and displays the contents of the migration log. Review the migration log for any
errors.

5. On (where  
 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.

&    ( !  


     
   

Update the services with the migrated service account by using the deployment process described in the
previous section and the information in Table 166

" 00#    !  


   &   '(

   ,  
!   - ! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    VANCOUVER MILAN

   noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2


-    R   - " 


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.

R   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 t he workstation to restart immediately or
as soon as possible.

     R    " 


   
  

1. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), logon with the -0    , start -* and select &  -  . .

2. When prompted by the &  -  . , use the information provided in Table 167 to
complete the wizard. Accept default settings when no information is specified.

" 01-     - " 


" -

.    

Test or Make Select -  R A


Changes

Domain Selection In the     box, type  ? 


((where     is the
name of the source domain).
In the     box, type   
((where    is the
name of the target domain).

Computer Selection Click 


In the  &   dialog box, select ? a (where  a  are all
the workstations and member servers in the resource domain), click , and then
click r8.

Organizational Unit Click )  .


Selection In the )   &  dialog box, navigate to  ? 

=&  (where    is the domain name of the Windows NT 4.0
resource domain), and then click r8.

Service Account Select $   !  


Selection

Transferable Select .


Objects

User Account In the !   box, type -0    


In the   box, type aá (where a  is the password for
ADMTResourceAcct)
In the   box, type   
((where    is the name of the
target domain).

Computer Options In the -  "        .    , select 

Naming Conflicts Select #       B  

The Migration Progress dialog box appears.

3. In the -     dialog box, when  is &   , click , $ .

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

This starts the installation of the migration agents

5. In the 
  -    -  dialog monitor the status of the agents.
When the status of all agents is   , click , $ 

Notepad opens and displays the contents of the Dispatch log. Review the Dispatch log for any errors.

6. On ? a (where  a  are all the workstations and member servers in the resource
domain), verify that the computers show up in the appropriate OU.

&    ( -    R    " 


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.

" 02#    !  


   &   '(

   ,  
!   - ! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    VANCOUVER MILAN

   noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2

-    R  &   

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.

 
   R           

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.

       R     

1. Migrate the shared local groups in the domain.

2. Migrate the Windows NT 4.0 domain controller to the Windows 2000 regional domain.

-    $ ð 

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.

         


  

1. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start -* and select ð   -  . .

2. When prompted by the ð   -  . , use the information provided in Table
169 to complete the wizard. Accept default settings when no information is specified.

" 04-    ð "ð " -


.    

Test or Make Select -  R A


Changes

Domain Selection In the     box, type  ? 


(where     is the
domain name of the Windows NT 4.0 resource domain).
In the     box, type   
(where    is the fully
qualified domain name of the Windows 2000 regional domain).

Group Selection Click 


In the  ð  dialog box, select all shared local groups, click , and then
click r8.

Organizational Unit Click )  .


Selection In the )   &  dialog box, navigate to  ? 
(where
    is the domain name of the Windows NT 4.0 resource domain), and
then click r8.

Group Options Select the -  ð  #     check box.
Click       .

User Account In the !   box, type -0    


In the   box, type a  (where password is the password for
ADMTResourceAcct)
In the   box, type   
. (where   is the fully
qualified domain name of the Windows 2000 regional domain).

Naming Conflicts Click #        B  .

The Migration Progress dialog box appears.

3. In the -     dialog box, when  is &   , click , $ .

Notepad opens and displays the contents of the migration log. Review the migration log for any
errors.

4. On á
 ?(where  is the name of a Windows 2000 domain controller in the regional
domain), start the 
  !  &   console.

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

6. Verify global groups exist in the OU.

&    ( -     

Migrate all shared local groups by using the deployment process described in the previous section and the
information in Table 170.

" 1#    -    ð "ð   &   '(

      ,  


!   - ! 

 VAN-NOAM-DC-01 MIL-EMEA-DC-01

    CANADA FABRIKAM

   noam.concorp.contoso.com emea.concorp.contoso.com

a  U56-eR#w A#34-1w2

-    R  &      %0    

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.

     R        %       

  

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

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

3. Ugrade  
?
 (where      is the computer name of the domain controller)
to Windows 2000 by using the information listed in Table 171.

" 1#    #    %    &  

 
    ! 

Convert NTFS
partitions

Computer name  
?
 (where      is the computer name of the domain
controller).

IP address a(where a  is the fixed IP address that you assign to the first
regional domain controller).

Subnet mask  
 (where "  is the subnet mask that you assign to the first
regional domain controller).

Networking DNSInternet Protocol (TCP/IP)


components

Primary WINS a á


(where primary_wins_server is the IP address of the existing
server primary WINS server or leave blank if there is no existing WINS infrastructure).

Secondary WINS ?


á
(where     
is the IP address of the
server existing primary WINS server or leave blank if there is no existing WINS
infrastructure).

Preferred DNS au


(where a    
 is the IP address of this domain
server controller).

Alternate DNS  



(where    
 is the IP address of another DNS
server server that is connected through a minimum number of network segments).

4. Install Active Directory on the  


?
 (where      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.

" 1%#    #  


      &  

.    

Domain Controller Type Click          .

Create Tree or Child Domain Verify that &      is selected.

Create of Join Forest Verify that &         is selected.

New Domain Name In the R       box, type  


Configure DNS Click [ *    R    .

Permissions Click    "     %


.

Directory Services Restore Mode In the   &    boxes, type
Administrator Password 
aá (where  a  is any strong password)

R   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  
?
 (where      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.

" 1+#    #  


      &  

.    

Remove Active Select the This           check box.
Directory

Network In the !   box, type 


(where   is the name of an
Credentials account that has administrator access).
In the   box, type aá (where a  is the password for the
account).

Administrator In the   and &    boxes, type 


á (where
Password  a  is the password for the an administrator account).

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

7. Join  
?
 (where      is the name of the domain controller) to
regional_domain (where regional_domain is the name of the Windows 2000 regional domain).

8. Join  
?
 (where      is the name of the domain controller) to

  
(where     is the name of the Windows 2000 regional domain).

9. Move  
?
 (where      is the name of the domain controller) from the
&  container in     to the 
  
=&   (where
    is the name of the Windows 2000 regional domain) by using Active Directory Users
and Computers snap-in.

&    ( -    R        %    

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.

" 1#    -     %0    

     # ,  


!  # - ! 

 a  VAN-VAN-DC-02 MIL-MIL-DC-02

a  172.16.48.12 172.16.132.22

"   255.255.252.0 255.255.252.0

a   
 172.16.48.15 172.16.132.15

    
 172.16.12.15 172.16.12.15
a    
 172.16.48.12 172.16.132.22

   


 172.16.48.14 172.16132.17

     VAN-VAN-DC-02 MIL-MIL-DC-02

 a  Xy-ZZ-y- T#23-Rwp2

Top of page

       R   

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.

 40  r       R  #     
  
R   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.

       R    

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.

Top of page

#      r    

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.
 % #      r    r #     
  
           

÷ Import accounts into the regional domain.

÷ Import data into the regional domain

#         

         

1. Create OU structure in the target domain.

2. Export account information.

3. Import account information.

4. Verify user account migration.

&    0    r!  

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

        r!         


  

1. Create the OU structure, shown in Figure 21, in 


  
u   
(where
    is the name of the regional domain and      is the name of the forest
root domain).
 %  r!    '0   
Create the following groups in the ??
=  OU (where   is the name of the
organizational unit you are using to import your existing accounts):

a. ??
_ou_admins

b. ??
_users_admins

c. ??
_group_admins

d. ??
_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    is the name of the Windows NT 4.0 account domain).

" 1/        r!  


ð 

      r )  &    r   r"< 

        All

  '(       User

  ' 


         User

  '% a    a  Group

  ') a     a   Computer

'(    #  

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.

  (       

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.

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

#    #  

After exporting the user account information, you are ready 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   
    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.

,    - 

After importing the accounts into their target OUs, you are ready to verify the migratio n of the user accounts.

 
       

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.

#       

After verifying the migration of user accounts, you are ready 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.

#  - " 


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.

&       - " 


After installing member servers, create sh ared folders on the member servers.

         " 




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

     - " 

After creating resources on member servers, you need 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

'" !       

After transferring data from existing location to member servers, establish user access to resources.

  "       

1. Establish share permissions.

2. Establish NTFS permissions.

R   To assign permissions to a user, you can assign permissions to groups and make the user a member of
the appropriate group.

,  !       

After establishing user access to resources, 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.

    

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

Anda mungkin juga menyukai