Sign In Sign-Up

Welcome!

Close

Would you like to make this site your homepage? It's fast and easy...

Yes, Please make this my home page!

No Thanks

  Don't show this to me again.

Close

PLANNING FOR UPGRADES

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.

Native versus Mixed-Mode Installations

Windows Server 2003 can exist in one of two primary modes (see Figure 3.1). 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 3.1.

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, Table 3.2 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.

Table 3.2. Comparison of Native and Mixed-Mode Functions and Features

Function and Feature	Native Mode	Mixed Mode
Administration across Domains	Full	Limited
Configuration Management with Desktop Queries	Full	Limited
Group Types Support	Universal, Global, Domain Local, Local	Global, Local
Multimaster Replication	Yes	Yes
Password Filters	Automatically on all domain controllers	Must be individually installed on each domain controller
Scalability	1 terabyte or more	40 MB
Security Group Nesting	Yes	No
Transitive Trust	Yes	No (not automatic with Windows NT)

THE PDC EMULATOR

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.

MIXED-MODE SECURITY

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. Table 3.3 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.

Table 3.3. 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

MIXED-MODE VARIATIONS

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 3.2 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.

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.