Seamlessly Migrate: Upgrading Windows 2000 Domain Controllers to Windows Server 2003

Table of Contents

This document provides a comprehensive guide on upgrading Microsoft Windows 2000 domain controllers to Windows Server 2003. It also covers the process of adding new Windows Server 2003 domain controllers into an existing Windows 2000 domain environment. Successfully migrating to Windows Server 2003 enhances the capabilities and security posture of your Active Directory forest. This process requires careful planning and execution to ensure a smooth transition and maintain directory health.

The steps outlined herein are crucial for preparing your infrastructure before introducing Windows Server 2003 domain controllers. While this article focuses on the Windows Server 2003 upgrade path, subsequent upgrades to newer operating systems like Windows Server 2008 or Windows Server 2008 R2 follow similar preparatory steps involving updated tools and procedures. Always consult the latest Microsoft documentation for upgrades beyond Windows Server 2003. This guide specifically addresses the transition from Windows 2000 to Windows Server 2003.

Domain and Forest Inventory¶

Before initiating any upgrades or introductions of Windows Server 2003 domain controllers, a thorough inventory of your existing Windows 2000 environment is mandatory. This crucial phase identifies potential compatibility issues and verifies the health of your Active Directory forest and domains. Addressing any pre-existing problems before introducing new domain controllers is essential for a successful upgrade. Neglecting this phase can lead to complex issues that are difficult to troubleshoot after the upgrade begins.

One primary consideration involves client compatibility with SMB signing, which is enabled by default on Windows Server 2003 domain controllers for enhanced security. You must ensure that all network clients accessing shared resources via the SMB/CIFS protocol can support this feature. Clients that cannot support SMB signing may experience connection issues. You might need to update older clients or temporarily adjust security settings on the new domain controllers.

Here is a compatibility overview for common SMB clients:

Client Operating System	Compatibility with Windows Server 2003 SMB Signing	Action Required
Windows Server 2003	Compatible	None
Windows XP Professional	Compatible	None
Windows 2000 Server	Compatible	None
Windows 2000 Professional	Compatible	None
Windows 98	Compatible	None
Windows NT 4.0	Compatible (with SP3+)	Install Service Pack 3 or later (SP6A recommended) or temporarily disable SMB signing on Windows Server 2003 DCs.
Windows 95	Compatible (with Directory Service Client)	Install the Windows 9x Directory Service Client or temporarily disable SMB signing on Windows Server 2003 DCs.
Microsoft Network Client for MS-DOS	Not Compatible	Use an alternative installation method or temporarily disable SMB signing on Windows Server 2003 DCs.
Microsoft LAN Manager 2.x	Not Compatible	Use an alternative installation method or temporarily disable SMB signing on Windows Server 2003 DCs.
Macintosh Clients (some)	Not Compatible (some versions)	Install updated software or temporarily disable SMB signing on Windows Server 2003 DCs. May receive “- Error -36 I/O”.
Other third-party SMB clients	Varies	Consult provider for updates or temporarily disable SMB signing on Windows Server 2003 DCs.

If upgrading clients is not immediately feasible, SMB signing can be temporarily disabled on the Windows Server 2003 domain controllers through Group Policy. Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft Network Server: Digitally sign communications (always). Apply this setting to an Organizational Unit (OU) containing your domain controllers.

Ensure all Windows 2000 domain controllers in the forest are running Windows 2000 Service Pack 4 (SP4) or a later operating system revision. If a full SP4 deployment is not possible, verify that the Ntdsa.dll file on each Windows 2000 domain controller has a date stamp and version later than June 4, 2001, and 5.0.2195.3673, respectively. Active Directory administration tools on newer client operating systems like Windows XP SP2 or Windows Server 2003 use LDAP signing by default.

Troubleshooting connections when administering Windows 2000 domain controllers from newer clients using NTLM authentication (e.g., across external trusts or via IP address) might require ensuring the target Windows 2000 DC has at least SP3 installed. Alternatively, you can disable LDAP signing on the administrative client machines if necessary. Identifying the operating system and service pack levels of your domain controllers is crucial for planning. The repadmin /showattr command can be used to query domain controller attributes like operatingSystem and operatingSystemServicePack.

Verifying end-to-end Active Directory replication across the entire forest is perhaps the most critical pre-upgrade step. All domain controllers must replicate all hosted naming contexts with their partners without errors. Use the repadmin /showreps command on each domain controller to check the replication status and latency (“Largest Delta”). Replication failures should be resolved before proceeding with the upgrade.

If replication issues persist and cannot be resolved within the Tombstone Lifetime (TSL) (default 60 days), domain controllers involved in the failures may need to be forcibly demoted using dcpromo /forceremoval. Their metadata must then be cleaned up from Active Directory using the Ntdsutil metadata cleanup command. Reintroducing these servers to the domain would require promoting them as new domain controllers. Forceful removal should be a last resort due to potential data loss on the removed DC.

Ensure the file system portion of Group Policy objects (GPOs) stored in the Sysvol share is consistent across all domain controllers in each domain. Tools like Gpotool.exe (from the Resource Kit) and Healthcheck (from Windows Server 2003 support tools) can help verify Sysvol consistency and File Replication Service (FRS) health. Any inconsistencies must be resolved to ensure policy settings are uniformly applied. FRS health is critical for the adprep /domainprep process as it modifies Sysvol permissions, triggering a full synchronization.

Use the Dcdiag.exe /e /test:frssysvol command to verify that all domain controllers in the forest have correctly shared the Netlogon and Sysvol directories. This check confirms basic FRS functionality and network accessibility of critical shares required for client authentication and policy application. Any failures reported by this command need immediate attention and resolution.

Inventory and verify the health and location of all Flexible Single Master Operations (FSMO) role holders in the forest. The Schema Master is needed for adprep /forestprep, and the Infrastructure Master of each domain is needed for adprep /domainprep. Ensure these role holders are online, healthy, and have replicated inbound changes recently. Use DCDIAG /test:FSMOCHECK to identify current role holders. If a role is held by a non-existent or permanently offline DC, it must be seized using Ntdsutil. If held by an unhealthy but recoverable DC, attempt to transfer the role.

A thorough review of event logs on all domain controllers is essential. Look for recurring errors or warnings related to physical/network connectivity, name registration/resolution (DNS/WINS), authentication, Group Policy processing, security policies, disk subsystem issues, schema, topology, or the replication engine. Addressing these underlying infrastructure problems before upgrading prevents them from complicating the migration process.

Check the available disk space on volumes hosting the Ntds.dit file and Active Directory log files on all domain controllers. Each volume should ideally have free space equivalent to at least 15-20% of the Ntds.dit file size. Insufficient disk space can halt the upgrade process or lead to performance issues. Refer to the “Domain controllers without sufficient disk space” section later for guidance on freeing up space.

Optionally, consider enabling DNS scavenging on all DNS servers in the forest, setting intervals (e.g., 7 days). Perform this well in advance (61+ days recommended) of the upgrade. This allows the DNS system to clean up aged resource records. This isn’t strictly required for the upgrade itself but is a good maintenance practice that can reduce database size over time, especially after removing old domain controllers.

Also optional, but recommended if not used, is disabling the Distributed Link Tracking (DLT) Server service on your Windows 2000 domain controllers before upgrading. Windows Server 2003 domain controllers have this service disabled by default. Disabling it pre-upgrade can simplify post-migration cleanup. If DLT is not actively used by clients, you can clean up existing DLT objects from Active Directory.

Finally, perform a system state backup of at least two domain controllers in every domain in the forest. These backups are your critical safety net. They allow you to restore the directory service to its pre-upgrade state if any unrecoverable issues occur during the migration process. Ensure these backups are stored securely and are easily accessible if needed.

Microsoft Exchange 2000 in Windows 2000 Forests¶

A known conflict exists when upgrading Windows 2000 forests that host Exchange 2000 before running the Windows Server 2003 adprep /forestprep command. Exchange 2000 introduces three attributes (houseIdentifier, secretary, labeledURI) with LDAPDisplayNames that clash with RFC-compliant versions defined by the Windows 2000 inetOrgPerson Kit and the Windows Server 2003 adprep tool. If the Exchange schema is added first, adprep /forestprep will “mangle” the LDAPDisplayNames of these attributes to resolve the conflict, prepending “DUP-” or similar characters.

This mangling can cause compatibility issues with applications that refer to these attributes by their expected LDAPDisplayName. Fortunately, this issue is avoidable or fixable depending on the order of schema additions.

Scenario 1: Exchange 2000 Schema Changes Added After adprep /forestprep¶

If you plan to introduce Exchange 2000 schema changes after successfully running the Windows Server 2003 adprep /forestprep command, no special cleanup is required regarding this specific conflict. The adprep schema changes will be in place, and subsequent Exchange 2000 schema additions will likely resolve the conflict gracefully or utilize different attribute names. You can proceed directly to the main upgrade steps.

Scenario 2: Exchange 2000 Schema Changes Installed Before adprep /forestprep (Prevention)¶

If Exchange 2000 schema changes are already present in your Windows 2000 forest, but you have not yet run the Windows Server 2003 adprep /forestprep command, you can prevent the mangling. This involves manually renaming the problematic Exchange 2000 attribute LDAPDisplayNames before running adprep /forestprep. Use an LDIF file to modify the schema.

Log on to the Schema Master with an account that is a member of the Schema Admins group. Create a text file named InetOrgPersonPrevent.ldf using Notepad. Copy the specific LDIF content provided in the original KB article into this file, ensuring no trailing spaces and using Unicode encoding. Replace DC=X and the domain name path placeholder with your forest root domain information. Run the LDIF file using the ldifde command on the Schema Master. Verify the attribute names are correctly changed before running adprep /forestprep.

Scenario 3: adprep /forestprep Run Before Exchange Schema Fix (Correction)¶

If you have already run the Windows Server 2003 adprep /forestprep command in a Windows 2000 forest containing the Exchange 2000 schema, the LDAPDisplayNames for houseIdentifier, secretary, and labeledURI will likely be mangled (e.g., starting with “DUP-“). You can confirm this using Ldp.exe to search the schema naming context for attributes with LDAPDisplayNames starting with “DUP*”.

To correct this after the fact, you must run the InetOrgPersonFix.ldf script. This script is typically found in the Support\Tools folder of the Windows Server 2003 installation media within the Support.cab file. Extract the InetOrgPersonFix.ldf file. Log on to the Schema Master, navigate to the directory where the file was extracted, and run the ldifde command with the -i -f inetorgpersonfix.ldf parameters, specifying the correct Base DN for your schema naming context. This will correct the mangled LDAPDisplayNames. Verify the correction using Ldp.exe again before proceeding with any Exchange 2000 installations if they haven’t occurred, or simply proceed with the rest of your upgrade if they have.

Overview: Upgrading Windows 2000 Domain Controllers to Windows Server 2003¶

Preparing a Windows 2000 forest and its domains for Windows Server 2003 domain controllers requires running the adprep command from the \I386 folder of the Windows Server 2003 installation media. This command introduces schema and configuration changes necessary for Windows Server 2003 domain controllers to function correctly within the existing Active Directory structure. The adprep tool has two main operations: forestprep and domainprep.

The adprep /forestprep command performs forest-wide changes, including schema extensions for new features like improved security descriptors and new object classes (e.g., inetOrgPerson). This operation needs to be run only once in the entire forest on the Schema Operations Master domain controller. Replication of these forest-wide changes is critical before proceeding to domain-specific preparations.

The adprep /domainprep command performs domain-specific changes within the domain partition and the Sysvol share. This includes updating security descriptors on certain objects and modifying Group Policies. This operation must be run on the Infrastructure Operations Master of each domain in the forest that will host Windows Server 2003 domain controllers. Domainprep verifies that forestprep changes have replicated before making its own modifications.

You cannot upgrade existing Windows 2000 domain controllers using Winnt32.exe or promote new Windows Server 2003 member servers into the domain using Dcpromo.exe until both adprep /forestprep and adprep /domainprep have successfully completed in the relevant domain and their changes have fully replicated to all domain controllers within that domain. Although adprep commands can be run multiple times, completed operations will not be rerun. Running these commands sequentially on the correct FSMO roles is a foundational step for the upgrade.

Here’s a simplified flow of the adprep process:

mermaid graph TD A[Start] --> B{Inventory & Verify Forest Health}; B -- Healthy --> C{Identify Schema Master}; C --> D{Run adprep /forestprep}; D --> E{Verify forestprep Replication}; E -- Replicated --> F{Identify Infrastructure Master (per domain)}; F --> G{Run adprep /domainprep (per domain)}; G --> H{Verify domainprep Replication (per domain)}; H -- Replicated per domain --> I{Proceed with DC Upgrades/Promotions}; I --> J[End]; B -- Issues Found --> K{Resolve Issues}; K --> B; D -- Failed --> L{Troubleshoot adprep /forestprep}; G -- Failed --> M{Troubleshoot adprep /domainprep};

Upgrading the Forest with the adprep /forestprep Command¶

To prepare your forest, follow these steps on the Schema Operations Master:

1. Ensure all prerequisites from the “Domain and forest inventory” section are met, especially system state backups, required hotfixes on Windows 2000 DCs, functional Active Directory replication, and healthy FRS replication. Pre-upgrade checks significantly reduce the risk of failure.
2. Log on to the Schema Master domain controller using an account that is a member of the Schema Admins security group for the forest root domain. This is a mandatory permission requirement.
3. Verify that the Schema Master has successfully replicated the schema partition recently using repadmin /showreps. This ensures it is up-to-date before applying changes.
4. While early documentation suggested isolating the Schema Master, current best practices do not require this and it may cause replication issues later. Keep the Schema Master connected to the network.
5. Open a command prompt and run the adprep /forestprep command from the \I386 directory of the Windows Server 2003 installation media. For example, D:\I386\adprep /forestprep. Wait for the command to complete. Ignore informational event ID 1153 if seen in the Directory Service event log.
6. Verify the successful completion of adprep /forestprep. Check the command output for errors. Look for the creation of the CN=Windows2003Update object under CN=ForestUpdates,CN=Configuration,DC=<forest_root_domain> in the Configuration partition and note its Revision attribute value. Optionally, verify the schema version has incremented to 30 by checking the ObjectVersion attribute under CN=Schema,CN=Configuration,DC=<forest_root_domain>. If adprep /forestprep fails, check the command path, verify Schema Admins membership (whoami /all), and review the Adprep.log file located in %systemroot%\System32\Debug\Adprep\Logs\<Latest_log>.
7. Ensure inbound and outbound replication is enabled on the Schema Master if it was temporarily disabled. Use repadmin /options -DISABLE_OUTBOUND_REPL.
8. Monitor replication to confirm that the adprep /forestprep changes have propagated to all domain controllers in the forest. Check for the updated schema version and the presence of the CN=Windows2003Update object in the Configuration partition on other DCs.
9. Specifically check for any mangled LDAPDisplayNames resulting from the Exchange 2000 conflict if applicable. If found, apply the InetOrgPersonFix.ldf as described in Scenario 3 of the Exchange section.
10. Ensure the logged-on user for the next steps is a member of the Domain Admins group in the domain being prepared.

Upgrading the Domain with the adprep /domainprep Command¶

After adprep /forestprep changes have fully replicated throughout the forest, you can run adprep /domainprep in each domain that will contain Windows Server 2003 domain controllers.

1. Identify the Infrastructure Operations Master domain controller for the specific domain you are preparing. Log on to this server using an account that is a member of the Domain Admins security group in that domain. Note that Enterprise Admins might not be Domain Admins in child domains.
2. Open a command prompt on the Infrastructure Master and run the adprep /domainprep command from the \I386 directory of the Windows Server 2003 installation media (e.g., D:\I386\adprep /domainprep). This command will apply domain-specific changes and modify permissions in the Sysvol share, triggering a full FRS synchronization.
3. Verify that adprep /domainprep completed successfully. Check the command output for errors. Look for the creation of the CN=Windows2003Update object under CN=DomainUpdates,CN=System,DC=<dn path of domain> and confirm the value of its Revision attribute. If adprep /domainprep fails, verify Domain Admins membership, check the command path, and review the Adprep.log file.
4. Monitor replication within the domain to ensure the adprep /domainprep changes have propagated to all other domain controllers. Verify the presence and matching Revision attribute value of the CN=Windows2003Update object under CN=DomainUpdates,CN=System on other DCs in the domain.
5. Repeat steps 1-4 for each domain in the forest where you intend to introduce Windows Server 2003 domain controllers. You can prepare domains individually just before upgrading/promoting DCs in that domain or prepare all domains in bulk after forestprep replicates. Once both forestprep and domainprep are complete and replicated in a domain, you are ready to upgrade Windows 2000 DCs or add new Windows Server 2003 DCs in that domain.

Upgrading Windows 2000 Domain Controllers by Using Winnt32.exe¶

With adprep /forestprep and adprep /domainprep successfully completed and replicated, and any client compatibility decisions made (especially regarding SMB signing), you can begin upgrading your Windows 2000 domain controllers to Windows Server 2003. You can also start promoting new Windows Server 2003 member servers or standalone servers to domain controllers using Dcpromo.exe. Microsoft recommends that the first domain controllers upgraded or promoted in the forest and in each domain should ideally hold important FSMO roles (Domain Naming Master, PDC Emulator for forest root, PDC Emulator for non-root domains) or be transferred those roles shortly after.

Perform the following steps for each Windows 2000 domain controller you plan to upgrade using Winnt32.exe:

1. Before running Winnt32.exe, uninstall Windows 2000 Administration Tools from the server if they were installed. Use the Add/Remove Programs tool in Control Panel. This step is specific to Windows 2000 upgrades.
2. Install any critical hotfixes or updates identified as necessary by Microsoft or your organization before starting the OS upgrade. Some updates might be required for a successful Windows Server 2003 installation.
3. Run a compatibility check by executing winnt32.exe /checkupgradeonly from the \I386 folder of the Windows Server 2003 installation media. This checks for potential issues that could prevent a successful upgrade. Address any compatibility warnings or errors reported by the check before proceeding with the actual upgrade.
4. Execute WINNT32.EXE from the \I386 folder of the Windows Server 2003 installation media to begin the in-place upgrade process. Follow the prompts to upgrade the existing Windows 2000 installation. The server will restart multiple times during this process.
5. After the upgrade completes, verify the lower security settings for earlier-version clients if you chose to disable SMB signing. Ensure the Group Policy object targeting the Domain Controllers OU correctly disables “Microsoft Network Server: Digitally sign communications (always)”.
6. Perform health checks on the newly upgraded Windows Server 2003 domain controller. Verify that the operating system started successfully, that expected hotfixes were applied during the process (or apply any remaining required ones), and that Active Directory replication (inbound and outbound) is functioning correctly for all partitions hosted on the DC. Check for the presence of the Netlogon and Sysvol shares and review the System, Application, and Directory Service event logs for errors or warnings.
7. For servers that were upgraded from Windows 2000, reinstall the Windows Server 2003 Administration Tools (Adminpak.msi) and Support Tools (Suptools.msi) from the \I386 and Support\Tools folders of the Windows Server 2003 media, respectively. These updated tools are necessary for administering the Windows Server 2003 environment.
8. Create new system state backups of the upgraded Windows Server 2003 domain controllers. It is recommended to back up at least the first two DCs upgraded in each domain. Store your old Windows 2000 backups separately and do not use them to restore a Windows Server 2003 system accidentally.
9. Optionally, perform an offline defragmentation of the Active Directory database (Ntds.dit) on the upgraded DCs. This is particularly beneficial after the Single Instance Store (SIS) process completes, which optimizes security descriptor storage on upgraded DCs. The SIS process is logged in the Directory Service event log (Event ID 1953 for start, Event ID 1966 for completion). An offline defragmentation using Ntdsutil.exe can significantly reduce the database size and improve performance. Refer to Microsoft KB 232122 for instructions.
10. Revisit the DLT Server Service. While disabled by default on new/upgraded Windows Server 2003 DCs, you may need to re-enable it via Group Policy if older Windows 2000 or Windows XP clients in your environment still rely on it. If DLT is not needed, plan to incrementally delete existing DLT objects using provided scripts. If deleting objects in bulk, be aware of potential replication issues and consider waiting the Tombstone Lifetime (default 60 days) plus garbage collection interval before performing an offline defragmentation to fully reclaim space.
11. Consider implementing the Active Directory best practice organizational unit (OU) structure if you haven’t already. After upgrading to Windows Server 2003 Domain functional level, you can redirect default containers (Users and Computers) to specified OUs using the redircmp and redirusr commands. This helps organize new objects created by downlevel APIs into a managed structure. Refer to Microsoft documentation on Active Directory OU design and redirecting containers (KB 324949).
12. Repeat steps 1 through 10 for each Windows 2000 domain controller you intend to upgrade. Apply step 11 (Best Practice OU structure) per domain as appropriate. Once all desired DCs are upgraded, consider raising the domain and forest functional levels to Windows Server 2003 to enable new features, assuming all domain controllers are now running Windows Server 2003 or later.

Dry-run Upgrades in a Lab Environment¶

Performing a “dry-run” upgrade in a lab environment is a highly recommended practice, especially for complex production forests. A lab environment that closely mirrors your production setup allows you to test and refine your upgrade process without risking your live environment. This practice helps uncover potential issues unique to your environment and build confidence in the planned procedure.

The lab environment should replicate key aspects of your production environment, including hardware configurations (server types, memory, disk layout, BIOS/firmware), software stack (OS versions, service packs, hotfixes, installed applications, schema modifications, security principals, policies), network infrastructure (DNS, WINS, link speeds), and realistic load simulations. The goal is not necessarily to replicate the full scale but rather to test critical operational aspects and interoperability.

Key activities to perform in the lab dry-run include:

• Executing all pre-upgrade inventory and health checks.
• Running adprep /forestprep and adprep /domainprep and observing their impact and replication behavior.
• Performing in-place upgrades of test Windows 2000 domain controllers using Winnt32.exe.
• Promoting new Windows Server 2003 servers using Dcpromo.exe.
• Testing client connectivity and application compatibility after the upgrade.
• Validating Active Directory and FRS replication health post-upgrade.
• Testing your rollback strategy in case of failure.
• Measuring disk space usage at various stages of the upgrade process to anticipate requirements in production.

The insights gained from lab testing inform your production upgrade plan, helping you estimate timelines, identify potential roadblocks, and define appropriate levels of caution. A successful dry-run increases the likelihood of a seamless transition in your production environment, minimizing downtime and mitigating risks.

Domain Controllers Without Sufficient Disk Space¶

Insufficient disk space on volumes hosting the Active Directory database (Ntds.dit) or log files is a common issue that can halt the upgrade process or impact performance. If your inventory reveals domain controllers with limited free space (less than 15-20% of the Ntds.dit size), follow these steps to free up space:

1. Delete temporary files and internet browser caches. Open a command prompt and use commands like cd /d C:\ and del *.tmp /s (replace C:\ with the relevant drive).
2. Remove user dump files or memory dump files if present. Use commands like cd /d C:\ and del *.dmp /s.
3. Temporarily relocate or remove files that can be easily replaced or accessed from other servers. This might include installation media contents, support tools (Adminpak, Suptools), or the contents of the %systemroot%\System32\Dllcache folder. Ensure you have access to these files later if needed.
4. Delete old or unused user profiles from the system. Right-click My Computer, go to Properties, select the User Profiles tab, and remove profiles that are no longer needed. Be cautious not to remove profiles used by service accounts.
5. Delete symbol files located in %systemroot%\Symbols. Use the command rd /s %systemroot%\symbols. This can reclaim a significant amount of space (70 MB to 600 MB or more) depending on the installed symbol set.
6. Perform an offline defragmentation of the Ntds.dit file after completing some of the above steps. While offline defrag can consolidate space, it temporarily requires free space roughly equal to the current database size plus the free space already inside the database. If the volume hosting Ntds.dit doesn’t have enough space for the temporary database copy, perform the defrag on a different volume or a network share with sufficient space. If still constrained, incrementally delete unnecessary objects (like old user/computer accounts, DNS records, DLT objects) from Active Directory before defragging.

By systematically clearing unnecessary files and potentially optimizing the database size, you can free up the required disk space for the Windows Server 2003 upgrade to proceed smoothly.

What are your biggest concerns or questions about this Windows 2000 to Windows Server 2003 domain controller upgrade process? Let me know in the comments below!