Upgrading to Windows Server 2003 : Architectural Changes Since Windows NT 4.0

1/26/2012 1:54:00 PM
Windows 2000 and the Windows Server 2003 family introduce numerous architectural improvements as well as some changes to the way Windows domains work. The following sections discuss the changes that are relevant to upgrading: the types of server roles available and the type of domain trusts that are used; new support for devices; Plug and Play (PnP); Power Management; and of course, the addition of the Active Directory service.

Domain Controllers and Server Roles

In Windows 2000 and the Windows Server 2003 family, the types of server roles are slightly different from those available in Windows NT. Windows NT 4.0 servers can have one of four roles: primary domain controller (PDC), backup domain controller (BDC), member server, and standalone server. Windows 2000 and the Windows Server 2003 servers can have one of three roles: domain controller (DC), member server, and standalone server.


Windows Server 2003 also uses the term “server role” to describe the function a server performs—for example, file server, print server, or SharePoint server.

Server Roles in Windows NT 4.0

Windows NT domains are single-master based, with the PDC serving as the master repository for a given domain. The PDC must carry out all changes to the domain. BDCs serve as working backups to the PDC and reduce the load on the PDC by serving client requests themselves. BDCs maintain a current copy of the domain by synchronizing periodically with the PDC; you can upgrade a BDC to the PDC if the PDC server fails or is taken out of service.

Member servers are simply Windows NT servers that belong to a Windows NT domain and are not domain controllers. Member servers usually perform file sharing or print sharing or run some other type of server software, such as Web, Domain Name System (DNS), or Dynamic Host Configuration Protocol (DHCP) server software. You can’t upgrade a Windows NT 4.0 member server to a PDC or BDC without a clean reinstallation of Windows NT, and you can’t demote a PDC or BDC to a member server without reinstalling Windows NT.

Standalone servers are Windows NT servers that do not belong to a Windows NT domain and are instead part of a workgroup. It is important to understand that although a standalone server doesn’t belong to a Windows NT domain, it isn’t limited in its duties as a server. It can still act as a DNS, DHCP, or other type of server, but it can’t act as a central repository for user and group data like a PDC or BDC can. To upgrade a standalone server to a PDC or BDC, you must reinstall Windows NT.

Server Roles in Windows 2000 and Windows Server 2003

The member server and standalone server roles are unchanged for the Windows 2000 Server and Windows Server 2003 families, but Windows 2000 and Windows Server 2003 replace the PDC and BDC roles with a single domain controller role. Domains in Windows 2000 are finally multiple-master based, with all Windows 2000 or Windows Server 2003 domain controllers acting as peers to one another. Any domain controller can make changes to the domain at will. All domain information is stored in Active Directory, which the File Replication Service (FRS) replicates between all domain controllers. The tradeoff is that Windows 2000 and Windows Server 2003 domain controllers cannot exist on a Windows NT domain until you upgrade the PDC of the domain to Windows 2000 or Windows Server 2003.

You can promote Windows 2000 and Windows Server 2003 member servers and standalone servers to domain controller status, and you can demote domain controllers to member servers or standalone servers without reinstalling the operating system—the only way to demote a BDC under Windows NT. However, as always, it’s preferable not to make more role changes than necessary.

Active Directory

Active Directory is probably the most important new feature in the Windows 2000 Server and Windows Server 2003 family. It is a scalable, easily administered, fault-tolerant directory service that is required by Windows 2000 and Windows Server 2003 domain controllers. Active Directory is also the usual repository for the DNS server database on Windows 2000 and Windows Server 2003 DNS servers.

Active Directory Domains

Although Active Directory doesn’t make fundamental changes to the way domains work for end users, it does introduce some important domain structures that affect the way you approach domain design. Active Directory, like the directory service in Windows NT, uses domains as the core unit of logical structure. Domains help organize the network structure to match the organization of the company. Each domain requires at least one domain controller (and preferably more) to store the domain information, and each domain controller can make changes to the domain.

Active Directory domains use DNS names for domain names instead of the Network Basic Input/Output System (NetBIOS) naming structure of Windows NT domains (although Windows 2000 Server and Windows Server 2003 generate NetBIOS names for backward compatibility). Active Directory domains are hierarchically organized—as required by DNS. Active Directory refers to hierarchically organized groups of domains with a contiguous namespace trees, and groupings of trees with noncontiguous namespaces are known as forests. For example, example.local and all subdomains (support.example.local, finance.example.local, and so forth) belong to a single tree; while a different division of the company (, for example) has its own tree in the forest. Because the companies share their networks and administer them together, they belong to the same forest; the suppliers and partners of the companies would have their own forests. You can establish trust relationships between the forests as necessary to allow them to do business with one another more easily.

Active Directory domains are nearly identical between Windows Server 2003 and Windows 2000 Server; however, upgrading the functional level of a forest and relevant domains to one of the Windows Server 2003 functional levels provides enhanced Active Directory management capabilities, including the ability to rename and move domains within or between forests.

Sites and Organizational Units

Active Directory also introduces the concepts of sites and organizational units (OUs). A site is a group of one or more Internet Protocol (IP) subnets that share local area network (LAN) connectivity. Within a site there can be one or more domains, or a single domain can span multiple sites.

Organizational units (OUs) are similar to domains in that they are containers for network objects such as user accounts and resources. Unlike domains, however, they do not mark a security boundary, and creating OUs doesn’t require adding domain controllers (because OUs exist within a domain and thus make use of the existing domain controller infrastructure). OUs in Active Directory provide an excellent way to provide organization within a domain without the need for additional security policies and domain controllers. You can easily convert OUs to domains, and domains to OUs, which makes them very flexible.

Forest Root Domains

The first domain you create in Active Directory automatically becomes the forest root domain—the top-level domain in the Active Directory hierarchy. If you create additional domain trees (with their own contiguous namespaces), Active Directory creates transitive two-way trusts between the trees and the forest root domain, as if the trees were child domains. Indeed, from a trust and replication perspective, it appears that the subsequent trees are children of the forest root, even though they use completely different namespaces.

Besides its significance as the hub of replication between trees, the forest root domain also contains the Enterprise Admins and Schema Admins groups, which have forest-wide administrative scope.

Because the forest root domain is so important, fault-tolerance and recoverability is critical. If a regional catastrophe wiped out all domain controllers and backups in the forest root domain, the Enterprise Admins and Schema Admins groups would be forever lost, and you would have to re-create the entire forest.

To help reduce the need to alter the forest root domain, you can create a dedicated forest root domain exclusively for forest-level administration and replication, and place the majority of accounts and resources in child domains. Because there are few user accounts and resources in a dedicated forest root domain, Active Directory structures that consist of a dedicated forest root and a single child domain are often said to be using the Single Global Domain Model. Active Directory structures that consist of a dedicated forest root with multiple child domains are referred to as using the Regional Domain Model—a nod to the fact that the child domains are often organized geographically.


You cannot easily retire or change the forest root domain, even if the organization changes. However, you can rename the forest root domain if the forest uses the Windows Server 2003 functional level, though you cannot move or delete it.

Trust Relationships

Trust relationships are an important component of large networks that consist of multiple domains. Simply stated, a trust relationship is a policy that enables users from one domain to access resources in another domain.

For example, say that a user, Susan, in the domain Administration, wants to access a resource in the domain Manufacturing, and that the Manufacturing domain trusts the Administration domain. When Susan attempts to access the resource, the resource must verify that she has an account that has permission to access it. To authenticate Susan, the resource in the Manufacturing domain contacts its local domain controller (DC, BDC, or PDC), which in turn queries a domain controller in the Administration domain and verifies that Susan has a valid account and that the account belongs to a group permitted to access the resource.

Trust Relationships in Windows NT 4.0

Among and between Windows NT 4.0 and earlier domains, all trusts are nontransitive, meaning that each trust is a one-way relationship between two domains that you must explicitly create. For two domains to trust each other, you must create two separate trust relationships—one for each direction.

A nontransitive trust is also strictly limited. For example, suppose that the domain Finance also trusts the domain Administration (as shown in Figure 1). When nontransitive trusts are involved, this statement tells you only that the Finance and Manufacturing domains both allow users from the Administration group access to their domains. It does not tell you anything about the relationship between the Finance and Manufacturing domains, nor does it indicate whether Administration, in turn, allows either Finance or Manufacturing to authenticate users. You must create each trust relationship separately and explicitly.

Figure 1. Three domains under Windows NT 4.0 and under Windows 2000

Trust Relationships in Active Directory

Active Directory introduces transitive trusts. Transitive trusts are always two-way, and they support pass-through authentication. Creating a trust between the Administration and Manufacturing domains (now probably called administration.example.local and manufacturing.example.local) automatically means that users in each domain can be authenticated and be eligible to access resources in the other domain (though they still need to have proper permissions, of course).

Pass-through authentication comes into play with child domains. With Active Directory domains, users in the child domain can use the parent domain’s trusts by means of the automatic two-way transitive trust that Active Directory creates between the child domain and the parent domain. For example, let’s say you create a widgets.manufacturing.example.local child domain. Users in this domain are automatically eligible to access resources in the manufacturing.example.local domain (the parent domain) as well as the example.local domain (the parent domain of the parent domain—the grandparent domain, if you will).

Transitive trusts become available after you upgrade a domain to Active Directory. Despite some confusion over the matter, they do operate in domains that use the Windows 2000 mixed functional level and work between trees in a forest, but they do not apply to remaining Windows NT domains in your company or to clients connected to Windows NT BDCs. (These domains and clients rely on existing one-way nontransitive trusts.) Explicit one-way trusts are also available between Active Directory–based domains, but you must create them manually.

Windows Server 2003 provides additional capability to set up one-way or two-way transitive trusts between forests, and the ability to rename and move domains within and between forests after you upgrade the forests to the Windows Server 2003 forest functional level.

Real World: Whom Do You Trust?

The question of transitive trusts arises in large multidomained enterprises. Active Directory domain controllers automatically use transitive trusts when communicating with other Active Directory domain controllers, even in domains that use the Windows 2000 mixed functional level. The existing trusts remain in place for use by Windows NT BDCs until you switch the domain to the Windows 2000 native or Windows Server 2003 functional level. Trusts that you add to or take from Windows NT domains are the nontransitive trusts that you explicitly and deliberately set. This means that if you are creating a new Active Directory domain, you must manually create trusts with existing Windows NT domains.

Table 1 shows the possible trust relationships between different types of domains.

Table 1. Trust relationships between domains of different types
 Windows NT DomainActive Directory Domain (Same Forest)Active Directory Domain (Different Forest)
Windows NT DomainOne-way trust[*]One-way trust[*]One-way trust[*]
Active Directory Domain (Windows 2000)One-way trust[*]Two-way transitive trust (One-way trust available)One-way trust[*]
Active Directory Domain (Windows Server 2003 forest functional level)One-way trust[*]Two-way transitive trust (One-way trust available)Two-way transitive forest trust (One-way trust available)

[*] You can establish one-way trusts in both directions, simulating a two-way trust.

Hardware Support

Hardware support for the Microsoft business operating systems has come a long way. Windows 2000 shed the Windows NT legacy of nonexistent drivers, device configuration nightmares, and poor support for modern technologies by introducing top-of-the-line hardware support for the whole alphabet soup: Plug and Play (PnP), Universal Serial Bus (USB), Institute of Electrical and Electronics Engineers (IEEE) 1394 (Firewire), and Advanced Configuration Power Interface (ACPI) device configuration and power management.


An up-to-date, ACPI-compatible BIOS is required for full use of PnP and power management. The ACPI BIOS should support the Advanced Programmed Interrupt Controller (APIC) standard, which raises the 15 interrupt request (IRQ) limit and enhances IO performance as well. (All multiprocessor systems support APIC, as do all systems certified for use with Windows Server 2003 or Windows XP.) If the system doesn’t boot after upgrading a standard Programmed Interrupt Controller (PIC) BIOS to APIC operation, restore the old BIOS or reinstall the operating system. Windows Server 2003 supports legacy Advanced Power Management (APM) and PnP BIOSs, but their features are limited.

Device drivers in Windows 2000 also changed to enhance system stability and to increase the number of devices supported. Windows 2000 supports the Win32 Driver Model (WDM), enabling most WDM drivers to work interchangeably with Windows 2000, Windows XP, Windows Server 2003, Windows 98, and Windows Me. Device Driver Signing triggers an alert when you install drivers that Microsoft hasn’t tested and digitally signed. (Administrators can create policies blocking the installation of unsigned drivers.) Microsoft also fine-tuned the driver model to reduce system instability and to facilitate PnP and power management. Windows XP added device driver rollback, and support for CD-RW drives and USB 2.0 devices. Windows Server 2003 added support for Fibre Channel, Hot Plug PCI, and storage area networks (SANs), among other technologies.

However, broad device driver availability is only part of the equation for servers. Because device drivers are one of the leading causes of system instability, simply having a driver isn’t enough. It is very important that servers use only device drivers that are Microsoft certified and digitally signed.


The vast majority of Windows 2000 drivers work fine in Windows XP and Windows Server 2003. Although many Windows NT 4.0 drivers work in Windows Server 2003, they do not support power management or Plug and Play and can more easily decrease the stability of the operating system. For this reason, most companies use Group Policy to block the installation of Windows NT 4.0 drivers. Windows 98 and Windows Me WDM drivers often work fine on Windows XP systems, but avoid them on servers for stability reasons—drivers are a leading cause of system crashes. Windows 95, Windows 3.x, and MS-DOS drivers absolutely don’t work in Windows 2000, Windows XP, or Windows Server 2003.

Software Support

Software support, like hardware support, is another area where Windows has made great advances since Windows NT 4.0, which is largely incapable of running applications written for other versions of Windows, such as Windows 98. Windows Server 2003 and Windows XP run many popular Windows 98 and Windows Me applications out of the box and support many more with Application Compatibility Updates, which are available from Microsoft Update (

Windows XP and Windows Server 2003 also provide special compatibility modes that simulate key aspects of the Windows 95, Windows 98, Windows NT, or Windows 2000 operating systems, allowing end users to take additional steps to run incompatible programs. Microsoft also provides the Application Compatibility Toolkit (see that administrators can use to inventory deployed applications, evaluate any compatibility problems, and create custom compatibility fixes for the applications.


Upgrading an existing Windows 98–based or Windows Me–based system presents additional complexities. Vendors often have one version of their software for Windows 98 and Windows Me, and another for Windows NT, Windows 2000, and Windows XP. Furthermore, the same application is installed differently depending on the operating system involved. Consequently, many applications require vendor-provided migration files (upgrade packs) during the operating system upgrade, or they must be uninstalled and then reinstalled after the upgrade completes.

  •  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
  •  Windows 7 : Using Advanced Security Options (part 1) - Configuring the Action Center & Performing a Manual Scan
    Top 10
    Microsoft Sues Comet For Pirating Windows
    IIS 7.0 : Configuring IIS Logging
    Documenting an Exchange Server 2010 Environment : Exchange Server 2010 Project Documentation
    SQL Server 2008 : Working with DML Queries - Using the UPDATE Statement (part 1)
    Linking PCs with a Network : Creating a Wired and Wireless Computer Network
    Samsung LED TV ES8000 - The SMART in Smart TV
    Mobile Application Security : SymbianOS Security - Introduction to the Platform
    Mobile Application Security : SymbianOS Security - Application Packaging
    SQL Server 2008 : Explaining Advanced Query Techniques - Creating and Altering Tables
    Hashing Algorithms: Extending the .NET Framework (part 1)
    Most View
    Parallel Programming with Microsoft .Net : Parallel Aggregation - Variations
    Silverlight : Response to Timer Events on the UI Thread
    The best social game apps for iOS Device (Part 1) - Draw Something, Mailboxing
    Fitbit Ultra: Track your move
    Programming Hashing Algorithms (part 1) - The HashAlgorithm Class
    Windows Server 2008 : Transport-Level Security - Active Directory Rights Management Services
    Designing a Windows Server 2008 R2 Active Directory : Choosing a Domain Structure
    Watch for File System Changes
    Windows Server 2003 : Installing and Configuring Domain Controllers
    ASP.NET AJAX : Partial Refreshes (part 3) - Triggers
    Fallen IT Giants
    Upgrading to SQL Server 2008
    Linking PCs with a Network : Creating a Wired and Wireless Computer Network
    SharePoint 2010 : Operations Management with the SharePoint Central Administration Tool (part 1) - Administering Application Management Tasks in SPCA
    Supporting Computers Running Windows Vista
    Ditch your printer today : Step-by-step print your files to PDF (part 1)
    Exchange Server 2010 : Utilize the Availability Options for Servers Based on Role (part 1) - Load-Balance Client Access Servers
    iPhone 3D Programming : Adding Depth and Realism - Lighting Up (part 2)