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.

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.

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.

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.

As any Windows 2000 administrator can attest, problems with DNS can spell disaster for an Active Directory environment. Because all servers and clients are constantly performing lookups on one another, a break in name-resolution service can severely affect Active Directory activity.

For this and other reasons, installing a redundant DNS infrastructure in any Active Directory implementation is strongly recommended. Even smaller environments should consider duplication of the primary DNS zone, and nearly as much emphasis as is put into protecting the global catalog AD index should be put into protecting DNS.

Security considerations for the DNS database should not be taken for granted. Secure updates to AD-integrated zones are highly recommended, and keeping DHCP servers off a domain controller can also help to secure DNS. In addition, limiting administrative access to DNS will help to mitigate problems with unauthorized “monkeying around” with DNS.

Active Directory was specifically written to be able to co-exist and, in fact, use a non-Microsoft DNS implementation as long as that implementation supports active updates and SRV records. For example, AD will function in all versions of Unix BIND 8.1.2 or later. With this point in mind, however, it is still recommended that an organization with a significant investment in Microsoft technologies consider hosting Active Directory DNS on Windows Server 2003 systems because functionality enhancements provide for the best fit in these situations.

For environments that use older versions of DNS or are not able (or willing) to host Active Directory clients directly in their databases, Active Directory DNS can simply be delegated to a separate zone in which it can be authoritative. The Windows Server 2003 systems can simply set up forwarders to the foreign DNS implementations to provide for resolution of resources in the original zone.

Certain situations in Active Directory require the use of secondary zones to handle specific name resolution. For example, in peer-root domain models, where two separate trees form different namespaces within the same forest, secondaries of each DNS root are required to maintain proper forestwide synchronization.

Because each tree in a peer-root model is composed of independent domains that might not have security privileges in the other domains, a mechanism will need to be in place to allow lookups to occur between the two trees. The creation of secondary zones in each DNS environment will provide a solution to this scenario, as illustrated in Figure 13.2.

Figure 13.2. Peer-root domain DNS secondary zones.

All Active Directory clients use DNS for any type of domain-based lookups. Logins, for example, require lookups into the Active Directory for specific SRV records that indicate the location of domain controllers and global catalog servers. Windows Server 2003, as previously mentioned, divides the location of the SRV records into a separate zone, which is replicated to all domain controllers that have DNS installed on them.

Subdomains for each site are created in this zone; they indicate which resource is available in those specific sites. In a nutshell, if an SRV record in the specific site subdomain is incorrect, or another server from a different site is listed, all clients in that site are forced to authenticate in other sites. This concept is important because a common problem is that when Active Directory sites are created before they are populated with servers, an SRV record from the hub location is added to that site subdomain in DNS. When a new server is added to those sites, their SRV records join the other SRV records that were placed there when the site was created. These records are not automatically deleted, and they consequently direct clients to servers across slow WAN links, often making login times very slow.

In addition to the site containers, the root of these containers contains a list of all domain controllers in a specific domain, as shown in Figure 13.3. These lists are used for name resolution when a particular site server does not respond. If a site domain controller is down, clients randomly choose a domain controller in this site. It is therefore important to make sure that the only entries in this location are servers in fast-connected hub sites. Proper grooming of these SRV records and placement of servers into their proper site subdomains will do wonders for client login times.

Figure 13.3. Site-level SRV records.

As network infrastructure experts have found, a solid DNS design and implementation is critical to the successful lookup, views, and replication of DNS information across the Active Directory environment.

Although Microsoft developed its own implementation of DNS in Windows NT 4.0, it was based on the RFC standards on which DNS was founded. With the introduction of Windows 2000, Microsoft adopted DNS as the name-resolution strategy for Microsoft products. Older, legacy name resolution systems such as WINS are slowly being phased out. Since that time, the DNS implementation used by Microsoft has evolved to include a number of key benefits that distinguish it from standard DNS implementations, such as those in other DNS implementations—for example, Unix BIND. To understand these improvements, however, you first need a basic understanding of DNS functionality.

Microsoft very clearly heard from the marketplace how the DNS used for Active Directory needed to have better compatibility with the DNS used throughout the industry. Besides providing various options for AD integration into existing DNS environments, with Windows Server 2003 Microsoft now supports the InetOrgPerson attribute that further extends Microsoft’s DNS compatibility for more common LDAP lookup and DNS integration compatibility.

DNS structure is closely linked to the development of the Internet and often is confused with the Internet itself. The structure of DNS is highly useful, and the fact that it has thrived for so long is a tribute to its functionality. A closer examination of what constitutes DNS and how it is logically structured is important in understanding the bigger picture of how DNS fits in Windows Server 2003.

The bounded area that is defined by the DNS name is known as the DNS namespace. microsoft.com is a namespace, as is marketing.companyabc.com. Namespaces can be either public or private. Public namespaces are published on the Internet and are defined by a set of standards. All the .com, .net, .org, and like namespaces are external, or public. An internal namespace is not published to the Internet but is also not restricted by extension name. In other words, an internal, unpublished namespace can occupy any conceivable namespace, such as dnsname.internal or companyabc.root. Internal namespaces are most often used with Active Directory because they give increased security to a namespace. Because such namespaces are not published, they cannot be directly accessed from the Internet.

The Start of Authority (SOA) record in a DNS database indicates which server is authoritative for that particular zone. The server referenced by the SOA records is subsequently the server that is assumed to be the best source of information about a particular zone and is in charge of processing zone updates. The SOA record contains information such as the Time to Live (TTL) interval, the contact person responsible for DNS, and other critical information, as illustrated in Figure 13.7.

Figure 13.7. A sample SOA record.

An SOA record is automatically created when DNS is installed for Active Directory in Windows Server 2003 and is populated with the default TTL, primary server, and other pertinent information for the zone. After installation, however, these values can be modified to fit the specific needs of an organization.

The most common type of RR in DNS is the host record, also known as an A record. This type of RR simply contains the name of the host and its corresponding IP address, as illustrated in Figure 13.8.

Figure 13.8. Sample host records.

The vast majority of RRs in DNS are A records because they are used to identify the IP addresses of most resources within a domain.

Name Server (NS) records identify which computers in a DNS database are the name servers, essentially the DNS servers for a particular zone. Although there can be only one SOA record for a zone, there can be multiple NS records for the zone, which indicate to clients which machines are available to run DNS queries against.

Service (SRV) records are RRs that indicate which resources perform a particular service. Domain controllers in Active Directory are referenced by SRV records that define specific services, such as the global catalog, LDAP, and Kerberos. SRV records are a relatively new addition to DNS, and did not exist in the original implementation of the standard. Each SRV record contains information about a particular functionality that a resource provides. For example, an LDAP server can add an SRV record indicating that it can handle LDAP requests for a particular zone. SRV records can be very useful for Active Directory because domain controllers can advertise that they handle global catalog requests, as illustrated in Figure 13.9.

Figure 13.9. Sample SRV record for an Active Directory global catalog entry.

A Mail Exchanger (MX) record indicates which resources are available for SMTP mail reception. MX records can be set on a domain basis so that mail sent to a particular domain will be forwarded to the server or servers indicated by the MX record. For example, if an MX record is set for the domain companyabc.com, all mail sent to [email protected] will be automatically directed to the server indicated by the MX record.

Reverse queries to DNS are accomplished through the use of Pointer (PTR) records. In other words, if a user wants to look up the name of a resource that is associated with a specific IP address, he would do a reverse lookup using that IP address. A DNS server would reply using a PTR record that would indicate the name associated with that IP address. PTR records are most commonly found in reverse lookup zones.

A Canonical Name (CNAME) record represents a server alias, or essentially allows any one of a number of servers to be referred to by multiple names in DNS. The record essentially redirects queries made to it to the A record for that particular host. CNAME records are useful when migrating servers and for situations in which friendly names, such as mail.companyabc.com, are required to point to more complex, server-naming conventions such as sfoexch01.companyabc.com.

Other, less common forms of records that might exist in DNS have specific purposes, and there might be cause to create them. The following is a sample list but is by no means exhaustive:

A forward lookup zone is created to do, as the name suggests, forward lookups to the DNS database. In other words, this type of zone resolves names to IP addresses and resource information. For example, if a user wants to reach Server1 and queries for its IP address through a forward lookup zone, DNS returns 10.0.0.11, the IP address for that resource.

A reverse lookup zone performs the exact opposite operation as a forward lookup zone. IP addresses are matched up with a common name in a reverse lookup zone. This is similar to knowing someone’s phone number but not knowing the name associated with it. Reverse lookup zones must be manually created, and do not always exist in every implementation. Reverse lookup zones are primarily populated with PTR records, which serve to point the reverse lookup query to the appropriate name.

In traditional (non-Active Directory–integrated) DNS, a single server serves as the master DNS server for a zone, and all changes made to that particular zone are done on that particular server. A single DNS server can host multiple zones, and can be primary for one and secondary for another. If a zone is primary, however, all requested changes for that particular zone must be done on the server that holds the master copy of the zone.

Creating a new primary zone manually is a fairly straightforward process. The following procedure outlines the creation of a standard zone for the companyabc.com DNS namespace:

A secondary zone is established to provide redundancy and load balancing for the primary zone. Each copy of the DNS database is read-only, however, because all recordkeeping is done on the primary zone copy. A single DNS server can contain several zones that are primary and several that are secondary. The zone creation process is similar to the one outlined in the preceding section on primary zones, but with the difference being that the zone is transferred from an existing primary server.

The concept of stub zones is new in Microsoft DNS. A stub zone is essentially a zone that contains no information about the members in a domain but simply serves to forward queries to a list of designated name servers for different domains. A stub zone subsequently contains only NS, SOA, and glue records. Glue records are essentially A records that work in conjunction with a particular NS record to resolve the IP address of a particular name server. A server that hosts a stub zone for a namespace is not authoritative for that zone.

As illustrated in Figure 13.12, the stub zone effectively serves as a placeholder for a zone that is authoritative on another server. It allows a server to forward queries that are made to a specific zone to the list of name servers in that zone.

Figure 13.12. Stub zones in Windows 2003.

You can easily create a stub zone in Windows Server 2003 after it is determined that a stub zone is required. The following procedure details the steps involved with the creation of a stub zone:

The newly created stub zone will hold only the SOA, NS, and glue records for the domain at which it is pointed.

The standard method for zone transfers, which transfers the entire contents of a DNS zone to other servers, is known as asynchronous zone transfer (AXFR) or full zone transfer. This type of zone transfer copies every item in the DNS database to a separate server, regardless of whether the server already has some of the items in the database. Older implementations of DNS used AXFR exclusively, and it is still used for specific purposes today.

An incremental zone transfer (IXFR) is a process by which all incremental changes to a DNS database are replicated to another DNS server. This saves bandwidth over AXFR replication changes because only the delta, or changes made to the database since the last zone transfer, are replicated.

IXFR zone transfers are accomplished by referencing an index number that is referenced on the SOA of the DNS server that holds the primary zone. This number is incremented upon each change to a zone. If the server requesting the zone transfer has an index number of 45, for example, and the primary zone server has an index number of 55, only those changes made during the period of time between 45 and 55 will be incrementally sent to the requesting server via an IXFR transfer. However, if the difference in index numbers is too great, the information on the requesting server is assumed to be stale, and a full AXFR transfer will be initiated. For example, if a requesting server has an index of 25, and the primary zone server’s index is 55, an AXFR zone transfer will be initiated, as illustrated in Figure 13.15.

Figure 13.15. IXFR zone transfers.

Recursive queries are most often performed by resolvers, or clients that need to have a specific name resolved by a DNS server. Recursive queries are also accomplished by a DNS server if forwarders are configured to be used on a particular name server. A recursive query essentially asks whether a particular record can be resolved by a particular name server. The response to a recursive query is either negative or positive. A common recursive query scenario is illustrated in Figure 13.16.

Figure 13.16. Recursive and iterative queries.

Iterative queries ask a DNS server to either resolve the query or make a “best guess” referral to a DNS server that might contain more accurate information about where the query can be resolved. Another iterative query is then performed to the referred server and so on until a result, positive or negative, is obtained.

In the example shown in Figure 13.16, Client1 in CompanyABC opens a Web browser and attempts to browse to the Web site for www.microsoft.com. A recursive query is initiated to the default name server; in this case, Server1 is contacted. Because Server1 is authoritative only for the companyabc.com namespace, and no entries exist for microsoft.com, the query is sent to an “upstream” DNS server that is listed in the root hints of the DNS server. That server, Server2, is not authoritative for microsoft.com but sends a referral back to Server1 for Server3, which is a name server for the .com namespace. Server3 knows that Server4 handles name-resolution requests for microsoft.com and sends that information back to Server1. A final iterative query is then sent from Server1 to Server4, and Server4 successfully resolves www to the proper IP address. Server1, with this information in hand, returns Client1’s original recursive query with the proper IP address and Client1’s browser successfully resolves www.microsoft.com.

This type of functionality lies at the heart of the distributed nature of DNS and allows DNS lookups to function as efficiently as they do.

Older versions of DNS relied on administrators manually updating all the records within a DNS database. Every time a resource was added or information about a resource was changed, the DNS database was updated, normally via a simple text editor, to reflect the changes. Dynamic DNS was developed as a direct response to the increasing administrative overhead that was required to keep DNS databases functional and up to date. With Dynamic DNS, clients can automatically update their own records in DNS, depending on the security settings of the zone.

It is important to note that only Windows 2000/XP and later clients support dynamic updates and that down-level (NT/9x) clients must have DHCP configured properly in order for them to be updated in DNS.

The Time to Live (TTL) value for a server is the amount of time (in seconds) that a resolver or name server will keep a cached DNS request before requesting it again from the original name server. This value helps to keep the information in the DNS database relevant. Setting TTL levels is essentially a balancing act between the need for updated information and the need to reduce DNS query traffic across the network.

In the example from the “Iterative Queries” section, if Client1 already requested the IP of www.microsoft.com, and the information was returned to the DNS server that showed the IP address, it would make sense that that IP address would not change often and could therefore be cached for future queries. The next time another client requests the same information, the local DNS server will give that client the IP address it received from the original Client1 query as long as the TTL has not expired. This helps to reduce network traffic and improve DNS query response time.

The TTL for a response is set by the name server that successfully resolves a query. In other words, you might have different TTLs set for items in a cache, based on where they were resolved and the TTL for the particular zone they originated from.

The TTL setting for a zone is modified via the SOA record. The procedure for doing this in Windows Server 2003 is as follows:

One of the main problems with a Dynamic DNS implementation lies with the security of the update mechanism. If no security is enforced, nothing will prevent malicious users from updating a record for a server, for example, to redirect it to their own IP address. For this reason, dynamic updates are, by default, turned off on new standard zones that are created in Windows Server 2003. However, with AD-integrated DNS zones, a mechanism exists that will allow clients to perform secure dynamic updates. Secure updates use Kerberos to authenticate users and ensure that only those clients that created a record can subsequently update the same record.

If you’re using DHCP to provide secure updates, one important caveat is that DHCP servers should not be located on the domain controller because of specific issues in regards to secure updates. The reason for this recommendation is that all DHCP servers are placed in a group known as DNSUpdateProxy. Members of this group do not take ownership of items that are published in DNS. This group was created because DHCP servers often dynamically publish updates for clients automatically, and the clients would need to modify their entries themselves. Subsequently, the first client to access a newly created entry would take ownership of that entry. Because domain controllers create sensitive SRV records and the like, it is not wise to use a domain controller as a member of this group, and it is subsequently not wise to have DHCP on domain controllers for this reason.

By default, a DNS installation includes a listing of Internet-level name servers that can be used for name resolution of the .com, .net, .uk, and like domain names on the Internet. When a DNS server cannot resolve a query locally in its cache or in local zones, it consults the Root Hints list, which indicates which servers to begin iterative queries with.

The Hints file should be updated on a regular basis to ensure that the servers listed are still relevant. This file is located in \%systemroot%system32DNScache.dns and can be updated on the Internet at the following address:

ftp://ftp.rs.internic.net/domain/named.cache

Forwarders are name servers that handle all iterative queries for a name server. In other words, if a server cannot answer a query from a client resolver, servers that have forwarders simply forward the request to an upstream forwarder that will do the iterative queries to the Internet root name servers. Forwarders are used often in situations in which an organization uses the DNS servers of an ISP to handle all name-resolution traffic. Another common situation occurs when Active Directory’s DNS servers handle all internal AD DNS resolution but forward outbound DNS requests to another DNS environment within an organization, such as a legacy Unix BIND server.

In conditional forwarding, queries that are made to a specific domain or set of domains are sent to a specifically defined forwarder DNS server. This type of scenario is normally used to define routes that internal domain resolution traffic will follow. For example, if an organization controls the companyabc.com domain namespace and the companyxyz.com namespace, it might want queries between domains to be resolved on local DNS servers, as opposed to being sent out to the Internet just to be sent back again so that they are resolved internally.

Forward-only servers are never meant to do iterative queries, but rather to forward all requests that cannot be answered locally to a forwarder or set of forwarders. If those forwarders do not respond, a failure message is generated.

If you plan to use forwarders in a Windows Server 2003 DNS environment, you can establish them by following these steps:

In environments with a significant investment in WINS lookups, the WINS database can be used in conjunction with DNS to provide DNS name resolution. If a DNS query has exhausted all DNS methods of resolving a name, a WINS server can be queried to provide for resolution. This method creates several WINS RRs in DNS that are established to support this approach.

To enable WINS to assist with DNS lookups, follow these steps:

As any good administrator knows, the Event Viewer is the first place to look for any type of troubleshooting. Windows Server 2003 makes it even more straightforward to use because DNS Events compiled from the Event Viewer are immediately accessible from the DNS MMC console. Parsing this set of logs can help you to troubleshoot DNS replication issues and query problems.

For more advanced Event Log diagnosis, you can turn on Debug Logging on a per-server basis. It is recommended that you turn on this functionality only as required, however, because log files can fill up fast with debugging turned on. To enable Debug Logging, follow these steps:

It is recommended that you turn off these settings after the troubleshooting is complete.

Performance Monitor is a built-in, often-overlooked utility that allows for a great deal of insight into issues in a network. In regards to DNS, many critical DNS counters can be monitored relating to queries, zone transfers, memory use, and other important factors.

Windows 2000 and later clients have a built-in client cache for name resolution that caches all information retrieved from name servers. When requesting lookups, the client resolver parses this cache first, before contacting the name server. Items remain in this cache until the TTL expires, the machine is rebooted, or the cache is flushed. In cases where erroneous information has been entered into the client cache, you can flush it by typing ipconfig /flushdns at the command prompt.

By default, all clients have a file named HOSTS that provides for a simple line-by line resolution of names to IP addresses. This file is normally located in \%systemroot%system32driversetc. Problems can occur when these manual entries conflict with DNS, and it is therefore wise to ensure that there are not conflicts with this HOSTS file and the DNS database when troubleshooting.

The NSLOOKUP command-line utility is perhaps the most useful tool for DNS client troubleshooting. Its functionality is basic, but the information that you obtain can do wonders for helping you to understand DNS problems. NSLOOKUP, in its most basic operation, contacts the default DNS server of a client and attempts to resolve a name that is input. For example, to test a lookup on www.companyabc.com, type nslookup www.companyabc.com at the command prompt. Different query types can be also input into NSLOOKUP. For example, you can create simple queries to view the MX and SOA records associated with a specific domain by following these steps, which are illustrated in Figure 13.20:

Figure 13.20. NSLOOKUP on an MX record.

NSLOOKUP’s functionality is not limited to these simple lookups. Performing an nslookup /? lists the many functions it is capable of. NSLOOKUP is a tool of choice for many name-resolution problems and is a must in any troubleshooter’s arsenal.

Another important tool for DNS resolution problems is the IPCONFIG utility, the same utility used for common TCP/IP issues. There are several key functions that IPCONFIG offers in regards to DNS. These functions can be invoked from the command prompt with the right flag, detailed as follows:

The TRACERT utility is a valuable resource that gives you an idea of the path that a DNS query takes when being sent over a network. By directing TRACERT at www.microsoft.com, for example, you can get an idea of how many routers and DNS servers the packet is crossing. The way that TRACERT works is simple but actually quite interesting. A DNS query that has a TTL of 1 is sent out. Because all routers are supposed to drop the TTL by 1 on each packet that they process, this means that the first router will refuse to forward the packet and send that refusal back to the originator. The originating machine then increments the TTL by 1 and resends the packet. This time the packet will make it past the first router and get refused by the second. This process continues until the destination is met, as illustrated in Figure 13.21. Needless to say, using this command-line utility is a simple yet effective way of viewing the path that a DNS query takes as it crosses the Internet.

Figure 13.21. Sample TRACERT results.

The DNSCMD utility is essentially a command-line version of the MMC DNS console. Installed as part of the Windows Server 2003 Support tools, this utility enables you to create zones, modify records, and perform other vital administrative functions. To install the support tools, run the support tools setup from the Windows Server 2003 CD (located in the support ools directory). You can view the full functionality of this utility by typing DNSCMD /? at the command line, as illustrated in Figure 13.22.

Figure 13.22. DNSCMD command-line options.

The server portion of DHCP is only half of the equation in a DHCP transaction. The request for an IP address comes from a specific interface known as the DHCP client. The client is installed with TCP/IP in Windows 2000 and higher clients and can be installed as an additional component in down-level clients.

The DHCP client, as previously mentioned, handles the communications with the DHCP Server service, in terms of handling IP requests and updates. Each iteration of the Windows client includes a different DHCP client, and there are slight variations in the functionality of each client; however, the overall function—to apply for and receive an IP address from a DHCP server—remains the same in each Windows client.

The Client/Server service has been updated in Windows 2000 clients and later, enabling it to automatically assign itself an IP address if no server is available; it does so through a process called Automatic Private IP Addressing (APIPA). APIPA clients automatically assign themselves an IP address in the 169.254.0.0/16 range in this situation, which allows them to have basic TCP/IP connectivity in small networks.

APIPA might be problematic in larger networks because it forces clients to assign themselves addresses in a range that is normally not part of a local company subnet. If a DHCP server is down, clients that are attempting to renew a lease with the server will fail and automatically assign themselves an APIPA address. When the server comes back online, they will not immediately re-register themselves and will effectively be cut off from the network. Subsequently, Microsoft supplies a Registry key that will disable APIPA in this situation. The key to be created is

HKLMSYSTEMCurrentControlSetServicesTcpipParametersInterfaces<AdapterName>
IPAutoconfigurationEnabled:REG_DWORD=0

You can create this key by following these steps on the client:

Because DHCP clients use network broadcasts to seek out DHCP servers, it is important that this traffic is routed properly on a network with multiple subnets. Effectively, this means that there must be some type of agent to detect DHCP broadcast packets and forward them to the appropriate DHCP server, if it is located on another network. For Cisco routers, for example, this takes the form of an ip-helper entry in the router configuration that designates the destination IP address for broadcast packets to be forwarded to. If this entry is not used, a Windows server running the Routing and Remote Access service must be configured as a DHCP relay agent, as illustrated in Figure 13.23.

Figure 13.23. DHCP broadcast packet routing.

Using the DNS Service in Windows Server 2003, clients can automatically register themselves in the DNS database through a mechanism called Dynamic DNS (DDNS).

DHCP in Windows Server 2003 integrates directly with DDNS to provide for automatic registration of clients into DNS. By default, all Windows 2000 or later clients will perform this function by themselves, but DHCP can be configured to allow for the Server service to update the Dynamic DNS record for the client. This option can be turned on and off at the server level, through the DHCP Manager MMC.

The process of backing up all DHCP settings and restoring them onto the same (or a different) server has been streamlined in Windows Server 2003. No longer do you need to export Registry keys and manually move databases between servers to migrate DHCP because the Backup and Restore process can be accomplished directly from the MMC. The process for backing up and restoring a DHCP database is as follows:

The DHCP client that is included in the Windows Server 2003 client equivalent, Windows XP, can have a static IP address assigned to clients when a DHCP server is unavailable. This static IP address takes the place of the APIPA address that would normally be configured in these cases.

This type of functionality would normally be used on mobile laptop computers that connect to different networks. When a user is at work, for example, his laptop would receive a DHCP address. When the user is at home, however, his laptop would use the backup static IP address defined in the network settings. To configure this functionality on a Windows XP client, perform the following steps:

The 50/50 failover approach effectively uses two DHCP servers that each handle an equal amount of client traffic on a subnet. Each DHCP server is configured with similar scopes, but each must have a different IP range to avoid IP addressing conflicts.

Figure 13.28 illustrates the 50/50 failover approach. As indicated in the diagram, the network has 200 clients defined by 192.168.1.0/24. Each DHCP server contains a scope to cover the entire specific client subnet. Server1’s scope is configured with exclusions for all IPs except for the range of 192.168.1.1–192.168.1.125. Server2’s scope is configured with exclusions for the first half and a client lease range of 192.168.1.126–192.168.1.254.

Figure 13.28. The 50/50 failover approach.

Upon requesting a client IP address, the first server to respond to a request will be accepted, thus roughly balancing the load between the two servers.

The advantage to this approach is that a degree of redundancy is built into the DHCP environment without the need for extra IP address ranges reserved for clients. However, several caveats must be considered before implementing this approach.

First and foremost, it is theoretically possible that one server is located closer to the majority of the clients, and therefore more clients would be directed to that particular server. This could theoretically cause the DHCP server to run out of client leases, making it ineffectual for redundancy. For this reason, it is preferable to consider other methods of failover for DHCP, if available.

Another important consideration whenever configuring DHCP servers in this method is that an exclusion range must be established for the range that exists on the other server so that when a client from the other server attempts to renew the lease, it is not refused a new lease. This situation could potentially occur if the exclusion is not established because the client and server would have trouble negotiating if the client was using an IP address out of the range that exists in the scope. Consequently, if the range exists, but an exclusion is established, the server will simply assign a new address in the backup range.

The 80/20 failover approach is similar to the 50/50 approach, except that the effective scope range on the server designated as the backup DHCP server contains only 20% of the available client IP range. In most cases, this server that holds 20% would be located across the network on a remote subnet, so it would not primarily be responsible for client leases. The server with 80% of the range would be physically located closer to the actual server, thus accepting the majority of the clients by responding to their requests faster, as illustrated in Figure 13.29.

Figure 13.29. The 80/20 failover approach.

In the event of Server1’s failure, Server2 would respond to client requests until Server1 could be re-established in the network.

The downside to this approach is that if Server1 is down for too long of a period of time, it would eventually run out of potential leases for clients, and client renewal would fail. It is therefore important to establish a disaster recovery plan for the server with 80% of the scopes so that downtime is minimized.

Just as with the 50/50 approach, it is important to establish exclusion ranges for the other DHCP server’s range, as described in the previous sections.

The 100/100 failover approach in Windows Server 2003 DHCP is the most effective means of achieving high availability out of a DHCP environment. However, several big “gotchas” must be worked out before this type of redundancy can be implemented.

The 100/100 failover approach in its simplest form consists of two servers running DHCP, with each servicing the same subnets in an organization. The scopes on each server, however, contain different, equivalent size ranges for clients that are each large enough to handle all clients in a specific subnet.

In Figure 13.30, the 10.2.0.0/16 subnet has a total of 750 clients. This subnet is serviced by two DHCP servers, each of which has a scope for the subnet. Each server has a scope with addresses from 10.2.1.1 through 10.2.8.254. The scope on Server1 excludes all IP addresses except those in the range of 10.2.1.1 through 10.2.4.254. The scope on Server2 excludes all IP addresses except those in the range from 10.2.5.1 through 10.2.8.254. Each effective range is subsequently large enough to handle 1,000 clients, more than enough for every machine on the network.

Figure 13.30. The 100/100 failover approach.

If one of the DHCP servers experiences an interruption in service, and it no longer responds, the second server will take over, responding to clients and allowing them to change their IP addresses to the IPs available in the separate range.

The advantages to this design are obvious. In the event of a single server failure, the second server will immediately issue new IP addresses for clients that previously used the failed server. Because both servers run constantly, the failover is instantaneous. In addition, the failed DHCP server could theoretically remain out of service for the entire lease duration because the second server will be able to pick up all the slack from the failed server.

The main caveat to this approach is that a large number of IP addresses must be available for clients, more than twice the number that would normally be available. This might prove difficult, if not impossible, in many networks that have a limited IP range to work with. However, in organizations with a larger IP range, such as those offered by private network configurations (10.x.x.x and so on), this type of configuration is ideal.

You must ensure that both ranges include the scopes from the other servers, to prevent the types of problems described in the preceding examples.

A Standby DHCP server is simply a server with DHCP installed, configured with scopes, but not turned on. The scopes must be configured in different ranges, as in the previous examples, but they normally lie dormant until they are needed. The advantage to this approach lies in the fact that the DHCP service can be installed on a server that will not normally be using additional resources for DHCP. If there is a problem, you simply need to activate the dormant scopes. An automated tool or script can be used to perform this function, if desired.

The final redundancy option with DHCP is to deploy a clustered server set to run DHCP. In this option, if a single server goes down, the second server in a cluster will take over DHCP operations. This option requires a greater investment in hardware and should be considered only in specific cases in which it is necessary.

A DHCP Superscope is used for environments in which multiple network subnets encompass a single scope environment. In these cases, a Superscope can be created to contain multiple scopes. The individual scopes are subsequently dependent on the master Superscope. If it is turned off, they will also be deactivated. Figure 13.31 illustrates a sample DHCP Superscope.

Figure 13.31. A DHCP Superscope.

A Multicast scope is created to allow clients to be assigned multicast IP addresses. A multicast IP address is one in which destination hosts can each have the same IP address, which is useful in one-to-many forms of communications such as Webcasts and videoconferencing sessions.

It is never wise to hand over full administrative privileges to individuals who need to perform only a specific network function. If a small group of administrators needs control over the DHCP environment, Windows Server 2003 makes it easy to delegate administrative capabilities to them through the inclusion of a group called DHCP Administrators. Adding users or, preferably, groups to this Security Group will enable those users to administer the DHCP servers in an environment.

Windows Server 2003 has made great strides in allowing virtually all administrative functions to be performed through the command line. This not only helps those users who are used to command-line administration, such as that in Unix operating systems, but also allows for the execution of scripts and batch files, which can automate administrative processes.

The Netsh command-line utility is one such utility that effectively enables you to accomplish virtually all DHCP tasks that can be run through the MMC GUI interface. For a full listing of potential functions with Netsh, run netsh /? from the command line, as illustrated in Figure 13.32.

Figure 13.32. Netsh command-line options.

DHCP in and of itself is an unauthenticated service, which means that anyone can establish a DHCP server on a network and start to accept clients and assign them erroneous addresses or redirect them for malicious purposes. Consequently, since Windows 2000, it has become necessary to authorize a DHCP server that is running in an Active Directory domain. After the DHCP server is authorized by the proper domain administrative authority, that server can then accept client leases.

The downside to this approach is that a Windows NT 4.0 server could still be added, unauthenticated, to a network. In this situation, it would become necessary to pull out a network analyzer to determine the location of rogue DHCP servers.

Authorization of a Windows Server 2003 DHCP server is straightforward and can be accomplished by following these steps:

If at all possible, the DHCP service should not be run on an Active Directory domain controller because the security of the SRV records generated is diminished. The reasons for this are as follows.

DNS entries in an Active Directory–integrated DNS zone are secure, which means that only the client that originally created the record can subsequently update that same record. This can cause problems with the DHCP server automatically updating client records, however, because the client no longer performs this function and cannot have security applied to a record.

DHCP in Windows Server 2003 overcomes this limitation by placing all DHCP servers in a special group in Active Directory, called DNSUpdateProxy. Members of this group do not have any security applied to objects that they create in the DNS database. The theory is that the first client to “touch” the record will then take over security for that record.

The problem with this concept is that the records created by DHCP servers possess no immediate security and are consequently subject to takeover by hostile clients. Because domain controllers are responsible for publishing SRV DNS records, which indicate the location of domain controllers, Kerberos servers, and the like, this leaves a gaping security hole that users could exploit. Consequently, it is preferable to keep DHCP off domain controllers. If this cannot be avoided, it is recommended that you not place the DHCP server into the DNSUpdateProxy group to avoid the security problems associated with it.

WINS is effectively a simple database of NetBIOS names and their corresponding IP addresses. Some additional information, such as domain name, server type, and so on, can be determined as well, from the 16th byte in a NetBIOS name stored in WINS.

WINS is considered legacy in the Microsoft world because NetBIOS resolution is being phased out in favor of the domain name system (DNS) form of name resolution. However, it is difficult to divorce WINS from modern networks because of the reliance on WINS by down-level (pre-Windows 2000) clients, legacy applications, and even some Microsoft services such as DFS that use WINS by default. Consequently, you might need to keep using WINS in Windows networks, unless you can definitively prove that it is no longer necessary.

DNS can use the WINS database to provide for quasi-DNS resolution of WINS clients. This means that if a request is sent to a DNS server to resolve client1.companyabc.com, for example, it is possible for that DNS server to use the WINS database to resolve requests for any zones where the WINS forward lookup is configured. If Client1 does not exist in the DNS database but exists in the WINS database instead, the DNS server will return the IP address that it obtained from WINS and attach the companyabc.com suffix to the record, as illustrated in Figure 13.35.

Figure 13.35. WINS integration with DNS.

This functionality must be enabled on the DNS server because it is not configured by default. To enable WINS resolution on a DNS server, follow these steps:

Although =the overall function of WINS has not changed significantly in Windows Server 2003, some additions to the management tools allow for increased functionality and capabilities:

In addition to these advances in Windows Server 2003, Windows 2000 introduced enhancements to WINS, such as an updated database engine, persistent connections, manual tombstoning, and other improvements.

To install WINS on a server using the Configure Your Server Wizard, follow these steps:

If a WINS server in an environment is the sole WINS server for that network, no additional configuration is required other than ensuring that clients will be pointing to the WINS server in their IP configuration. However, if additional WINS servers are established in an environment, exchanging database information between the multiple servers will become necessary. You establish this type of replication topology through the designation of push/pull partners.

A push partner for a particular WINS server is another WINS server that serves as the destination for WINS changes to be “pushed” to. A pull partner is a WINS server from which changes are “pulled.” In a nutshell, if Server1 has Server2 configured as a push partner, Server2 must have Server1 configured as a pull partner, and vice versa.

A WINS push/pull topology should roughly map to an organization’s network topology. For example, if an organization is composed of two main offices that serve as network hubs, and several branch offices, each with its own WINS servers, the WINS push/pull topology could look something like Figure 13.38.

Figure 13.38. Sample WINS push/pull topology.

WINS replicates database changes on a set schedule, which can be modified on a per connection basis. Just as with any network communications, the replication schedule should be modified to fit the particular needs of an organization. If a WAN link is saturated with traffic, it might be wise to throttle back the WINS replication schedule. However, if a link between push/pull partners is robust, a shorter schedule can be established. To change the default schedule of 30 minutes, follow these steps:

The page shown in Figure 13.39 can also be used to change other push/pull partner settings, such as replication partner types, persistent connections, and other pertinent replication information.

A Windows client does not immediately resort to a WINS server to determine the IP address of a NetBIOS name. This knowledge is essential in the troubleshooting of name resolution on a Windows client. Instead, a client first contacts a local NetBIOS cache for resolution. If an IP address changes, this cache might report the old address, impeding troubleshooting. To flush this cache, run nbtstat -R (with uppercase R) at the command line.

In addition to the local cache, clients always parse an LMHOSTS file, if one exists, before contacting a WINS server. If the LMHOSTS file contains erroneous information, it will impede proper name resolution. Always check to see whether this file is populated (it is usually located in \%systemroot%winntsystem32driversetc on clients) before beginning to troubleshoot the WINS server.

There are two key factors to consider when designing a WINS environment. The first factor is accessibility. Having a local, fast connection to a WINS server will aid in the processing of client requests. Because WINS has low overhead for servers, it is consequently a good idea to include at least one WINS server in all locations with more than 5–10 users. In smaller environments, WINS can be installed as part of a local file server whereas in larger environments, dedicated multiple utility servers running WINS are recommended.

The replication topology you establish should normally follow the lines of a network infrastructure, as previously mentioned. If a network uses a hub and spoke design, WINS should follow the same basic topology.

The WINS service itself is one of the more straightforward services to migrate to a separate set of servers as part of an upgrade to Windows Server 2003. A simple upgrade of the existing WINS server will do the trick for many environments; however, migrating to a separate server or set of servers might be beneficial if you’re changing topology or hardware.

Migration of an existing WINS environment is most easily accomplished through the procedure described in this section. This procedure allows for the migration of an entire WINS database to a new set of servers, but without affecting any clients or changing WINS server settings. Figure 13.40 illustrates a WINS migration using this procedure.

Figure 13.40. WINS migration procedure, step 1.

In Figure 13.40, the existing servers, OldServer1 and OldServer2, handle WINS traffic for the entire network of fictional CompanyABC. They are configured with IP addresses 10.1.1.11 and 10.1.1.12, which are configured in all clients’ IP settings as Primary and Secondary WINS, respectively. OldServer1 and OldServer2 are configured as push/pull partners.

The new servers, NewServer1 and NewServer2, are added to the network with the WINS service installed and configured as push/pull partners for each other. Their initial IP addresses are 10.1.1.21 and 10.1.1.22. OldServer1 and NewServer1 are then connected as push/pull partners for the network. Because the servers are connected this way, all database information from the old WINS database is replicated to the new servers, as illustrated in step 1 shown in Figure 13.40.

After the entire WINS database is replicated to the new servers, the old servers are shut down (on a weekend or evening to minimize impact), and NewServer1 and NewServer2 are immediately reconfigured to take the IP addresses of the old servers, as illustrated in step 2 shown in Figure 13.41.

Figure 13.41. WINS migration procedure, step 2.

The push/pull partner relationship between NewServer1 and NewServer2 is then re-established because the IP addresses of the servers changed. The entire downtime of the WINS environment can be measured in mere minutes, and the old database is migrated intact. In addition, because the new servers assume the old IP addresses, no client settings need to be reconfigured.

There are a few caveats with this approach, however. If the IP addresses cannot be changed, WINS servers must be changed on the client side. If you’re using DHCP, you can do this by leaving all old and new servers up in an environment until the WINS change can be automatically updated through DHCP. Effectively, however, WINS migrations can be made very straightforward through this technique, and they can be modified to fit any WINS topology.

Just like the DHCP database, the WINS database is based on the Microsoft JET database technology and is consequently subject to the need for regular maintenance. Scheduling maintenance for each WINS database is recommended on a quarterly or semi-annual basis. The WINS database file, wins.mdb, is stored in the \%systemroot%system32wins directory. You can run maintenance against the database by entering the following commands at the command line:

The global catalog in Active Directory is an index of all objects in an Active Directory forest. All domain controllers in Windows Server 2003’s Active Directory are not by default global catalog servers, so they must be established as such through the following procedure:

Universal group caching is a process by which an Active Directory site caches all universal group membership locally so that the next time clients log in, information is more quickly provided to the clients and they are able to log in faster.

Universal group caching is more effective than placing a GC/DC server locally because only those universal groups that are relevant to a local site’s members are replicated and are cached on the local domain controller. The downside to this approach, however, is that the first login for clients will still be longer than if a local GC/DC were provided, and the cache eventually expires, requiring another sync with a GC/DC.

You can set up universal group caching on a site level as follows:

As you learned in the preceding sections, you must make decisions regarding the most efficient placement of DCs and GC/DCs in an environment. Decisions on placement of GC/DCs and universal group caching sites must be made with an eye toward determining how important fast logins are for users in a site compared to higher replication throughput. However, for many Windows Server 2003 environments, the following rules apply:

The recommendations listed here are generalized and should not be construed as relevant to every environment. However, these general guidelines should help you to size an Active Directory environment for domain controller placement.