Focusing on the Windows Server 2003 Infrastructure Components

Focusing on the Windows Server 2003 Infrastructure Components

Although an enterprise network has many functional layers , this chapter focuses on three key components that are critical to the functionality of a Windows Server 2003 environment. These three aspects ”network addressing, name resolution, and directory integration ”provide for the base-level functionality expected of any modern enterprise network and provide the backbone for the Windows Server 2003 infrastructure.

Network Addressing as the Infrastructure Foundation

The first critical component of a network is addressing , or allowing clients to assume a logical place in a network so that packets of information can be forwarded to and from the clients . This component was historically accomplished by proprietary network protocols, one for each network operating system (NOS). This gave NOS designers a great deal of flexibility in tailoring the communications components of their network to their specific design needs but made it difficult to exchange information between networks.

The Transmission Control Protocol/Internet Protocol (TCP/IP) was designed to interoperate between different varieties of networks, allowing them to speak a common "language," of sorts. The rise of this protocol coincided with the widespread adoption of the Internet itself, and it was this popularity and ubiquitous use of this protocol that led Microsoft to choose it as the standard protocol for Windows 2000. Windows Server 2003 continues to use TCP/IP as the default network protocol, expanding its place within the Microsoft NOS world.

TCP/IP requires that each node on a network be addressed by a unique IP address, such as 10.23.151.20. Each IP address must be assigned to every node on a network, either manually or by automatic methods . The automatic addressing component is the place where the DHCP service comes in with Windows Server 2003.

DHCP provides the automation of the critical TCP/IP addressing in Windows Server 2003 and makes administration of a network more palatable. You can find more details on DHCP in the section on "The Dynamic Host Configuration Protocol (DHCP) In Depth" later in this chapter.

Simplifying Address Look-up with Name Resolution

The second critical aspect in networks is name resolution. Because humans understand the concept of names better than they do IP addresses, the need arises to translate those sets of numbers into common names.

Windows Server 2003 supports two types of name resolution. The first type, the domain name system (DNS), translates IP addresses into fully qualified domain name (FQDN) addresses, which allows them to be addressed in an Active Directory or Internet DNS structure.

The second type of name resolution, mapping legacy Microsoft NetBIOS names into IP addresses, is provided by WINS. Although it is technically possible (and ideal) to create a Windows Server environment free of NetBIOS name resolution, the truth is that divorcing a network from WINS dependency is very difficult, so it will remain an active part of network services in most organizations, at least for a few more years . You can find more information on WINS in the "Continuing Usage of Windows Internet Naming Service (WINS)" section later in this chapter.

Centralizing Address Information with Directory Integration

The final important service that is supplied by a functional enterprise network is directory placement and lookup capability. Having a centralized directory that controls access to resources and provides for centralized administration is a vital function in modern networks.

Active Directory is the directory service that is provided with Windows Server 2003 and is built into many of the operating system components. The servers that handle the login requests and password changes and contain directory information are the domain controllers and global catalog domain controllers, which will be explained in more detail in the "The Active Directory Global Catalog" section later in this chapter.

Subsequently, domain controller and global catalog placement is a critical piece of a Windows Server 2003 environment. Special considerations must be made regarding this concept because access to directory lookup and registration is key for client functionality on a network.

Network Services Changes in Windows Server 2003

Windows Server 2003's implementation of Active Directory expands upon the advanced feature set that Windows 2000 DNS introduced. Several key functional improvements were added, but the overall design and functionality changes have not been significant enough to change any Windows 2000 design decisions that were previously made regarding DNS. The following sections describe the functionality introduced in Windows 2000 DNS that has been carried over to Windows Server 2003 DNS and helps to distinguish it from other DNS implementations .

Active Directory “Integrated Zones

The most dramatic change in Windows 2000's DNS implementation was the concept of directory-integrated DNS zones, known as AD-integrated zones. These zones were stored in Active Directory, as opposed to in a text file as in standard DNS. When the Active Directory was replicated, the DNS zone was replicated as well. This also allowed for secure updates, using Kerberos authentication, as well as the concept of multimaster DNS, in which no one server is the master server and all DNS servers contain a writeable copy of the zone.

Windows Server 2003 uses AD-integrated zones, but with one major change to the design. Instead of storing the zone information in Active Directory, it is instead stored in the application partition to reduce replication overhead. You can find more information on this concept in the following sections.

Dynamic Updates

As previously mentioned, dynamic updates, using Dynamic DNS (DDNS), allow clients to automatically register and unregister their own host records as they are connected to the network. This concept was a new feature with Windows 2000 DNS and is carried over to Windows Server 2003.

Unicode Character Support

Introduced in Windows 2000 and supported in Windows Server 2003, Unicode support of extended character sets enables DNS to store records written in Unicode, or essentially multiple character sets from many different languages. This functionality essentially allows DNS servers to use and perform lookups on records that are written with nonstandard characters , such as underscores, foreign letters , and so on.

BEST PRACTICE: Make Any DNS Implementation Compliant

Although Microsoft DNS supports Unicode characters, it is best practice that you make any DNS implementation compliant with the standard DNS character set so that you can support zone transfers to and from non-Unicode “compliant DNS implementations such as Unix BIND servers. This includes a “z, A “Z, 0 “9, and the hyphen (-) character.

DNS Changes in Windows Server 2003

In addition to the changes in Windows 2000 DNS, the Windows Server 2003 improvements help to further establish DNS as a reliable, robust name-resolution strategy for Microsoft and non-Microsoft environments. An overall knowledge of the increased functionality and the structural changes will help you to further understand the capabilities of DNS in Windows Server 2003. Some of the major changes in DNS in Windows Server 2003 that also solve several problem in Windows 2000 DNS are summarized in the following points:

• DNS Stored in Application Partition. Perhaps the most significant change in Windows Server 2003's DNS, Active Directory “integrated zones are now stored in the application partition of the AD. For every domain in a forest, a separate application partition is created and is used to store all records that exist in each AD-integrated zone. Because the application partition is not included as part of the global catalog, DNS entries are no longer included as part of global catalog replication.

  Previously, in Windows 2000, all AD-integrated zones were stored as global catalog objects and replicated to all global catalog servers in an entire forest. Many times, this information was not applicable across the entire forest, and unnecessary replication traffic was created. Subsequently, the application partition concept was enacted, and replication loads are now reduced, while important zone information is delegated to areas of the network where they are needed.

• Automatic Creation of DNS Zones. The Configure a DNS Server Wizard, as demonstrated in "Installing DNS Using the Configure Your Server Wizard" section later in this chapter, allows for the automatic creation of a DNS zone through a step-by-step wizard. This feature greatly eases the process of creating a zone, especially for Active Directory. You can invoke the wizard by right-clicking on the server name in the DNS MMC and choosing Configure a DNS Server.

• No "Island" Problem. Windows 2000 previously had a well-documented issue that was known as the "island" problem, which was manifested by a DNS server that pointed to itself as a DNS server. If the IP address of that server changed, the DNS server updated its own entry in DNS, but then other DNS servers within the domain were unable to successfully retrieve updates from the original server because they were requesting from the old IP address. This effectively left the original DNS server in an "island" by itself, hence the term .

  Windows Server 2003 DNS first changes its host records on a sufficient number of other authoritative servers within DNS so that the IP changes made will be successfully replicated, thus eliminating this "island" problem. As a result, it is no longer necessary to point a root DNS server to another DNS server for updates, as was previously recommended as a method of resolving this issue.

• Forest Root Zone for _msdcs Moved to Separate Zone. In Active Directory, all client logons and lookups are directed to local domain controllers and global catalog servers through references to the SRV records in DNS. These SRV records were stored in a subdomain to an Active Directory domain that was known as the _msdcs subdomain.

  In Windows Server 2003, _msdcs has been relocated to become a separate zone in DNS, as shown in Figure 13.1. This zone, stored in the application partition, is replicated to every domain controller that is a DNS server. This listing of SRV records was moved mainly to satisfy the requirements of remote sites. In Windows 2000, these remote sites had to replicate the entire DNS database locally to access the _msdcs records, which led to increased replication time and reduced responsiveness. If you delegate the SRV records to their own zone, only this specific zone can be designated for replication to remote site DNS servers, saving replication throughput and increasing the response time for clients.

  Figure 13.1. The _msdcs zone in Windows 2003 DNS.