270 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems Figure 6.4 Configuring Advanced TCP/IP Properties settings. Figure 6.5 Enabling the use of an LMHOSTS file for NetBIOS name resolution. 91_tcpip_06.qx 2/25/00 1:00 PM Page 270 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 271 The Windows 2000 Windows Internet Name Service (WINS) The Windows 2000 WINS server is fully RFC-compliant and includes many extra features that optimize its use on Windows networks. The Windows 2000 WINS server is also interoperable with “downlevel” (NT) WINS servers, which allows it to peacefully coexist in hybrid Windows 2000/Windows NT 4.0 networks. In this section, we’ll examine the types of exchanges that take place between the WINS client and WINS server, and look at the WINS Proxy Agent. NetBIOS Name Registration When a WINS client starts up, it will register its NetBIOS name with a configured WINS server via a “NetBIOS Name Registration Request.” If the WINS client’s name does not already exist in the WINS server’s database, the WINS server will send a “Positive NetBIOS Name Registration Response” to the WINS client. If the WINS client’s name is already in the WINS database, the WINS server returns a WACK (wait for acknowledgement) message to the WINS client. The WINS server then issues a “challenge” (NetBIOS Node Adapter Status message) to the IP address associated with that NetBIOS name in its database. If there is no response from the registered owner of the NetBIOS name, the WINS server will return a “Positive NetBIOS Name Registration Response” to the WINS client, and its name and IP address will be recorded in the WINS database. If the owner does respond to the challenge, the WINS client that is attempting to register the name will receive a “Negative NetBIOS Name Registration Response” and will not be able to initialize its TCP/IP stack. If the computer that is registering its name and the IP address is the same as the one in the WINS database, it will be treated as a refresh of the WINS database entry, and the renewal date will be updated for the entry. A WINS database entry must be renewed periodically. The amount of time that can pass before the WINS client must renew its name is the “renewal interval,” which is configured at the WINS server. The default for the Windows 2000 WINS server is 6 days, or 144 hours. (This is correct. NOTE 91_tcpip_06.qx 2/25/00 1:00 PM Page 271 272 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems Six days is 144 hours. If you have read some of the Windows NT 4.0 books on the market, you might have noticed that many of them state the Windows NT 4.0 WINS server’s default renewal interval was “4 days, or 144 hours.” While you might have figured this was just “WINS new math,” it was in fact an error in the Windows NT WINS server help file which was then perpetuated by the authors of several popular books.) Figure 6.6 shows the default settings on a Windows NT 4.0 WINS server. Figure 6.6 Default interval settings on a Windows NT 4.0 WINS server. NOTE The renewal interval for WINS entries was 96 hours, or 4 days, for the WINS server included with Windows NT 3.5. Figure 6.7 shows the help file entry for the WINS server. This machine is running Service Pack 5. If a name is not renewed within the renewal interval, the record is marked as “Released” in the WINS database. A released record can be updated without challenge. If the record is not renewed or updated for a period of time called the “extinction interval,” the record will be tombstoned and removed from the WINS database during scavenging. We’ll cover scav- enging and tombstoning later in the chapter. 91_tcpip_06.qx 2/25/00 1:00 PM Page 272 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 273 Figure 6.7 Help file on the Windows NT 4.0 WINS Server renewal intervals. NetBIOS Name Query Request When a WINS client needs the IP address of a destination host, it will send a NetBIOS Name Query Request to the WINS server. If the WINS server has a mapping for the NetBIOS name sought after, it will return the IP address in a Positive NetBIOS Name Query Response. If it does not have the name ,it will return a Negative NetBIOS Name Query Response. If the first WINS server that is queried does not contain a mapping, the WINS client will move through a list of “Secondary WINS servers” and query each one of those in turn until one of the Secondary WINS servers returns a Positive Name Query Response. The Windows 2000 WINS client services allow you to enter up to 12 Secondary WINS servers. While this leads to a greater degree of fault tolerance for your WINS queries, you should exercise care when assigning multiple WINS servers. If you config- ure a client to use 10 Secondary WINS servers, and none of them have a mapping for the destination host, you will have to wait for all of these 91_tcpip_06.qx 2/25/00 1:00 PM Page 273 274 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems WINS servers to be queried before moving to the next step in the NetBIOS name resolution process. Multiple Secondary WINS servers, therefore, should be considered a double-edged sword. NetBIOS Name Release When a WINS client is shut down “gracefully,” it will issue a NetBIOS Name Release message to the WINS server with which it registered its name. This will mark the NetBIOS name as inactive and will allow other machines to use the name without a challenge. If the WINS client is not shut down gracefully, the release message will not be sent, and another computer will not be able to use the name without first going through the challenge process. Multihomed Computers and WINS What about multihomed machines? How do they register their name with a WINS server? There are different types of multihomed machines. One type has mul- tiple IP addresses bound to a single network card. In this arrangement, only the first IP address assigned to the machine will be registered with this machine’s NetBIOS name in the WINS database. The second type of multihomed machine is more common: a machine with multiple network adapters, each with a single IP address assigned to it. Each adapter will register its NetBIOS name and IP address with the WINS server, and the WINS server will mark these entries for the multi- homed computer as a multihomed name registration. When the WINS server receives a NetBIOS Name Query Request for the NetBIOS name of the multihomed machine, it will send all the IP addresses it has registered to that NetBIOS name. Now that the client has a bunch of IP addresses to choose from, how will it decide which one to use? If one of the IP addresses returned by the WINS server is on the same subnet as the computer that made the request, it will try to connect to that IP address first. If multiple IP addresses are returned that are on the same subnet, it will pick one of those at random. If none of those in the list are on the same subnet, then, again, an IP address will be chosen at random. For multihomed WINS servers, Windows 2000 does not guarantee the binding order for NetBIOS when more than one connection is present and active. A multihomed WINS server should have all installed connections configured as routable interfaces. 91_tcpip_06.qx 2/25/00 1:00 PM Page 274 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 275 A multihomed WINS server must have its primary IP addresses assigned to each network connection (assuming you’ve configured more than one IP address per connection), and you should configure each primary IP address as Push and Pull partners at other servers that will replicate with the multihomed WINS server. Each IP address should be configured as a replication partner to all other WINS servers that it will be partnering with. When configuring replication partners, you can ensure that a specific network connection is used if you specify an IP address for the remote multihomed server you are adding at a WINS server. If you enter a NetBIOS name instead of IP addresses, when replication partners are specified and resolved by a name entered in the WINS con- sole, it is possible that a packet generated by WINS could use any of the interfaces and their respective IP addresses. This apparently random behavior results from WINS referring to its local IP routing table, which contains all of the installed interfaces, before it sends packets to the remote server. WINS Proxy Agents A WINS Proxy Agent is a machine configured to listen for NetBIOS Name Query Requests and forward these to a WINS server. WINS Proxy Agents are useful when you have non-WINS-enabled machines on a segment that need NetBIOS name resolution services. When a non-WINS-enabled machine (which includes b-node clients) issues a NetBIOS Name Query Request, the WINS Proxy Agent intercepts the request and forwards it to its configured WINS server. If the WINS server contains a mapping for the NetBIOS name in question, it will send a Positive NetBIOS Name Query Response to the WINS Proxy Agent, which in turn sends the answer to the machine that issued the broad- cast. The WINS Proxy Agent also caches the successful query. If a subse- quent request for the same NetBIOS name is broadcast again, the WINS Proxy Agent will be able to answer the request from its cache, rather than referring the request to a WINS server. A question that comes up from time to time is how to alter the Proxy’s name cache timeout. The WINS Proxy Agent uses the NetBIOS Remote Name Cache Table for that computer, thus you can configure the CacheTimeout parameter in the Registry, mentioned earlier, to customize the WINS Proxy Agent’s cache settings. 91_tcpip_06.qx 2/25/00 1:00 PM Page 275 276 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems WINS Configuration Issues After a WINS server is installed, a certain amount of configuration needs to be accomplished. While this book isn’t about installation and configu- ration of Network Services, some configuration issues are worth mention- ing in the context of trouble prevention and troubleshooting. (For complete coverage of installation and configuration of Windows 2000 Network services, we highly recommend “Managing Windows 2000 Networking Services” published by Syngress Media.) Static Mappings One of the great strengths of WINS is that it is a dynamic database. Unlike an LMHOSTS file that has to be manually updated every time a machine changes its IP address, WINS clients automatically update their records in WINS. This is especially wonderful in an environment that uti- lizes DHCP, where managing LMHOSTS files would quickly wear down the resolve of even the staunchest of network administrators. However, non-WINS clients are not able to register themselves with the WINS server. If you have non-WINS clients running NetBIOS applications, you may want to include their names in the WINS database so that WINS- enabled clients can query the database and find the IP addresses of the non-WINS enabled clients. To do this, you must enter a “static mapping” for each non-WINS client into the WINS database. Static mappings allow WINS clients to find these non-WINS comput- ers’ IP addresses by performing WINS queries. This circumvents the need to create and distribute LMHOSTS file entries for the non-WINS clients. TIP WINS servers do not respond to NetBIOS Name Query Request Broadcast messages. Several times, we have encountered a “problem” with a WINS server that was not “responding.” In each case, the WINS server was on the same segment as the WINS clients. The administrators felt that since the WINS server was on the same segment as the clients, the WINS server should be able to respond to the Name Query Request. This is not the case. Therefore, if you have non-WINS clients that must resolve NetBIOS names for remote nodes, you should install a WINS Proxy Agent on the subnet with the non-WINS clients, regardless of whether there is a WINS server on that subnet or not. 91_tcpip_06.qx 2/25/00 1:00 PM Page 276 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 277 Problems with Static WINS Entries Static mappings should only be used for non-WINS clients that intend to stay non-WINS clients. Some administrators may import LMHOSTS files and create static mappings for computers that have the capability to be WINS clients. If you do this, you should enable the “Migrate On” setting. By default, static entries are not overwritten by dynamic name registrations. If you decide to WINS-enable clients that were not for- merly WINS-enabled, they will not be able to dynamically update their WINS records. However, if you enable Migrate On at the WINS servers, static entries will be overwritten by dynamic name registra- tions. This is great when it works. However, there are times when the static entries are not overwritten. One example is the <1Ch> entries in the WINS database. These entries represent domain controllers, and this value is used by downlevel WINS clients to find machines with which they can authenticate. That means if you decide to change the IP address of a domain controller, even if you have sub- sequently enabled it as a WINS client, it will not update its IP address with the WINS database. If a WINS client queries the WINS database for a domain controller, and finds that static entry and attempts to authenticate against the static entry that no longer exists, bad things will happen. This problem is further exacerbated by replication of the static entry. When a static record is replicated, its status as a static record is replicated with it. This means that you must delete the record at all WINS servers, to prevent it from being rereplicated back to a machine from which it had been deleted. In NT 4.0, after the entry was deleted from all the WINS servers, you had to restart the domain controller. However, Windows 2000 allows you to reregister the WINS client by using the nbtstat –RR command. For IT Professionals WINS Replication Networks with more than a single WINS server will need to synchronize the contents of the WINS database among all WINS servers on the net- work. This process of database synchronization is accomplished via WINS replication. 91_tcpip_06.qx 2/25/00 1:00 PM Page 277 278 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems The WINS replication process ensures that every WINS server on a network has WINS database records for all the WINS servers on the net- work. In this way, it shouldn’t matter what WINS server you query, because all WINS servers will contain the same database records. When a computer registers its NetBIOS name and IP address with its Primary WINS server, that server is called the “owner” of that record. The record is also given a “version ID.” The most recent record registered at a WINS server defines the most recent version ID of the WINS database. When a WINS server replicates its records to other WINS servers, only records with higher version IDs than the ones contained on the other WINS servers are replicated, because those are the only ones that have changed since the previous replication. The owner of a WINS record has the highest version ID for each record that it owns. If this is not the case, then something strange is going on, and you need to investigate! Partnership Agreements WINS servers replicate their information by forming partnerships. There are two types of partnerships you can form between WINS servers: Pull and Push. When a WINS server is a Pull partner of another WINS server, it will send an update trigger to its partner on a periodic basis. This is configured at the WINS server that is the Pull partner. When a WINS serv- er is a Push partner to another WINS server, that WINS server sends an update trigger when a certain number of records or “version IDs” have changed. In general, Microsoft recommends that you configure Windows 2000 WINS servers to be both Push and Pull partners of each other. However, there may be times when you prefer to configure WINS servers to be only Pull partners. This would be the case when WINS servers are separated by slow WAN links, and you wish to minimize the traffic on the WAN link during busy times of the workday. In this case, you configure the WINS servers to be Pull partners of each other, and configure the replication trigger to be sent during the quiet times of the evening or early morning. Each WINS record is about 40 bytes when replicated. If you have 1000 updated WINS records to replicate, that would require about 40,000 bytes, or 40KB. That’s not very much traffic, even for a 56 Kbps WAN link. However, if you had 10,000 WINS updates to send during a replica- tion, that would be about 400,000 bytes, or 400KB. This would make an impact on a 56 Kbps WAN link, since it transfers less than 7 KBps. NOTE 91_tcpip_06.qx 2/25/00 1:00 PM Page 278 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 279 In actual practice, the transfer of 400KB would take about two minutes on a typical analog modem. Depending on the type of responsiveness you expect from your link, this may or may not be acceptable. Remember that it is unlikely that an organization of 10,000 computers will have all of them update their records simultaneously. The only time this might occur is if there was a large-scale power outage, and all the machines updated their WINS records at the same time when coming back online. This is somewhat unlikely, but you should be prepared in case it happens. It’s easy to get confused when we start talking about kilobits (abbreviated as “kb”) and kilobytes (abbreviated as “KB”). Just remember that (in most computer systems) a byte equals eight bits. A bit consists of a single binary digit, 0 or 1. WINS partnerships are configured in the WINS management console, which you can access via the Administrative Tools menu (see Figure 6.8). Note the “Unknown” WINS server names. These WINS servers were added via WINS Autodiscovery, and their NetBIOS names are not included on the Replication Partners list, just the IP addresses. NOTE Figure 6.8 The WINS management console. Right-clicking the Replication Partners node in the left pane of the console and clicking Properties will bring up the Replication Partners Properties dialog box. Click the Push Replication tab and you will see the dialog box shown in Figure 6.9. 91_tcpip_06.qx 2/25/00 1:00 PM Page 279 [...]...91_tcpip_06.qx 2/ 25/ 00 1:00 PM Page 280 280 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems Figure 6.9 The Push Replication settings in the Replication Partners Properties dialog box Now click the Pull Replication tab and you see something similar to Figure 6.10 Figure 6.10 The Pull Replication settings in the Replication Partner Properties dialog box 91_tcpip_06.qx 2/ 25/ 00... manually compact the database using the jetpack.exe command from the command prompt 91_tcpip_06.qx 2/ 25/ 00 1:01 PM Page 291 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 291 TIP Searching the Windows 2000 Help files and TechNet for guidance on how to compact the Windows 2000 WINS database will leave you with an empty feeling inside To manually compact the Windows 2000 database,... should lessen as applications and network clients are upgraded to Windows 2000 In a pure Windows 2000 environment, WINS can be done away with entirely as the Windows 2000 computers will be able to use DDNS (which, like WINS, is updated dynamically) instead 91_tcpip_06.qx 2/ 25/ 00 1:01 PM Page 288 288 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems Figure 6. 15 A five-node Ring... normal tape backup procedure, and all will be well 91_tcpip_06.qx 2/ 25/ 00 1:01 PM Page 289 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 289 Figure 6.16 The WINS server Properties dialog box The best practice is to have the WINS server back up its database, and then you “back up the backup.” You might even consider a special backup schedule for the files in the WINS backup folder... networks of up to five sites 91_tcpip_06.qx 2/ 25/ 00 1:00 PM Page 287 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 287 Figure 6.14 A four-node Ring has a maximum intersite hop count of 2 5 min 5 min 15 min 15 min 15 min 15 min 5 min 5 min 4-Node Ring Convergence Time in Worst Case Scenario is 40 minutes with a Maximum Hop Count of two But what happens in our five-intersite model... 91_tcpip_06.qx 2/ 25/ 00 1:00 PM Page 281 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 281 This all seems pretty straightforward However, after you have configured Push and Pull partners, right-click on one of the partners in the right pane, and then click Properties You will see the box shown in Figure 6.11 Figure 6.11 Replication Properties for a specific replication partner If you’re... its Adjacent Hub Server Spoke Server Spoke Server Dallas Hub Spoke Server Spoke Server Spoke Server Los Angeles Hub Portland Hub Spoke Server 91_tcpip_06.qx 2/ 25/ 00 1:00 PM Page 286 286 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems However, the Hub servers would be configured in a “Ring,” where each adjacent member in the ring is configured as a Pull partner of the other This... this chapter In the second scenario, we have WAN links of equal speed connecting all three sites Intrasite replication would be configured in the same fashion as seen in the first scenario, using a central Hub server setup as a Push and Pull replication partner to the remaining Spoke servers This design is seen in Figure 6.13 91_tcpip_06.qx 2/ 25/ 00 1:00 PM Page 2 85 Troubleshooting Windows 2000 NetBIOS... 91_tcpip_06.qx 2/ 25/ 00 1:01 PM Page 293 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 293 mystery to some NT administrators in the past, and for the most part, were usually ignored However, if you know the meanings of the other options, you will be able to troubleshoot problems with your WINS lookups (and DNS lookups) more easily Resolution of Unqualified Names The first option... replicated to other WINS servers 91_tcpip_06.qx 2/ 25/ 00 1:01 PM Page 297 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 297 Problems Arising from Split Registrations Let’s look at an example You are installing a new WINS server, and give it the NetBIOS name NEWWINS You install the WINS service and then go to the TCP/IP Advanced Properties dialog box on this new WINS server . Replication Partners Properties dialog box. Figure 6.10 The Pull Replication settings in the Replication Partner Properties dialog box. 91_tcpip_06.qx 2/ 25/ 00 1:00 PM Page 280 Troubleshooting Windows 2000. resolution. 91_tcpip_06.qx 2/ 25/ 00 1:00 PM Page 270 Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 271 The Windows 2000 Windows Internet Name Service (WINS) The Windows 2000 WINS. hop count of 3. 15 min 15 min 15 min 5 min 5 min 5 min 5 min 5- Node Ring Convergence Time in Worst Case Scenario is 50 minutes with a Maximum Hop Count of three. 5 min 15 min 15 min 91_tcpip_06.qx