Background Information for Upgrading Windows 2000 Domains to Windows Server 2003 Domains
Updated: March 28, 2003
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
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 and Windows Server 2003 Service Pack 1 (SP1) 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.
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.
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:
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.
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
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.
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:
Remote Interactive Logon
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.