WINDOWS 2000 TROUBLE SHOOTING TCP/I P phần 5 pot

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
280 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems

Now click the Pull Replication tab and you see something similar to
Figure 6.10.
Figure 6.9 The Push Replication settings in the 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 NetBIOS Name Resolution Problems • Chapter 6 281
This all seems pretty straightforward. However, after you have config-
ured 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 thinking the figures appear to be different, you are correct. In
this first case, when you right-clicked on the Replication Partners node in
the left pane, you were setting defaults for all replication partners for this
WINS server. You can get more granular control over replication parame-
ters by setting replication parameters for each WINS server separately.
This is something to keep in mind when replication intervals do not
appear to be what you thought they should be.
WINS Partner Autodiscovery
Do you find the whole process of figuring out what WINS servers to make
partners, and then configuring the replication parameters, a little confus-
ing? There may be some help for you. Windows 2000 WINS servers can be
configured to find other WINS servers by using an Autodiscovery process.
A WINS server configured to find its own replication partners will broad-
cast IGMP messages to a multicast group with the group address of
224.0.1.24.
91_tcpip_06.qx 2/25/00 1:00 PM Page 281
282 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems

The 224.0.1.24 group address is reserved for Microsoft WINS servers.
This multicast will take place every 40 minutes by default, but the
interval can be configured via the WINS console. Each member of the
group will respond to the multicast announcement with its IP address.
After the partners are automatically discovered, they will be set up as
Push and Pull partners. Then Pull replication triggers will be sent every
two hours to discovered partners.
Autodiscovery is best used in small LANs where two WINS servers are
located on a single segment. You can use automatic partner configuration
in a routed environment by opening up the routers to IGMP multicast
traffic to the WINS group address. The amount of broadcast traffic for a
network with two or three segments would be minimal. After the partners
are discovered, you can then configure replication parameters on an
individual basis.
If you choose to take advantage of WINS autoconfiguration on a seg-
mented network, you can control how many hops the multicast message
will extend. Go to the Registry and open:
HKLM\System\CurrentControlSet\Services\WINS\Parameters
Open the McastTtl entry. The default value is two hops, with a limit
of 32. Note that this is different from the default value of six hops seen in
Windows NT 4.0.
In a larger WINS network with many routed subnets, WINS automatic
replication would create more problems than it’s worth, both from the
multicast traffic standpoint, and the WINS replication architectural view-
point.
WINS Network Topologies
According to Microsoft recommendations, you only need one Primary
WINS server and one Secondary WINS server for every 10,000 computers
on your network.
NOTE

TIP
91_tcpip_06.qx 2/25/00 1:00 PM Page 282
Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 283
Microsoft documentation even goes so far as to recommend that you call
Microsoft Consulting Services if your network installation consists of more
than 20 WINS servers. In reading this documentation, you almost get a sense
of urgency about this issue. Why would Microsoft be so concerned about the
number of WINS servers deployed by an organization? Based on our own
consulting experiences, here’s a guess: Many organizations employ far too
many WINS servers than they actually need, and in the process of deploying
these redundant WINS servers, problems in WINS database synchronization
“pop up.” Many companies with multiple WINS servers create Push and Pull
partner relationships in an almost arbitrary fashion.
This does not optimize WINS database consistency throughout the
organization. Microsoft may be trying to “head trouble off at the pass” by
urging customers to call before getting themselves into this sort of situation.
A WINS network topology needs to be defined for any company with
more than two WINS servers. The preferred WINS topology is the “Spoke
and Hub” arrangement.
Spoke and Hub topology
In the Spoke and Hub model, one WINS server is chosen to be a “Hub” WINS
server. This Hub collects WINS updates from all the other “Spoke” WINS
servers. After collecting all the WINS changes on the network, the Hub WINS
server is able to replicate the collective knowledge of all the WINS servers on
the network. This model is similar to the relationships between the Domain
Master Browser and Master Browser(s) on a multiple segment network.
If your organization contains multiple, geographically disparate sites,
you will need to put together a WINS replication model for each site, and
another model for intersite WINS replication.
Intrasite replication should be based on the Spoke and Hub model. A

single WINS server at each site is selected as a Hub WINS server. All other
WINS servers are Spoke servers, and they are configured to be both Push
and Pull partners of the Hub WINS server. By employing the Hub and
Spoke model, you can simplify the replication partnerships, and be
assured that all WINS servers will receive updates to changes in each
WINS server’s database.
Push and Pull Partnerships
Microsoft recommends that you always configure machines as Push and
Pull partners when they are separated by fast LAN connections. When
WINS servers are located across relatively slow WAN links, it is
NOTE
91_tcpip_06.qx 2/25/00 1:00 PM Page 283
284 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems
sometimes preferred to have them configured as Pull partners only.
For example, imagine that your company consists of 7500 computers
distributed among three geographically separated sites. The main head-
quarters is located in Dallas, Texas, where there are 3500 machines. You
also have regional headquarters located in Los Angeles, California and
Portland, Oregon. Each of the regional offices has 2000 computers. Your
network is a Windows-based network, and all computers are capable of
being WINS clients.
You have been asked to create a WINS network to accommodate two dif-
ferent scenarios. The first scenario has the remote sites connected to the
Dallas site, but not to each other. The second scenario has all the sites con-
nected to each other with WAN links of equal speed.
In this first scenario, we would select a single WINS server as a site Hub
for Dallas, Los Angeles, and Portland. The remaining Spoke WINS servers
within each site would be configured as Push and Pull partners of their
respective Hub server. This configuration assures full replication of WINS
database entries among all WINS servers within each site.

To ensure WINS database consistency among all WINS servers in
the organization, the Hub servers need to replicate their WINS data-
bases. We will create another Spoke and Hub arrangement among the
site Hubs, using the Dallas WINS server as the “Hub of the Hubs.”
Dallas is chosen as the Hub-Hub server because each remote site is
connected to Dallas via WAN links, but the remote sites are not con-
nected to each other. The remote sites are configured as Pull partners
to the Dallas hub to minimize impact on the WAN links. By using this
configuration, all changes are pooled at the Dallas WINS server. These
changes are then distributed back to the remote Hub servers, which
then distribute the changes back to their respective Spoke WINS
servers. This design is seen in Figure 6.12.
The major drawback of using a single central Hub server for synchro-
nizing all the Hubs across the WAN is that it there is a single point of fail-
ure. If the Dallas server becomes unavailable, no WINS database
replication takes place across the WAN until it comes back online. This
can have a major impact in destabilizing the WINS synchronization
scheme, because in order to bring all the WINS servers back into equilib-
rium, we have to take into account not only the time to bring the downed
WINS back online, but also the convergence time for all the sites. We’ll
talk about convergence time a little later in 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 fash-
ion 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 284
Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 285
Figure 6.12 Hub servers replicating with a central server.
Los Angeles Hub Portland Hub

Dallas Hub
Spoke
Server
Spoke
Server
Spoke
Server
Spoke
Server
Spoke
Server
Spoke
Server
Spoke
Server
Central Hub
Remote WINS act as
Spokes for Dallas
Central Hub WINS
Figure 6.13 Each site Hub replicates with adjacent Hubs.
Los Angeles Hub Portland Hub
Dallas Hub
Spoke
Server
Spoke
Server
Spoke
Server
Spoke
Server

Spoke
Server
Spoke
Server
Spoke
Server
Ring Replication
Each Hub Server
Replicates with its
Adjacent Hub Server
91_tcpip_06.qx 2/25/00 1:00 PM Page 285
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 arrangement avoids a single point of failure. Also, in this
three-site scenario, convergence of the WINS database takes place more
quickly.
Convergence Time
Convergence time represents the total time it would take for a
changed WINS record to be replicated to all the WINS servers on the
network. Let’s continue with the scenarios we’ve been working with.
In the first scenario, all site Hubs were connected to the central
Dallas Hub. If the intrasite Pull interval was 5 minutes, and the inter-
site Pull interval was 15 minutes, what is the maximum time required
to get an updated WINS record from a machine in Portland to a
machine in Los Angeles?
The answer is 40 minutes. It would take 5 minutes to get the
changed record from a Spoke server in Portland to the Portland Hub.
Then it would take up to 15 minutes to get the record from the
Portland Hub to the Dallas Hub. Then another 15 minutes would pass

to get the record from the Dallas Hub to the Los Angeles Hub, and
finally another 5 minutes to replicate the record from the Los Angeles
Hub to the Los Angeles Spoke. The WINS intersite “hop count” was
two: one hop to the Dallas Hub, and a second hop from the Dallas to
the Los Angeles Hub.
What is the convergence time in the second scenario? All site Hubs
are only one hop away from any other site Hub. For a changed WINS
record to get to Los Angeles, it would take 5 minutes for the Portland
Spoke to get the information to the Portland Hub, then 15 minutes for
the Portland Hub to the Los Angeles Hub, and then 5 minutes from
the Los Angeles Hub to the Los Angeles Spoke, for a total of 25 min-
utes. It would appear that the Ring model is more efficient, as well as
being fault tolerant.
However, the speed of convergence is related to the number of
intersite hops (assuming all intrasite hops are always equal to 1, and
the Pull interval is the same for all intrasite servers). A ring of four
intersite Hubs would have a maximum hop count of 2 and a maxi-
mum convergence time of 40 minutes, as seen in Figure 6.14. The
same would be true of a five-node intersite setup. So, using the Ring
replication model appears to be equal, or superior to the Hub model
for networks of up to five sites.
91_tcpip_06.qx 2/25/00 1:00 PM Page 286
Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 287
But what happens in our five-intersite model if one of the sites goes
down? The maximum hop count is no longer 2; it is now 3, as shown in
Figure 6.15.
The convergence time in the five-intersite Hub model with one downed
site is now 50 minutes and requires three hops! In the example in Figure
6.15, the convergence time is now 50 minutes.
When planning your WINS networks, think about the level of fault tol-

erance required for NetBIOS name resolution using WINS.
As time passes, reliance on WINS and NetBIOS should lessen as appli-
cations 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.
Figure 6.14 A four-node Ring has a maximum intersite hop count of 2.
15 min
15 min
15 min15 min
5 min
5 min
5 min
5 min
4-Node Ring
Convergence Time in Worst Case
Scenario is 40 minutes with a Maximum
Hop Count of two.
91_tcpip_06.qx 2/25/00 1:00 PM Page 287
288 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems
Backing Up the WINS Database
The Windows 2000 WINS server automatically backs up the WINS database
to a folder of your choice every three hours. The rub here is that you must
configure this directory first before the WINS server will automatically back
up the WINS database. To configure WINS backup, open the WINS console,
right-click on the name of your WINS server in the left pane, and click
Properties. You will see the dialog box that appears in Figure 6.16.
In Figure 6.16, you can see that a directory named WINSBAK on drive
C: is dedicated to the WINS backup files. The WINS server does not create
this directory. You must first create the physical directory on the server’s

hard drive, and then come to this dialog box and type in the path to the
backup directory that you created.
For fault tolerance reasons, you might think it would be a good idea to
put the backup files on a mapped network drive. In that way, you could
quickly access them in case of a hard disk crash. Unfortunately, this
won’t work, as the WINS service will not save backup copies of the WINS
database to a remote location. Be sure to include your backup directory
in your normal tape backup procedure, and all will be well.
Figure 6.15 A five-node Ring with one downed site has a maximum 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 2/25/00 1:01 PM Page 288
Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 289
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 that you’ve speci-
fied. On more than one occasion, we’ve seen the look of dismay on the
face of a network administrator after a server crash when there were no

WINS backups on hand. It’s not a pretty sight.
Backing Up the WINS Registry Settings
If you have a relatively complex WINS replication scheme, you should also
back up the WINS server’s Registry settings. You can do this by opening
regedt32 from the run command, and then navigating to:
HKLM\System\CurrentControlSet\Service\WINS
Some people have told me that they don’t think backing up a WINS
database is that important. Their reasoning is that all the WINS clients will
end up reregistering themselves again with the WINS server, and the rebuilt
WINS server will get replicated copies of all other WINS entries as well.
While this is all true, be forewarned that you will end up with quite a bit of
additional network traffic if you choose this option. Replication partners
will have to send all the records that they own, as well as records with
version IDs higher than ones that have already been replicated to the
rebuilt WINS server. This can take quite some time as the WINS database is
reconverged. Also, WINS clients that reregister with the rebuilt WINS server
will need to create new WINS records on that server, and these records will
need to be replicated as new version ID records with the rebuilt server’s
replication partners.
NOTE
Figure 6.16 The WINS server Properties dialog box.
91_tcpip_06.qx 2/25/00 1:01 PM Page 289
290 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems
Then click the Registry menu, and click Save Key. Back up the saved
key to a safe place. When you need to rebuild the WINS server, open the
Registry editor on the new machine, click the Registry menu, and click
Restore. This will copy the saved key into the new Registry.
Scavenging the Database
The WINS database contains both active and inactive records. Over time,
this database can grow very large, with many of the entries no longer

being used. In order to clean up the “garbage” in the database, the WINS
server goes through a periodic scavenging process. When the database is
scavenged, obsolete records are removed; this shrinks the size of the file.
The advantage is that smaller WINS databases can be searched more
quickly and will improve WINS record registrations and queries.
WINS will automatically scavenge and remove tombstoned records
based on the intervals set in the WINS server Properties sheet. If a WINS
client fails to renew its record during the period of time called the “renew-
al interval,” the record is marked as inactive. The record will remain in
the inactive state for a period called the “extinction interval.” If the record
is not updated during the extinction interval, it will be tombstoned. The
record remains in the tombstoned state for a period called the “extinction
timeout.” After the extinction timeout passes, the record will be automati-
cally scavenged from the database (will be deleted).
After the records are removed, you may be surprised to find that the
database is still about the same size. This is because empty fields are still
represented in the database. You must compact the database to regain
disk space and speed database searches.
If you choose to manually compact the database, be sure to stop the
WINS server first. You can stop the WINS server by opening a command
prompt and typing net stop wins, or from the WINS console by right-
clicking your WINS server in the left pane, tracing down to All Tasks, and
then tracing over and clicking Stop. Then restart the WINS server after
compacting by clicking Start at the same location you clicked Stop. Or,
from the command prompt, type net start wins.
Interactions with DNS Servers
As discussed earlier, you can configure DNS servers to resolve NetBIOS
names to IP addresses. Configuring a DNS server to do this is simple.
WINS will automatically compact the database when the WINS server is not
in use. If the database size reaches a size of more than about 40MB, you

should manually compact the database using the jetpack.exe command
from the command prompt.
TIP
91_tcpip_06.qx 2/25/00 1:01 PM Page 290
Troubleshooting Windows 2000 NetBIOS Name Resolution Problems • Chapter 6 291
TIP
Figure 6.17 The WINS tab in the forward lookup zone Properties dialog box.
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, do the
following:
■
At the command prompt, type net stop wins and press ENTER.
■
Change to the %systemroot%\system32\wins directory.
■
Type jetpack wins.mdb tmp.mdb.
■
The jetpack engine will inform you that the process has completed
successfully.
■
Restart the WINS service by typing net start wins at the command
prompt.
Configuring the DNS Server to Use WINS Forward Lookup
Open the DNS management console, and right-click one of your forward
lookup zones. Note here that in order to enable a DNS server to do a WINS for-
ward lookup, you must have at least one forward lookup zone enabled. After
right-clicking one of the forward lookup zones, click Properties and then click
the WINS tab. You will see a dialog box like the one in Figure 6.17.
After you’ve put a check mark in the “Use WINS forward lookup” and

entered an IP address in the “IP address” box, the DNS server will search
for NetBIOS name and IP address mappings at a WINS server.
However, it’s not always quite as simple as that. You might wonder
how the DNS server knows that you are searching for a NetBIOS name.
And how does it know when it’s time to check the WINS server database
91_tcpip_06.qx 2/25/00 1:01 PM Page 291
292 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems
to resolve a NetBIOS name? Does the DNS server just strip off everything
to the right of the leftmost period in a fully qualified domain name
(FQDN), and send what’s left to the WINS server? Does it send every
unqualified name to a WINS server directly?
Wow, those are good questions. To answer them, we need to get a bet-
ter idea of how DNS clients send queries to a DNS server, and what kind
of information is sent to the DNS server from the DNS client when it
sends a DNS query.
Examining DNS Configuration Settings
Open the TCP/IP Properties sheet, and click ADVANCED as you did earlier
in the chapter. Click the DNS tab. You will see a dialog box like the one
that appears in Figure 6.18.
Figure 6.18 The DNS tab in the Advanced TCP/IP Settings Properties sheet.
The DNS server addresses section is straightforward: Those are the IP
addresses that DNS queries are sent to. The top one is the first DNS serv-
er to be queried, and if it returns a “host not found” message, the next
DNS server will be queried. Those other settings have been somewhat of a
91_tcpip_06.qx 2/25/00 1:01 PM Page 292
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 button that says “Append primary and connection specific
DNS suffixes” causes a DNS query for an unqualified DNS request to
automatically append the machine’s domain membership and a connec-
tion-specific domain membership to the request.
For example, if my machine belongs to the tacteam.net domain, and I
type http://blah in my browser’s address box, this represents an unqual-
ified domain name, because no domain suffix is included in the request.
Since DNS servers need to know what zone database to check, you must
include a domain name in the request. My machine belongs to the
tacteam.net domain, so the request issued to the DNS server is actually
for blah.tacteam.net, and the DNS server will attempt to resolve that
name first. (If I had included another domain name in the “DNS suffix for
this connection:” text box, it would send another query for blah.<connec-
tion_specific_domain>.)
Each network interface card (NIC) can be assigned its own domain
suffix to send that is independent of the machine’s domain member-
ship.
Determining Domain Membership
How do you know your machine’s domain membership? Right-click on
My Computer, click Properties, then click the Network Identification
tab. You will see something similar to the dialog box shown in
Figure 6.19.
All right, now that we’ve got all that down, let’s look at another
unqualified DNS query. This time, we’ll type http://DAEDALUS into the
Web browser’s address box. The DNS query is sent to the Preferred DNS
server as daedalus.tacteam.net. The tacteam.net domain does not contain
a resource record for a computer named DAEDALUS, so it strips off
everything to the right of the leftmost period in the FQDN and only sends
the host name portion to the WINS server. The WINS server will check for

“DAEDALUS” in its database, and if a NetBIOS mapping exists, it is
returned to the DNS server. The DNS server then returns the IP address
to my computer, and the http request is made to that IP address.
91_tcpip_06.qx 2/25/00 1:01 PM Page 293
294 Chapter 6 • Troubleshooting Windows 2000 NetBIOS Name Resolution Problems
Problems with Heterogeneous DNS Environments
If you are running a mixed DNS environment that includes both Microsoft
and non-Microsoft servers, you might have trouble with zone database
replication between a Microsoft Primary DNS server and non-Microsoft
Secondary DNS servers if the “Do not replicate this record” check box is
not marked. Non-Microsoft DNS servers won’t know what to do with the
WINS-enabled zone, and may reject it. So, if you have a mixed DNS envi-
ronment, you must leave that box checked, and not allow WINS lookups
for the zone.
The way around this problem is to create a zone dedicated for WINS
lookups. For example, if we were running a mixed DNS environment here,
I would create a wins.tacteam.net zone, and then I would configure the
clients (either manually or using DHCP) to append the wins.tacteam.net
domain suffix to their DNS queries by including it in the DNS suffix
search order. Here’s how it works:
You type the name http://EXETER into your Web browser. The
wins.tacteam.net domain suffix is appended to the DNS query. When the
DNS server receives the query, it will look for a resource record in the
wins.tacteam.net zone database. It won’t find one, because we will not
include any host records in that zone.
Figure 6.19 The Network Identification tab in the System Properties dialog box.
91_tcpip_06.qx 2/25/00 1:01 PM Page 294