Architectural Improvements in Windows 2000

Architectural improvements in Windows 2000 include changes to the types of server roles available and to the type of domain trusts that are used; new support for devices, Plug and Play (PnP), and power management; and, of course, the addition of the Active Directory service. However, all these changes mean that some existing applications and drivers might not work under the new Windows 2000 architecture.

Domain Controllers and Server Roles in Windows 2000

In Windows 2000, the types of server roles are slightly different from those available under Windows NT. Windows NT 4 servers can have one of four roles: primary domain controller (PDC), backup domain controller (BDC), member server, and stand-alone server.

Windows NT domains are single-master based, with the PDC serving as the master repository for a given domain. All changes to the domain must be carried out by the PDC. BDCs serve as working backups to the PDC and also 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; they can be upgraded to the PDC if that server fails or is taken out of service.

Member servers are simply Windows NT servers that belong to a Windows NT domain and 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. Member servers can't be upgraded to a PDC or BDC without a clean reinstallation of Windows NT.

Stand-alone 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 stand-alone 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 by definition it can't be a PDC or BDC. Like member servers, you have to reinstall Windows NT from scratch to upgrade a stand-alone server to a PDC or BDC.

The member server and stand-alone server roles are the same in Windows 2000 as in Windows NT, but the PDC and BDC roles are replaced with a single domain controller role. Yes, domains in Windows 2000 are finally multiple-master based, with all Windows 2000 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 handles replication between all domain controllers. The trade-off is that Windows 2000 domain controllers cannot exist on a Windows NT domain until the PDC of the domain has been upgraded to Windows 2000. This issue is covered in greater detail later in this chapter, in the section entitled Planning a Domain Upgrade.

Windows 2000 member servers and stand-alone servers can be promoted to domain controller status, and domain controllers can be demoted to member servers or stand-alone 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 family. It is a scalable, easily administered, fault-tolerant directory service that is required by Windows 2000 domain controllers and is also recommended for use on Windows 2000 DNS servers. Active Directory is covered in detail in Chapters 11 and 12, so we address it only briefly in this chapter. It is useful to review a few points before entering into a discussion about upgrading Windows NT domains to Windows 2000.

Active Directory Domains

Although Active Directory doesn't make fundamental changes to the way domains work for end users in Windows 2000, it does introduce some important domain structures that affect the way one should 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, either politically or geographically. Each domain requires at least one domain controller (and preferably more) to store the domain information, with each domain controller being a master of the domain. See Chapter 3 for more on domain planning.

Active Directory domains use DNS names for domain names instead of the NetBIOS naming structure of Windows NT domains (although NetBIOS names are generated for backward compatibility). Active Directory domains are hierarchically organized, as required by DNS. In Active Directory, hierarchically organized groups of domains with a contiguous namespace are called trees, and groupings of trees with noncontiguous namespaces are called forests. For example, scribes.com and all subdomains (support.scribes.com, finance.scribes.com, etc.) would belong to a single tree; a different division of the company, wwowidgets.com, might have its own tree in the forest. Because the companies share their networks and are administered together, they belong to the same forest; the suppliers and partners of the companies would have their own forests. Trust relationships can be established between the forests as necessary to allow them to more easily do business with each other.

Sites, Structural Domains, and Organizational Units

Active Directory also introduces the concepts of sites, structural domains, and organizational units (OUs). A site is defined as 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. See "Planning the Site Topology" later in this chapter for further information.

Structural domains are domains that contain no accounts; they simply serve as a root to lower level child domains. As such, structural domains make it easy to restructure child domains, and they also make replication between domains easier and faster, as all domains simply replicate with the structural domain, which serves as a sort of replication hub. For a further discussion, see the Real World note "Using Structural Domains," later in this chapter.

Organizational units (OUs) are very 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 therefore 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. They can also easily be converted to domains, and domains can easily be converted to OUs, making them very flexible. You'll find more on the uses and creation of OUs in Chapter 11.

Trust Relationships in Active Directory

Trust relationships complicate life in an enterprise with multiple Windows NT domains. Windows 2000 takes a big step toward simplification, although, as is often the case with improvements, things might get worse before they get better.

Simply stated, a trust relationship is a mechanism by which users and resources in one domain can be authenticated by a domain controller in another domain. For example, say that a user, Erin, in the Windows NT 4 domain Administration, wants to access a resource in the Windows NT 4 domain Manufacturing. When Erin attempts to access the resource, the resource must verify that she has an account that's allowed to access it. If a trust relationship is established so that the Manufacturing domain trusts the Administration domain, the resource in the Manufacturing domain will contact its local BDC or PDC, which will in turn query the PDC or a BDC in the Administration domain and verify that Erin has a valid account and that the account belongs to a group permitted to access the resource.

Among and between Windows NT 4 and earlier domains, all trusts are nontransitive, meaning that each trust is a one-way relationship between two domains that must be established explicitly. For two domains to trust each other, two separate trust relationships must be established—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 7-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. Each trust relationship must be established separately and explicitly.

Figure 7-1. Three domains under Windows NT 4 and under Windows 2000.

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.yourcompany.com and manufacturing.yourcompany.com) would thus automatically mean that users in each domain could be authenticated and be eligible to access resources in the other domain (though they'd 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 make use of the parent domain's trusts using the automatic transitive trust that is created between the child domain and the parent domain. For example, let's say you create a widgets.manufacturing.yourcompany.com child domain. Users in this domain are automatically eligible to access resources in the manufacturing.yourcompany.com domain (the parent domain) as well as the yourcompany.com domain (the parent domain of the parent domain, or the grandparent domain if you will.

Transitive trusts become available once a domain is upgraded to Active Directory. Despite some confusion over the matter, they do operate in mixed-mode domains, 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 they must be manually established.

Real World

Whom Do You Trust?

The question of transitive trusts arises in large multidomained enterprises. But even there, it's not an issue until all of the Windows NT domain controllers have been permanently removed from a domain. Although there are advantages to having all domains be Windows 2000 domains, it's not necessary to rush to reach that point. In the meantime, the existing trusts remain in place during the upgrade process, and the only trusts that are added are the nontransitive ones that you explicitly and deliberately set. This means that if you are creating a new Windows 2000 domain, you have to manually create trusts with existing Windows NT domains.

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

Table 7-1. Trust relationships between domains of different types

	Windows NT Domain	Windows 2000Domain (Same Forest)	Windows 2000Domain (Different Forest)
Windows NT Domain	One-way trust1	One-way trust1	One-way trust1
Windows 2000 Domain	One-way trust1	Two-way transitive trust (one-way trusts available)	One-way trust1

Hardware Support

Without dispute, Windows NT has always been very particular about hardware. Users of Windows 95 and Windows 98 have long enjoyed broad device driver support, PnP, Power Management, IEEE 1394 (Firewire), and Universal Serial Bus (USB)—the latter in Windows 95 OSR 2.1 and Windows 98. Windows NT 4 and earlier versions lack support for pretty much all the previously listed features. Windows 2000 changes all of that.

Windows 2000 introduces top-of-the-line support for PnP, USB, IEEE 1394 (Firewire), and Advanced Configuration Power Interface (ACPI) device configuration and power management. Device support is also vastly improved and getting better now that Windows XP is Microsoft's primary desktop operating system (as most Windows XP drivers are backward-compatible with Windows 2000). In most cases, if the device was supported under Windows NT 4, it will be supported under Windows 2000 with a native Windows 2000 driver. However, the same is not always true for Windows 95/98, so check the Hardware Compatibility List (HCL) or contact the device manufacturer to determine whether the device is supported under Windows 2000.

An up-to-date, ACPI-compatible BIOS is required for full use of PnP and Power Management. Legacy Advanced Power Management (APM) and PnP BIOSs are supported, but their features are limited.

Device drivers in Windows 2000 have changed to enhance system stability and to increase the number of devices supported. The Win32 Driver Model (WDM) is now supported, enabling many drivers to work interchangeably with Windows 2000 and Windows 98 (as well as Windows XP). Device Driver Signing is also supported, and drivers that haven't been tested and digitally signed by Microsoft trigger an alert when installed. (Administrators can also create policies preventing unsigned drivers from being installed.) Changes have also been made to the driver model to prevent system instability and to facilitate PnP and Power Management, which unfortunately prevents some Windows NT drivers from working in Windows 2000. In addition, power management and PnP aren't available with Windows NT 4 drivers.

As in Windows NT 4, device drivers written for Windows 95, Windows 3.x, or MS-DOS will not work in Windows 2000. Windows XP drivers should, in most cases, work fine with Windows 2000.

Software Support

Software support is an area in which Windows 2000 has some compatibility issues (and lags somewhat behind Windows XP). Like Windows NT 4, Windows 2000 might experience compatibility problems with MS-DOS and Windows 3.x programs (especially any that directly access the hardware). Windows 95/98 applications that don't explicitly support Windows NT or Windows 2000 might also run into problems. Nearly all Windows NT 4 applications run under Windows 2000.

Microsoft, recognizing the problem Windows 2000 has with earlier applications, has done a couple of things to address this issue. The first thing they did was release regular Application Compatibility Updates, which are available for download from Windows Update. These updates are a series of tweaks designed to make programs run that previously exhibited problems under Windows 2000. The second thing they did was provide special compatibility modes (as seen in Windows XP) that can be turned on by administrators, a feature that was added in Windows 2000 Service Pack 2 (see Chapter 25 for more information). This allows users or administrators to run a program in a compatibility mode (once compatibility modes have been enabled) designed to simulate Windows 95, Windows 98, or Windows NT with various service packs.

Upgrading an existing Windows 95/98-based system presents additional complexities because vendors often have different versions of their software for Windows 95/98 and Windows NT/2000, or because 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.