default, the DNS server will allow zone transfers to only those DNS servers listed as name servers for the zone. However, you might need to reconfigure these restrictions so that you specify the IP addresses of computers that are authorized to pull zone information. ■ Another cause of failed zone transfers is the use of nonstandard characters in DNS names. By default, Microsoft DNS servers are configured to load the zone even if they encounter bad data. However, BIND servers are not as forgiving. In addition, WINS forward and reverse lookup records can cause problems if replicated to BIND servers.You can prevent WINS records from replicating to BIND servers. If you are replicating to BIND servers, you should use only standard DNS characters. ■ Another common cause of zone transfer problems is an incorrect version number in the SOA of the primary or secondary zone.To determine whether to request a zone transfer from the primary server, the secondary server will compare the version number of the pri- mary’s SOA with its own. If the primary’s number is higher, the secondary will request either a full or an incremental zone transfer. If the version number is reset on the primary so that it is lower than the version number in the secondary’s SOA, the zone transfer will fail. ■ If queries to subdomains are failing, the cause is most likely a lame delegation of authority. A lame delegation occurs when the name server and glue address records do not point correctly to the servers that are authoritative for the subdomain. NSLookup and DNSLint are useful tools in helping to troubleshoot problems with delegations. ■ If dynamic updates are failing, the cause of the problem might be related to the security settings and ownership of RRs in their ACLs. For example, if a DHCP server is the orig- inal owner of a record and a client subsequently gets its IP address from another DHCP server, the dynamic update will fail. Another cause of failed dynamic updates is that the primary zone is, for whatever reason, unavailable. Dynamic updates can occur in only pri- mary or Active Directory-integrated zones. Troubleshooting NetBIOS Name Resolution To avoid problems with NetBIOS name resolution in the first place, you should take very seriously the best practices that Microsoft recommends for the deployment of WINS servers and clients. In general, these best practices require the following: ■ Be conservative in your estimates of the number of WINS servers you need. ■ Use full replication partnership agreements. ■ Use a hub-and-spoke replication topology to reduce convergence time in large environ- ments. ■ Do not install WINS on a multihomed server. To troubleshoot problems with NetBIOS name resolution, you should first analyze the problem to determine whether it is a client configuration problem or a problem related to WINS server records or WINS server configuration, such as failed replication. 736 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 736 Issues Related to Client Computer Configuration First, you should determine whether a problem that appears to be related to client configuration affects a single computer or a group of computers that all get their TCP/IP configuration from the same DHCP server or the same DHCP server scope.You should also verify the WINS server con- figuration by using the ipconfig /all command.The output of this command will list any WINS servers that are either manually configured or dynamically configured through DHCP.You should ping the IP addresses of the WINS servers listed in the client configuration to verify that communi- cation is possible with these computers. Another command you can use to troubleshoot problems related to client configuration is the nbtstat command. With the nbtstat command, you can cause a release and refresh of the NetBIOS registration for the client computer, view the remote name cache, view statistics on recent NetBIOS name resolution activity, and so on. Sometimes, a recently cached but incorrect entry in the remote name cache is causing a specific problem.You can also use the nbtstat command to clear the con- tents of the cache, except for those entries that are preloaded with the #PRE tag in an LMHOSTS file (these entries are obvious when you view the remote name cache using the nbtstat command). In addition to verifying the correct configuration of the WINS server entries, you might want to consider whether the client is configured as an h-node, an m-node, a b-node, or a p-node client. For example, if the client is configured as an m-node client, it will use name query broadcasts before reverting to unicast name queries to the WINS server. If there is a duplicate NetBIOS name on the subnet, resolution to this name will occur first in the case of an m-node client. Furthermore, you should consider the presence of an LMHOSTS file on the client computer and the order in which LMHOSTS will be used in name resolution queries. If the clients are using an LMHOSTS file and it appears that an LMHOSTS file is involved in the problem, you need to verify that the entries in the file are correct. Issues Related to WINS Servers In troubleshooting problems with name resolution that involve the WINS server, it is useful to first determine the scope of the problem. For example, does the problem involve dynamic or static name mappings, deleted records, replication, or a corrupted database? You should also consider any error messages that the NetBIOS client receives, such as “Network path not found” or “Duplicate name.” In addition, you should look at any events that are recorded in the System event log for the WINS service that might provide an indication of a corrupted database or problems with replication. Finally, you should confirm whether the problem affects one or multiple WINS servers. If the problem affects only one WINS server, you should first verify that the WINS service has started properly and that the database is not corrupted. Problems Related to Static Mappings You should avoid the use of static mappings except in situations where you need WINS to provide resolution to NetBIOS applications running on non-WINS clients or you want to provide static, permanent name mappings to mission-critical servers to mitigate the risk of redirection attacks. However, if you are using static mappings and the problem is related to these entries, you should do the following: Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 737 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 737 ■ Verify that the entries are correct and that they have replicated properly. ■ If you have deleted the static mapping, you need to verify that the tombstoned record, in the case of a tombstone rather than simple deletion, has replicated properly. ■ If the client error message refers to a “duplicate name” and there is a static mapping for the name, you need to ensure that the migrate on setting is enabled to allow the dynamic name registration to overwrite the manual registration. Problems Related to Multihomed WINS Servers Multihomed WINS servers are not a recommended configuration and are the cause of many WINS-related problems. Some of the problems you might experience with multihomed WINS servers can be hard to track down. If you are experiencing intermittent problems with name resolu- tion or if you are having problems with replication, chances are that these can be traced to the con- figuration of the multihomed WINS server. However, if you must use a multihomed WINS server and if you are experiencing problems, you should do the following: ■ Verify that all network devices on the multihomed WINS servers are configured as routable interfaces with correct TCP/IP information. (You should never colocate the WINS service with the RAS service—that is just asking for trouble.) ■ Verify that all TCP/IP configurations use the IP address of the WINS server for both their primary and alternate WINS servers. (You can leave this configuration blank if you like, because the WINS server will register itself without this configuration.) ■ Verify that all the replication partners of the multihomed WINS servers are configured to replicate with all the configured IP addresses of the WINS server, and not the NetBIOS name. Problems Related to Replication Problems related to replication almost always are the result of not following Microsoft’s recom- mended practices, such as installing too many WINS servers, installing WINS on a multihomed computer, or using limited replication partnerships. For example, installing too many WINS servers (more than 20, according to Microsoft) can cause intermittent and hard-to-locate problems with replication. In troubleshooting replication problems, you should first consider whether the problem is related to network communication and name resolution to the replication partners themselves. Consider the following questions: 738 Chapter 20 • Planning, Implementing, and Maintaining a Name Resolution Strategy 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 738 ■ Can you ping the IP address of the replication partner? ■ If the replication partner is a multihomed computer, have you configured the replication partner settings with the IP addresses of the multihomed computer, rather than the NetBIOS name? ■ Does the NetBIOS name of the WINS server resolve to the correct IP address? If you are using limited replication partnerships (push-only and pull-only) replication partners, you should ensure that these partnerships are set up correctly.Also, you might achieve best results by setting up reciprocal partnerships on the push and pull partners. For example, a computer that is configured as a pull-only partner to another WINS server should also configure that WINS server as its push partner.To illustrate, WINS-A has configured WINS-B as its pull partner; WINS-B in turn should configure WINS-A as its push partner. (To ensure that records are never pushed and repli- cated strictly according to the pull replication schedule, you can set the push trigger threshold to a very high number that will never be reached between pull replication cycles.) If replication partnerships are configured correctly and there is good connectivity, but you are still experiencing intermittent problems, the version IDs on some replicated records may not be cor- rectly incremented.You can resolve this problem by entering a new starting version ID for the WINS database in the WINS console or using the netsh command. Planning, Implementing, and Maintaining a Name Resolution Strategy • Chapter 20 739 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 739 301_BD_W2k3_20.qxd 5/24/04 9:10 AM Page 740 Planning, Implementing, and Maintaining the TCP/IP Infrastructure In this chapter: Understanding Windows 2003 Server Network Protocols Planning an IP Addressing Strategy Planning the Network Topology Planning Network Traffic Management Introduction Transmission Control Protocol/Internet Protocol (TCP/IP) is the default network/transport protocol stack for a Windows Server 2003 network, and it is impor- tant for all network administrators to be intimately familiar with the TCP/IP protocols, IP addressing, and how to plan an IP infrastructure. This chapter deals with the TCP/IP infrastructure. We’ll discuss Internet Group Management Protocol version 3 (IGMPv3), IP version 6 (IPv6) support, the alternate configuration feature, and automatic determination of interface metrics. You’ll find out how to plan an IP addressing strategy, including how to analyze your addressing requirements and how to create an effective subnetting scheme.You’ll learn about transitioning to the next generation of IP, IPv6, and we’ll introduce IPv6 utilities such as Netsh, Ipsec, PING, and Tracert. We’ll discuss 6to4 tunneling, the IPv6 Helper service, and connecting to the 6bone. Next, we’ll discuss the planning of the network topology.This includes analyzing hardware requirements and planning for the placement of physical resources.You’ll learn how to plan network traffic management, as well as how to monitor network traffic and devices using Network Monitor and System Monitor. We’ll show you how to deter- mine bandwidth requirements and how to optimize your network’s performance. Chapter 21 741 301_BD_W2k3_21.qxd 5/12/04 2:43 PM Page 741 Understanding Windows 2003 Server Network Protocols The networking architecture of Windows Server 2003 uses the Network Driver Interface Specification (NDIS). NDIS provides a kind of wrapper in the I/O Manager layer of Windows that allows the hardware driver to be independent of the protocols used to communicate on your network. Additionally, this allows for multiple network adapters with virtually any device driver, without having any effect on the transport protocols used. Let’s take a look at some of the details involved with networking. The Multiprotocol Network Environment Microsoft Windows Server 2003, like its predecessors, uses a layered network architecture. Since it is layered, it is possible to extend the functionality of networking Windows Server 2003 with third- party software components.The layered structure also provides the Windows Server 2003 platform with the ability to allow different protocols to communicate using the same structure and methods, so users can access data in the same fashion, regardless of what networking protocol is used. Windows Server 2003 products use the TCP/IP protocol stack by default.The following net- work protocols are supported on Windows Server 2003: ■ TCP/IP version 4 The default protocol for Windows Server 2003. ■ TCP/IP version 6 The next generation of TCP/IP. ■ IPX/SPX Used by many networks running Novell NetWare. ■ AppleTalk Provides the basis for Services for Macintosh and AppleTalk routing and seed routing support. The Windows Server 2003 architecture that supports multiple protocols also allows multiple network adapters. Each adapter can use any combination of protocols or networking components, known as binding. It is also possible for you to change the order in which protocols are bound to the adapter.You can choose to move the most commonly used protocols on the client up to the top of the binding order to provide faster performance. When configuring protocols on your computer, it is always desirable to make the fewest possible changes on the client in order to simplify the administration of the network. On a TCP/IP network with more than 25 hosts, it is a good idea to implement a DHCP server. By default, all Windows XP and Windows Server 2003 machines are configured to use DHCP. Occasionally, you might need to manually configure the IP address of your machine. If you do configure the address manually, pay close attention to the information you provide in the dialog box. Errors in the configuration will hinder network communication for that machine, and in some cases, cause problems that could pre- vent other machines from functioning properly. What’s New in TCP/IP for Windows Server 2003 There are many enhancements to the networking and communications components of Windows Server 2003.The TCP/IP protocol suite has been enhanced with some of the latest technologies, as 742 Chapter 21 • Planning, Implementing, and Maintaining the TCP/IP Infrastructure 301_BD_W2k3_21.qxd 5/12/04 2:43 PM Page 742 well as improvements on existing functionality. For more information about other networking and communication feature enhancements, see the white paper titled “Microsoft Windows Server 2003- Technical Overview of Networking and Communication” (www.microsoft.com/win- dowsserver2003/techinfo/overview/netcomm.mspx). IGMPv3 Typical communications over an IP-based network are directed unicast communications. Unicast is basically a single, direct request sent from one host to another, and only the two hosts interact over the established route. For example, when you click a hyperlink in a Web browser, you are requesting HTTP data from the host defined in the link, which, in turn, delivers the data to your browser.This is useful in the Web-browsing environments we have grown accustomed to, where there is a demand for a personal, user-controlled experience. Unicast is not useful for delivering streams of audio or video to large audiences, since a single stream of audio/video data is very costly for only one user.This is where multicast communications are effective. Multicast provides a single stream for multiple hosts.The hosts select the data by requesting the local routers to forward those packets of data from the host providing the multicast data to the subnet of the listening host. When the host decides to stop listening to the multicast traffic, IGMP is responsible for notifying the router that the host is no longer participating. A set of listening hosts is called a multicast group. IGMP is responsible for providing the function- ality necessary for hosts to join and leave those groups that receive IP multicast traffic. Each of the versions of IGMP—versions 1, 2, and 3—is automatically supported by Windows Server 2003. IGMPv3 adds functionality to distribute multiple multicast sources regionally and allow the host to select the multicast source that is located closest to the host. An example of this would be a situation in which you send a video stream broadcasting a speech from the president of your company and have several machines scattered across the United States providing the feed.Then IGMPv3 allows the hosts to provide an include list or an exclude list of those servers.The multicast routers would be responsible for forwarding the multicast traffic from the include list of servers and for preventing the forwarding of traffic from the excluded sources. As you can see, this feature can be very useful to help reduce network bandwidth utilization. IPv6 The next generation of TCP/IP is here! Previously, it was possible to experiment with IPv6, but under the covers, the protocol stack was still dependent on IPv4 calls for WinSock functions. With the release of Windows Server 2003, the IPv6 protocol stack is designed for production use. IPv4 has a limited number of host addresses available (2 32 , or about 4 billion hosts).That might sound like a lot, but over the past 30 years, the pool of available addresses has been exhausted due to the popularity and growth of the Internet. With IPv6, the host address is 128 bits instead of 32, which means that we will have 2 128 (about 340,000,000,000,000,000,000,000,000,000,000,000,000) host addresses available.That means we could have about 2 96 (about 75 trillion trillion, or 75,000,000,000,000,000,000,000,000,000) addresses of our very own.That should last for at least a couple of years. We will discuss transitioning to IPv6 and its features in more detail in the “Transitioning to IPv6” section later in this chapter. Planning, Implementing, and Maintaining the TCP/IP Infrastructure • Chapter 21 743 301_BD_W2k3_21.qxd 5/12/04 2:43 PM Page 743 Alternate Configuration Automatic alternate configuration is an enhancement to TCP/IP that allows for a valid static IP address configuration on a DHCP-configured machine. Without an alternate configuration defined, a computer that is unable to obtain an IP address lease from a DHCP server will automatically receive an Automatic Private IP Addressing (APIPA) address from the 169.254.0.0/16 pool. Automatic Determination of Interface Metric The automatic metric feature is enabled by default.The purpose of the automatic metric feature is to determine the speed of the interface for each default gateway and to assign the metric, which is the cost of using a particular route. The metric is weighted by the number of hops to the destination.The number of hops to any host on the local subnet is one. Every router that must be used to reach the destination is another hop. When it is determined that there are multiple routes to the same destination, the metric is eval- uated to determine which is the lowest metric and subsequently the fastest route to the destination. The metric for the loopback adapter and the limited broadcast is always 1.The other addresses have a metric based on the cost of using that route for that network adapter. With multiple network adapters, a multihomed computer, the route table would indicate a different metric for each default route, but only one would be used.Table 21.1 shows a configuration with identical network adapters: one adapter on the 192.168.69.0/24 network and the other on the 192.168.70.0/24 net- work. Table 21.1Description of Routes with a Multihomed Computer Network Description Destination Netmask Gateway Interface Metric Default route 0.0.0.0 0.0.0.0 192.168.69.111 192.168.69.111 20 Default route 0.0.0.0 0.0.0.0 192.168.70.100 192.168.70.100 30 Loopback 127.0.0.1 255.0.0.0 127.0.0.1 127.0.0.1 1 network Local network 192.168.69.0 255.255.255.0 192.168.69.111 192.168.69.111 20 Local IP address 192.168.69.111 255.255.255. 127.0.0.1 127.0.0.1 20 255 Local network 192.168.70.0 255.255.255.0 192.168.70.100 192.168.70.100 30 Local IP address 192.168.70.111 255.255.255. 127.0.0.1 127.0.0.1 30 255 Subnet 192.168.69.255 255.255.255. 192.168.69.111 192.168.69.111 20 broadcast 255 Multicast 224.0.0.0 240.0.0.0 192.168.69.111 192.168.69.111 20 address Multicast 224.0.0.0 240.0.0.0 192.168.70.100 192.168.70.100 20 address 744 Chapter 21 • Planning, Implementing, and Maintaining the TCP/IP Infrastructure 301_BD_W2k3_21.qxd 5/12/04 2:43 PM Page 744 Table 21.1Description of Routes with a Multihomed Computer Network Description Destination Netmask Gateway Interface Metric Limited 255.255.255. 255.255.255. 192.168.69.111 192.168.69.111 1 broadcast 255 255 Limited 255.255.255. 255.255.255. 192.168.70.100 192.168.70.100 1 broadcast 255 255 Note that the metric for the default route for the second network, on the adapter for the 192.168.70.100 interface, is higher than the metric for the default route on the 192.168.69.111 interface.This indicates that the 192.168.69.111 network adapter is first in the binding order. Since the metric for the default gateway for the second adapter is higher than the first network adapter, the second gateway is never used and is not necessary. You can use the route command to add routes and change metrics.The command is route add –p Destination Mask Gateway IF Metric, where: ■ Destination is the network destination address. ■ Mask is the appropriate subnet mask defined for the destination network. ■ Gateway is the address of the router interface used to interface with the network. ■ IF is the interface you want to associate this route to. ■ Metric is the metric for this gateway. The –p parameter specifies that you want to persist this route, so that it will be there if you reset the adapter or restart the machine. If you do not specify –p, the route is temporary and will not be saved. If you want to delete a route, use the route delete Destination command to remove the desti- nation route from the route table. You can disable the automatic metric feature by accessing the properties for the desired connec- tion, as follows: 1. Select Internet Protocol (TCP/IP) and click Properties. 2. In the Internet Protocol (TCP/IP) Properties dialog box, click the Advanced button. 3. Uncheck Automatic metric. 4. Provide an Interface metric. The minimum value is 1. 5. Click OK. 6. Run the route print command. What changed? You will notice that all of the metric values are now 1. You can change the values manually, which can allow you to redirect traffic over a slower inter- face that would normally have a higher metric. Planning, Implementing, and Maintaining the TCP/IP Infrastructure • Chapter 21 745 301_BD_W2k3_21.qxd 5/12/04 2:43 PM Page 745 . possible to extend the functionality of networking Windows Server 2003 with third- party software components .The layered structure also provides the Windows Server 2003 platform with the ability to. TCP/IP for Windows Server 2003 There are many enhancements to the networking and communications components of Windows Server 2003 .The TCP/IP protocol suite has been enhanced with some of the latest. determine whether to request a zone transfer from the primary server, the secondary server will compare the version number of the pri- mary’s SOA with its own. If the primary’s number is higher, the secondary