Upgrading Windows 2000 Domains To Windows Server 2003 Domain

C H A P T E R 9
Upgrading
Windows 2000 Domains
to Windows Server 2003
Domains
Upgrading your network operating system from Microsoft® Windows® 2000 to Windows® Server 2003 requires
minimal network configuration and typically has a low impact on user operations. The upgrade process is
straightforward, efficient, and allows your organization to take advantage of the improved security that is
offered by Windows Server 2003.
In This Chapter
Overview of Upgrading Your Windows 2000 Domains to Windows Server 2003 Domains
........................................................................................................................... .100
Planning to Upgrade Windows 2000 Domains to Windows Server 2003 Domains108
Completing Pre-Upgrade Tasks.................................................................... ........117
Upgrading Windows 2000 Domains to Windows Server 2003 Domains...............127
Completing Post-Upgrade Tasks.................................................... ......................136
Additional Resources.............................................................................. .............140
Related Information
• For more information about designing the Active Directory® directory service logical structure
and the DNS infrastructure needed to support Active Directory, see “Designing the Active
Directory Logical Structure” in this book.
• For more information about Active Directory functional levels, see “Enabling Advanced
Windows Server 2003 Active Directory Features ” in this book.
• For more information about upgrading from Microsoft® Windows NT® version 4.0 to Windows
Server 2003 Active Directory, see “Upgrading Windows NT 4.0 Domains to Windows
Server 2003 Active Directory” in this book.
• For more information about deploying a DNS infrastructure for name resolution on your
network, see “Deploying DNS ” in Deploying Network Services of this kit.
100 Chapter 9 Upgrading Windows 2000 Domains to Windows Server 2003 Domains
Overview of Upgrading Your

Windows 2000 Domains to
Windows Server 2003 Domains
By upgrading your network operating system from Microsoft® Windows® 2000 Server to the Microsoft®
Windows® Server 2003, Standard Edition; Windows® Server 2003, Enterprise Edition; or Windows®
Server 2003, Datacenter Edition operating system, you can maintain your current network and domain
configuration while improving the security, scalability, and manageability of your network infrastructure.
Prior to upgrading your Windows 2000 domains, review your business objectives and decide how they relate to
your existing Active Directory infrastructure. Although your objectives might not require other significant
changes to your existing environment, the operating system upgrade is an opportune time to review your
existing Active Directory design, including your Active Directory logical structure, site topology, and domain
controller capacity. You might find opportunities for increased efficiencies and cost savings that you can
incorporate into your upgrade process.
Additionally, ensure that you test your upgrade process in a lab and pilot program. For more information about
lab testing and piloting, see “Planning an Active Directory Deployment Project” in this book.
When the domain upgrade process is complete, all domain controllers will be running Windows Server 2003,
and the Active Directory domain and forest will be operating at the Windows Server 2003 functional level. At
the Windows Server 2003 forest functional level, you can take advantage of all advanced Active Directory
features. For more information about advanced Active Directory features related to Active Directory functional
levels, see “Enabling Advanced Windows Server 2003 Active Directory Features” in this book.
Additional Resources 101
Note
For a list of the job aids that are available to assist you in upgrading
from Windows 2000 Server to Windows Server 2003, see “Additional
Resources” later in this chapter.
Process for Upgrading Windows 2000

Domains to Windows Server 2003 Domains
Upgrading your Windows 2000 Active Directory environment to a Windows Server 2003 Active Directory
environment involves completing several tasks. Figure 9.1 shows the tasks in the upgrade process.
Figure 9.1 Upgrading Windows 2000 Domains to Windows Server 2003 Domains
Background Information for Upgrading

Windows 2000 Domains to Windows
Server 2003 Domains
Before you begin the process of upgrading your Windows 2000 Active Directory environment to Windows
Server 2003 Active Directory, become familiar with some important issues that affect the upgrade process.
Active Directory Preparation Tool

To prepare your Windows 2000 forest and domains for upgrade to Windows Server 2003 Active Directory, or
for the introduction of a new Windows Server 2003–based domain controller, you must use the Active Directory
Preparation tool (Adprep.exe). Adprep.exe is located on the Windows Server 2003 operating system CD.
Adprep.exe prepares the forest and domains for an Active Directory upgrade by performing a collection of
operations prior to the installation of the first Windows Server 2003–based domain controller, including:
• Extending your current schema with new schema information that Adprep.exe provides, while
preserving previous schema modifications in your environment.
• Resetting permissions on containers and objects throughout the directory for improved security
and interoperability with new Windows Server 2003 domains.
• Copying administrative tools to manage new Windows Server 2003 domains to the local
computer.
Note
Changes made by Adprep.exe do not affect the functioning of
Windows NT 4.0–based or Windows 2000–based domain controllers.
For more information about using Adprep.exe to prepare your environment, see “Prepare Your Infrastructure for
Upgrade” later in this chapter.
Application Directory Partitions for DNS

Application directory partitions provide storage for application-specific data that can be replicated to a specific
set of domain controllers in the same forest. If you have at least one domain controller in your forest running
Windows Server 2003 and the domain naming master is also running Windows Server 2003, you can take
advantage of application directory partitions.
For example, you can use application directory partitions to store DNS data on Windows Server 2003–based
domain controllers. DNS-specific application directory partitions are automatically created in the forest and in
each domain when the DNS service is installed on new or upgraded Windows Server 2003–based domain
controllers. If application directory partition creation fails during Active Directory installation, DNS attempts to
create the partitions again every time that the service starts.
Note
The creation and deletion of application directory partitions, including
the default DNS application directory partitions, requires that the
domain naming master role holder reside on a Windows Server 2003–
based domain controller.
The following DNS-specific application directory partitions are created during Active Directory installation:
• ForestDnsZones — A forest-wide application directory partition shared by all DNS servers in
the same forest
• DomainDnsZones — Domain-wide application directory partitions for each DNS server in the
same domain
SRV resource records
A Windows Server 2003–based domain controller’s Net Logon service uses dynamic updates to register SRV
resource records in the DNS database, as described in “A DNS RR for specifying the location of services (DNS
SRV).” For more information about this draft, see the Internet Engineering Task Force (IETF) web page. This
SRV record is used to map the name of a service, such as the Lightweight Directory Access Protocol (LDAP)
service, to the DNS computer name of a server that offers that service. In a Windows Server 2003 network, an
LDAP resource record locates a domain controller. A workstation that is logging on to a Windows Server 2003
domain queries DNS for SRV records in the general form:
_Service._Protocol.DnsDomainName
where Service is the service requested, Protocol is the protocol requested, and DnsDomainName is the fully
qualified DNS name of the Active Directory domain.
Active Directory servers offer the LDAP service over the TCP protocol; therefore, clients find an LDAP server
by querying DNS for a record of the form:
_ldap._tcp.DnsDomainName
Note
The service and protocol strings require an underscore (_) prefix to
prevent potential collisions with existing names in the namespace.
This format is applicable for implementations of LDAP servers other than Windows Server 2003–based domain
controllers and also possible implementations of LDAP directory services that employ Global Catalog servers
other than servers running Windows Server 2003.
_msdcs.domain_name subdomain
This Microsoft-specific subdomain allows location of domain controllers that have Windows Server 2003–
specific roles in the domain, as well as the location by globally unique identifier (GUID) when a domain has
been renamed.
To facilitate location of Windows Server 2003–based domain controllers, the Net Logon service in addition to
the standard _Service._Protocol.DnsDomainName format records , also registers SRV records that identify the
well-known server-type pseudonyms “dc” (domain controller), “gc” (Global Catalog), “pdc” (primary domain
controller), and “domains” (GUID) as prefixes in the _msdcs.domain_name subdomain. To accommodate
locating domain controllers by server type or by GUID (abbreviated “dctype”), Windows Server 2003–based
domain controllers register SRV records in the following form in the _msdcs.domain_name subdomain:
_Service._Protocol.DcType._msdcs.DnsDomainName
_msdcs.forest_root_domain subdomain
The _msdcs.forest_root_domain subdomain stores forest-wide resource records that are of interest to clients and
domain controllers from all parts of the forest. For example, all domain controllers in the forest register
CNAME and LDAP, Kerberos, and GC SRV resource records in the msdcs.forest_root_domain subdomain. The
CNAME resource records are used by the replication system to locate replication partners and the GC SRV
resource records are used by clients to lookup global catalog servers.
For any two domain controllers to replicate with each other, including two domain controllers from the same
domain, they must be able to look up forest-wide locator records. For a newly created domain controller to
participate in replication, it must be able to register its forest-wide records in DNS, and other domain controllers
must be able to look up these records. Therefore, the DNS servers that are authoritative for the
_msdcs.forest_root_domain subdomain needs to be available for replication and global catalog lookups.
For this reason, it is recommended that you create a separate _msdcs.forest_root_domain zone and define its
replication scope so that it is replicated to all DNS servers in the forest. For more information about creating a
separate _msdcs.forest_root_domain zone, see KB article 817470. To find this article, see the Microsoft
Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
Some organizations running Windows 2000 Active Directory already created an _msdcs.forest_root_domain to
help clients locate domain controllers more efficiently. If an _msdcs.forest_root_domain already exists in your
Windows 2000 environment, then it is recommended that you move the zone to the ForestDnsZones application
directory partition after all domain controllers in the forest are running Windows Server 2003. In addition, for
each domain in the forest, move the _msdcs.domain_name zone to the DomainDnsZones application directory
partition for that domain.
Moving the Active Directory–integrated DNS zones into the domain and forest-wide application directory
partitions provides the following benefits:
• Because the forest-wide application directory partition can replicate outside a specified domain,
and because moving the _msdcs.forest_root_domain into the forest-wide application directory
partition replicates it to all domain controllers in the forest that are running the DNS service,
you do not have to use DNS zone transfer to replicate the zone file information to DNS servers
outside the domain.
• Domain-wide replication can be targeted to minimize replication traffic because administrators
can specify which of the domain controllers running the DNS service receive the DNS zone
data.
• Forest-wide replication can be targeted to minimize replication traffic because DNS data is no
longer replicated to the global catalog.
• DNS records located on global catalog servers in the forest are removed, minimizing the
amount of information replicated with the global catalog.
For more information about using application directory partitions to store DNS data, see “Use DNS Application
Directory Partitions” later in this chapter.
Intrasite Replication Frequency

Windows 2000 domain controllers that are upgraded to Windows Server 2003 maintain their default intrasite
replication frequency of 300/30. This means that any changes made to Active Directory replicate to all other
domain controllers in the same site five minutes (300 seconds) after a change is made, with a 30-second offset
before notifying the next domain controller, until the forest functional level is raised to Windows Server 2003.
When the forest functional level is raised to Windows Server 2003, the replication frequency of Active
Directory is changed to the Windows Server 2003 default setting of 15/3. This means that changes will replicate
to all domain controllers in the same site 15 seconds after a change is made, with a 3-second offset before
notifying the next domain controller. If you modified the 300/30 default replication frequency setting in
Windows 2000, the setting does not change to the 15/3 default setting in Windows Server 2003 after you
complete the upgrade. However, a new installation of Windows Server 2003 will always use the 15/3 intrasite
replication frequency setting.
Important
Do not modify the default 300/30 intrasite replication frequency on
Windows 2000 domain controllers. Instead, upgrade your
Windows 2000 domain to Windows Server 2003 and raise the forest
functional level to Windows Server 2003 to take advantage of the 15/3
intrasite replication frequency.
New Groups and New Group Memberships Created After Upgrading

the PDC
After upgrading the Windows 2000–based domain controller holding the role of the PDC emulator in each
domain in the forest to Windows Server 2003, several new well-known and built-in groups are created and some
new group memberships are established. If you transfer the PDC emulator role to a Windows Server 2003–
based domain controller instead of upgrading it, these groups will be created when the role is transferred. The
new well-known and built-in groups are:
• Builtin\Remote Desktop Users
• Builtin\Network Configuration Operators
• Performance Monitor Users
• Performance Log Users
• Builtin\Incoming Forest Trust Builders
• Builtin\Performance Monitoring Users
• Builtin\Performance Logging Users
• Builtin\Windows Authorization Access Group
• Builtin\Terminal Service License Server
The newly established group memberships are:
• If the Everyone group is in the Pre-Windows 2000 Compatible Access group, the Anonymous
Logon group and Authenticated Users group are also added to the Pre-Windows 2000
Compatible Access group.
• The Network Servers group is added to the Performance Monitoring alias.
• The Enterprise Domain Controllers group is added to the Windows Authorization Access group.
In addition, when upgrading the Windows 2000 domain controller that holds the role of the PDC emulator in the
forest root domain, the following additional security principals are created:
• LocalService
• NetworkService
• NTLM Authentication
• Other Organziation
• Remote Interactive Logon
• SChannel Authentication
• This Organization
For more information about new well-known and built-in groups in Windows Server 2003, see “Default groups”
in Help and Support Center for Windows Server 2003.
Security Policy Considerations When Upgrading from Windows 2000

to Windows Server 2003
Server message block (SMB) packet signing and secure channel signing are security policies 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 (SP2) 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 allowed 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.
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 (SP3) 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.
For more information about configuring secure channel signing on Windows Server 2003–based domain
controllers, see “Modify Security Policies” later in this chapter.
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.
Planning to Upgrade
Windows 2000 Domains to
Planning to upgrade your Windows 2000 environment to Windows Server 2003 Active Directory involves
completing the tasks and procedures that are shown in Figure 9.2.
Figure 9.2 Planning to Upgrade Windows 2000 Domains to
Create a Pre-Upgrade Task Checklist

You can create a pre-upgrade task checklist to help organize the tasks necessary to prepare for a successful
domain upgrade. In your checklist, include the tasks listed in the sample checklist in Figure 9.3, in addition to
any additional tasks specific to your organization.
For a worksheet to assist you in creating your own pre-upgrade task checklist, see “Pre-Upgrade Task
Checklist” (DSSUPWN_1.doc) on the Microsoft® Windows® Server 2003 Deployment Kit companion CD (or
see “Pre-Upgrade Task Checklist” on the Web at http://www.microsoft.com/reskit).
Figure 9.3 Example of a Pre-Upgrade Task Checklist
Assign Appropriate Credentials

Assign appropriate credentials to the users who are responsible for preparing the forest and domain for an
Active Directory upgrade. The adprep /forestprep command requires a user account that is a member of the
Schema Admins, Enterprise Admins, and Domain Admins groups. The adprep /domainprep command requires
a user account that is a member of the Domain Admins group in the targeted domain.
Additionally, the security context can affect the ability of an administrator to complete the upgrade from
Windows 2000 to Windows Server 2003. Members of the Builtin\Administrators group can upgrade the
operating system and install software on a computer. The following groups are members of the
Builtin\Administrators group by default:
• The Enterprise Admins group is a member of Builtin\Administrators in the forest root domain
and in each regional domain in the forest.
• The Domain Admins group is a member of Builtin\Administrators in their domain.
• The Domain Admins group is a member of Builtin\Administrators on member servers in their
domain.
Table 9.1 shows the credentials that are required to upgrade servers, depending on the domain membership of
the servers.
Table 9.1 Credentials Required to Upgrade Servers to Windows Server 2003
Domain Member Domain Member
Controller in Server in Controller in Server in
Credential
Forest Root Forest Root Regional Regional
Domain Domain Domain Domain
Enterprise
Admins in forest
root domain
Domain Admins
in forest root
domain
Builtin\Administr
ators in forest
root domain
Domain Admins
in regional
domain
Builtin\Administr
ators in regional
domain
You also need to ensure that the administrator who is upgrading the domain controllers has the following rights:
• Backup files and directories (SE_BACKUP_NAME)
• Modify firmware environment values (SE_SYSTEM_ENVIRONMENT_NAME)
• Restore files and directories (SE_RESTORE_NAME)
• Shut down the system (SE_SHUTDOWN_NAME)
The setup program cannot run properly if these rights are not defined, or if they are disabled by a domain Group
Policy setting on the computer.
To verify if user rights assignments are disabled by a domain Group Policy
setting
1. In the Run dialog box, type mmc, and then click OK.
2. Click File, and then click Add/Remove snap-in.
3. In the Add/Remove snap-in dialog box, click Add.
4. In the Available Standalone snap-ins dialog box, select Group Policy, and then click Add.
5. At the Welcome to the Group Policy Wizard screen, verify that Local Computer appears in the
Group Policy Object: box, and then click Finish.
6. Close the Add/Remove snap-in dialog box and the Add Standalone snap-in dialog box.
7. In the Console Root, navigate to the Local Computer Policy\Computer Configuration\Windows
Settings\Security Settings\Local Policies\User Rights Assignment folder.
8. In the details pane, verify that the user who will perform the upgrade is a member in one of the
groups that has the necessary rights assigned. The policies are named identically to the user
rights listed above.
Assign the appropriate credentials in advance to allow both testing and deployment to proceed without
unexpected security delays.
Introduce a Windows Server 2003–Based

Member Server
Before you begin the domain upgrade process, introduce a Windows Server 2003–based member server into
your environment. Installing Active Directory on a Windows Server 2003–based member server facilitates the
domain upgrade process by allowing all existing services to run uninterrupted while you are upgrading to
Windows Server 2003 Active Directory.
You can introduce the member server to any domain in the forest; however, if your forest root domain is a
dedicated root, it is recommended that you introduce the member server into the forest root domain. Placing the
member server into a dedicated root domain has the lowest impact on your environment because users generally
do not log on to a dedicated forest root domain; therefore, user authentications are minimal.
After you prepare the Windows 2000 forest and domain by using the Active Directory Preparation tool, install
Active Directory on the member server, creating an additional domain controller in the existing domain. The
Windows Server 2003–based member server will become the first Windows Server 2003–based domain
controller in the forest.
Determine Supported Software Upgrades

Identify the versions of Windows 2000 that are running in your environment, and then determine whether you
can upgrade the operating system on your computers to Windows Server 2003, or whether you must perform a
clean operating system installation.
Table 9.2 lists the Windows 2000 operating system platforms and indicates which platforms can be upgraded
directly to each version of Windows Server 2003.
Table 9.2 Supported Upgrade Paths to Windows Server 2003

Upgrade to Upgrade to
Upgrade to
Windows Windows
Windows
Platform Server 2003, Server 2003,
Server 2003,
Enterprise Datacenter
Standard Edition
Edition Edition
Microsoft®
Windows® 2000
Professional
Windows 2000 Server
Microsoft®
Windows® 2000
Advanced Server
Microsoft®
Windows® 2000
Datacenter Server
Assess Hardware Requirements

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
necessary to run Windows Server 2003. You can retain domain controllers that do not meet the necessary
hardware requirements to serve as rollback servers in the event that you must roll back your deployment. In
most cases, a Windows 2000–based domain controller meets the requirements to be upgraded to Windows
Server 2003, as long as it has adequate disk space.
At minimum, a domain controller requires available free disk space for the Active Directory database, Active
Directory log files, SYSVOL, and the operating system. Use the following guidelines to determine how much
disk space to allot for your Active Directory installation:
• On the drive that will contain the Active Directory database, NTDS.dit, provide 0.4 gigabytes
(GB) of storage for each 1,000 users. For example, for a forest with two domains (domain A,
domain B), with 10,000 and 5,000 users respectively, provide a minimum of 4 GB of disk space
for each domain controller that hosts domain A and a minimum of 2 GB of disk space for each
domain controller that hosts domain B. Available space must equal at least 10 percent of your
existing database size, or at least 250 megabytes (MB), whichever is greater.
• On the drive containing the Active Directory log files, provide at least 500 MB of available
space.
• On the drive containing the SYSVOL shared folder, provide at least 500 MB of available space.
• On the drive containing the Windows Server 2003 operating system files, to run setup, provide
at least 1.25 GB to 2 GB of available space.
For more information about assessing the hardware requirements of domain controllers in a Windows
Server 2003 domain, see “Planning Domain Controller Capacity” in this book.
Determine Domain Controller Upgrade Order

Determine the order in which you will upgrade your domain controllers before beginning the domain upgrade
process. Record the name, IP address, the domain in which the domain controller will be located, and the
operations master roles held by each domain controller before and after the upgrade. Finally, record the order in
which you will upgrade the operating system on each domain controller.
The recommended order for upgrading domain controllers from Windows 2000 to Windows Server 2003 is:
• Install Active Directory on a Windows Server 2003–based member server in the forest root
domain by using the Active Directory Installation Wizard. This creates the first Windows
Server 2003–based domain controller.
• Upgrade the operating system on the Windows 2000–based domain controller holding the role
of domain naming master. If you choose not to upgrade the domain controller, transfer the
domain naming master role to a domain controller running Windows Server 2003.
• Upgrade the domain controller that holds the PDC emulator role in each domain, or transfer the
roles to Windows Server 2003–based domain controllers.
• Continue upgrading all Windows 2000–based domain controllers to Windows Server 2003 until
the domain upgrade is complete.
Note
This order for upgrading or installing Windows Server 2003 domain
controllers is a recommendation only. It is safe to upgrade the domain
controllers holding the domain naming master and PDC emulator roles
at any time in the upgrade process.
Use a domain controller documentation table to document information about each domain controller in the
forest. For a worksheet to assist you in documenting your domain controller information, see “Windows 2000
Domain Controller Documentation” (DSSUPWN_2.doc) on the Windows Server 2003 Deployment Kit
companion CD (or see “Windows 2000 Domain Controller Documentation” on the Web at
http://www.microsoft.com/reskit).
Figure 9.4 shows an example of a completed domain controller documentation table for Contoso.
Figure 9.4 Example of a Windows 2000 Domain Controller Documentation Table
Develop a Test Plan

It is important to develop a plan for testing your domain upgrade procedures throughout the upgrade process.
Before you begin, test your existing domain controllers to ensure that they are functioning properly, and
continue to test your domain controllers throughout the process to verify that Active Directory replication is
consistent and successful.
Many of the tools required to verify your domain upgrade procedures are located in the Support\Tools folder on
the Windows Server 2003 operating system CD. Install the Windows Server 2003 support tools on a client
computer running Microsoft® Windows® XP Professional or on a Windows Server 2003–based member server.
Table 9.3 lists the tools and log files to use in your test plan.
Table 9.3 Tools and Logs Used to Test Domain Upgrade Procedures
Tool / Log File Description Location
Repadmin.exe Checks replication consistency Windows Server 2003
and monitors both inbound and operating system CD in
outbound replication partners. the Support\Tools
Displays replication status of folder.
inbound replication partners and
directory partitions.
Dcdiag.exe Diagnoses the state of domain Windows Server 2003
controllers in a forest or operating system CD in
enterprise, tests for successful the Support\Tools
Active Directory connectivity and folder.
functionality, and returns the
results as passed or failed.
Netdiag.exe Diagnoses networking and Windows Server 2003
connectivity problems by operating system CD in
performing a series of tests to the Support\Tools
determine the state of your folder.
network client and whether it is
functional.
Nltest.exe Queries and checks the status of Windows Server 2003
trusts and can forcibly shut operating system CD in
down domain controllers. the Support\Tools
folder.
Dnscmd.exe Provides the properties of DNS Windows Server 2003
servers, zones, and resource operating system CD in
records. the Support\Tools
folder.
Adprep Log Provides a detailed progress %systemroot%\System3
report of the forest and domain 2\Debug\Adprep folder.
preparation process.
Dcpromoui.log Provides a detailed progress %systemroot%\Debug
and report of the Active Directory folder.
Dcpromo.log installation. Includes information
regarding replication and
services in addition to applicable
error messages.
Adsiedit.exe A Microsoft Management Windows Server 2003
Console (MMC) snap-in that acts operating system CD in
as a low-level editor for Active the Support\Tools
Directory and allows you to view, folder.
add, delete, and move objects
and attributes within the
directory.
For more information about Windows Support Tools, in Help and Support Center for Windows Server 2003,
click Tools, and then click Windows Support Tools.
Create a test matrix that meets your needs, based on the services that you require to support your environment.
For a worksheet to assist you in documenting your test matrix, see “Windows 2000 Upgrade Test Matrix”
(DSSUPWN_3.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Windows 2000
Upgrade Test Matrix” on the Web at http://www.microsoft.com/reskit).
Figure 9.5 shows an example of a completed upgrade test matrix.
Figure 9.5 Example of a Windows 2000 Upgrade Test Matrix
Develop a Recovery Plan

Develop a recovery plan for use in the event that some portion of your domain upgrade process fails. A
successful recovery plan includes:
• Step-by-step instructions, so that the upgrade team can restore normal operations to the
organization.
• A sign-off process, ensuring that all team members review, agree upon, and sign off on the
recovery plan.
For more information about developing a recovery plan, see the Active Directory Disaster Recovery link on the
Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
Completing Pre-Upgrade Tasks

Prior to upgrading your Windows 2000 environment to Windows Server 2003 Active Directory, you must
complete several pre-upgrade tasks.
Figure 9.6 shows the process for completing pre-upgrade tasks.
Figure 9.6 Completing Pre-Upgrade Tasks
Determine Service Pack Levels

Before preparing your infrastructure for upgrade and installing the Windows Server 2003 operating system, all
Windows 2000–based domain controllers in the forest must be running Windows 2000 Service Pack 1 (SP1)
with QFE 265089, or Windows 2000 SP2 (or later).
QFE 265089 (included in Windows 2000 SP2 and later) is required to prevent potential domain controller
corruption. Use the repadmin /showattr command to inventory the operating system and service pack revision
level on all domain controllers in a particular domain.
Note
When administering Windows 2000–based domain controllers from a
computer running Windows XP Professional or Windows Server 2003,
you might experience interoperability problems with the Windows
Server 2003 administrative tools unless your Windows 2000–based
domain controllers are running Windows 2000 SP3 or later. Some
Windows Server 2003 Active Directory administrative tools sign and
encrypt all LDAP traffic. Computers running Windows 2000 SP3 or later
can interpret the signed and encrypted LDAP traffic.
To determine domain controller operating system and service pack levels

• For each domain in the forest, type the following command at the command line of a computer
that has the Windows Server 2003 support tools installed:
repadmin /showattr domain controller in target domain ncobj:domain: “/filter:
(&(objectcategory=computer)(primaryGroupID=516))” /subtree
/atts:operatingSystem,operatingSystemVersion,operatingSystemServicePack
The following text is sample output from this command:

DN: CN=NA-DC-01,OU=Domain Controllers,DC=company,DC=com
1> operatingSystem: Windows Server 2003
1> operatingSystemVersion: 5.2 (3663)
DN: CN=NA-DC-02,OU=Domain Controllers,DC=company,DC=com
1> operatingSystem: Windows 2000 Server
1> operatingSystemVersion: 5.0 (2195)
1> operatingSystemServicePack: Service Pack 3
Note
The repadmin /showattr command does not show any hotfixes that
might be installed on a domain controller.
Upgrade domain controllers to the appropriate service pack as needed. For more information about
recommended hotfixes to use with Service Pack 2, see article 331161, “List of Fixes to Use on Windows 2000
Domain Controllers Before You Run the Adprep/Forestprep Command” 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.
Backup Domain Data

Back up your Windows 2000 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:
• To allow for fault tolerance, ensure successful replication between two domain controllers in
each domain.
• Back up two domain controllers in each domain in the forest, including System State data.
• Test all backup media to ensure that the data can be restored successfully.
Important
Store backup media in a secure off-site location designated by, and
accessible to, the upgrade team before you begin the upgrade process.
Resolve Upgrade and Application

Compatibility Problems
Before upgrading a server to Windows Server 2003, use the Winnt32.exe command-line tool with the
/checkupgradeonly parameter to identify potential upgrade problems, such as inadequate hardware resources or
compatibility problems.
Two application compatibility problems you might need to resolve include:
• Distributed File System (DFS) root shares are not supported if they are hosted on a file
allocation table (FAT) partition.
In Windows Server 2003, DFS root shares must be located on NTFS partitions with no files or
directories under the DFS link.
For more information about deploying DFS, see “Designing and Deploying File Servers” in
Planning Server Deployments in this kit.
• Windows 2000–based computers running Remote Installation Services (RIS) might cause errors
in a Windows Server 2003 Active Directory domain.
When using Windows 2000 RIS server in your Windows Server 2003 Active Directory Domain,
you might receive the following error when using the Client Installation Wizard (CIW):
"Unable to create or Modify Computer account"
Error: 00004E4F
This error occurs because Windows Server 2003 creates machine account objects differently
from Windows 2000. To prevent this error from occurring when creating machine accounts,
configure the Windows 2000–based RIS servers in your environment to point to a domain
controller running Windows 2000. This is done by adding the DefaultServer registry parameter
to the Windows 2000 RIS servers.
For more information about configuring optional registry parameters for the Boot Information
Negotiation Layer (BINL) service, see article 235979, “Optional Registry Parameters for the
BINL Service” in the Microsoft Knowledge Base. To find this article, see the Microsoft
Knowledge Base link on the Web Resources page at
You must remove the Windows 2000 Administration Tools Pack before upgrading to Windows
Server 2003. For more information about Windows 2000 administration tools and upgrade
issues, see article 304718, “Administering Windows 2000–Based Computers Using
Windows XP Professional–Based Clients,” in the Microsoft Knowledge Base. To find this
article, see the Microsoft Knowledge Base link on the Web Resources page at
To identify potential upgrade and compatibility 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 prior to performing the upgrade.
Prepare Your Infrastructure for Upgrade

Preparing your infrastructure for upgrade involves resolving any Adprep.exe compatibility problems with
Microsoft® Exchange 2000 and Services for UNIX 2.0 and then running Adprep.exe to prepare the forest and
domains for the upgrade. Before you upgrade the first Windows 2000–based domain controller to Windows
Server 2003 Active Directory, you must use Adprep.exe to:
• Run adprep /forestprep once on the schema master to prepare the forest.
• Run adprep /domainprep once on the infrastructure master in each domain in which you plan
to place a Windows Server 2003–based domain controller.
When you are upgrading the operating system on a Windows 2000–based domain controller to Windows
Server 2003, Setup (Winnt32.exe) verifies that the forest and domain have been prepared. If you have not
prepared the forest and the domain in which the domain controller will be a member, or if the changes have not
fully replicated, Winnt32.exe fails, the upgrade terminates, and you are notified that you must run Adprep.exe
/forestprep in the forest and Adprep.exe /domainprep in the target domain.
Note
You can run Adprep.exe multiple times, but it performs actions only
once. For example, Adprep.exe does not adjust access control lists
(ACLs) each time you run the command.
You must prepare your infrastructure before using the Active Directory Installation Wizard to install Active
Directory on a Windows Server 2003–based member server. The Active Directory installation fails if the wizard
detects that the forest and domain have not been prepared.
Caution
Adprep.exe is the only supported method of upgrading the
Windows 2000 Active Directory schema to Windows Server 2003.
Attempting to use any other script or tool for this purpose can cause
problems with the schema and is not supported by Microsoft.
To prepare your Windows 2000 Active Directory forest and domain for the upgrade to Windows Server 2003
Active Directory, Adprep.exe performs the following tasks:
• Updates the Active Directory schema.
Note
Changes that are made to the global catalog by Adprep.exe do not
cause a full synchronization of the global catalog because the partial
attribute set is not changed.
• Improves default security descriptors.

• Upgrades display specifiers.
• Adjusts access control lists on Active Directory objects and on files in the SYSVOL shared
folder to allow domain controller access.
In versions of Windows earlier than Windows Server 2003, including the Everyone security
identifier (SID) on an ACL or group membership allows authenticated users, guest users, and
anyone with an anonymous logon to gain access to many resources. Windows 2000–based
domain controllers also use anonymous access to gain control of some Active Directory objects
and files. In Windows Server 2003, the Everyone group no longer contains the anonymous
users group, thus restricting domain controller access to particular objects. Adprep.exe adjusts
the ACLs on these objects so that domain controllers can still access them.
• Creates new objects that are used by applications such as COM+ and Windows Management
Instrumentation (WMI).
• Creates new containers in Active Directory that are used to verify that the preparation was
successful.
You can run Adprep.exe only at the command line.
Resolve Adprep.exe Compatibility Problems with Exchange 2000

When you prepare the forest by using the Active Directory Preparation tool in a Windows 2000 forest
containing the Exchange 2000 schema, the LDAP display names of the three Windows Server 2003
InetOrgPerson attributes Secretary, labeledURI, and houseIdentifier conflict with the non-RFC-compliant
versions added by Exchange 2000. On the domain controller that receives the Windows Server 2003 schema
updates, the lDAPDisplayName attributes for the Exchange 2000 definitions of these attributes are modified to
prevent a conflict. When the changes are replicated in Active Directory, however, the additional domain
controllers inadvertently detect the changes as a schema collision because duplicate names are present.
When Active Directory detects a duplicate name, it modifies the name of one of the objects by adding “Dup”
and some unique characters to the beginning of the name. For example, the Secretary, labeledURI, and
houseIdentifier name collisions appear similar to the following:
lDAPDisplayName: DUP-labeledURI-9591bbd3-d2a6-4669-afda-48af7c35507d
lDAPDisplayName: DUP-secretary-c5a1240d-70c0-455c-9906-a4070602f85f
lDAPDisplayName: DUP-houseIdentifier-e7c5d1bd-a422-4b9e-b4db-ecad2b6839cf
If you are already running Exchange 2000, you need to run the fixup script found in article 31469, “ADPREP
Command Causes Mangled Attributes in Windows 2000 Forests That Contain Exchange 2000 Servers.” To find
this article, see the Microsoft Knowledge Base link on the Web Resources page at
If you have not yet deployed Exchange 2000 in your environment, you can avoid name collisions by preparing
the Active Directory forest by using adprep /forestprep to create the initial definition of the Secretary,
labeledURI, and houseIdentifier attributes before installing Exchange 2000. Specifically, you can avoid LDAP
display name collision problems by doing one of the following:
• Run the Active Directory Preparation tool in a Windows 2000 forest before you install
Exchange 2000.
• Add Exchange 2000 to an existing Windows Server 2003 forest.
For more information about schema collisions between Exchange 2000 and Windows Server 2003, see article
314649, “ADPREP Command Causes Mangled Attributes in Windows 2000 Forests That Contain
Exchange 2000 Servers,” and article 325379 “How to Upgrade Windows 2000 Domain Controllers to Windows
Server 2003” in the Microsoft Knowledge Base. To find these articles, see the Microsoft Knowledge Base link
on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
Resolve Adprep.exe Compatibility Problems with Services for UNIX 2.0

Adprep.exe prepares the forest or domain with the schema attribute CN=uid, which is compliant with RFC 2307
for use by the Server for Network Information System (NIS) component of Services for UNIX. However, in
Services for UNIX 2.0, the Server for NIS component uses a different attribute schema: CN-
uid,CN=msSFUName. This discrepancy can cause the upgrade to Windows Server 2003 to fail. To solve this
problem, either upgrade to Windows Services for UNIX 3.0 or install the Q293783_sfu_2_x86_en.exe hotfix.
To resolve Server for NIS compatibility issues with Windows Server 2003
1. Run Q293783_sfu_2_x86_en.exe on the domain controller that holds schema master role.
2. Review the Hotfix.txt file that is included with the hotfix for installation specifics.
3. Verify end-to-end Active Directory replication of the schema throughout the forest.
For more information about Services for UNIX 2.0 application compatibility issues and the hotfix installation
file, see article 293783, “Cannot Upgrade Windows 2000 Server to Windows Server 2003 with Windows
Services for UNIX 2.0 Installed” 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.
Prepare the Forest for the Upgrade

Before preparing the forest for the upgrade, use your preferred monitoring tool to verify that replication is
functioning properly. If domain controllers are not replicating properly, the upgrade process will fail. The
changes made by Adprep.exe must replicate for the upgrade to succeed.
After verifying successful replication, use the adprep /forestprep command to prepare the forest for the
upgrade.
To prepare the Active Directory forest for the upgrade
1. In the forest root domain, log on to the domain controller that holds the schema master role with
Schema Admins, Enterprise Admins, and Domain Admins credentials.
2. Insert the Windows Server 2003 operating system CD, or connect to the network installation
shared folder, and then locate and open the I386 folder. At the command line, type:
adprep /forestprep
The following warning appears:

ADPREP WARNING:
Before running adprep, all Windows 2000 domain controllers in the forest should
be upgraded to Windows 2000 Service Pack 1 (SP1) with QFE 265089, or to Windows
2000 SP2 (or later).
QFE 265089 (included in Windows 2000 SP2 and later) is required to prevent
potential domain controller corruption.
For more information about preparing your forest and domain see KB article
Q331161 at http://support.microsoft.com.
[User Action]
If ALL your existing Windows 2000 domain controllers meet this requirement,
type C and then press ENTER to continue. Otherwise, type any key and press
ENTER to quit.
You can either continue with the preparation process or quit and install SP2. It is recommended
that you install SP2 or later on all Windows 2000–based domain controllers before continuing.
After adprep /forestprep has finished, verify that all operations have completed successfully.
To verify that the Active Directory Preparation tool has completed all operations
successfully
1. At the command line, type:
adsiedit.msc
Important
Adsiedit.exe is one of the Windows 2000 support tools, which is still
installed on the computer at this point in the domain upgrade process.
If you have removed the Windows 2000 support tools, you can reinstall
them from the Support\Tools folder on the Windows 2000 operating
system CD. For more information about Adsiedit.exe, in Help and
Support Center for Windows Server 2003, click Tools, and then click
Windows Support Tools.
2. Expand the Configuration container and verify that CN=ForestUpdates has been created.
3. Expand CN=ForestUpdates and verify that CN=Windows2003Upgrade is present.
4. Examine the Event Log for any event messages that indicate that the domain controller is not
functioning properly.
5. Verify that the changes that Adprep.exe made to the schema operations master are being
replicated to all other the domain controllers in the forest.
Successful replication is necessary when preparing an entire forest for Active Directory upgrade
because you can prepare a domain controller by using the adprep /domainprep command only
if it has received the changes made by the adprep /forestprep command. Attempting to
upgrade a domain controller that has not received the changes generates an error message.
Allow enough time for the changes to replicate to all domains in the forest.
Tip
Adprep.exe creates a log file each time it runs that can help you
troubleshoot errors. The log file documents each step of the forest
preparation process. Each Adprep.exe log file is located in a subfolder
in the %systemroot%\System32\Debug\Adprep folder. Each subfolder
is stamped with the date and time when Adprep.exe was run.
Although preparing the forest root domain for upgrade is not a difficult or unsafe procedure, you can take the
schema master offline as a precautionary measure to protect the Active Directory schema from corruption. If a
problem occurs while the computer is offline, use the following steps to recover:
1. Ensure that the corrupted schema operations master is not connected to the production
environment.
2. From a functional domain controller in the forest root domain, seize the schema master
operations role.
3. Use the Repadmin.exe tool to verify that the new schema operations master is replicating
successfully within the domain.
4. Perform a new Windows 2000 operating system installation on the corrupted computer.
Prepare the Domain for Upgrade

After you prepare the forest for the upgrade, you must also prepare each domain in which you plan to operate a
Windows Server 2003–based domain controller.
To prepare the Active Directory domain for upgrade
1. Log on to the infrastructure master by using Domain Admins credentials.
2. Insert the Windows Server 2003 operating system CD, or connect to the network installation
shared folder, and then locate and open the I386 folder. At the command line, type:
adprep /domainprep
After adprep /domainprep has finished, verify that all operations have completed successfully.
To verify that the Active Directory Preparation tool has completed all operations
successfully
• Using Adsiedit.exe, expand the Domain container, and then go to DC=domainname,DC=com,
CN=System, CN=DomainUpdates. Verify that CN=Windows2003Upgrade is present.
–or–
In Active Directory Users and Computers, from the View menu, select Advanced Features.
Expand the System container, go to the DomainUpdates container, and then expand it. Verify
that the Windows2003Upgrade container is present.
If you receive an error message, do one of the following, based on the error message text:
• Run the adprep /forestprep command.
• Wait for replication to complete.
• Troubleshoot replication.
Upgrading Windows 2000 Domains

to Windows Server 2003 Domains
You can begin the actual domain upgrade process after the forest is prepared, all changes made by the adprep
/forestprep command have replicated throughout the forest, and all applicable domains have been prepared with
adprep /forestprep.
Figure 9.7 shows the process for upgrading Windows 2000–based domain controllers to Windows Server 2003
Active Directory.
Figure 9.7 Upgrading Windows 2000 Domains to Windows Server 2003 Domains
Windows Server 2003–based domain controllers can be introduced in your environment by either installing
Active Directory on a Windows Server 2003–based member server by using the Active Directory Installation
Wizard or by upgrading the operating system of an existing Windows 2000–based domain controller. Refer to
your domain controller documentation table, and follow the upgrade order determined earlier in the planning
process. For more information about the order in which to upgrade your domain controllers, see “Determine
Domain Controller Upgrade Order” earlier in this chapter.
Note
Before you attempt to upgrade a domain controller in another domain
to Windows Server 2003 Active Directory, remember that you must first
run the adprep /domainprep command on the infrastructure master
role holder in that domain. Run adprep /forestprep only once in the
forest root domain, and run adprep /domainprep once in each domain
in the forest in which you plan to locate a Windows Server 2003-based
domain controller.
Install Active Directory on Windows

Server 2003–Based Member Servers
Install Active Directory on a Windows Server 2003–based member server that is located in the forest root
domain by using the Active Directory Installation Wizard. When you install Active Directory, the member
server becomes a domain controller. You can install Active Directory on any Windows Server 2003–based
member server that meets the domain controller hardware requirements. This is the recommended method for
introducing Windows Server 2003 into your environment.
The Active Directory Installation Wizard:
• Allows you to create an additional domain controller in the existing domain.
• Configures the local server to host the directory service.
• Creates directory partitions and default domain security principals.
• Allows you to install or configure DNS.
To install Active Directory on a Windows Server 2003–based member server, start the Active Directory
Installation Wizard by using one of the following methods:
To install Active Directory on a Windows Server 2003–based member server

• At the command line, 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.
After the first Windows Server 2003–based domain controller has been deployed, you can install Active
Directory on additional domain controllers by installing from media, a new installation feature of Windows
Server 2003. Installing 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
information 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
• In the Run dialog box, type dcpromo /adv, and then click OK.
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, you will have the option to make this new domain controller a global
catalog. The wizard will then proceed with the installation.
Table 9.4 lists information for installing Active Directory on a Windows Server 2003–based member server, in
addition to sample data for installing Active Directory on an additional domain controller in the existing
Contoso forest. Contoso will install Active Directory from a Windows Server 2003, Enterprise Edition CD by
using the dcpromo command.
Table 9.4 Installing Active Directory on Windows Server 2003–Based Member Servers
Wizard Page or
Action Example
Dialog Box
Domain Controller Select Additional domain controller
Type for an existing domain.
Network Credentials Type the user name and 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 Domain Type the full DNS name of the forest Concorp.contoso.
Controller root domain. com
Database and Log Type the folder locations specified Database folder:
Folders by your design. C:\Windows\NTDS
Log folder:
D:\Logs
Shared System Confirm or type the location C:\Windows\SYSV
Volume specified by your design. OL
Directory Service In the Password and Confirm
Restore Mode password boxes, type any strong
Administration password.
Password
Verify that all information on the Summary page is accurate, and then click Finish. After Active Directory is
installed, you will be prompted to restart the computer. The installation will not be complete until the computer
restarts.
After you install Active Directory on the Windows 2003–based member server, allow sufficient time for
replication to occur and other domain controllers to synchronize with the new domain controller.
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
Upgrade Existing Windows 2000–Based

Domain Controllers
When you upgrade the operating system on a Windows 2000–based domain controller to Windows Server 2003,
the computer immediately assumes the role of domain controller after the final restart of the computer. It is not
necessary to install Active Directory by using the Active Directory Installation Wizard. Upgrade the following
existing Windows 2000–based domain controllers early in the upgrade process:
• The Windows 2000–based domain controller that holds the role of the domain naming master.
This will ensure the creation of application directory partitions that will later be used for DNS.
If you choose not to upgrade the domain naming master, you must transfer the role of the
domain naming master to a Windows Server 2003 domain controller.
When a domain controller running the DNS Server service restarts for the first time after the
operating system has been upgraded to Windows Server 2003, it will try to subscribe to existing
application directory partitions or create them if it does not detect them. If the domain naming
master is not a Windows Server 2003–based domain controller, the creation of the application
directory partitions will fail and errors will be generated.
• The Windows 2000–based domain controller that holds the PDC emulator role in the forest root
domain. This will ensure that additional security principals are created for the forest. For more
information about the additional security principals that are created after the PDC emulator in
the forest root domain is upgraded, see “Background Information for Upgrading Windows 2000
Domains to Windows Server 2003 Domains” earlier in this chapter.
• All other Windows 2000–based domain controllers that hold the PDC emulator role. This will
ensure that all new Windows Server 2003 groups and group memberships are created. If you
choose not to upgrade the PDC emulator for each domain, you must transfer the PDC role to a
To initiate the installation of the operating system on a domain controller, insert the Windows Server 2003
operating system CD on the domain controller, or, if the Windows Server 2003 media are shared over the
network, run the Winnt32.exe command-line tool.
You can also perform an unattended installation of Windows Server 2003. Instructions for creating an answer
file for an Active Directory installation are located in the Deploy.cab file in the Support\Tools folder on the
Windows Server 2003 operating system CD. Inside the Deploy.cab file, open Ref.chm to access the Unattend.txt
file. Expand Unattend.txt in the left pane, and then click DCInstall.
Modify Security Policies

To ensure that clients running older versions of the Windows operating system will be able to access domain
resources in the new Windows Server 2003 domain, you might have to modify default security policies.
Important
Be aware that by modifying these policies you are weakening the
default security policies in your environment. However, this is
necessary to ensure that some clients running earlier versions of
Windows will be able to access domain resources. After all 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–based clients as soon as possible.
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 Windows 95 or
Windows NT 4.0 with Service Pack 2 (SP2) and earlier without the Directory Service Client Pack 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 (SP3) 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 logon and access domain resources on the network is to apply the
appropriate service pack or the Directory Service Client Pack. If you cannot apply the most recent service pack
or the Directory Service Client Pack, configure all Windows Server 2003–based domain controllers to not
require SMB packet signing or secure channel signing by disabling 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)
Back up the Default Domain Controllers Policy Group Policy object before modifying it. Use the Group Policy
Management Console (GPMC) to back up the Group Policy object so that it can be restored if necessary. The
Group Policy Management Console (GPMC) is a tool that permits you to manage Group Policy for multiple
domains and sites in one or more forests. GPMC is the recommended method for managing Group Policy;
however this chapter does not assume that you are using GPMC for security policy management and
deployment.
GPMC is not included with Windows Server 2003. To obtain GPMC, see the Group Policy Management
Console (GPMC) link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
To disable SMB packet and secure channel signing enforcement 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. Click the Group Policy tab, and then click Edit.
3. Under Computer Configuration, go to the Windows Settings\Security Settings\Local
Policies\Security Options folder.
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), and then click Disabled to prevent secure channel signing from being required.
7. Click OK.
To apply the Group Policy change immediately, either restart the domain controller, or type gpupdate /force at
a command line, and then press ENTER.
Note
Modifying these settings in the Domain Controllers container will
change the Default Domain Controllers Policy. Policy changes made
here will be replicated to all other domain controllers in the domain, so
you only need to modify these policies one time to affect the Default
Domain Controllers Policy on all domain controllers.
For more information about SMB packet signing and secure channel signing, see “Background Information for
Upgrading Windows 2000 Domains to Windows Server 2003 Domains” 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.
For more information about managing and deploying security policies and the Group Policy Management
Console (GPMC), see “Deploying Security Policy” in Designing a Managed Environment in this kit.
Update Group Policy Permissions

Group Policy Modeling is a new feature of the GPMC that simulates the resultant set of policy for a particular
configuration. The simulation is performed by a service that runs on Windows Server 2003–based domain
controllers. To perform the simulation across domains, the service must have read access to all Group Policy
objects (GPOs) in the forest.
In a Windows Server 2003 domain that has been upgraded from Windows 2000 or newly installed, the
Enterprise Domain Controllers group is automatically given read access to all newly created GPOs. This ensures
that the service can read all GPOs in the forest.
However, if the domain was upgraded from Windows 2000, the Enterprise Domain Controllers group will not
have read access to any existing GPOs that were created prior to the upgrade. The Group Policy Management
Console detects this when you click a GPO and notifies the user that Enterprise Domain Controllers do not have
read access to all GPOs in this domain. To solve this problem, use the sample script that is provided with the
Group Policy Management Console, GrantPermissionOnAllGPOs.wsf. This script will update the permissions
on all GPOs in the domain. You must be a member of the Domain Admins group or have permissions to modify
security on all GPOs in the domain to run this script.
Note
To download the GPMC, see the Group Policy Management Console
link on the Web Resources page at
To update permissions on all GPOs in a domain

1. At the command line, change to the %programfiles%\Gpmc\Scripts folder.
2. Type the following:
cscript grantpermissiononallgpos.wsf “Enterprise Domain Controllers”
/permission:read /domain: domainname
For more information about using GPMC for deploying Group Policy, see “Designing a Group Policy
Infrastructure” in Designing a Managed Environment in this kit.
Perform Clean-up Tasks

After upgrading to Windows Server 2003, perform the following clean-up operations:
• After the security descriptor propagator has finished building the single instance store, perform
an offline defragmentation of the database on each upgraded domain controller. This reduces
the size of Active Directory on the file system by up to 40 percent, reduces the memory
footprint, and updates pages in the database to Windows Server 2003 format. For more
information about performing an offline defragmentation of the Active Directory database, 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 then download the Active Directory Operations Guide. The
procedure for performing an offline defragmentation of the database applies to both
Windows 2000 and Windows Server 2003.
• Create a new System State backup for at least two domain controllers in your environment. For
more information about backing up Active Directory, see the Active Directory Operations
Guide. The procedure for backing up System State data applies to both Windows 2000 and
Windows Server 2003. Be sure to label all backup tapes with the operating system version that
the domain controller is running, including service packs and hotfixes.
Completing Post-Upgrade Tasks

After upgrading the operating system on all domain controllers in the forest to Windows Server 2003, complete
the domain upgrade by raising the domain and forest functional levels to Windows Server 2003, and use newly
created application directory partitions to store DNS information. You must then redirect the Users and
Computers containers.
Figure 9.8 shows the tasks necessary to complete your upgrade to Windows Server 2003 Active Directory.
Figure 9.8 Completing the Upgrade to Windows Server 2003 Active Directory
Raise Domain and Forest Functional Levels

To enable all Windows Server 2003 Active Directory features, raise the functional level of your forest to
Windows Server 2003. This will automatically raise the functional level of all domains to Windows
Server 2003.
Important
Raising the domain and forest functional levels to Windows
Server 2003 is a nonreversible task and prohibits the addition of
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 raising functional levels to take advantage of advanced
Windows Server 2003 features, ensure that you will never need to
install domain controllers running Windows NT 4.0 or Windows 2000 in
your environment.
After all domains are operating at the Windows Server 2003 functional level, raise the forest functional level to
Windows Server 2003. To do this, right-click Active Directory Domains and Trusts in Active Directory
Domains and Trusts, and select Raise Forest Functional Level. This allows you to take advantage of all
Windows Server 2003 forest-level features.
Note
You can only raise the functional level of the forest to Windows
Server 2003 if all domains are set to the Windows 2000 native
functional level or higher.
For more information about enabling functional levels after upgrading from a Windows 2000 environment 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.
Use DNS Application Directory Partitions

Use application directory partitions for Active Directory–integrated DNS zones to reduce replication traffic and
the amount of data stored in the global catalog.
After completing the upgrade of all Windows 2000–based domain controllers in the forest to
Windows Server 2003, move the Active Directory–integrated DNS data on all DNS servers from the domain
partition into the newly created DNS application directory partitions. This is done by changing the replication
scope of the DNS zones.
Move the DNS zones that you want to replicate to all DNS servers in the forest to the forest-wide DNS
application directory partition, ForestDnsZones. For each domain in the forest, move the DNS zones that you
want to replicate to all DNS servers in the domain to the domain-wide DNS application directory partition,
DomainDnsZones.
Important
Before you attempt to move DNS data to an application directory
partition, make sure that the domain naming master is hosted on a
If there is an existing _msdcs.forest_root_domain zone on your DNS server, move it to the ForestDnsZones
application directory partition.
If the _msdcs.forest_root_domain zone is not present as a separate zone on your DNS server, you do not need to
perform this procedure because the DNS data that is stored in the _msdcs.forest_root_domain is moved with the
forest root domain zone to the domain-wide application directory partition, DomainDnsZones.
Note
For more information about DNS and application directory partitions,
see “Background Information for Upgrading Windows 2000 Domains to
Windows Server 2003 Domains” earlier in this chapter.
To change the replication scope of the domain-wide DNS zone by using a DNS
application directory partition
1. On a domain controller that hosts a DNS server in the particular domain, open the DNS snap-in,
right-click the DNS zone that uses the fully qualified domain name of the Active Directory
domain, and then click Properties.
2. Click the Change button next to Replication: All domain controllers in the Active Directory
domain.
3. Click To all DNS servers in the Active Directory domain domainname.
To change the replication scope of the _msdcs.forest_root_domain DNS zone by
using a DNS application directory partition
1. On a domain controller that hosts a DNS server in the forest root domain, open the DNS snap-
in, right-click the _msdcs.forest_root_domain DNS zone, and then click Properties.
2. Click the Change button next to Replication: All domain controllers in the Active Directory
domain.
3. Click To all DNS servers in the Active Directory forest forestname.
For more information about creating, enlisting in, and removing application directory partitions, see Help and
Support Center for Windows Server 2003. For more information about creating a DNS design for Active
Directory, see “Designing the Active Directory Logical Structure” in this book.
Redirect Users and Computers

The default CN=Users and CN=Computers containers that are created when Active Directory is installed are not
organizational units. 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, do not allow administrators to
specify a target organizational unit and, therefore, to create these objects in either the CN=Computers container
or the CN=User container by default. Examples of these earlier versions include the net user and net computer
commands, the net group command, the netdom add command where the /ou parameter is either not specified
or supported, or Windows NT 4.0 tools such as User Manager for Domains.
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
containers to an organizational unit specified by the administrator so that Group Policy can apply to containers
hosting newly created objects.
Important
The CN=Users and CN=Computers containers are computer-protected
objects. For backward compatibility reasons, you cannot (and must not)
remove them. 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 user created with earlier versions of user interface and command-line management
tools.
2. At the command line, change to the System32 folder by typing:
cd %systemroot%\system32
3. At the %systemroot%\System32 folder, type the following, where newuserou is the name of the
new user OU and domainname is the name of the domain:
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 created with earlier versions of user interface and command-line
management tools.
2. At the command line, change to the System32 folder by typing:
cd %systemroot%\system32
3. At the %systemroot%\System32 folder, type the following, where newcomputerou is the name
of the new computer OU and domainname is the name of the domain:
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 domain upgrade process.
• Verify that the NETLOGON and SYSVOL shared folders exist and that the File Replication
service (FRS) is functioning without error by checking the Event Viewer.
• Verify that Group Policy is being applied successfully by checking the application log in Event
Viewer for Event ID 1704.
• Verify that all SRV, CNAME, and A resource records have been registered in DNS.
• Continuously monitor your domain controllers and Active Directory. Using a monitoring
solution such as Microsoft® Operations Manager to monitor the distributed Active Directory
service and the services that it relies on helps maintain consistent directory data and a consistent
level of service throughout the forest.
After these 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
• “Enabling Advanced Windows Server 2003 Active Directory Features” in this book for more
information about advanced Active Directory features and how they are related to functional
levels.
• “Designing the Active Directory Logical Structure” in this book.
• “Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory” in this book.
• “Deploying DNS” in Deploying Network Services of this kit for more information about
deploying DNS to support name resolution on your network.
• The Active Directory Branch Office Planning Guide link on the Web Resources page at
Related Tools
• Adsiedit.exe
The ADSIEdit.exe tool is an MMC 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.
• Repadmin.exe
The Repadmin.exe tool can be used to administer replication between domain controllers in
Active Directory. For information about how to use the Repadmin.exe tool, 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.
• “Installing and Upgrading the Operating System” in Help and Support Center for Windows
Server 2003 for more information about Active Directory preparation and the Active Directory
Preparation tool (Adprep.exe).
• “Managing Core Network Services” in Help and Support Center for Windows Server 2003 for
more information about application directory partitions.
Related Job Aids
• “Pre-Upgrade Task Checklist” (DSSUPWN_1.doc) on the Windows Server 2003 Deployment
Kit companion CD (or see “Pre-Upgrade Task Checklist” on the Web at
• “Windows 2000 Domain Controller Documentation” (DSSUPWN_2.doc) on the Windows
Server 2003 Deployment Kit companion CD (or see “Windows 2000 Domain Controller
Documentation” on the Web at http://www.microsoft.com/reskit).
• “Windows 2000 Upgrade Test Matrix” (DSSUPWN_3.doc) on the Windows Server 2003
Deployment Kit companion CD (or see “Windows 2000 Upgrade Test Matrix” on the Web at

Upgrading Windows 2000 Domains To Windows Server 2003 Domain

Uploaded by

Document Information

Original Description:

Original Title

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 2000 Domains To Windows Server 2003 Domain

Uploaded by

Copyright:

Available Formats

C H A P T E R 9

Overview of Upgrading Your

Process for Upgrading Windows 2000

Background Information for Upgrading

Active Directory Preparation Tool

Application Directory Partitions for DNS

Intrasite Replication Frequency

New Groups and New Group Memberships Created After Upgrading

Security Policy Considerations When Upgrading from Windows 2000

Create a Pre-Upgrade Task Checklist

Assign Appropriate Credentials

Introduce a Windows Server 2003–Based

Determine Supported Software Upgrades

Table 9.2 Supported Upgrade Paths to Windows Server 2003

Assess Hardware Requirements

Determine Domain Controller Upgrade Order

Figure 9.4 Example of a Windows 2000 Domain Controller Documentation Table

Develop a Test Plan

Develop a Recovery Plan

Completing Pre-Upgrade Tasks

Determine Service Pack Levels

To determine domain controller operating system and service pack levels

The following text is sample output from this command:

Backup Domain Data

Resolve Upgrade and Application

Resolve any reported problems prior to performing the upgrade.

Prepare Your Infrastructure for Upgrade

• Improves default security descriptors.

Resolve Adprep.exe Compatibility Problems with Exchange 2000

Resolve Adprep.exe Compatibility Problems with Services for UNIX 2.0

Prepare the Forest for the Upgrade

The following warning appears:

Prepare the Domain for Upgrade

Upgrading Windows 2000 Domains

Install Active Directory on Windows

To install Active Directory on a Windows Server 2003–based member server

Upgrade Existing Windows 2000–Based

Modify Security Policies

To disable SMB packet and secure channel signing enforcement on Windows

Update Group Policy Permissions

To update permissions on all GPOs in a domain

Perform Clean-up Tasks

Completing Post-Upgrade Tasks

Raise Domain and Forest Functional Levels

Use DNS Application Directory Partitions

Redirect Users and Computers

To redirect the Computers container

Completing the Upgrade

You might also like