Upgrading Windows NT 4

C H A P T E R 8
Upgrading
Windows NT 4.0
Domains to
Windows Server 2003
Active Directory
Upgrading your domains from Microsoft® Windows NT® 4.0 to Windows® Server 2003 Active Directory®
directory service enables your organization to improve the security and scalability of your network
infrastructure while reducing administrative overhead. As an alternative to restructuring Windows NT 4.0
domains, the in-place upgrade is an efficient, time-saving process that minimizes the effect on the
Windows NT 4.0 production environment.
In This Chapter
Overview of Upgrading Windows NT 4.0 Domains.......................................... .....288
Collecting Design Information........................................................ .....................295
Completing Pre-Upgrade Tasks.................................................................... ........310
Upgrading Domains from Windows NT 4.0 to Windows Server 2003
Active Directory................................................................... ...............................312
Completing Post-Upgrade Tasks.................................................... ......................349
Additional Resources.............................................................................. .............353
Related Information
• For more information about restructuring domains when upgrading from Windows NT 4.0 to
Windows Server 2003, see “Restructuring Windows NT 4.0 Domains to an Active Directory
Forest” in this book.
• For more information about the Active Directory logical structure, see "Designing the Active
Directory Logical Structure" in this book.
• For more information about Windows Server 2003 Active Directory Functional Levels, see
“Enabling Advanced Windows Server 2003 Active Directory Features” in this book.
• For more information about Active Directory site topology, see "Designing the Site Topology"
in this book.
32 Chapter 8 Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory
Overview of Upgrading
Windows NT 4.0 Domains
Upgrading your Windows NT 4.0 domains to the Microsoft® Windows® Server 2003, Standard Edition and
Windows® Server 2003, Enterprise Edition operating systems enables you to simplify and reduce network
administration. Windows Server 2003 Active Directory integrates with other applications and services and
allows you to delegate administrative responsibility at the appropriate level when you have multiple
organizations existing in a single domain structure.
When you upgrade your Windows NT 4.0 domains to Windows Server 2003 Active Directory, you improve
scalability because Active Directory domains can scale to meet the needs of your organization. You also gain
new capabilities by using Group Policy, and you gain more flexibility for business units.
In addition, performing an in-place upgrade of Windows NT 4.0 domains to Windows Server 2003 Active
Directory has no adverse effect on your Windows NT 4.0 production environment. There are fewer
administrative complexities than with restructuring your environment, such as maintaining access to shared
directories, files, and printers. Groups and group memberships are retained. You do not need to migrate local
profiles, and you retain the existing passwords and profiles for domain users.
Before planning and implementing Windows NT 4.0 in-place upgrades, ensure that your organization has
already:
• Designed the Active Directory logical structure of the forest and Domain Name System (DNS)
for your Active Directory environment.
• Designed a site topology to efficiently locate domain controllers.
• Deployed a Windows Server 2003 forest root domain if that is the upgrade path that your
organization has decided on. For more information about the paths for in-place upgrading a
Windows NT 4.0 environment, see “Upgrading Domains from Windows NT 4.0 to Windows
Server 2003 Active Directory” later in this chapter.
After completing the in-place upgrade process, you can perform an in-place upgrade for any remaining
Windows NT domains or restructure them into your new Windows Server 2003 forest. For information about
restructuring Windows NT 4.0 domains to a Windows Server 2003 forest, see "Restructuring Windows NT 4.0
Domains to an Active Directory Forest" in this book.
Note
For a list of the job aids that are available to assist you in upgrading
your Windows NT 4.0 domains to Windows Server 2003 Active
Directory, see “Additional Resources” later in this chapter.
Overview of Upgrading Windows NT 4.0 Domains 33
Process for Upgrading Windows NT 4.0

Domains to Windows Server 2003 Active
Directory
Upgrading your Windows NT 4.0 domains to Windows Server 2003 Active Directory involves first completing
the necessary preparation tasks and then following the steps to complete the upgrade. Figure 8.1 shows the
process for upgrading Windows NT 4.0 domains to Windows Server 2003 Active Directory.
Figure 8.1 Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory
Background Information for Upgrading to

Windows Server 2003 Active Directory
Before you begin the Windows NT 4.0 in-place domain upgrade, become familiar with some important issues
that affect the upgrade process.
PDC Offline Operations

During the process of upgrading the operating system on the primary domain controller (PDC) from
Windows NT 4.0 to Windows Server 2003 and installing Active Directory, client operations such as logon and
resource access will continue to function because these services are provided by backup domain controllers.
However, because the PDC will be offline during most phases of the upgrade process, typically between one and
three hours, operations that require data to be written to the domain will not succeed. For example, users will
not be able to change their passwords and administrators will not be able to create, delete, or unlock user
accounts. Administrative tools, such as User Manager for Domains or Server Manager, can be used only in read-
only mode on backup domain controllers in the domain. In addition, you will not be able to create new objects,
such as users and groups, while the PDC is offline.
Full Synchronization of the Local Security Authority Database

After upgrading a Windows NT 4.0 PDC, or after transferring the PDC role to another domain controller, the
LSA will perform a single full synchronization of all objects in the database. This synchronization causes events
to be logged in Event Viewer; specifically, Event Viewer in Windows Server 2003 will log Event ID 5713 and
Event Viewer in Windows NT 4.0 will log Event ID 5717. However, the LSA database contains relatively few
objects and the full synchronization does not affect network performance.
Do not confuse the full synchronization of the LSA database with a backup domain controller (BDC) full
synchronization. A BDC full synchronization typically happens when too many changes occur on a PDC before
the PDC can replicate the changes to a BDC. The number of objects that are replicated during a BDC full
synchronization and the amount of network traffic that is generated depends on the number of users, groups, and
workstations in the domain.
Domain Users and Client Workstation Operating Systems

When Microsoft® Windows® 2000, Microsoft® Windows® XP, and Windows Server 2003 clients attempt to
authenticate with a domain controller, they first retrieve a list of domain controllers from either DNS or WINS,
and will then authenticate with the first domain controller that responds to their authentication request. The first
domain controller to respond is usually a domain controller located closest to the client. The client and the
domain controller will then negotiate which authentication protocol to use.
When Windows 2000, Windows XP, and Windows Server 2003 clients are members of a Windows NT 4.0
domain, they will only use the NTLM protocol to authenticate because that is the only authentication protocol
supported by Windows NT 4.0. Windows 2000 and Windows Server 2003 domain controllers are capable of
using either the NTLM or the more secure Kerberos authentication protocol.
When performing an in-place upgrade of a Windows NT 4.0 domain to Windows Server 2003, the first domain
controller upgraded is the Windows NT 4.0 PDC. If clients in the domain running Windows 2000, Windows XP,
and Windows Server 2003 select the new Active Directory domain controller for authentication, the negotiation
of the authentication protocol will reveal that there are now domain controllers in the domain that support the
Kerberos protocol. These clients will then upgrade their secure channel to exclusively use the Kerberos protocol
for authentication requests and will no longer attempt to authenticate using the NTLM protocol, potentially
causing the new Active Directory domain controller to become overloaded with authentication requests.
To prevent Windows Server 2003–based domain controllers from being overloaded with authentication requests,
configure each Windows Server 2003–based domain controller to emulate a Windows NT 4.0–based domain
controller during the upgrade process. Configuring a newly upgraded Windows Server 2003–based domain
controller to emulate a Windows NT 4.0–based domain controller by using the NT4Emulator registry entry
shields the new domain controller from getting too many authentication requests from Active Directory clients.
Shielding the Active Directory domain controller takes place before the operating system is upgraded to
Windows Server 2003 to prevent clients running Windows 2000, Windows XP, and Windows Server 2003 from
ever establishing exclusive communications with a Windows Server 2003–based domain controller.
When upgrading additional Windows NT 4.0–based domain controllers after the PDC has been configured to
emulate a Windows NT 4.0–based domain controller, you must remember to configure the computer you are
upgrading with the NeutralizeNT4Emulator registry entry. This is so that the additional domain controller will
recognize the upgraded PDC that is emulating a Windows NT 4.0–based domain controller as an Active
Directory domain controller. If the computer is not configured to neutralize emulation, you will not be able to
install Active Directory because the additional domain controller will not be able to authenticate to an Active
Directory domain controller.
For each site in which clients are running Windows 2000, Windows XP, and Windows Server 2003, ensure that
you have enough Windows Server 2003–based domain controllers deployed in that site before removing
Windows NT 4.0 emulation.
For more information about emulating Windows NT 4.0–based domain controllers, see “Configure Protection
Against Domain Controller Overload” later in this chapter.
For more information about domain controller placement, see “Designing the Site Topology” in this book. For
more information about domain controller capacity planning and determining the number of domain controllers
needed in each site to service Active Directory clients, see “Planning Domain Controller Capacity” in this book.
Service Compatibility
In Windows NT 4.0 and earlier server operating systems, services running in the context of the Local System
account communicate with other services over the network by using null sessions (a session in which a user
name or password is not provided). In Windows 2000 and later operating systems, services running in the
context of the Local System account on the local computer use the local computer account to authenticate to
other servers. By default, Active Directory does not accept null session queries.
Of all the services that run in the context of the Local System account, Remote Access Services (RAS) is the
most prominent. You cannot use null sessions to access network resources by using NTLM authentication unless
the remote computer allows access with null credentials.
In an Active Directory environment containing both Windows NT 4.0–based and Windows Server 2003–based
domain controllers, a member server that is running Windows NT 4.0 and is configured as a RAS server cannot
retrieve information from a Windows Server 2003–based domain controller. For example, if a caller tries to dial
into your network and accesses a Windows NT 4.0 member server that is configured as a RAS server, the RAS
server must query a domain controller first to verify whether the caller has permission to dial into the network.
Therefore, RAS operates correctly only if the domain controller responding to the RAS authentication request is
a Windows NT 4.0–based BDC or the Active Directory domain has been configured to allow resources to be
accessed by using null credentials. By upgrading the operating system on Windows NT 4.0 member servers that
are configured as RAS servers to Windows Server 2003, you ensure that RAS callers are successfully
authenticated by a Windows Server 2003 Active Directory–based domain controller.
The recommended solution is to upgrade the RAS servers to Windows Server 2003. However, if this cannot be
done, the alternatives are:
• While installing Active Directory on the upgraded Windows NT 4.0 PDC, on the Permissions
page of the Active Directory Installation wizard, select Permissions compatible with pre-
Windows 2000 Server operating systems.
– or –
• Add the Everyone group and the Anonymous Logon group to the Pre-Windows 2000
Compatible Access built-in group by using Active Directory Users and Computers or the
command line.
To add the Everyone group to the Pre-Windows 2000 Compatible Access
Group by using the command line
• At the command line, type:
net localgroup "Pre-Windows 2000 Compatible Access" Everyone /add
To add the Anonymous Logon group to the Pre-Windows 2000

Compatible Access Group by using the command line
• At the command line, type:
net localgroup "Pre-Windows 2000 Compatible Access" “Anonymous Logon” /add
Note After this update to the Pre-Windows 2000 Compatible Access group
replicates, you must restart the Server service on all domain
controllers.
Both of these methods combined allow null sessions to read information out of the directory. After you upgrade
all RAS servers, and when you no longer need backward compatibility with operating systems earlier than
Windows 2000, remove the Everyone group and the Anonymous Logon group from the Pre-Windows 2000
Compatible Access built-in group. For more information about removing the Everyone group and the
Anonymous Logon group from the Pre-Windows 2000 Compatible Access group, see “Eliminate Anonymous
Connections to Domain Controllers” later in this chapter.
LAN Manager Replication Service and the File Replication Service

In Windows NT 4.0, the LAN Manager Replication (LMRepl) service provides single master replication of
logon scripts and other database information located in the NETLOGON share on a Windows NT 4.0–based
domain controller that is designated as an export server to all other Windows NT 4.0–based domain controllers
in the domain. LMRepl can be configured only on Windows NT 4.0–based domain controllers. In
Windows 2000 and Windows Server 2003, logon scripts and profile information are stored in the NETLOGON
shared folder (which contains policies and scripts for non-Active Directory clients) and the SYSVOL shared
folder (which contains Group Policy files and scripts for Active Directory clients). The File Replication service
(FRS), a multimaster replication engine that runs automatically on all Windows Server 2003–based domain
controllers, replaces the LMRepl service and replicates the NETLOGON and SYSVOL shared folders between
domain controllers in a Windows Server 2003 domain.
During the in-place domain upgrade process, your environment includes Windows NT 4.0–based BDCs
operating with Windows Server 2003–based domain controllers. FRS and LMRepl are not backward
compatible. Therefore, to provide support for the LMRepl service in the Active Directory environment, you
need to create a bridge between LMRepl and FRS to replicated new files created in the NETLOGON folder on
Windows Server 2003 domain controllers to the Windows NT 4.0 export server. The bridge is created by using
the Lbridge.cmd script and the Robocopy.exe tool so that both services can operate autonomously. Do this by
selecting one Windows Server 2003–based domain controller to copy the SYSVOL shared folder to the
Windows NT 4.0 export directory of the Windows NT 4.0 export server. You can use a regularly scheduled
script to copy the shared folder. For more information about creating this script, see “Synchronize File
Replication Services” later in this chapter.
Security Policy Considerations when Upgrading from Windows NT 4.0

to Windows Server 2003
Server message block (SMB) packet signing and secure channel signing are security policies that are enabled by
default on Windows Server 2003–based domain controllers. To allow clients running earlier versions of
Windows to communicate with domain controllers running Windows Server 2003, you might need to
temporarily disable these security policies during the upgrade process.
SMB packet signing
SMB packet signing is a security mechanism that protects the data integrity of SMB traffic between client
computers and servers, and prevents man-in-the-middle attacks by providing a form of mutual authentication.
This is done by placing a digital security signature into each SMB packet, which is then verified by the
receiving party. Server-side SMB signing is required by default on Windows Server 2003–based domain
controllers, which means that all clients are required to have SMB packet signing enabled.
Clients running Windows NT 4.0 with Service Pack 2 or earlier, and clients running Microsoft® Windows® 95
without the Directory Service Client Pack, do not support SMB packet signing. These clients will not be able to
authenticate to a Windows Server 2003–based domain controller. To ensure successful authentication, upgrade
these clients to a later version of the operating system or Service Pack. However, if you cannot upgrade your
clients, you can allow them to be authenticated by configuring SMB packet signing on all Windows
Server 2003–based domain controllers so that SMB packet signing is preferred but not required.
For more information about SMB packet signing, see “Microsoft network server: Digitally sign communications
(always)” in Help and Support Center for Windows Server 2003.
For more information about configuring SMB packet signing on Windows Server 2003–based domain
controllers, see “Modify Security Policies” later in this chapter.
For more information about the Directory Services Client Pack, see article 323466, “Availability of the
Directory Services Client Update for Windows 95 and Windows 98” in the Microsoft Knowledge Base. To find
this article, see the Microsoft Knowledge Base link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources.
Secure channel signing and encryption
When a computer becomes a member of a domain, a computer account is created. Each time the computer
starts, it uses the computer account password to create a secure channel with a domain controller for its domain.
This secure channel is used to ensure secure communications between a domain member and a domain
controller for its domain. Secure channel signing is required by default on Windows Server 2003–based domain
controllers, which means that all clients must enable secure channel signing and encryption.
Clients running Windows NT 4.0 with Service Pack 3 or earlier installed do not support secure channel signing.
These clients will not be able to establish communications with a Windows Server 2003–based domain
controller. To ensure successful communication, upgrade these clients to a later version of the operating system
or Service Pack. However, if you cannot upgrade your clients, you must disable secure channel signing on all
Windows Server 2003–based domain controllers so that the traffic passing through the secure channel is not
required to be signed or encrypted.
Note
Unlike SMB packet signing, secure channel signing does not affect
Windows 95 clients.
For more information about secure channel signing, see “Domain member: Digitally encrypt or sign secure
channel data (always)” in Help and Support Center for Windows Server 2003.
For more information about configuring secure channel signing on Windows Server 2003–based domain
controllers, see “Modify Security Policies” later in this chapter.
Collecting Design Information

In preparation for deployment, the forest owner in your organization is responsible for working with the
deployment team to acquire the following information:
• Documentation of your current Windows NT 4.0 environment.
• Names of the Windows NT 4.0 domains that will be upgraded and the order in which to
upgrade them.
• Supported operating system upgrade paths for your Windows NT 4.0–based domain controllers.
Information such as domain diagrams, network services, and trust relationships might have been documented as
part of the design process, and collecting it will be a matter of querying the design team. However, information
such as the existing network and hardware configuration of each domain controller might have to be collected or
documented by the forest owner during the deployment phase of the project.
In addition, the forest owner is responsible for developing a test plan and for developing a recovery plan in the
event that the deployment does not complete successfully.
Figure 8.2 shows the steps involved in collecting the design information that will be used to upgrade
Windows NT 4.0 domains to Windows Server 2003 Active Directory.
Figure 8.2 Collecting Design Information
Document the Existing Environment

Before upgrading a Windows NT 4.0 domain to Windows Server 2003 Active Directory, document the existing
Windows NT 4.0 domain structure.
Create a diagram that includes the following information:
• The names of all account and resource domains.
• The inbound and outbound trust relationships that each domain shares.
If documentation already exists for your domain, review the existing documentation for accuracy and clarity.
Figure 8.3 shows an example of the existing Windows NT 4.0 domain structure for a fictitious company, Trey
Research.
Figure 8.3 Example of a Windows NT 4.0 Domain Diagram
In addition to documenting the existing domain structure, document the following:

• The domain controllers and the services that each provides in the domain.
• The existing hardware configuration on all domain controllers in the domain.
• The existing network configuration, including IP address and network adapter information for
each domain controller.
• The current domain controller assignments and the role that you plan to assign to each domain
controller after the in-place domain upgrade.
Document Domain Controllers and Services

Identify and document the domain controllers in the existing Windows NT 4.0 domain. Include in your
documentation the role that each domain controller assumes in the domain and the services that each domain
controller provides. Identify domain controllers that provide Remote Access Service and the LAN Manager
Replication (LMRepl) service, because upgrading to Windows Server 2003 Active Directory affects these
services.
For a worksheet to assist you in documenting domain controllers and services see “Windows NT 4.0 Domain
Controllers and Services” (DSSUPNT_1.doc) or “Windows NT 4.0 Domain Controller Documentation”
(DSSUPNT_5.xls) on the Microsoft® Windows® Server 2003 Deployment Kit companion CD (or see
“Windows NT 4.0 Domain Controllers and Services” or “Windows NT 4.0 Domain Controller Documentation”
on the Web at http://www.microsoft.com/reskit). “Windows NT 4.0 Domain Controller Documentation” is a
master worksheet combining the information from all four individual worksheets in this section.
Example: Documenting Windows NT 4.0 Domain Controllers and

Services
Trey Research has a Windows NT 4.0 account domain that includes nine domain controllers running
Windows NT 4.0. Because the resource domains hold all of the application servers, the account domain does not
include member servers. The PDC, SEA-EAST-DC01, is also a Windows Internet Name Service (WINS) server,
as are two BDCs, BOS-EAST-DC01 and BOS-EAST-DC02.
Trey Research documented the domain controllers and services in their Windows NT 4.0 domain, as shown in
Figure 8.4.
Figure 8.4 Example of Windows NT 4.0 Domain Controllers and Services Worksheet
For more information about the effect of upgrading to Windows Server 2003 Active Directory on the RAS
service and the LMRepl service, see “Background Information for Upgrading to Windows Server 2003 Active
Directory” earlier in this chapter.
Document the Existing Hardware Configuration

Review and document the existing hardware configuration of each domain controller that you plan to upgrade to
Windows Server 2003. Use this information to identify the domain controllers in your environment that you can
upgrade to Windows Server 2003 and the domain controllers that do not meet the hardware requirements for
Windows Server 2003. Retain at least one domain controller that does not meet Windows Server 2003 hardware
requirements to serve as a rollback server in the event that you must roll back your deployment.
If the PDC does not meet the hardware requirements, you can transfer the PDC role to a backup domain
controller (BDC) that does meet the hardware requirements and upgrade it. If none of your Windows NT 4.0
domain controllers meet Windows Server 2003 hardware requirements, install a Windows NT 4.0 BDC on a
computer that does meet the hardware requirements for a domain controller that is running Windows
Server 2003 and transfer the PDC role to it.
You can also add a Windows Server 2003–based member server to a Windows NT 4.0 domain at any time
before you upgrade to Windows Server 2003 Active Directory because Windows Server 2003–based member
servers can operate within a Windows NT 4.0 environment. You can install Active Directory on the member
server after you upgrade the PDC.
For more information about the hardware requirements of domain controllers in a Windows Server 2003
domain, see “Planning Domain Controller Capacity” in this book. To determine whether your hardware
configuration is compatible with Windows Server 2003, see the Windows Server Catalog link on the Web
Resources page at http://www.microsoft.com/windows/reskits/webresources.
For a worksheet to assist you in documenting your existing domain controller hardware configuration, see
“Windows NT 4.0 Hardware Configuration” (DSSUPNT_2.doc) or “Windows NT 4.0 Domain Controller
Documentation” (DSSUPNT_5.xls) on the Windows Server 2003 Deployment Kit companion CD (or see
“Windows NT 4.0 Hardware Configuration” or “Windows NT 4.0 Domain Controller Documentation” on the
Web at http://www.microsft.com/reskit).
Example: Documenting the Windows NT 4.0 Hardware Configuration

Figure 8.5 shows an example of a Hardware Configuration worksheet for the Windows NT 4.0–based domain
controllers in the EAST domain for Trey Research.
Figure 8.5 Example of a Windows NT 4.0 Hardware Configuration Worksheet
Domain controllers BOS-EAST-DC02 and WDC-EAST-DC02 do not meet the minimum memory requirements
for a Windows Server 2003–based domain controller. Therefore, Trey Research has determined that BOS-
EAST-DC02 will be used as the Windows NT 4.0 rollback server if a problem occurs during the in-place
upgrade process and WDC-EAST-DC02 will be assigned as a member server in the Windows Server 2003
forest. All other Windows NT 4.0–based domain controllers are capable of supporting Windows Server 2003
Active Directory.
Document the Existing Network Configuration

Document the existing network configuration for your Windows NT 4.0 domain. Some network adapter drivers
that are included with earlier versions of the operating system are not distributed with Windows Server 2003. If
you attempt to upgrade a Windows NT 4.0–based domain controller to Windows Server 2003 and a network
adapter is installed for which a driver is not provided, your network information might be lost or detected
incorrectly during the upgrade.
Note
You can install device drivers that are not included on the Windows
Server 2003 operating system CD from the vendor’s Web site.
Create a network configuration table listing the type of network adapter that each domain controller uses. Also
include the TCP/IP configuration information for each domain controller, including IP address, subnet mask,
and default gateway. You can run the ipconfig command at the command line to determine IP address, subnet
mask, and default gateway. For more information about the ipconfig command, type ipconfig /? at the command
line.
To determine whether the network card is supported by Windows Server 2003, see the Windows Server Catalog
link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
For a worksheet to assist you in documenting your existing Windows NT 4.0 network configuration, see
“Windows NT 4.0 Network Configuration” (DSSUPNT_3.doc) or “Windows NT 4.0 Domain Controller
Documentation” (DSSUPNT_5.xls) on the Windows Server 2003 Deployment Kit companion CD (or see
“Windows NT 4.0 Network Configuration” or “Windows NT 4.0 Domain Controller Documentation” on the
Web at http://www.microsoft.com/reskit).
Figure 8.6 shows an example of a network configuration worksheet for the EAST domain for Trey Research.
Figure 8.6 Example of a Windows NT 4.0 Network Configuration Worksheet

Document Domain Controller Role Assignments

As part of your in-place domain upgrade plan, assign the existing Windows NT 4.0–based domain controllers
roles that they will assume in the Windows Server 2003 domain after the upgrade is complete. Assign one of the
following three roles to Windows NT 4.0–based domain controllers in a Windows Server 2003 domain:
• Windows Server 2003–based domain controller. Assign the role of Windows Server 2003–
based domain controller to any Windows NT 4.0 PDCs and other Windows NT 4.0–based
domain controllers that meet the appropriate hardware and software requirements.
• Rollback server. Assign the role of rollback server in the Windows Server 2003 domain to a
Windows NT 4.0 BDC that does not meet the Windows Server 2003 domain controller
hardware requirements.
• Windows Server 2003–based member server. Assign the role of member server in the
Windows Server 2003 domain to a Windows NT 4.0–based BDC that does not meet the
Windows Server 2003 domain controller hardware requirements.
For more information about the software and hardware requirements for Windows Server 2003–based domain
controllers, see “Determine Supported Operating System Upgrades” later in this chapter and “Document the
Existing Hardware Configuration” earlier in this chapter.
Create a domain controller assignment table that outlines the roles that you plan to assign to your
Windows NT 4.0–based domain controllers in the Windows Server 2003 domain. In this table, list the
Windows NT 4.0–based domain controllers in your domain, indicate whether they meet the hardware
requirements for Windows Server 2003, and list the role for each domain controller before and after you
upgrade the domain, as shown in
Figure 8.7.
For a worksheet to assist you in documenting Windows NT 4.0–based domain controller roles, see
“Windows NT 4.0 Domain Controller Role Assignment” (DSSUPNT_4.doc) or “Windows NT 4.0 Domain
Controller Documentation” (DSSUPNT_5.xls) on the Windows Server 2003 Deployment Kit companion CD (or
see “Windows NT 4.0 Domain Controller Role Assignment” or “Windows NT 4.0 Domain Controller
Documentation” on the Web at http://www.microsoft.com/reskit).
Figure 8.7 Example of a Windows NT 4.0 Domain Controller Role Assignment Worksheet
Determine the Domain Upgrade Order

Before you begin the in-place domain upgrade process, determine the order in which you plan to upgrade your
Windows NT 4.0 domains. Because account domains generally contain more objects than resource domains,
upgrade your account domains before upgrading your resource domains. This allows your organization to take
advantage of Windows Server 2003 security and administration features early in the upgrade process.
The order in which you upgrade account domains in your organization can affect the efficiency of your in-place
domain upgrade process. Use the following guidelines to determine the order in which to upgrade multiple
account domains:
• Upgrade domains that will become targets for restructuring first. After upgrading these
domains, you can restructure remaining domain objects into the restructuring target. Target
domains must be set at the Windows 2000 native domain functional level before restructuring
objects into them.
• Upgrade domains over which you have direct control and to which you have easy access. This
allows convenient access to these domains in the event that you must roll back your deployment
if the upgrade does not go as planned.
For more information about restructuring Windows NT domains, see “Restructuring Windows NT 4.0 Domains
to an Active Directory Forest” in this book.
Determine Supported Operating System

Upgrades
Identify the Windows NT 4.0 platforms that are running in your environment and determine whether an
operating system upgrade to Windows Server 2003 is supported, or whether you must perform a clean operating
system installation.
Table 8.1 lists the Windows NT 4.0 platforms and indicates which platforms you can upgrade directly to each
edition of Windows Server 2003. You do not need to reinstall applications on platforms that you can upgrade
directly to Windows Server 2003.
Table 8.1 Supported Upgrade Paths to Windows Server 2003
Upgrade to Upgrade to Upgrade to
Windows Windows Windows
Platform Server 2003, Server 2003, Server 2003,
Standard Enterprise Datacenter
Edition Edition Edition
Windows NT 4.0 Server,
Standard Edition
Windows NT 4.0 Terminal
Server
Windows NT 4.0 Server,
Enterprise Edition
Important
All versions of Windows NT 4.0 must have Service Pack 5 or later
installed before upgrading to Windows Server 2003.
If you have computers in your environment that are running operating systems that you cannot upgrade directly
to a version of Windows Server 2003, such as Windows NT 3.51, you must do one of the following:
• If you need to retain applications that are located on those computers, upgrade the computers to
run an operating system that you can upgrade to Windows Server 2003 after verifying that those
applications will function on and are supported by Windows Server 2003.
• If you do not need to retain applications that are located on those computers, perform a clean
installation of Windows Server 2003 on those computers.
Develop a Test Plan

Develop a plan for testing your in-place domain upgrade procedures throughout the in-place domain upgrade
process to ensure that they have completed successfully and to determine whether the process of upgrading
Windows NT 4.0 domains to Windows Server 2003 Active Directory was successful.
Table 8.2 lists the Active Directory configurations that you must test and the tools that you can use to test each
configuration. For more information about the options that are available for these tools, see “Active Directory
support tools” in Help and Support Center for Windows Server 2003. For more information about specific
configuration and functionality tests that you can perform before and after the Active Directory installation, see
the Active Directory link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources. Search under “Administration and Configuration
Guides” and download the Active Directory Operations Guide.
Table 8.2 Active Directory Configuration Test Components
Configuration Tool Purpose
Active Dcdiag.exe Tests for successful Active Directory
Directory connectivity and functionality. Confirms
service that the domain controller has passed the
diagnostic tests (such as connectivity
and replicated objects). Each test must
return a "passed" result.
Netdiag.exe Diagnoses networking and connectivity
problems by performing a series of
tests to determine the state of your
network client and whether it is
functional.
Active Repadmin.exe /replsum Returns all replication events taking
Directory place between the forest root domain and
replication other Active Directory domain
controllers. This must return a successful
replication event with all inbound and
outbound replication partners.
BDC Nltest.exe Shows connection status for all the
replication /bdc_query:domainnam BDCs. This must show "status =
status e success" for each domain controller
within the domain.
After you confirm that the Active Directory configuration is correct, you need to verify that Active Directory is
functioning correctly.
Table 8.3 lists the Active Directory functions that you need to test and the methods that you can use to perform
the tests.
Table 8.3 Active Directory Functionality Test Components

Function Test Method
Trust Verify the transitive Use the verify feature in Active
relationships trusts with the parent Directory Domains and Trusts on the
domain and the one- upgraded PDC to validate the trust
way trusts with relationships that are in place.
Windows NT 4.0
domains.
New user Create a new user on Log on with administrator credentials
creation the Windows and use Active Directory Users and
Server 2003–based Computers to verify that the new user
domain controller. was created successfully.
New user After replication to 1. Type Net User at a command prompt
object BDCs takes place, on a Windows NT 4.0–based domain
replication determine whether new controller, and then verify that the new
user is replicated to user account exists.
BDCs. 2. Modify a property of an existing user
and verify that the modified property
replicates with the user.
Successful Verify that users can 3. Disconnect the Windows
logon request log on successfully. Server 2003–based domain controller
to confirm that the Windows NT 4.0–
based domain controller is validating
the user logon request.
4. Verify that you can log on successfully
by using the new user account
credentials from each client machine.
5. Verify that all client operating systems
in the upgraded domain and the
domains that it trusts can log on
successfully.
6. Repeat step number two over trust
relationships where the trusting
domain controller has a secure
channel with the Windows NT 4.0–
based and Windows Server 2003–
based domain controllers in the
trusted domain.
Successful Verify that the user can 1. Access e-mail resources.
resource access important 2. Access roaming profiles.
access resources.
3. Access printers.
4. Resource permissions belonging to
the user and a group.
Develop a Recovery Plan

Create a recovery plan for use if the in-place domain upgrade process does not go as planned. Select a
Windows NT 4.0 BDC to be used as a rollback server. Synchronize the BDC with the PDC and take the rollback
server offline in the event that it must be promoted to a PDC to restore the domain to its original state. Although
you are unlikely to need the offline domain controller, it is recommended that you take one offline as a
precautionary step if the Security Accounts Manager (SAM) account database on all domain controllers
becomes corrupt.
Include the following in your recovery plan:
• The steps needed for recovery. Be sure to provide clear instructions so that the deployment team
can restore normal operations to the organization if necessary.
• The estimated time that can elapse before recovery must take place. When elements of the
upgrade process test unsuccessfully, you might spend unanticipated amounts of time identifying
and correcting errors. Establish clear guidelines for the time period after which the deployment
team must restore operations for end users.
• Team review and sign-off. All members of the deployment team must sign off on the recovery
plan. This signifies consensus about the recovery plan and reduces the chances that
misunderstandings occur when the upgrade process does not go as planned.
Restoring the Domain to its Original State

If your in-place upgrade process fails, you can roll back a Windows Server 2003 Active Directory domain to its
original state as a Windows NT 4.0 domain. There are two ways to roll back the deployment to its original state:
Note
The first recovery method is preferred for restoring a domain to its
original state. The second recovery method should only be used if the
SAM database on all domain controllers becomes corrupt.
1. Remove (either by disconnecting the network cable or turning off) any Windows Server 2003–
based domain controllers from the domain.
2. Promote a Windows NT 4.0 BDC to become the PDC.
3. Synchronize all Windows NT 4.0–based domain controllers.
4. Test Windows NT 4.0 server operations and domain validation.

5. Document the reasons for the unsuccessful domain upgrade and communicate them to your
design team.
6. Restart the design phase for the in-place domain upgrade. Be sure to include steps to mitigate
the factors that caused the first in-place domain upgrade to fail.
– or –
7. If a failure occurs after performing the steps above, remove all Windows Server 2003–based
domain controllers from the network and promote the Windows NT 4.0 BDC that has been
designated as the rollback server to become the PDC.
8. Perform a full synchronization of all Windows NT 4.0 BDCs.
9. Test Windows NT 4.0 server operations and domain validation.
10. Document the reasons for the unsuccessful domain upgrade and communicate them to your
design team.
11. Restart the design phase for the in-place domain upgrade. Be sure to include steps to mitigate
the factors that caused the first in-place domain upgrade to fail.
Important
You must take all Windows Server 2003–based domain controllers
offline before you promote the rollback server to become the new PDC.
If any Windows Server 2003–based domain controllers remain online in
the domain, the promotion of the BDC to a PDC will not work.
Completing Pre-Upgrade Tasks

After you create your plan for upgrading your Windows NT 4.0 domains to Windows Server 2003 Active
Directory, you must complete the pre-upgrade tasks shown in Figure 8.8 before beginning the in-place upgrade
process for your domain.
Figure 8.8 Completing Pre-Upgrade Tasks
Relocate the LMRepl File Replication

Service
To maintain the replication of files in the NETLOGON shared folder from the Windows NT 4.0 export server to
all other Windows NT 4.0 BDCs running the LMRepl replication engine during the in-place domain upgrade
process, upgrade all servers that are hosting import directories before you upgrade the server that is hosting the
export directory.
If the server hosting the export directory is the PDC, you can do one of the following:
• Promote a BDC that meets the Windows Server 2003 domain controller hardware requirements
to become the new PDC and demote the existing PDC to serve as a BDC hosting the export
server.
– or –
• Reconfigure the LMRepl export server on a BDC and remove it from the PDC.
To test the new configuration to ensure that LMRepl continues to work correctly, place an empty file on the
export server and verify that the file is replicated to the import directories during replication. Next, delete the
replicated file from the import directory, and then verify that the file is deleted during the next replication.
Ensure Remote Access Service

Compatibility
To ensure remote access compatibility in a mixed Windows NT 4.0 and Windows Server 2003 environment,
upgrade the operating system on all remote access servers in the domain to Windows Server 2003 before you
begin the in-place domain upgrade process. If RAS is running on a domain controller, upgrade that domain
controller early in the in-place domain upgrade process to minimize security risks.
Enable the Windows NT 4.0 Environment

Change Freeze
Before you upgrade the PDC in your Windows NT 4.0 domain to Windows Server 2003 Active Directory, you
must freeze the Windows NT 4.0 environment to ensure that no other domain changes occur until after the PDC
is upgraded. Freeze the Windows NT 4.0 environment when:
• You have completed all of the updates to the Windows NT 4.0 domain and have replicated them
to all domain controllers.
• You have synchronized a BDC and have taken it offline for recovery purposes.
When you freeze the Windows NT 4.0 environment, no additional domain changes can take place until you
upgrade the Windows NT 4.0 PDC to Windows Server 2003. Communicate to all appropriate individuals that
changes to the environment, such as password updates, will not be accepted after a specific date.
Upgrading Domains from

Windows NT 4.0 to Windows
Server 2003 Active Directory
Before you begin the Windows NT 4.0 in-place upgrade process, determine the upgrade path that your Active
Directory design specifies. The Active Directory design will specify one of two possible in-place upgrade paths:
• Upgrade to a regional domain in an existing forest.
Before upgrading a Windows NT 4.0 domain and joining an existing forest as a regional
domain, you must first deploy a Windows Server 2003 forest root domain. Complete the
planning and design phases of your Active Directory deployment and then complete the process
for deploying the forest root domain. After the forest root domain is deployed, complete the in-
place domain upgrade process by following the steps outlined in “Upgrade to a Regional
Domain in an Existing Forest” later in this chapter. For more information about deploying the
Windows Server 2003 forest root domain, see “Deploying the Windows Server 2003 Forest
Root Domain” in this book.
Note
If your organization already has a Windows 2000 or Windows
Server 2003 Active Directory infrastructure in place, complete the in-
place upgrade process by upgrading to a regional domain in an
existing forest.
To help illustrate the process for upgrading to a regional domain in an existing forest, sample
data for Trey Research, is provided within the context of the tasks that must be performed.
• Upgrade to a single domain forest.
To create a new single domain forest, complete the in-place domain upgrade process by
following the steps outlined in “Upgrading to a Single Domain Forest” later in this chapter. To
help illustrate the process for upgrading to a single domain forest, sample data for a fictitious
company, Fabrikam, Inc, is provided within the context of the tasks that must be performed.
For more information about designing an Active Directory logical structure and determining what forest design
model best suits your organization, see “Designing the Active Directory Logical Structure” in this book.
Figure 8.9 shows the two paths available for upgrading domains from Windows NT 4.0 to Windows
Server 2003 Active Directory and additional tasks that all organizations must perform regardless of which
option is specified by the Active Directory design. The additional tasks, including modifying security policies,
synchronizing file replication services, recreating trusts, using DNS registration to decrease the workload on the
PDC emulator, and upgrading additional domain controllers, are performed after the PDC is upgraded.
Figure 8.9 Upgrading Domains from Windows NT 4.0 to Windows Server 2003 Active
Directory
After the in-place domain upgrade is complete, you can upgrade additional Windows NT 4.0 domains in-place
or restructure the remaining Windows NT 4.0 domains into your Windows Server 2003 Active Directory
environment. For more information about restructuring Windows NT 4 domains, see “Restructuring
Windows NT 4.0 Domains to an Active Directory Forest” in this book.
Upgrade to a Regional Domain in an Existing

Forest
To complete the process for upgrading to a regional domain in an existing forest, perform the following tasks:
1. Back up all domain data.
2. Enable the Windows Server 2003 interim forest functional level in the existing forest.
3. Delegate the DNS zone in the forest root domain.
4. Configure protection against domain controller overload.
5. Upgrade the operating system of the Windows NT 4.0 PDC.
6. Install Active Directory.
7. Perform post-upgrade tests.
Back Up the Domain Data

Back up your Windows NT 4.0 domain data before you begin the upgrade. This task varies according to the
operations and procedures that already exist in your environment. At minimum, complete the following steps:
• Back up the PDC.
• Back up the BDC that you designated as the rollback server.
• Test all backup media to ensure that the data can be restored successfully.
Important
Store backup media in a secure offsite location designated by and
accessible to the deployment team before you begin the upgrade
process.
Enable the Windows Server 2003 Interim Forest Functional

Level
If all domain controllers in the existing forest are running Windows Server 2003, the functional level of the
forest is set at Windows 2000, and the functional level of the forest root domain is set at Windows 2000 mixed,
you can raise the forest functional level to Windows Server 2003 interim. Raising the forest functional level to
Windows Server 2003 interim is recommended in order to take advantage of the Windows Server 2003 Active
Directory features available at that level. However, if you are considering adding Windows 2000–based domain
controllers to your environment at any time, you can maintain the Windows 2000 forest functional level and still
upgrade your Windows NT 4.0 domains.
Raise the forest functional level in the existing forest to Windows Server 2003 interim before upgrading the
PDC and joining the existing forest during the Active Directory installation. By raising the forest functional
level in the existing forest before you upgrade the PDC, any additional domains that you upgrade as regional
domains will automatically join the Windows Server 2003 forest at the Windows Server 2003 interim domain
functional level.
Important
If you raise the forest and domain functional level to Windows
Server 2003 interim, you cannot return to the Windows 2000 mixed
domain functional level or to the Windows 2000 forest functional level.
After you raise the functional level to Windows Server 2003 interim, the
environment only supports Windows NT 4.0– and Windows
Server 2003–based domain controllers. You can no longer add
Windows 2000–based domain controllers into this environment.
You cannot use Active Directory administrative consoles to raise the forest functional level to Windows
Server 2003 interim. Instead, use a Lightweight Directory Access Protocol (LDAP) application such as
ADSI Edit or LDP in Windows Support Tools to edit the value of the msDS-Behavior-Version attribute. You
must be a member of the Enterprise Admins group to raise the forest functional level, and you must do this on
the domain controller that holds the schema master role.
To raise the forest functional level to Windows Server 2003 interim by using ADSI
Edit
1. In ADSI Edit, expand the Configuration partition, expand
CN=Configuration,DC=forestname,DC=domainname,DC=com
2. Right-click CN=Partitions, and then click Properties.
3. Select the msDS-Behavior-Version attribute, and then click Edit.
4. In the Value field, type 1 to raise the forest functional level to Windows Server 2003 interim,
and then click OK.
For more information about raising functional levels, see “Enabling Advanced Windows Server 2003 Active
Directory Features” in this book.
Delegate the DNS Zone for the New Regional Domain

The Active Directory DNS owner in your organization is responsible for delegating the zone that matches the
name of the regional domain to the DNS servers that are running on the domain controllers in the regional
domain.
Before you create the new regional domain, delegate the DNS zone for the new Windows Server 2003 regional
domain on any domain controller in the forest root domain DNS zone.
To delegate the DNS zone for the new regional domain
1. Open the DNS snap-in from any domain controller in the forest root domain.
2. In the console tree, right-click the forest root domain zone, and then click New Delegation.
3. Table 8.4 lists information to complete the New Delegation Wizard, as well as sample data for
delegating the DNS domain for the first two regional domain controllers in the
east.trccorp.treyresearch.net domain, SEA-EAST-DC01 and SEA-EAST-DC02. Accept the
default settings when no information is supplied.
Table 8.4 Delegating the DNS Domain for the New Regional Domain
Wizard Page Action Example
Delegated In the Delegated Domain box, type the East
Domain Name name of the regional domain.
Name Servers 1. Click Add. In the New Resource SEA-EAST-
Record dialog box, in the Server name DC01.trccorp.tre
box, type the name of the first domain yresearch.net
controller you plan to deploy.
2. In the New Resource Record dialog 172.16.16.10
box, in the IP address box, type the
corresponding IP address of the domain
controller, click Add, and then click OK. SEA-EAST-
DC02.trccorp.tre
3. Click Add, and in the New Resource
yresearch.net
Record dialog box, in the Server name
box, type the name of another domain
controller you plan to deploy in the 172.16.16.11
regional domain.
4. In the New Resource Record dialog
box, in the IP address box, type the
corresponding IP address of the other
domain controller, click Add, and then
click OK.
Configure Protection Against Domain Controller Overload

Before installing Windows Server 2003 on the Windows NT 4.0 PDC, shield the domain controller by
configuring it to emulate a Windows NT 4.0–based domain controller. By shielding the domain controller,
clients running Windows 2000, Windows XP, and Windows Server 2003 will not recognize it as an Active
Directory domain controller. Clients will authenticate with the new Windows Server 2003–based domain
controller as if it were a Windows NT 4.0–based domain controller. This step protects the domain controller
from being overloaded with authentication requests from Active Directory clients.
Maintain the emulation setting until enough Windows Server 2003–based domain controllers are in each site to
service all Active Directory clients.
Note
After removing the NT4Emulator registry entry, Windows 2000,
Windows XP, and Windows Server 2003 clients will not immediately
begin to use the Kerberos authentication protocol. This will be delayed
until each client resets its secure channel or is restarted.
If no Windows 2000, Windows XP, or Windows Server 2003 clients are running in a particular site, or if a
Windows Server 2003–based domain controller has the capacity to support the number of clients that are present
in the site, you do not need this configuration.
Caution
The registry editor bypasses standard safeguards, allowing settings
that can damage your system, or even require you to reinstall
Windows. If you must edit the registry, back it up first and see the
Registry Reference on the Windows Server 2003 Deployment Kit
companion CD or on the Web at http://www.microsoft.com/reskit.
To configure emulation on a Windows NT 4.0–based domain controller before

upgrade
1. In the Run dialog box, type regedit, and then press ENTER.
2. In the registry editor, navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Click Edit, click New, and then click DWORD Value.
4. For the new entry name, type NT4Emulator, and then press ENTER.
5. Double-click the entry name that you typed in the previous step.
6. In the Edit DWORD Value dialog box, type 1 in the Value data: box, and then click OK.
7. Click Registry, and then click Exit to close the registry editor.
Repeat this procedure as needed on each Windows NT 4.0–based domain controller that you plan to upgrade to
Windows Server 2003.
After you protect the PDC from becoming overloaded, you must be sure to neutralize the emulation on any
additional domain controllers you upgrade. Additional domain controllers in the same domain must be able to
contact an Active Directory domain controller in their domain for the Active Directory installation to succeed.
On Windows NT 4.0 BDCs, setting the NT4Emulator registry entry before the operating system upgrade will
protect the domain controller from overload. Setting the NeutralizeNT4Emulator registry entry immediately
afterward allows the BDC to contact an Active Directory domain controller that has the NT4Emulator registry
entry set and successfully install Active Directory. For more information about neutralizing Windows NT 4.0
emulation, see “Neutralize Windows NT 4.0 Domain Controller Emulation” later in this chapter.
After you upgrade all domain controllers, or you have enough Windows Server 2003–based domain controllers
to authenticate the clients in your domain that are running Windows 2000, Windows XP, and Windows
Server 2003, you can reverse this configuration by editing the registry again and removing the NT4Emulator
registry entry.
Upgrade the Operating System of the Windows NT 4.0 PDC

Before upgrading the operating system to Windows Server 2003, use the Winnt32.exe command-line tool to
detect any upgrade problems you might have to resolve. This tool reports potential upgrade problems, such as
inadequate hardware resources or compatibility problems.
To determine potential upgrade problems
• At the command line, connect to the I386 directory located at your installation source and type
the following command:
winnt32 /checkupgradeonly
Resolve any reported problems before performing the upgrade.

To install the operating system on the computer, insert the Windows Server 2003 operating system CD in the
CD-ROM drive of the domain controller and select the option to install the operating system, or use an
automated installation method. If the Windows Server 2003 media is shared on the network, run the
Winnt32.exe command from the installation source.
Complete the operating system installation by doing the following:
• Select Upgrade for the Installation type.
• Use the NTFS file system to convert the partitions. The installation of Active Directory will not
succeed if you do not have at least one NTFS partition available on which to locate the
SYSVOL shared folder.
• Verify that you are using a static IP address.
• Configure DNS client settings by using the IP address of the closest DNS server for the
Preferred DNS server setting and either leave the Alternate DNS server setting blank or use
the IP address of the closest DNS server. These DNS client settings are temporary and will be
changed during the installation of Active Directory.
• Install Windows Support Tools, which are available in the \Support\Tools folder on the
Windows Server 2003 operating system CD.
During the operating system upgrade the computer will restart three times. After you upgrade the operating
system on a Windows NT 4.0 domain controller to Windows Server 2003, the computer is in an intermediate
state, meaning that the computer is no longer a Windows NT 4.0–based domain controller, and it is not a
Windows Server 2003–based member server or domain controller until Active Directory is installed. After the
computer restarts for the last time, the Welcome to the Active Directory Installation Wizard appears.
Install Active Directory

The Active Directory Installation Wizard creates the Active Directory database and moves objects from the
Windows NT 4.0 Security Accounts Manager (SAM) to the Active Directory database.
Note
When you are upgrading to a regional domain in an existing Active
Directory forest, ensure that the domain naming master in the forest
root domain is running Windows Server 2003 before installing Active
Directory on the newly upgraded PDC. This ensures that application
directory partitions are created on the first domain controller in the new
regional domain.
In addition, on the first domain controller in a new regional domain in an existing forest, the wizard does the
following:
• Prompts the administrator to verify the installation and configuration of the DNS Server
service.
• Configures DNS recursive name resolution forwarding by adding the IP addresses of the
existing entries for Preferred DNS server and Alternate DNS server to the list of DNS
servers on the Forwarders tab of the Properties sheet for the domain controller.
• Configures DNS recursive name resolution by root hints, by adding the root hints that are
configured on the Preferred DNS server to the list of DNS servers on the Root Hints tab of
the Properties sheet for the domain controller.
• Configures the Preferred DNS server to point to the DNS server that is running locally on the
domain controller, and configures the Alternate DNS server to point to the closest DNS server.
• Creates the DomainDnsZones application directory partition that is used by DNS to hold
domain-wide DNS data.
Table 8.5 lists information to install Active Directory on an upgraded Windows NT 4.0 PDC and sample data for
installing Active Directory on the first domain controller in a new regional domain in the
trccorp.treyresearch.net forest, SEA-EAST-DC01.
Table 8.5 Information to Install Active Directory on a Windows NT 4.0 PDC
Wizard Page
Action Example
or Dialog Box
Create New Select Child Domain in an existing
Domain domain tree
Network Type the user name and password of
Credentials an account with sufficient privileges to
install Active Directory on this
computer, and the fully qualified
domain name of the parent domain.
Child Domain Enter the full DNS name of the parent trccorp.treyresearch.ne
Installation domain and the single label name of t
the new regional domain. east
Database and Type the folder locations specified by The design for Trey
Log Folders your design Research specifies that
the database folder
remain in the default
location:
C:\Winnt\Ntds, and that
the log folder is placed
on a separate partition:
D:\Logs
Shared Confirm or type the location specified C:\Winnt\Sysvol
System by your design
Volume
DNS DNS Registration Diagnostics will
Registration indicate that it cannot find the name
Diagnostics and address of the DNS server with
which this domain controller will be
registered. This is because the pre-
created delegation record points to the
local computer and DNS has not been
installed on the domain controller at
this point.
Select the option to Install and
configure the DNS server on this
computer and set this computer to use
this DNS server as its preferred DNS
server.
(continued)
Table 8.5 Information to Install Active Directory on a Windows NT 4.0 PDC (continued)
Wizard Page or
Action Example
Dialog Box
Permissions Select the security level specified by Because Trey
your design: Research currently
• Permissions compatible with pre- has services running
Windows 2000 server operating on Windows NT 4.0–
systems based servers under
the context of the
• Permissions compatible only with
Local System
Windows 2000 or Windows
account, they
Server 2003 operating systems
selected Permissions
compatible with pre-
Windows 2000 server
operating systems.
Directory In the Password and Confirm
Service password boxes, type any strong
Restore Mode password
Administration
Password
Verify that all information on the Summary page is accurate, and then click Finish. After the Active Directory
Installation Wizard finishes, you will be prompted to restart the computer. The installation will not be complete
until the computer restarts.
For more information about installing and removing Active Directory, see the Directory Services Guide of the
Microsoft® Windows® Server 2003 Resource Kit (or see the Directory Services Guide on the Web at
http://www.microsoft.com/reskit).
After you install Windows Server 2003 Active Directory, enable Remote Desktop for Administration, formerly
known as Terminal Services in Remote Administration mode, to enable administrators to log on remotely if
necessary. To enable Remote Desktop for Administration, in Control Panel, double-click System, select the
Remote tab, and then select Allow users to connect remotely to this computer.
Verify DNS Server Recursive Name Resolution

DNS server recursive name resolution is configured automatically during the Active Directory installation
process. If your design specifies a different configuration, you can use the DNS snap-in or Dnscmd.exe to
modify these settings. Use the DNS snap-in to verify DNS server recursive name resolution based on the
information in Table 8.6.
Table 8.6 Information to Verify DNS Server Recursive Name Resolution
Method Configuration
Recursive No additional configuration is necessary. When the DNS server
name specified as the Preferred DNS server during the installation
resolution by process is correctly configured, the root hints are automatically
root hints configured. To verify the root hints by using the DNS snap-in:
1. In the console tree, right-click the domain controller name, and
then click Properties.
2. In the Properties sheet for the domain controller, view the root
hints on the Root Hints tab.
Root hints are the recommended method to use for recursive
name resolution in a Windows Server 2003 environment.
Recursive Forward unresolved queries to specified DNS servers. To verify
name forwarding by using the DNS snap-in:
resolution by 1. In the console tree, right-click the domain controller name, and
forwarding then click Properties.
2. On the Forwarders tab, in the selected domain’s Forwarders list,
verify that the IP addresses match those specified by your
design.
Forwarders should be used only if that is what your
organization’s design specifies. Root hints are the
recommended method to use for recursive name resolution in a
Windows Server 2003 environment.
No existing No additional configuration is necessary.
DNS In this environment, if you want to configure internal DNS
infrastructure servers to resolve queries for external names, configure this
DNS server to forward unresolved queries to an external server,
such as one in your perimeter network, or one hosted by an
Internet service provider.
Perform Post-Upgrade Tests

After the Active Directory Installation Wizard completes, verify the Active Directory installation. Review the
Windows Server 2003 Event Viewer for any errors and use the DNS snap-in to verify that the DomainDnsZones
was created under the DNS root zone.
You can also verify that Event ID 4500 has been logged in DNS Events to ensure that application directory
partitions have been created.
Next, perform the tests defined in your test plan to test the Active Directory configuration and verify whether
Active Directory is functioning correctly. For more information about developing a test plan, see “Develop a
Test Plan” earlier in this chapter.
After performing post-upgrade tests and verifying that the upgrade of the Windows NT 4.0 PDC and the
installation of Active Directory succeeded, complete the upgrade process by continuing to “Modify Security
Policies” later in this chapter.
Upgrade to a Single Domain Forest

To complete the process for upgrading to a single domain forest, perform the following tasks:
1. Back up all domain data.
2. If you have an existing DNS infrastructure, delegate the DNS zone for the new Windows
Server 2003 domain.
4. Upgrade the operating system of the Windows NT 4.0 PDC.
6. Configure the site topology.
7. Configure the Windows Time Service.
8. Enable aging and scavenging for DNS.
9. Verify DNS server recursive name resolution.
Important
When upgrading to a single domain forest, any individual who is a
member of the Domain Admins group in the existing Windows NT 4.0
domain will become a member of the Domain Admins and Enterprise
Admins groups. Before upgrading the first Windows NT 4.0 domain,
remove users whom you do not want to have full access to the entire
forest from both the Administrators and Domain Admins groups.
Back Up the Domain Data

Back up your Windows NT 4.0 domain data before you begin the upgrade. This task varies according to the
operations and procedures that already exist in your environment. It is recommended that you complete the
following steps:
• Back up the PDC.
• Back up the BDC that you designated as the rollback server.
• Test all backup media to ensure that the data can be restored successfully.
Important
Before you begin the upgrade process, store the backup media in a
secure offsite location designated by and accessible to the upgrade
team.
Delegate the DNS Zone for the Windows Server 2003

Domain
If your organization has an existing DNS infrastructure, review current network diagrams and DNS domain
hierarchy diagrams. Also review the existing DNS zone configuration, replication, and resource records that are
used for delegation and forwarding. To configure the DNS zone for the single domain forest, the DNS
administrator of your existing DNS infrastructure delegates the zone matching the name of the new Windows
Server 2003 domain to the DNS servers that are running on the domain controllers in the single domain forest.
Important
When no DNS infrastructure exists, skip this step in the process for
upgrading to a single domain forest and proceed to the next step,
"Configure Protection Against Domain Controller Overload” later in this
chapter. The remainder of this step describes the process of
configuring and delegating a zone in the existing DNS internal
namespace.
In preparation for the deployment of the single domain forest, create a delegation for the DNS servers that will
be running on the domain controllers in the Windows Server 2003 domain. Create the delegation by adding
DNS name server (NS) and address (A) resource records to the parent DNS zone.
Note
The delegation that occurs in this step references the first Windows
Server 2003–based domain controller, which does not currently exist.
The DNS service is installed and configured on the first Windows
Server 2003–based domain controller in a later step.
To delegate the DNS zone for the Windows Server 2003 domain
1. Create a name server (NS) resource record in the parent zone. Use the full DNS name of the
domain controller.
forest_root_domain IN NS domain_controller_name
2. Create a host address (A) resource record in the parent zone. Use the full DNS name of the
domain controller.
domain_controller_name IN A domain_controller_ip_address
For example, the DNS administrator for Fabrikam created the following DNS resource records
in the parent zone, fabrikam.com:
• fabricorp IN NS SEA-FAB-DC01.fabricorp.fabrikam.com
• SEA-FAB-DC01.fabricorp.fabrikam.com IN A 172.16.16.2
Configure Protection Against Domain Controller Overload

Before installing Windows Server 2003 on the Windows NT 4.0 PDC, shield the domain controller by
configuring it to emulate a Windows NT 4.0–based domain controller. By shielding the domain controller,
clients running Windows 2000, Windows XP, and Windows Server 2003 will not recognize it as an Active
Directory domain controller. Clients will authenticate with the new Windows Server 2003–based domain
controller as if it were a Windows NT 4.0–based domain controller, protecting it from being overloaded with
authentication requests from Active Directory clients.
Maintain the emulation setting until there are enough Windows Server 2003–based domain controllers in each
site to service all Active Directory clients.
Note
After removing the NT4Emulator registry entry, Windows 2000,
Windows XP, and Windows Server 2003 clients will not immediately
begin to use the Kerberos authentication protocol. This will be delayed
until each client resets its secure channel or is restarted.
If no Windows 2000, Windows XP, or Windows Server 2003 clients are running in a particular site, or if the
Windows Server 2003–based domain controller has the capacity to support the number of clients that are present
in the site, this configuration is not needed.
Caution

upgrade
1. In the Run dialog box, type regedit, and press ENTER.
5. Double-click the name that you typed in the previous step.
Repeat this procedure as needed on each Windows NT 4.0–based domain controller that you plant to upgrade to
a Windows Server 2003.
After you protect the PDC from becoming overloaded, you must neutralize the emulation on any additional
domain controllers that you plan to upgrade. For the Active Directory installation to succeed, additional domain
controllers in the same domain must be able to contact an Active Directory domain controller in their domain.
On Windows NT 4.0 BDCs, setting the NT4Emulator registry entry before the operating system upgrade will
protect the domain controller from overload. Setting the NeutralizeNT4Emulator registry entry immediately
afterward will allow the BDC to contact an Active Directory domain controller that has the NT4Emulator
registry entry set and successfully install Active Directory. For more information about neutralizing
Windows NT 4.0 emulation, see “Neutralize Windows NT 4.0 Domain Controller Emulation” later in this
chapter.
After you upgrade all domain controllers, or you have enough Windows Server 2003–based domain controllers
to authenticate the clients in your domain that are running Windows 2000, Windows XP, and Windows
Server 2003, you can reverse this configuration by editing the registry again and removing the NT4Emulator
registry entry.
Upgrade the Operating System of the Windows NT 4.0 PDC

detect any upgrade problems. This tool reports potential upgrade problems, such as inadequate hardware
resources or compatibility problems.
Resolve reported problems before performing the upgrade.

Winnt32.exe command.
Complete the operating system installation by doing the following:
1. Select Upgrade for the Installation type.
2. Use NTFS to convert the partitions. The installation of Active Directory will not succeed if you
do not have at least one NTFS partition available on which to locate the SYSVOL shared folder.
3. Verify that you are using a static IP address.
4. Configure DNS client settings by using the IP address of the closest DNS server for the
Preferred DNS Server settings. If you have more than one DNS server, add the IP address of
the next closest DNS server to the Alternate DNS server setting. If there are no other DNS
servers, leave the alternate setting blank. These DNS client settings are temporary and will be
changed during the installation of Active Directory.
5. Install Windows Support Tools, which are available in the \Support\Tools folder on the
During the operating system upgrade the computer will restart three times. After you upgrade the operating
system on a Windows NT 4.0 domain controller to Windows Server 2003, the computer is in an intermediate
state, meaning that the computer is no longer a Windows NT 4.0–based domain controller, and it is not a
Windows Server 2003–based member server or domain controller until Active Directory is installed. After the
computer restarts for the last time, the Welcome to the Active Directory Installation Wizard appears.
Install Active Directory

Immediately proceed with the installation of Active Directory by continuing the Active Directory Installation
Wizard. The Active Directory Installation Wizard creates the Active Directory database and moves objects from
the Windows NT 4.0 SAM to the Active Directory database. In addition, on the first domain controller in a new
domain, the wizard proceeds through the following tasks:
• Prompts the administrator to verify the installation and configuration of the DNS Server
service.
• Configures DNS recursive name resolution forwarding by adding the IP addresses of the
existing entries for Preferred DNS server and Alternate DNS server to the list of DNS
servers on the Forwarders tab of the Properties sheet for the domain controller.
• Configures DNS recursive name resolution by root hints, by adding the root hints that are
configured on the Preferred DNS server to the list of DNS servers on the Root Hints tab of
the Properties sheet for the domain controller.
• Configures the Preferred DNS server to point to DNS server that is running locally on the
domain controller, and configures the Alternate DNS server to point to the closest DNS server.
• Creates two application directory partitions that are used by DNS. The DomainDnsZones
application directory partition holds domain-wide DNS data, and the ForestDnsZones
application directory partition holds forest-wide DNS data.
• Prompts the administrator to select the forest functional level.
Table 8.7 lists information to install Active Directory on a Windows NT 4.0 PDC, and lists sample data for
installing Active Directory on the first domain controller in the single domain forest for Fabrikam, SEA-FAB-
DC01.
Table 8.7 Information to Install Active Directory on a Windows NT 4.0 PDC
Wizard Page or
Action Example
Dialog Box
Create New Select Domain in a new forest
Domain
New Domain Type the full DNS name of the Fabricorp.fabrikam.com
Name domain
Forest Choose Windows Server 2003 Because Fabrikam does not
Functional interim plan to add any
Level Windows 2000–based
domain controllers to their
forest at any time they chose
the Windows Server 2003
interim forest functional
level.
Database and Type the folder locations The design for Trey
Log Folders specified by your design Research specifies that the
database folder remain in
the default location:
C:\Winnt\Ntds, and that the
log folder is placed on a
separate partition: D:\Logs
Shared System Confirm or type the location C:\Winnt\Sysvol
Volume specified by your design
(continued)
Table 8.7 Information to Install Active Directory on a Windows NT 4.0 PDC (continued)
Wizard Page or
Action Example
Dialog Box
DNS DNS Registration Diagnostics
Registration will indicate that it cannot find
Diagnostics the name and address of the
DNS server with which this
domain controller will be
registered. This is because the
pre-created delegation record
points to the local computer and
DNS has not been installed on
the domain controller at this
point.
Select the option to Install and
configure the DNS server on
this computer and set this
computer to use this DNS
server as its preferred DNS
server.
Permissions Select the security level Because Fabrikam currently
specified by your design: has services running on
• Permissions compatible with Windows NT 4.0–based
pre-Windows 2000 server servers under the context of
operating systems the Local System account,
they selected Permissions
• Permissions compatible only
compatible with pre-
with Windows 2000 or
Windows 2000 server
Windows Server 2003
operating systems
operating systems
Directory In the Password and Confirm
Service password boxes, type any
Restore Mode strong password
Administration
Password
For more information about installing and removing Active Directory, see the Directory Services Guide of the
Windows Server 2003 Resource Kit (or see the Directory Services Guide on the Web at
Configure the Site Topology

When you install Active Directory on the first domain controller in the forest, a site object named Default-First-
Site-Name is created in the Sites container in Active Directory. The server object for the first domain controller
is created in this site.
If no additional sites have been defined in Active Directory, the server object for all subsequent domain
controllers will be added to the Default-First-Site-Name site object. However, if additional sites are defined in
Active Directory and the IP address of the installation computer matches an existing subnet in a defined site, the
domain controller is added to that site.
Note
Domain controllers are only added to sites based on their IP address at
the time of installation. After installation, if the IP address, subnet, or
site information of a domain controller changes, an administrator must
manually move the domain controller to the new site.
To simplify the placement of the domain controller into the appropriate site, configure your site topology before
you install Active Directory on additional domain controllers. After all sites are created, a server object for each
additional domain controller is created in the appropriate site according to its IP address.
Configure your Active Directory site topology as specified in your site topology design. For information about
creating a site topology design, see “Designing the Site Topology” in this book. For more information about
configuring your site topology, see “Configure site settings: Active Directory” and “Configure replication
between sites: Active Directory” in Help and Support Center for Windows Server 2003.
Configure the Windows Time Service on the Forest Root

Domain Controller
When deploying a single domain forest, it is important to correctly configure the Windows Time Service on the
forest root domain controller to meet your organization’s needs. The Windows Time Service provides time
synchronization to peers and clients, ensuring that there is consistent time throughout an enterprise.
By default, the first domain controller that is deployed holds the PDC emulator operations master role, and
should be set to synchronize from a valid Network Time Protocol (NTP) source. If no source is configured, the
service will log a message to the event log, and use the local clock when providing time to clients. Although
internet NTP sources are valid for this configuration, it is recommended that a dedicated hardware device, such
as a GPS, or Radio clock be employed in the interest of security.
It is recommended that you repeat this operation when the PDC emulator operations master role is transferred or
seized in the forest root domain.
To configure the Windows Time Service on first forest root domain controller
1. Log on to the domain controller.
2. At the command line, type:
W32tm /config /manualpeerlist:<peers> /syncfromflags:manual
where <peers> is a space–delimited list of DNS and/or IP addresses. When specifying multiple
peers, enclose the list in quotation marks.
3. Update the Windows Time Service configuration. At the command line, type:
W32tm /config /update
– or –
Net stop w32time
Net start w32time
Note
When specifying a manual peer, do not use the DNS name or IP
address of a computer that uses the forest root domain controller as its
source for time, such as another domain controller in the forest. The
time service will not operate correctly if there are cycles in the time
source configuration.
For more information about configuring and deploying the Windows Time Service, see the Directory Services
Guide of the Windows Server 2003 Resource Kit (or see the Directory Services Guide on the Web at
Enable Aging and Scavenging for DNS

In a new single domain forest you will need to enable aging and scavenging on Windows Server 2003–based
domain controllers running the DNS Server service to allow automatic cleanup and removal of stale resource
records (RRs), which can accumulate in zone data over time.
With dynamic update, RRs are automatically added to zones when computers start on the network. However, in
some cases, they are not automatically removed when computers leave the network. For example, if a computer
registers its own host (A) RR at startup, and is later incorrectly disconnected from the network, its host (A) RR
might not be deleted. If your network has mobile users and computers, this situation can occur frequently.
If left unmanaged, the presence of stale RRs in zone data might cause problems, including the following:
• If a large number of stale RRs remain in server zones, they can eventually take up server disk
space and cause unnecessarily long zone transfers.
• DNS servers loading zones with stale RRs might use outdated information to answer client
queries, potentially causing the clients to experience name resolution problems on the network.
• The accumulation of stale RRs at the DNS server can degrade its performance and
responsiveness.
Caution
By default, the aging and scavenging mechanism for the DNS Server
service is disabled. Enable aging and scavenging only after you
understand all parameters. Otherwise, the server could be accidentally
configured to delete resource records that should not be deleted. If a
resource record is accidentally deleted, not only will users fail to
resolve queries for that resource record, but any user can create the
resource record and take ownership of it, even on zones configured for
secure dynamic update.
For more information about how to configure aging and scavenging,
see “Understanding aging and scavenging: DNS” in Help and Support
Center for Windows Server 2003.
To enable the aging and scavenging features, and to configure the applicable server and its Active Directory–
integrated zones, perform these tasks:
• Enable aging and scavenging at the server. These settings determine the effect of zone-level
properties for any Active Directory–integrated zones loaded at the server.
• Enable aging and scavenging for selected zones at the DNS server. When zone-specific
properties are set for a selected zone, these settings apply only to the applicable zone and its
resource records. Unless these zone-level properties are otherwise configured, they inherit their
defaults from comparable settings maintained in server aging/scavenging properties.
To set aging and scavenging properties for the DNS server
1. Log on to the computer that is running the DNS Server service with an account that is a
member of the local Administrators group.
2. In the DNS console tree, right-click the applicable DNS server, and then click Set
Aging/Scavenging for all zones.
3. Select the Scavenge stale resource records check box.
4. Modify other aging and scavenging properties as needed.
To set aging and scavenging properties for a zone

1. Log on to the computer that is running the DNS Server service with an account that is a
member of the local Administrators group.
2. In the DNS console tree, right-click the applicable zone, and then click Properties.
3. On the General tab, click Aging, and then select the Scavenge stale resource records check
box.
4. Modify other aging and scavenging properties as needed.
Verify DNS Server Recursive Name Resolution

DNS server recursive name resolution is configured automatically during the Active Directory installation
process. If your design specifies a different configuration, you can use the DNS snap-in or Dnscmd.exe to
modify these settings. Use the DNS snap-in to verify DNS server recursive name resolution based on the
information in Table 8.8.
Table 8.8 Information to Verify DNS Server Recursive Name Resolution
Method Configuration
Recursive No additional configuration is necessary. When the DNS server
name specified as the Preferred DNS server during the installation
resolution by process is correctly configured, the root hints are automatically
root hints configured. To verify the root hints by using the DNS snap-in:
1. In the console tree, right-click the domain controller name, and
then click Properties.
2. In the Properties sheet for the domain controller, view the root
hints on the Root Hints tab.
Root hints are the recommended method to use for recursive
name resolution in a Windows Server 2003 environment.
Recursive Forward unresolved queries to specified DNS servers. To verify
name forwarding by using the DNS snap-in:
resolution by 1. In the console tree, right-click the domain controller name, and
forwarding then click Properties.
2. On the Forwarders tab, in the selected domain’s Forwarders list,
verify that the IP addresses match those specified by your
design.
Forwarders should be used only if that is what your
organization’s design specifies. Root hints are the
recommended method to use for recursive name resolution in a
Windows Server 2003 environment.
No existing No additional configuration is necessary.
DNS In this environment, if you want to configure internal DNS
infrastructure servers to resolve queries for external names, then configure
this DNS server to forward unresolved queries to an external
server, such as one in your perimeter network, or one hosted by
an Internet service provider.

After the Active Directory Installation Wizard completes, verify the Active Directory installation. Review the
Windows Server 2003 event log for any errors and use the DNS snap-in to verify that the following two DNS
zones were created under the DNS root zone:
• DomainDnsZones
• ForestDnsZones
You can also verify that Event ID 4500 has been logged in DNS Events to ensure that application directory
partitions have been created.
Next, perform the tests defined in your test plan to test the Active Directory configuration and verify whether
Active Directory is functioning correctly. For more information about developing a test plan, see “Develop a
Test Plan” earlier in this chapter.
After performing post-upgrade tests and verifying that the upgrade of the Windows NT 4.0 PDC and the
installation of Active Directory succeeded, complete the upgrade process by continuing to “Modify Security
Policies” later in this chapter.
Modify Security Policies

To ensure that clients running earlier versions of the Windows operating system can access domain resources in
the new Windows Server 2003 domain, you might have to modify default security policies.
In order to increase security, Windows Server 2003–based domain controllers require by default that clients
attempting to authenticate to them use SMB packet and secure channel signing. Clients running the Windows 95
operating system without the Directory Service Client Pack or Windows NT 4.0 with Service Pack 2 and earlier
do not support SMB packet signing and will not be able to log on or access domain resources on the network.
Clients running Windows NT 4.0 with Service Pack 3 and earlier do not support secure channel signing and will
not be able to establish communications with a domain controller in their domain.
The most secure way to enable these clients to log on and access domain resources on the network is to apply
either the appropriate service pack or the Directory Service Client Pack. If you cannot apply either of these,
configure all Windows Server 2003–based domain controllers to not require SMB packet signing and secure
channel signing. To do this, disable the following settings in the Default Domain Controllers Policy:
• Microsoft network server: Digitally sign communications (always)
• Domain member: Digitally encrypt or sign secure channel data (always)
Important
If you modify these policies, the default security policies in your
environment are weakened. However, this is necessary to ensure that
some clients running earlier versions of Windows can access domain
resources. After all the clients in your environment are running versions
of Windows that support SMB packet and secure channel signing, you
can re-enable these security policies to increase security. It is
recommended that you upgrade your Windows clients as soon as
possible.
To make SMB packet and secure channel signing optional on Windows

Server 2003–based domain controllers
1. Open Active Directory Users and Computers, right-click the Domain Controllers container,
and then click Properties.
2. Select the Group Policy tab, and then click Edit.
3. Under Computer Configuration, navigate to Windows Settings\Security Settings\Local
Policies\Security Options.
4. In the details pane, double-click Microsoft network server: Digitally sign communications
(always) and then click Disabled to prevent SMB packet signing from being required.
5. Click OK.
6. In the Details pane, double-click Domain member: Digitally encrypt or sign
secure channel data (always), click Disabled to prevent secure channel signing
from being required, and then click OK.
7. To apply the Group Policy change immediately, either restart the domain controller, or run the
gpupdate /force command.
Note
Modifying these settings in the Domain Controllers container will
change the Default Domain Controllers Policy. Policy changes that are
made here are replicated to all other domain controllers in the domain,
requiring you to modify these policies only one time.
For more information about SMB packet signing and secure channel signing, see “Background Information for
Upgrading to Windows Server 2003 Active Directory” earlier in this chapter.
For more information about security policies, see “Security options: Security Setting Descriptions” in Help and
Support Center for Windows Server 2003.
Synchronize File Replication Services

After upgrading the Windows NT 4.0 PDC, create a script to copy logon script and profile information from the
NETLOGON shared folder on the new Windows Server 2003–based domain controller to the REPL$ share on
the Windows NT 4.0 BDC that is providing export services to other Windows NT 4.0 BDCs in the domain.
To create logon script and profile replication between Windows Server 2003–
based and Windows NT 4.0–based domain controllers
1. Create a user account on a Windows NT 4.0 BDC in the Windows Server 2003 domain by using
User Manager for Domains and the information in Table 8.9.
Table 8.9 User Account Information for Logon Script and Profile Replication
When Prompted For Use
User name LbridgeAcct
Description Account used by lbridge.cmd for replication.
Password password (where password is any password that
meets the security requirements for your
organization).
Select User Must Change Password At Next Logon to clear the checkbox.
2. Use the information listed in Table 8.10 to ensure that the LbridgeAcct has the correct
permissions on both the Windows Server 2003–based domain controller and on the
Windows NT 4.0 BDC.
Table 8.10 Permissions for the LbridgeAcct User Account
Folder Permission
On the Windows NT 4.0 BDC, ensure that the LbridgeAcct Full Control
is granted Full Control to the REPL$ share.
In Server Manager, select the computer configured as the
export server, click Computer, and select Shared
Directories. Select REPL$, and then click Properties. In
the Share Properties dialog box, click Permissions, click
Add, and then click Show Users. Select the LbridgeAcct.
In the Type of Access drop-down list box, select Full
Control.
On the Windows Server 2003–based domain controller in Read
the new Windows Server 2003 domain, ensure that the
LbridgeAcct is granted Read access to the NETLOGON
shared folder.
Access the NETLOGON shared folder by typing
\\win_dc\Netlogon (where win_dc is the name of the
Windows Server 2003–based domain controller) in the
Run dialog box.
3. Create a destination folder on the Windows Server 2003–based domain controller where you
will install the Lbridge.cmd script and the Robocopy.exe tool.
4. Modify the path statement in Environment Variables to include the destination folder. Right-
click My Computer, click Properties, click the Advanced tab, and then click Environment
Variables. In the System Variables list, select Path and click Edit. Append the Variable value
with the location of the destination folder (;C:\destination folder).
The Lbridge.cmd script and Robocopy.exe tools are available on the Windows Server 2003
Deployment Kit companion CD.
5. On the Windows Server 2003–based domain controller, in Windows Explorer, right-click the
Lbridge.cmd script, and then click Edit. Edit as indicated in Table 8.11.
Table 8.11 Modifications to the lbridge.cmd Script
Script Line Change To
Set L-Destination=%1 Set L-Destination=\\winnt_dc\REPL$
(where winnt_dc is name of the
Windows NT 4.0 BDC hosting the
LMRepl export server.
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
6. On the Windows Server 2003–based domain controller, open Control Panel, point to
Scheduled Tasks, and then click Add Scheduled Task.
7. Complete the Scheduled Task Wizard by using the information in Table 8.12. Accept the default
settings when no information is supplied.
Table 8.12 Scheduled Task Wizard Actions for Lbridge.cmd
Wizard Page Action
Click the program you Click Browse.
want Windows to run In the Select Program to Schedule dialog box,
click lbridge.cmd.
Type a name for this Type FRS - LMRepl Replication Bridge.
task
Perform this task Select Daily.
Start time Enter the time and date that you want the
replication to start.
Enter the user name Type LbridgeAcct.
Enter the password Type the password that you have chosen for
LbridgeAcct.
Confirm the password Confirm the password for LbridgeAcct.
Open advanced Select the check box.
properties for this task
when I click Finish
The FRS - LMRepl Replication Bridge dialog box opens.

8. In the FRS - LMRepl Replication Bridge dialog box, on the Schedule tab, click Advanced.
9. In the Advanced Schedule Options dialog box, select the Repeat task check box.
10. In the Every box, specify how often you want the script to run.
11. In the Duration box, specify how long you want the script to run, and then click OK.
12. In the FRS - LMRepl Replication Bridge dialog box, on the Schedule page, click OK.
To verify that the script ran successfully and replication is occurring from the Windows Server 2003–based
domain controller to all Windows NT 4.0–based domain controllers, place a file called Test.txt into the
\\Win_dc\SYSVOL\sysvol\domainname\scripts folder. After replication is scheduled to take place, verify that
the Test.txt file has replicated to the \Winnt_dc\system32\REPL\Import\scripts folder.
Recreate Trusts
Trust relationships between Windows NT 4.0 domains use NetBIOS domain names. During the in-place
upgrade of your Windows NT 4.0 environment, if some of your Windows NT 4.0 domains have trust
relationships with other Windows NT 4.0 domains that are then upgraded into separate forests, those trust
relationships between the domains in different forests remain, but continue to use the NetBIOS domain name. It
is recommended that trust relationships between domains in different forests use the DNS name for the domain
in order to gain better functionality in a Windows Server 2003 environment. To rename the trust relationship by
using the DNS name for the domain, delete and recreate external trust relationships that exist between
Windows NT 4.0 domains and Active Directory domains in different forests. Trusts that use NetBIOS names
and exist between Windows NT 4.0 domains can be left in place.
Use DNS Registration to Decrease the

Workload on the PDC Emulator
After upgrading the Windows NT 4.0 PDC, the domain controller hosts the PDC emulator operations master
role. Of all the operations master roles, the PDC emulator role has the greatest effect on the domain controller
that is hosting that role because the PDC emulator fulfills additional tasks in the domain, such as processing
password changes, processing authentication requests if the password fails on the authenticating domain
controller, and all write operations to the domain that are requested or performed by applications or by clients
running Windows 2000, Windows XP, and Windows Server 2003.
In domains with more than 10,000 users, it might be necessary to reduce the number of authentication requests
received by the PDC emulator and allow it to perform other tasks. If, after upgrading the Windows NT 4.0 PDC,
CPU utilization is higher than 50 percent or if disk queues remain higher than two for several hours or days,
reduce the number of client authentication requests that are received by the PDC emulator.
Note
Other factors that can increase the workload on the PDC emulator
include pre-Active Directory clients or applications that have been
written to contact the PDC emulator.
To reduce the number of client authentication requests that are processed by the PDC emulator, adjust its weight
or its priority in the DNS environment. If you want to proportionately reduce the number of client authentication
requests received by the PDC emulator, adjust its weight. If you want to ensure that the PDC emulator does not
receive any client authentication requests, adjust its priority.
Active Directory assigns a default value of 100 for the weight. By creating a new registry entry for the weight
and assigning it a decreased value of 50, you can proportionately reduce the number of client authentication
requests that are sent to the PDC. This ensures that the PDC will authenticate half of the number of clients that it
would if the weight value remained at 100.
Active Directory assigns a default value of zero for the priority. By creating a new registry entry for the priority
and assigning it an increased value of 200, you can ensure that the PDC will never receive client authentication
requests unless it is the only accessible domain controller.
Caution
companion CD or at http://www.microsoft.com/reskit.
To change the weight for DNS SRV records by using the registry
3. Click Edit, click New, and then click DWORD value.
4. For the new entry name, type LdapSrvWeight, and then press ENTER. (The value name is not
case sensitive.)
5. Double-click the entry name you just typed. .
6. In the Edit DWORD Value dialog box, select Decimal as the Base option.
7. Enter a value between 0 and 65535 (the recommended value is 50), and then click OK.
8. Click File, and then click Exit to close the registry editor.
Adjusting the priority of the domain controller also reduces the number of client referrals. However, rather than
reducing it proportionally to the other domain controllers, changing the priority causes DNS to stop referring all
clients to this domain controller unless all domain controllers with a lower priority setting are unavailable.
Note
A lower value entered for LdapSrvPriority indicates a higher priority. A
domain controller with an LdapSrvPriority setting of 100 has a lower
priority than a domain controller with a setting of 10. Therefore, clients
attempt to use the domain controller with the setting of 10 first.
To change the priority for DNS SRV records by using the registry
3. Click Edit, click New, and then click DWORD value.
4. For the new entry name, type LdapSrvPriority, and then press ENTER.
5. Double-click the entry name that you just typed.
6. In the Edit DWORD Value dialog box, select Decimal as the Base option.
7. Enter a value between 0 and 65535 (the recommended value is 200), and then click OK.
8. Click File, and then click Exit to close the registry editor.
For more information about adjusting the weight or the priority of the PDC emulator, see the Active Directory
link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. Search under
“Administration and Configuration Guides” and download the Active Directory Operations Guide.
Upgrade Additional Domain Controllers

After you upgrade the operating system and install Active Directory on the Windows NT 4.0 PDC, add another
Windows Server 2003–based domain controller to the domain as soon as possible. This provides redundancy for
any clients running in the environment.
You can add additional domain controllers to the Windows Server 2003 domain by upgrading Windows NT 4.0–
based BDCs and installing Active Directory, or by adding Windows Server 2003–based member servers to the
domain and installing Active Directory on the member servers.
To complete the process for upgrading additional domain controllers, perform the following tasks:
2. Neutralize Windows NT 4.0 domain controller emulation.
3. Upgrade the operating system of Windows NT 4.0 BDCs.
5. Install DNS on additional domain controllers.
6. Reconfigure the DNS Service.
7. Add Windows NT 4.0 BDCs to the Windows Server 2003 domain if necessary.
Configure Protection Against Domain Controller Overload on

Additional Domain Controllers
To configure an additional domain controller against overload, perform the same steps that were performed to
configure protection on the Windows NT 4.0 PDC. Configure the domain controller to emulate a
Windows NT 4.0–based domain controller before you upgrade the operating system and install Active
Directory.
Caution

upgrade
Keep the registry editor open to perform the next step in the upgrade process.
Neutralize Windows NT 4.0 Domain Controller Emulation

On all additional domain controllers, you must be sure to neutralize Windows NT 4.0 emulation before
installing Active Directory. When deploying additional domain controllers, the computers must be able to
contact an Active Directory domain controller during the installation of Active Directory. If the Active Directory
domain controllers that you have already upgraded have been configured to protect against domain controller
overload by setting the value of the NT4Emulator registry entry to one, the additional domain controllers will
only recognize them as Windows NT 4.0–based domain controllers and the Active Directory installation will
fail.
Caution
To neutralize Windows NT 4.0 emulation

3. For the new entry name, type NeutralizeNT4Emulator, and then press ENTER.
You can also administer Windows Server 2003–based domain controllers that have been configured to emulate a
Windows NT 4.0–based domain controller from a workstation running Windows 2000 or Windows XP. If you
intend to use a management workstation that is running Windows 2000 or Windows XP, you must first
neutralize the emulation mode on the management workstation so that Windows Server 2003–based domain
controllers will respond to it.
Upgrade Windows NT 4.0 BDCs

You can upgrade any Windows NT 4.0 BDC to a Windows Server 2003–based domain controller as long as it
meets the hardware requirements for a domain controller running Windows Server 2003. For more information
about the hardware requirements for Windows Server 2003–based domain controllers, see “Planning Domain
Controller Capacity” in this book.
detect any upgrade problems. This tool reports potential upgrade problems, such as inadequate hardware
resources or compatibility problems.
Resolve reported problems before performing the upgrade.

Winnt32.exe command.
To complete the operating system installation, perform these tasks:
1. Select Upgrade for the Installation type.
2. Use NTFS to convert the partitions. The installation of Active Directory will not succeed if you
do not have at least one NTFS partition available on which to locate the SYSVOL shared folder.
3. Verify that you are using a static IP address.
4. On the first additional domain controller upgraded, configure DNS client settings by using the
IP address of the PDC for the Preferred DNS server setting and do not specify an IP address in
the Alternate DNS server setting.
On all remaining domain controllers that are upgraded, configure DNS client settings by using
the IP address of the PDC for the Preferred DNS server setting and use the IP address of the
second domain controller upgraded for the Alternate DNS server setting.
These DNS client settings are temporary and will be changed during the installation of Active
Directory.
5. Install Windows Support Tools, which are available in the \Support\Tools folder on the
During the operating system upgrade the computer will restart three times. After the computer restarts for the
last time, the Welcome to the Active Directory Installation Wizard appears.
Install Active Directory on the Additional Domain Controllers

The process for installing Active Directory on additional domain controllers is identical whether you upgraded
to a regional domain controller in an existing domain or upgraded to a single domain forest. After upgrading the
operating system on a Windows NT 4.0 additional domain controller to Windows Server 2003, the computer is
in an intermediate state, meaning that the computer is no longer a Windows NT 4.0–based domain controller,
nor is it a Windows Server 2003–based member server or domain controller.
The Active Directory Installation Wizard allows you to create an additional domain controller or a member
server in the new domain. If you will be installing Active Directory by replicating the directory data over the
network or from another media source, select the Member Server option in the Active Directory Installation
Wizard. Selecting Member Server will configure the computer to be a Windows Server 2003–based member
server, allowing you to install Active Directory at a later time.
To install Active Directory on a Windows Server 2003–based member server
• At the command prompt, type Dcpromo
– or –
Open Administrative Tools, and then click Configure Your Server Wizard. Select Domain
Controller (Active Directory) to configure your domain controller. After the Configure Your
Server Wizard finishes, the Active Directory Installation Wizard begins.
You can also install Active Directory by using the install from media feature, new in Windows Server 2003.
Install from media allows you to pre-populate Active Directory with System State data backed up from an
existing Windows Server 2003–based domain controller. This backup can be present on local CD, DVD, or hard
disk partition. Installing from media drastically reduces the time required to install directory data by reducing
the amount of data that is replicated over the network. Installing from media is most beneficial in environments
with very large domains or for installing new domain controllers that are connected by a slow network link.
To install Active Directory on a Windows Server 2003–based member server from
media
• Type dcpromo /adv in the Run dialog box.
The wizard prompts you to choose a network share or a backup as the installation source. If you
are installing from backup files, you must identify the location of the files. If the domain
controller from which you restored the System State data was a global catalog server, you will
have the option make this new domain controller a global catalog server. The wizard will then
proceed with the installation.
For more information about installing and removing Active Directory, see the Directory Services Guide in the
Windows Server 2003 Resource Kit (or see the Directory Services Guide on the Web at
Table 8.13 lists information for installing Active Directory on additional domain controllers, as well as sample
data for installing Active Directory on additional domain controllers in a regional domain in the existing Trey
Research forest or in the Fabrikam single domain forest. Trey Research will install Active Directory
immediately after upgrading the operating system. Fabrikam will use the dcpromo /adv command to install
Active Directory on a member server by copying directory data over the network from a domain controller.
Table 8.13 Installing Active Directory on Additional Domain Controllers
Wizard Page
Action Example
or Dialog Box
Additional Select whether you want Upgrading to a regional domain
Domain the computer to become a in an existing forest:
Controller or member server or an Trey Research will select
Member additional domain Additional domain controller to
Server controller for the domain. install Active Directory
immediately.
Upgrading to a single domain
forest:
Fabrikam will select Member
Server. They will install Active
Directory at a later time using the
dcpromo /adv command.
Domain Select Additional domain Upgrading to a regional domain
Controller controller for an existing in an existing forest:
Type domain. Trey Research will not see this
wizard page.
forest:
When Fabrikam initiates the
Active Directory Installation
Wizard by using the dcpromo
/adv command, this is the first
wizard page that appears.
Copying Select either: Upgrading to a regional domain
Domain • Over the network from a in an existing forest:
Information domain controller Trey Research will not see this
• From these restored wizard page because they chose
backup files to install Active Directory
immediately following the
operating system upgrade.
forest:
Fabrikam will copy domain
information from the first domain
controller that is deployed, SEA-
FAB-DC01, which is in the same
location as the new one.
Therefore, they selected Over the
network from a domain controller
to copy the information in the
shortest time.
(continued)
Table 8.13 Installing Active Directory on Additional Domain Controllers (continued)

Wizard Page
Action Example
or Dialog Box
Network Type the user name and
Credentials password of an account
with sufficient privileges to
install Active Directory on
this computer, and the fully
qualified domain name of
the domain in which the
computer will become an
additional domain
controller.
Additional Type the full DNS name of Upgrading to a regional domain
Domain the forest root domain. in an existing forest:
Controller Trey Research will not see this
wizard page. It appears only if
you are installing Active
Directory over the network from
a domain controller.
forest:
Fabricorp.fabrikam.com
Database and Type the folder locations Database folder:
Log Folders specified by your design. C:\Windows\NTDS
Log folder: D:\Logs
Shared Confirm or type the location C:\Windows\SYSVOL
System specified by your design.
Volume
Directory In the Password and
Service Confirm password boxes,
Restore Mode type any strong password.
Administratio
n Password
Note
All additional domain controllers added to a single domain forest should
be configured as Global Catalog servers. For more information about
global catalog server placement, see “Designing the Site Topology” in
this book.
Install DNS on Additional Domain Controllers

Install DNS on all Windows Server 2003–based domain controllers that are added to the domain.
To install DNS on additional domain controllers using the Windows Components
Wizard
1. Click Start, point to Settings, and click Control Panel.
2. Double click Add or Remove Programs, and then click Add/Remove Windows
Components.
3. In Components, select the Networking Services check box, and then click Details.
4. In Subcomponents of Networking Services, select the Domain Name System (DNS)
checkbox, click OK, and then click Next.
5. If prompted, in Copy files from, type the full path to the distribution files and then click OK.
The required files will be copied to your hard disk.
Reconfigure the DNS Service

After deploying additional domain controllers in either a new regional domain in an existing forest or in a single
domain forest, do the following to reconfigure the DNS service:
• Configure the DNS client settings of the first and subsequent domain controllers
After you have deployed an additional domain controller, modify the DNS client settings on the
first domain controller. Because no other domain controllers were running when you deployed
the first domain controller, modify the DNS client settings on the first domain controller to
include the additional domain controller. As you deploy more domain controllers, you might
also need to modify the Alternate DNS server setting specified on existing domain controllers
to ensure that this setting points to the closest DNS server.
• Update the DNS delegation
If you have delegated the DNS zone to an existing DNS server, update the DNS delegation for
the domain after you install the DNS Server service on new domain controllers.
Add Windows NT 4.0 BDCs to Windows Server 2003 Domain

If you have applications in your environment that can run only on a Windows NT 4.0–based domain controller
and if all the Windows NT 4.0 BDCs have been upgraded to Windows Server 2003 or the existing
Windows NT 4.0 BDC in your environment becomes unavailable, you might need to add an additional
Windows NT 4.0 BDC to your environment. You can do this by installing a new Windows NT 4.0 BDC in the
domain. Prior to installing the new Windows NT 4.0 BDC in the domain, you must first add the new computer
account to the Windows Server 2003 domain.
Note
You will not be able to install a new Windows NT 4.0–based BDC in
your environment if you have SMB packet signing and secure channel
signing enabled. If these security policies are enabled in your
environment, modify them before installing a new Windows NT 4.0–
based BDC. For information about modifying security policies, see
“Modify Security Policies” earlier in this chapter.
To add a Windows NT 4.0 BDC to a Windows Server 2003 domain

1. In Active Directory Users and Computers, right-click the Domain Controllers folder.
2. Point to New, and then click Computer.
3. Type the computer name of the BDC.
4. Ensure that the checkboxes are selected for Assign this computer account as a pre-
Windows 2000 Computer and Assign this computer account as a backup domain
controller.
5. Install the BDC in to the domain.

After each additional domain controller is deployed, verify that the upgrade was successful. Use the same tests
and tools that you used to verify that the upgrade of the Windows NT 4.0 PDC was successful. For more
information about developing a test plan, see “Develop a Test Plan” earlier in this chapter.
Also verify that DNS recursive name resolution is configured according to your organization’s DNS design. For
more information about verifying recursive name resolution, see “Verify DNS Server Recursive Name
Resolution” earlier in this chapter.
Completing Post-Upgrade Tasks

After you upgrade all domain controllers in the domain to Windows Server 2003, complete the post-upgrade
tasks. These tasks are the final step in the process for upgrading Windows NT 4.0 Domains to Windows
Server 2003 Active Directory, as shown in Figure 8.10.
Figure 8.10 Completing Post-Upgrade Tasks
Eliminate Anonymous Connections to

Domain Controllers
After you upgrade all the servers in the domain hosting services that run as Local System and use Anonymous
or null credentials when accessing a domain controller, such as Windows NT 4.0 RAS servers, remove the
Everyone and Anonymous Logon groups from the Pre-Windows 2000 Compatible Access built-in group. This
task increases the security of your domain by preventing anonymous connections to domain controllers.
To remove groups from the Pre-Windows 2000 Compatible Access Group using
the command line
• At a command prompt, type:
net localgroup “Pre-Windows 2000 Compatible Access” GroupName /delete
When using the net localgroup command to add or delete any group or group member name that includes
spaces, such as the Anonymous Logon group, you must enclose the group name in quotation marks.
Raise Domain and Forest Functional Levels

Although the Windows Server 2003 domain functional level provides a number of features and advantages,
enable this functional level only when all your Windows NT 4.0 BDCs have been upgraded and you are certain
that your environment is ready.
Important
If you raise the domain and forest functional levels to
Windows Server 2003, this action cannot be reversed and you cannot
add Windows NT 4.0–based or Windows 2000–based domain
controllers to the environment. Any existing Windows NT 4.0 or
Windows 2000–based domain controllers in the environment will no
longer function. Before you raise functional levels to take advantage of
advanced Windows Server 2003 features, ensure that you will never
need to install domain controllers that run Windows NT 4.0 or
Windows 2000 in your environment.
After you determine that your environment is ready, use Active Directory Domains and Trusts to enable the
Windows Server 2003 domain functional level.
After all domains are operating at the Windows Server 2003 functional level, raise the forest functional level to
Windows Server 2003 to take advantage of all Windows Server 2003 forest-level features.
For more information about enabling functional levels and the features available at the Windows Server 2003
domain and forest functional levels, see “Enabling Advanced Windows Server 2003 Active Directory Features”
in this book.
Redirect the Users and Computers

Containers
The default CN=Users and CN=Computers containers that are created when Active Directory is installed are not
organizational units (OUs). Objects in the default containers are more difficult to manage because Group Policy
cannot be applied directly to them. New user accounts, computer accounts, and security groups that are created
by using earlier versions of user interface and command-line management tools, such as the net user and net
computer commands, the net group command, the netdom add command where the /ou command is either not
specified or supported, or Windows NT 4.0 tools such as User Manager for Domains, do not allow
administrators to specify a target organizational unit and therefore create these objects in either the
CN=Computers container or the CN=User container by default.
It is recommended that administrators who upgrade Windows NT 4.0–based and Windows 2000–based domain
controllers to Windows Server 2003 redirect the well-known path for the CN=Users and CN=Computers to an
OU that is specified by the administrator so that Group Policy can apply to containers that are hosting newly
created objects.
Important
The CN=Users and CN=Computers containers are computer-protected
objects. You cannot (and must not) remove them for backward
compatibility purposes. However, you can rename these objects.
In Windows Server 2003 Active Directory, when the domain functional level has been raised to Windows
Server 2003, you can redirect the default CN=Users and CN=Computers containers to organizational units that
you specify so that each can support Group Policy, making them easier to manage.
To redirect the Users container
1. In Active Directory Users and Computers, create an organizational unit container to which you
will redirect users that were created with earlier versions of user interface and command-line
management tools.
2. At the command line, change to the system32 directory by typing:
Cd %systemroot%\system32
3. At the %systemroot%\system32 directory, type:

Redirusr ou=newuserou,DC=domainname,dc=com
To redirect the Computers container

1. In Active Directory Users and Computers, create an organizational unit container to which you
will redirect computer objects that were created with earlier versions of user interface and
command-line management tools.
2. At the command line, change to the system32 directory by typing:
Cd %systemroot%\system32
3. At the %systemroot%\system32 directory, type:

Redircmp ou=newcomputerou,DC=domainname,dc=com
For more information about creating an organizational unit design, see “Designing the Active Directory Logical
Structure” in this book.
Completing the Upgrade

Complete the following tasks to finalize the process:
• Review, update, and document the domain architecture to reflect any changes that you made
during the in-place domain upgrade process.
• Review your operating procedures and administrative tasks to determine whether new Windows
Server 2003 features, such as Group Policy objects or distributed administration, affect the
operations environment. Be sure to document any changes that you identify.
• Remove the FRS script from the domain controller that you scheduled to provide the daily
script export to an LMRepl server.
• After you ensure that your Windows Server 2003 Active Directory environment is operating
successfully for a period of time, you can redeploy the rollback server that you reserved for the
recovery process. If you do not need the Windows NT 4.0 BDC to achieve the required load
balance among your domain controllers, maintain the rollback server for one week. Maintain
the backup of the rollback server for a longer period of time to be safe.
• Some Windows NT 4.0 applications, such as Microsoft® Systems Management Server (SMS),
can have an unpredictable effect on the domain when installed after the domain has been
upgraded to Active Directory. Ensure that you are running SMS 2.0 and have installed Service
Pack 4. For more information about SMS, see the SMS Downloads link on the Web Resources
page at http://www.microsoft.com/windows/reskits/webresources.
After the above tasks have been completed successfully, you will have completed the in-place upgrade process.
Additional Resources
These resources contain additional information and tools related to this chapter.
Related Information
• “Restructuring Windows NT 4.0 Domains to an Active Directory Forest” in this book for more
information about restructuring domains when upgrading from Windows NT 4.0 to Windows
Server 2003.
• “Designing the Active Directory Logical Structure” in this book for more information about the
Active Directory logical structure.
• “Designing the Site Topology” in this book for more information about Active Directory site
topology.
• “Enabling Advanced Windows Server 2003 Active Directory Features” in this book for more
information about enabling functional levels.
• “Deploying DNS” in Deploying Network Services for more information about deploying DNS.
Related Tools
• Adsiedit.exe
The ADSI Edit tool (Adsiedit.exe) is a Microsoft Management Console snap-in that you can use
to edit objects in the Active Directory database. For more information about Adsiedit.exe, in
Help and Support Center for Windows Server 2003, click Tools, and then click Windows
Support Tools.
• Ldp.exe
Ldp.exe provides an interface to perform LDAP operations against Active Directory. For more
information about Ldp.exe, in Help and Support Center for Windows Server 2003, click Tools,
and then click Windows Support Tools.
Related Help Topics
For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set
search options. Under Help Topics, select the Search in title only check box.
• “Active Directory” in Help and Support Center for Windows Server 2003.
• “Windows Support Tools” under “Tools” in Help and Support Center for Windows Server 2003.
• “Configure site settings” in Help and Support Center for Windows Server 2003 for more
information about creating site objects, subnet objects, and associating subnets with sites.
• “Understanding aging and scavenging” in Help and Support Center for Windows Server 2003
for more information about how to configure aging and scavenging of stale resource records.
Related Job Aids

• “Windows NT 4.0 Domain Controllers and Services” (DSSUPNT_1.doc) on the Windows
Server 2003 Deployment Kit companion CD (or see “Windows NT 4.0 Domain Controllers and
Services” on the Web at http://www.microsoft.com/reskit).
• “Windows NT 4.0 Hardware Configuration” (DSSUPNT_2.doc) on the Windows Server 2003
Deployment Kit companion CD (or see “Windows NT 4.0 Hardware Configuration” on the Web
at http://www.microsoft.com/reskit).
• “Windows NT 4.0 Network Configuration” (DSSUPNT_3.doc) on the Windows Server 2003
Deployment Kit companion CD (or see “Windows NT 4.0 Network Configuration” on the Web
at http://www.microsoft.com/reskit).
• “Windows NT 4.0 Domain Controller Role Assignment” (DSSUPNT_4.doc) on the Windows
Server 2003 Deployment Kit companion CD (or see “Windows NT 4.0 Domain Controller Role
Assignment” on the Web at http://www.microsoft.com/reskit).
• “Windows NT 4.0 Domain Controller Documentation” (DSSUPNT_5.xls) on the Windows
Server 2003 Deployment Kit companion CD (or see “Windows NT 4.0 Domain Controller
Documentation” on the Web at http://www.microsoft.com/reskit).

Upgrading Windows NT 4

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Upgrading Windows NT 4

Uploaded by

Copyright:

Available Formats

C H A P T E R 8

Process for Upgrading Windows NT 4.0

Background Information for Upgrading to

PDC Offline Operations

Full Synchronization of the Local Security Authority Database

Domain Users and Client Workstation Operating Systems

To add the Anonymous Logon group to the Pre-Windows 2000

LAN Manager Replication Service and the File Replication Service

Security Policy Considerations when Upgrading from Windows NT 4.0

Collecting Design Information

Document the Existing Environment

Figure 8.3 Example of a Windows NT 4.0 Domain Diagram

In addition to documenting the existing domain structure, document the following:

Document Domain Controllers and Services

Example: Documenting Windows NT 4.0 Domain Controllers and

Document the Existing Hardware Configuration

Example: Documenting the Windows NT 4.0 Hardware Configuration

Document the Existing Network Configuration

Figure 8.6 Example of a Windows NT 4.0 Network Configuration Worksheet

Document Domain Controller Role Assignments

Determine the Domain Upgrade Order

Determine Supported Operating System

Develop a Test Plan

Table 8.3 Active Directory Functionality Test Components

Develop a Recovery Plan

Restoring the Domain to its Original State

4. Test Windows NT 4.0 server operations and domain validation.

Completing Pre-Upgrade Tasks

Relocate the LMRepl File Replication

Ensure Remote Access Service

Enable the Windows NT 4.0 Environment

Upgrading Domains from

Upgrade to a Regional Domain in an Existing

Back Up the Domain Data

Enable the Windows Server 2003 Interim Forest Functional

Delegate the DNS Zone for the New Regional Domain

Configure Protection Against Domain Controller Overload

To configure emulation on a Windows NT 4.0–based domain controller before

Upgrade the Operating System of the Windows NT 4.0 PDC

Resolve any reported problems before performing the upgrade.

Install Active Directory

Verify DNS Server Recursive Name Resolution

Perform Post-Upgrade Tests

Upgrade to a Single Domain Forest

Back Up the Domain Data

Delegate the DNS Zone for the Windows Server 2003

Configure Protection Against Domain Controller Overload

To configure emulation on a Windows NT 4.0–based domain controller before

Upgrade the Operating System of the Windows NT 4.0 PDC

Resolve reported problems before performing the upgrade.

Install Active Directory

Configure the Site Topology

Configure the Windows Time Service on the Forest Root

Net start w32time

Enable Aging and Scavenging for DNS

To set aging and scavenging properties for a zone

Verify DNS Server Recursive Name Resolution

Perform Post-Upgrade Tests

Modify Security Policies

To make SMB packet and secure channel signing optional on Windows

Synchronize File Replication Services

The FRS - LMRepl Replication Bridge dialog box opens.

Use DNS Registration to Decrease the