Upgrading to Windows Server 2003 : Planning a Windows NT Domain Upgrade (part 1)

1/26/2012 1:57:07 PM
Upgrading a Windows NT 4.0 domain to Active Directory isn’t quite the three-click process that you perform when upgrading a single Windows NT 4.0 workstation to Windows XP. In fact, considerable planning is necessary before you even start Windows Setup on the first computer. You must upgrade some computers, such as the PDC and BDCs, in a specific order, while you can upgrade other computers, such as client computers and Windows NT member servers, at any time.

The following sections are essential for anyone planning a Windows NT 4.0 domain upgrade. They cover documenting an existing network, making a recovery plan, planning the Active Directory forest, and developing an upgrade strategy. Subsequent sections cover preparing for the upgrade, the actual upgrade process, and finally, switching an upgraded domain into native Windows 2000 or Windows Server 2003 mode.


You must upgrade the Active Directory schema before adding Windows Server 2003 domain controllers to an existing Windows 2000 Active Directory forest or before adding Windows Server 2003 R2 domain controllers to a Windows Server 2003 or Windows 2000 Active Directory forest.

Choosing Whether to Upgrade or Migrate

If your current domain structure is unsatisfying, it might be tempting to start from scratch, migrating accounts and resources into a fresh Active Directory domain. Resist this impulse if possible.

When migrating to a new domain, you must select a new domain name (a political nightmare in its own right), update all existing links and e-mail addresses, and educate users how to log on and find resources in the new domain. In addition, it’s important to realize that everyone needs to sign off on a decision of this magnitude, and that can be tough. The decision to migrate to a new domain structure is political, not technical.

With that said, it makes sense to look at migrating to a new domain or domain tree if doing so makes it possible to merge two or three separate domains or trees into a single domain or tree. Just remember to carefully weigh the pros and cons and get everyone’s approval before tackling this complex issue. If you choose to migrate to a new domain, refer to the Active Directory for Microsoft Windows Server 2003 Technical Reference for information about the Active Directory Migration Tool (ADMT) and other tools that can help make migration easier.


An in-place domain upgrade is a domain upgrade that you perform while leaving the domain intact. You can also upgrade domains by removing the PDC from the domain, and upgrading it offline. Meanwhile, the BDCs provide services to the existing domain. After testing the upgraded PDC, bring it back into the production domain and upgrade the remaining BDCs.

An Overview of the Active Directory Migration Tool (ADMT)

The Active Directory Migration Tool (ADMT) is a powerful program that you can use to migrate accounts, groups, trusts, profiles, and passwords from an existing Windows NT 4.0, Windows 2000, or Windows Server 2003 domain structure to a new Active Directory forest. This is useful when you want to perform a major domain restructure while minimizing downtime.

Before you can use ADMT to migrate to a new Active Directory forest, you must document the existing domains, trusts, groups, user accounts, service accounts, and computers: Then you must design and create the new Active Directory forest and domain trees. Once the new forest is operating properly, prepare for the migration by performing the following tasks (see the Active Directory Migration Tool Help system for a complete list):

  • Enable remote registry access on all computers that you want to migrate.

  • Switch the functional level of the target domain to Windows 2000 native or Windows Server 2003 functional level. (The source domain can be a Window NT 4.0 domain or an Active Directory domain with any functional level.)

  • Create a temporary two-way trust between the source and target domains. A two-way trust allows you to use an administrator account from the source domain, which is more likely to have the proper permissions on the source objects. At a minimum, the source domain must trust the target domain.

  • Add a common administrator account to the local administrators group on every workstation and member server that you want to migrate. (You can use Active Directory Service Interfaces [ADSI] scripts to automate this.) Then use this account in ADMT to migrate these computers.

  • Disconnect any mapped network drives or connections between the source and target domains.

  • Identify or create a user account for the migration that has administrative privileges in the source and target domains, as well as Exchange Administrator privileges if you want to use the Exchange Directory Migration Wizard.

After preparing the source and target domains, install ADMT on a domain controller in the new forest and then use the ADMT wizards to perform the following tasks (ADMT installs the necessary agents on the source computers if you created the appropriate trusts and permissions):

  • Perform a test run of each migration task, such as migrating user or computer accounts. ADMT allows you to perform a test migration without modifying the actual domains.

  • Create migration reports for each migration test run, and analyze the reports for any problems.

  • Fix any problems, and rerun the tests.

  • Perform the migration in stages, and test the results of each migration stage.

  • Use the Security Translation Wizard to update the access control lists (ACLs) for migrated objects to grant them appropriate permissions in the target forest.

See the Active Directory Migration Tool Help for additional information about migrating and restructuring domains using ADMT. You can download ADMT from the Microsoft Web site at by searching for “ADMT”.

Documenting the Existing Network

The first step in planning an in-place domain upgrade is to document the current network structure. To do so, take an inventory of the following network attributes:

  • The existing domain model

  • Existing trust relationships

  • Account and resource domains

  • DNS namespaces currently in use

  • Server software and compatibility issues

The sections that follow describe how to document each of these features.


Windows Server 2003 digitally signs all server message block (SMB) protocol communications by default for greater network security. Because of this, Windows 9x systems must install the DS Client Pack (found on a Windows 2000 Server CD-ROM in the \clients\win9x folder) and Windows NT 4.0 systems must be running Service Pack 4 or newer to access Windows Server 2003 domain controllers. Computers running Microsoft Windows for Workgroups or Mac OS X do not at present support SMB signing. If you can’t upgrade or retire these systems, you can disable this setting using Group Policy—the location is Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft Network Server: Digitally Sign Communications.

The Existing Domain Model

The type of domain structure, or model, that the existing Windows NT domains use determines how you implement Active Directory trees and forests. Table 1 summarizes the types of domain models that might be in use.

Table 1. Domain models available in Windows NT
Domain ModelDescription
Single-domainA single Windows NT domain
Single-masterOne account domain and multiple resource domains
Multiple-masterMultiple account domains with two-way trusts between them and multiple resource domains that trust all master domains
Complete trustEvery domain is a resource domain and an account domain, with each domain trusting every other domain

Existing Trust Relationships

Document existing trust relationships, and determine whether all trusts are still necessary. Windows preserves existing trust relationships during an upgrade to maintain compatibility with Windows NT 4.0 BDCs. However, Windows doesn’t import trusts with Windows NT 4.0 domains into Active Directory. Re-create these trusts in Active Directory before upgrading or taking the last BDC in the domain offline.

If you upgrade any domains into separate forests and want to maintain trust relationships between the forests, delete the existing trusts (which use NetBIOS domain names) after upgrading the PDC and re-create them using fully qualified DNS domain names.

Account Domains and Resource Domains

Record the current number of account domains and resource domains. Also think about whether you want to restructure your domains, either before or after you upgrade the network to Active Directory.

DNS Namespaces

If the company has already deployed DNS, carefully document the namespaces currently in use. You cannot easily rename domains after you create them, and they must be unique on the network.

Server Software and Compatibility Issues

A crucial and sometimes forgotten step in documenting a network is to make an inventory of the servers. Record the server names, hardware capabilities, locations, operating system version, and service pack levels of the following types of servers, and evaluate any compatibility issues or problems with the servers before you begin the upgrade process:

  • Domain Controllers You must upgrade the Windows NT 4.0 PDC before upgrading any other domain controllers in the domain or adding any Windows 2000 or Windows Server 2003 domain controllers if you want to maintain the existing domain. You can upgrade the BDCs after that.

    Windows Server 2003 and Windows 2000 replace the LAN Manager Replication Service feature of Windows NT with the file replication service (FRS), which Windows installs automatically on all domain controllers. If you must maintain compatibility with the LAN Manager Replication Service, see Microsoft Knowledge Base Article 248358 or refer to the Microsoft Windows Server 2003 Resource Kit.


    The preferred way to upgrade a domain is to purchase a new server to use as the PDC to upgrade. (Install Windows as a BDC, and then promote it to PDC.) This ensures that the computer is modern, compatible, and fast enough to adequately run Windows Server 2003. It also minimizes the amount of junk residing on the hard drive and in the registry, providing the “closest-to-clean installation” experience possible.

  • File and Print Servers You can easily upgrade file and print servers to Windows Server 2003 or migrate the server settings and data to a server running Windows Server 2003. Migrating to a new server can yield performance gains from newer hardware and can also help consolidate servers. Use the Microsoft File Server Migration Toolkit (available for download at or Print Migrator to streamline the migration process.

  • DNS, DHCP, and Windows Internet Name Service (WINS) Servers Upgrade Windows NT 4.0 DNS, DHCP, and WINS servers to Windows Server 2003 or Windows 2000 Server to maximize functionality and to minimize problems.

  • Windows NT RRAS Servers Windows NT 4.0 Routing and Remote Access Service (RRAS) servers need access to a real BDC for user information. They work erratically while on a mixed-mode Active Directory domain, and cease to work entirely after you upgrade the last BDC. For this reason, upgrade any Windows NT 4.0 RRAS servers before you start the domain upgrade process (if practical), or immediately after stabilizing the newly upgraded domain with two or more domain controllers.


    When setting up an Active Directory domain, the Active Directory Setup Wizard gives you the option of weakening the security settings for Active Directory to support pre–Windows 2000 clients. (They’re talking about Windows NT 4.0 RRAS servers here.) Don’t do it—instead upgrade or replace these servers with Windows 2000 or Windows Server 2003 RRAS servers.

  • Windows NT 3.51 Servers If there are still Windows NT 3.51 servers or clients on your network, upgrade them or get rid of them. If you absolutely can’t part with your Windows NT 3.51 (or earlier) computers, leave an existing domain running under Windows NT 4.0 (or create one if necessary) and establish the appropriate trust relationship between this domain and your Active Directory structure. Just keep them off Active Directory domains.

    Security Alert

    Windows NT 3.51 computers joined to an Active Directory domain can deny access to user or group logon events, or they can incorrectly grant access to users or groups to which you have denied access. These difficulties and security breaches occur because of the way in which Windows NT 3.51 generates access tokens when a user logs on to the server.

  • NetWare Servers Determine whether you want to synchronize Active Directory with Novell Directory Services (NDS). Check the release notes included on the Windows Server 2003 CD-ROM for any compatibility issues with NetWare.

  • Samba Servers Samba servers might require access to a real Windows NT 4.0 domain controller (instead of a Windows Server 2003 running the PDC emulator). Record the location and capabilities of any Samba servers on the network, and make a special note of whether they require access to Windows NT domain controllers. (If they do, postpone switching the network to a native mode until this issue is cleared up.) Many Samba servers also do not support SMB signing.

  • Other Application Servers Evaluate all application servers carefully for known issues with Windows 2000, Windows Server 2003, and Active Directory.


    Windows NT 4.0 Enterprise Edition clusters cannot perform a rolling upgrade directly to Windows Server 2003. (A rolling upgrade allows the cluster to stay online while you upgrade each node one at a time.) To deal with this, either take the cluster offline and upgrade each node, or perform a rolling upgrade to Windows 2000, and then Windows Server 2003.

Choosing Whether to Upgrade Individual Servers

Upgrading a server preserves all settings and, when upgrading the PDC, allows you to keep the domain and all its user accounts and resources. However, performing a clean install yields the best performance and reliability. Here’s how you can balance these tradeoffs:

  • Upgrade the PDC and any application servers that are difficult to set up.

  • Retire any aging Windows NT servers, or repurpose them as desktop machines running Windows XP.

  • Back up any relevant data, and then perform clean installs of Windows Server 2003 on any other Windows NT servers that are powerful enough to run Windows Server 2003. After installation is complete, restore the data. The File Server Migration Toolkit and Print Migrator tools can help with this process. (You can download them from

  • Replace any retired servers with new Windows Server 2003 systems that serve whatever role you need.

  •  Upgrading to Windows Server 2003 : Architectural Changes Since Windows NT 4.0
  •  Windows Server 2008 R2 monitoring and troubleshooting : Event Viewer - Configuring event-based tasks & Setting up event log forwarding
  •  Windows Server 2008 R2 monitoring and troubleshooting : Performance Monitoring
  •  Working with the windows 7 common file dialogs (part 3) - Defining a File Save Dialog
  •  Working with the windows 7 common file dialogs (part 2) - Defining a File Open Dialog
  •  Working with the windows 7 common file dialogs (part 1)
  •  Programming Excel with VBA and .NET : Variables (part 4) - User-Defined Types & Objects
  •  Programming Excel with VBA and .NET : Variables (part 3) - Constants, Enumerations & Arrays
  •  Programming Excel with VBA and .NET : Variables (part 2) - Conversions, Scope and Lifetime
  •  Programming Excel with VBA and .NET : Variables (part 1) - Names & Declarations
  •  Windows Vista : Performing Local PC Administration (part 2) - Performing common workstation administration tasks
  •  Windows Vista : Performing Local PC Administration (part 1) - Working with workstation administration tools
  •  Filtering Out Evil with Firewalls (part 3) - Manually Configuring a Firewall's Ports
  •  Filtering Out Evil with Firewalls (part 2)
  •  Filtering Out Evil with Firewalls (part 1)
  •  Windows 7 : Windows Driver Foundation Architecture (part 4) - Tools for Development and Testing
  •  Windows 7 : Windows Driver Foundation Architecture (part 3) - Driver Frameworks
  •  Windows 7 : Windows Driver Foundation Architecture (part 2) - Integrated I/O Queuing and Cancellation
  •  Windows 7 : Windows Driver Foundation Architecture (part 1)
  •  Windows 7 : Using Advanced Security Options (part 2) - Configuring Windows Defender
    Top 10
    Microsoft Content Management Server Development : Managing Channels and Postings with the PAPI - Copying Postings
    Making Movies On Your Camera (Part 1)
    Get to a SharePoint Site
    iPhone Application Development : How Xcode and Interface Builder Implement MVC
    Sony: From Vaio to Vita
    The Language of Apple Platforms : Object-Oriented Programming and Objective-C
    Microsoft XNA Game Studio 3.0 : Displaying Images - Using Resources in a Game (part 2) - Positioning Your Game Sprite on the Screen
    Programming with DirectX : Shading and Surfaces - Types of Textures
    Mobile Phone Game Programming : Using Sprite Animation - Working with the Layer and Sprite Classes
    Embed a Web Browser in Your Application
    Most View
    .NET Enterprise Services Technologies : Windows Workflow Foundation (WF)
    Programming .NET Security : Asymmetric Encryption Explained (part 1) - Creating Asymmetric Keys
    Advanced ASP.NET : Data-Access Components (part 2) - Using the Data-Access Component
    Filtering Out Evil with Firewalls (part 3) - Manually Configuring a Firewall's Ports
    Add RAM to boost performance : Upgrading desktop PC memory
    Windows 7 : Detecting and Resolving Computer Problems (part 1) - Solving the Tough Problems Automatically
    Programming .NET Security : Programming XML Signatures (part 2) - Embedding Objects in the Signature
    JavaScript Patterns : Essentials - Minimizing Globals
    Installing Exchange Server 2010 into an existing Exchange Server 2007 environment (part 2) - Installing the Exchange Server 2010 servers
    Windows Vista : Automating Recurrent Tasks (part 1) - Working with the Command Prompt
    Server-Side Browser Detection and Content Delivery : Mobile Detection (part 4) - Device Libraries
    Using SQL Server 2005 Integration Services : Programming Integration Services (part 4) - Connecting the Source and Destination Adapters with a Path
    Optimizing for Vertical Search : The Opportunities in Vertical Search
    Security Fundamentals : Forms Authentication
    SQL Server 2008 : Using the CLR - Understanding Permission Sets
    iPhone 3D Programming : Anisotropic Filtering: Textures on Steroids
    # BlackBerry Java Application Development : Networking - HTTP Basics
    Mobile Application Security - BlackBerry Security - Permissions and User Controls (part 1) - RIM Controlled APIs
    Windows Server 2008 R2 Active Directory Domain Services Primer : Examining AD DS’s Structure
    Put It On The Bluetooth