The issues discussed in previous sections of this book all apply to planning an upgrade for a Windows NT enterprise. However, a number of additional issues must be taken into account that do not exist when creating a Windows Server 2003 enterprise from scratch.


This discussion assumes that administrators who are involved with the upgrade from Windows 200/NT have full working knowledge of that operating system. If you do not have administrative knowledge of Windows NT, please seek additional reference information on it. Although it is possible to perform an upgrade from Windows NT to Windows Server 2003 without knowing Windows NT, doing so could result in problems.

Native versus Mixed-Mode Installations

Windows Server 2003 can exist in one of two primary modes (see Figure). The first is the native mode. Here all domain controllers with a domain or forest use Windows Server exclusively, although down-level clients and servers can still run using other versions of Windows 2000 and Windows NT, Windows 3.x, and Windows 9x. The second is the mixed mode, in which Windows Server 2003, Windows 2000, and Windows NT domain controllers are accommodated. The two modes are compared in Figure.

1. Native versus Mixed Mode Domains


One of the most significant planning decisions to make is which mode Windows Server 2003 will operate under, native or mixed. As discussed in later chapters, working in native mode has a number of advantages. For quick reference, Figure provides a comparison of native and mixed-mode functions and features.

As described in the Active Directory installation section in Chapter 6, advancing to native mode involves a single command. However, in practical terms many enterprises will need to phase their migration to Windows Server 2003 and therefore will operate in mixed mode for some prescribed period of time. Therefore, for the purpose of this initial planning discussion we will assume that the deployment will initially involve a mixed-mode environment.


Cross-forest authentication in mixed mode requires special attention. To enable a server running Routing and Remote Access in a domain in one Active Directory forest to authenticate the remote access credentials for a user account in a domain in another Active Directory forest, use a RADIUS proxy.

Comparison of Native and Mixed-Mode Functions and Features

Function and Feature

Native Mode

Mixed Mode

Administration across Domains



Configuration Management with Desktop Queries



Group Types Support

Universal, Global, Domain Local, Local

Global, Local

Multimaster Replication



Password Filters

Automatically on all domain controllers

Must be individually installed on each domain controller


1 terabyte or more

40 MB

Security Group Nesting



Transitive Trust


No (not automatic with Windows NT)


Since the Windows Server 2003 domain model is based on a multimaster domain scheme in which all domain controllers replicate information as peers, the Windows NT Primary Domain Controller (PDC) and Backup Domain Controller model is replaced. However, in mixed mode, Windows Server must also fill the role of the PDC. Therefore, it includes a PDC Emulator that permits continued interaction with Windows NT BDC and member servers.

A Windows Server domain controller is selected to serve as the PDC Emulator. When requests for changes in the Windows NT Security Account Management (SAM) database occur, the PDC Emulator maintains SAM and replicates that information using NTLM to the BDC. It also supports authentication logon requests for LAN Manager (LANMAN), but this activity is transparent to down-level clients. The PDC Emulator communicates changes to the Active Directory so that normal replication can occur between domain controllers. While all Windows Server 2003 objects are maintained by Active Directory, this data is exposed to down-level clients as a flat Windows NT data store.


The scalability of the Active Directory in a mixed environment is limited to 40 MB as a result of the size limitation that existed on Windows NT domain controllers. This limitation can be overcome and full scalability provided to the Active Directory only by moving to native mode.


Mixed-mode environments involve a number of security-related concerns. They are briefly outlined here.

  • Object security and relative identifiers. The relative identifier (RID) identifies the domain controller that creates objects and limitations, and is always unique. Every domain controller can create objects and assign a RID in a native environment. However, in Windows NT domains only the PDC assigns identifiers based on sequential numbers. This situation creates an obvious possibility for conflict. Therefore, in a mixed environment every domain assigns a Windows Server domain controller (usually the upgraded PDC) to act as a RID Master. The RID Master creates the security identifiers (SIDs, also known as security principals) for down-level domain controllers. Each domain controller is assigned a set of RIDs within a domain by the RID Master. The domain controllers then use RIDs in conjunction with their unique domain IDs to issue security IDs for new groups, user accounts, and computer accounts.

  • SAM database. When a PDC is upgraded, all information stored in the Security Account Manager is moved to the Active Directory. In mixed environments, the PDC Emulator communicates down-level changes to the SAM databases in the remaining BDC. Figure illustrates migration of a SAM database to the Active Directory.

  • System security application. Windows NT group policies used by clients and servers are processed by Windows Server 2003; however, once an upgrade occurs, only Windows Server 2003 group policies will be recognized. Older Windows NT policies can be used on an upgraded system via an option set to enable them. However, this should be done with great caution. A better approach is to create policies that mimic the desired Windows NT policies and apply them as part of the Windows Server deployment.

  • Trust relationships. As discussed in Chapter 6, Windows .NET uses two-way transitive trust relationships between domains. These are not automatically supported by Windows NT down-level domain controllers. To permit authentication between domains in a mixed environment, Windows NT domain controllers must establish an explicit trust.

Migration of SAM Database Information to the Active Directory

SAM Database Component

Moved to Active Directory

User Accounts

User container

Computer Accounts

Computer container

Built-in Local/Global Groups

Built-in container

Non–Built-in Groups

User container

PDC Computer Account

Domain controller organizational unit

NTFS File and Folder Permissions

Retained, not changed


The mixed-mode environment limits some of the Windows Server 2003 services. A partial list of limitations in mixed-mode environment includes the following:

  • Logon services. When Windows Server 2003 clients try to log on, they first use the DNS to find a Windows Server domain controller and use Kerberos for authentication. If a Windows Server domain controller cannot be located, the client uses the NTLM protocol and logs on to a Windows NT domain controller. In this case, no Windows Server 2003 group policies and scripts are processed. A minimum of one Windows .NET domain controller per site should be installed to prevent this rollover.

  • Replication services. Windows Server 2003 uses the File Replication Service (FRS). FRS replaces the Windows NT LAN Manager Replication (LMRepl) service, which Windows Server 2003 does not support. Therefore, these services in mixed environments must be bridged. The Windows NT export directory server should be upgraded last and those containing the import directory first. Add the export list on Windows Server by use of the Server Manager. The Windows NT scripts directory should be copied to the Windows Server 2003 domain controller system volume.

Domain Models

Windows Server 2003 is designed under a multimaster replication domain model, which is much less complex than the four models available under Windows NT. The transitive trust relationships between domains in Windows Server 2003 permit flexible configurations that greatly simplify the older models. Note that it may be appropriate to go directly to the Chapter 6 discussion of the Windows Server domain model after reading this section.

In the upgrading of Windows NT domain models, it is important to understand how the current model will be used in Windows Server 2003. The following is a brief summary of how the Windows Server 2003 domain model relates to Windows NT domains.

  • Windows NT single domain model. The Windows NT single domain model converts directly to the Windows Server 2003 domain model. It provides the added value of being able to break the existing domain into organizational units in which administrative delegation can occur.

  • Windows NT master domain model. In Windows NT, the master domain model provided a hierarchy in which child domains were used as resource domains. One-way trust relationships went from the resource domains to the master domain. This model can remain in place under Windows Server 2003 with the added value of two-way transitive trusts between domains. The master domain should be upgraded first and will become the root domain for the Windows Server domain tree. Alternatively, the Windows NT resource domains can be included in a single Windows Server domain and treated as administrative organizational units.

  • Multimaster domain model. The Windows NT multimaster domain model provides two-way trusts between two or more master domains. It was used primarily in large enterprises where decentralized account management was desired. To move this model across, you will need to create a domain tree. The root domain should initially be created and remain empty. The master domains should then be upgraded as child domains in the domain tree.

  • Complete trust domain model. The complete trust model provided two-way trusts between all the domains. The upgrade can take the form of a single forest with multiple domains or the creation of multiple forests with explicit trust.

Figure illustrates how existing Windows NT domains can be adapted to Windows Server 2003. In the cases of existing Windows NT multimaster domain model and the complete trust domain model, two alternative migration paths are illustrated.

2. Changing Domain Models


Upgrade Steps

Six primary steps should be taken during the upgrading of a Windows NT enterprise to Windows Server 2003. The objective of these steps is to preserve account information and other data from the Windows NT environment.

  1. Review the domain structure and determine the DNS name. As suggested previously, changes to the domain structure may be required. At this stage you will need to understand the current trust relationships and how they will be implemented under Windows Server 2003, as well as determine the number of domain controllers per domain. Also, you must assign DNS-compliant names during the upgrade process. If you do not have a DNS name, we recommend that you select one and register it through one of the Internet name registration authorities.

  2. Establish a backup and recovery plan. Guarding against accidents or improper upgrade installations is very important. First, back up all services running on the PDC, and test the backup media prior to continuing. Second, make sure that the PDC and all BDCs are fully synchronized. Third, remove a BDC from the network, promote it as a standalone PDC, and demote it back to BDC status. Make sure that no data corruption occurs and that the system is fully operational. The system should remain apart from the network until the upgrade to Windows Server 2003 has been carried out and fully tested. This BDC is your lifeline if Windows Server 2003 fails and it is necessary to revert to Windows NT. In such a case, the Windows Server 2003 domain controllers would be removed and this system would go back online and be promoted as the PDC.

  3. Upgrade the Primary Domain Controller. The PDC is always the first domain controller to be upgraded. If the current PDC is older, slower, and lacking sufficient disk and memory, consider replacing it before upgrading. The root Windows Server 2003 domain controller initially serves many functions, including the Schema Master and Global Catalog server functions. To make this upgrade, install a new system as a BDC and then promote it to the PDC. Now Windows Server 2003 can be installed. After the basic installation is completed, install the Active Directory. The Windows NT SAM database security components, including user accounts, local and global groups, and computer accounts, are moved into the Active Directory. If other domains exist, they should be upgraded after the root Windows Server 2003 domain controller with the Active Directory fully operational. (The initial upgrade should be done off-line in a test environment.)

  4. Upgrade the secondary domain controllers. BDCs should be upgraded as soon as possible to prevent continued use of a mixed mode. When the existing BDCs join the domain, they are automatically promoted to peer-level domain controllers, and should then be added to the replication topology. (Retain a BDC until the Windows Server 2003 installation has been judged to be successful.)

  5. Upgrade workstations and member servers. Workstations and member servers can be upgraded in any order. We suggest installing the Active Directory client so that organizational units are visible. Systems without Active Directory client software, or down-level systems, view objects as flat stores without information about which organizational unit they reside in.

  6. Verify and test the upgrade. Verification and testing should take place from both the domain controller and the user client vantage point. From the root domain controller, review the dcpromo.log file. In addition, run two scripts available with the Windows Server 2003 Resource Kit: listdc.vbs to list all the domain controllers, and listdomains.vbs to list domain names within a tree. From the client perspective, attempt several user logons to verify if logon authentication is operational, user and group accounts have been applied, and logon scripts are being run.


Upgrading cluster environments involves a very precise set of procedures. Microsoft provides more than forty pages of instructions for this specialized installation. These instructions are included in the release notes of Windows Server 2003 products. We strongly advise that you refer to the release notes before initiating any such upgrade.

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows