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.
Note
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 (example.com, 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.
Note
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.
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.
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 Domain | Active Directory Domain (Same Forest) | Active Directory Domain (Different Forest) |
|---|
| Windows NT Domain | One-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) |
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.
Note
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.
Note
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 (http://update.microsoft.com/microsoftupdate).
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 http://www.microsoft.com/technet/prodtechnol/windows/appcompatibility/default.mspx)
that administrators can use to inventory deployed applications,
evaluate any compatibility problems, and create custom compatibility
fixes for the applications.
Note
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.
