Nội dung Text: Windows Server 2008 Inside Out- P18

Troubleshooting the DNS Server Service 817
Section/Entry (Command) Description Example/Accepted Values
fAutoCacheUpdate Indicates how server caching 0; default, saves all responses
(/secureresponses) works. to name queries to cache.
1; saves only records in same
DNS subtree to cache.
fSlave (/isslave) Determines how the DNS 0; default, recursion is
server responds when enabled. If the forwarder
forwarded queries receive no does not respond, the server
response. attempts to resolve the query
itself using recursion.
1; recursion is disabled. If the
forwarder does not respond,
the server terminates the
search and sends a failure
message to the resolver.
fNoRecursion Indicates whether the server 0; default, DNS server
(/norecursion) performs recursive name performs if requested.
resolution. 1; DNS server doesn’t perform
recursion.
fRoundRobin (/roundrobin) Indicates whether server 1; default, automatically load
allows round robin load balances using round robin
balancing when there are for any hosts with multiple A
multiple A records for hosts. records.
0; disables round robin.
fStrictFileParsing Indicates server behavior 0; default, continues to load,
(/strictﬁleparsing) when it encounters bad logs error.
records. 1; stops loading DNS ﬁle and
logs error.
fBindSecondaries Indicates the zone transfer 1; default, for pre-BIND 4.9.4
(/bindsecondaries) format for secondaries. compatibility.
By default, DNS server is 0; enables compression and
conﬁgured for compatibility multiple transfers on Windows
with other DNS server types. secondaries and others with
BIND 4.9.4 or later.
fWriteAuthorityNs Indicates whether the 0; default, writes for referrals
(/writeauthorityns) server writes NS records in only.
the authority section of a 1; writes for all successful
response. authoritative responses.
fLocalNetPriority Determines the order in 1; returns records with similar
(/localnetpriority) which host records are IP addresses ﬁrst.
returned when there are 0; returns records in the order
multiple host records for the in which they are in DNS.
Chapter 24
same name.

818 Chapter 24 Implementing and Managing DNS
Section/Entry (Command) Description Example/Accepted Values
Aging Conﬁguration
ScavengingInterval Indicates the number of 0x0; scavenging is disabled.
(/scavenginginterval) hours between scavenging
intervals.
DefaultAgingState Indicates whether scavenging 0; default, scavenging is
(/defaultagingstate) is enabled by default in new disabled.
zones. 1; scavenging is enabled.
DefaultRefreshInterval Indicates the default refresh 168 (set in hexadecimal)
(/defaultrefreshinterval) interval in hours.
DefaultNoRefreshInterval Indicates the default no- 168 (set in hexadecimal)
(/defaultnorefreshinterval) refresh interval in hours.
ServerAddresses
Addr Count The number of IP addresses 1
conﬁgured on the server and Addr[0] => 192.168.1.50
the IP address used.
ListenAddresses
Addr Count The number and value of 1
IP addresses conﬁgured for Addr[0] => 192.168.1.50
listening for requests from
clients. NULL IP Array when
there are no speciﬁc IP
addresses that are designated
for listening for requests
from clients.
Forwarders
Addr Count The number and value 1
of IP addresses of servers Addr[0] => 192.168.12.8
conﬁgured as forwarders.
NULL IP Array when there are
no forwarders.
Forward timeout Timeout for queries to 3
(/forwardingtimeout) forwarders in seconds.
Slave Indicates whether recursion is 0; recursion is enabled
enabled. 1; recursion is disabled
Another useful command for troubleshooting a DNS server is Dnscmd /Statistics. This
command shows you the following information:
DNS server time statistics, including server start time, seconds since start, and
Chapter 24
stats of last cleared date and time
Details on queries and responses, including total queries received, total
responses sent; the number of UDP queries received and sent, UDP responses

Troubleshooting the DNS Server Service 819
received and sent; and the number of TCP queries received and sent, TCP
responses received and sent
Details on queries by record, including the exact number of each type of record
sent
Details on failures and where they occurred, including recursion failures, retry
limits reached, and partial answers received
Details on the total number of dynamic updates, the status for each update type;
later breakdowns on number and status of secure updates, the number of updates
that were forwarded, and the types of records updated
Details on the amount of memory used by DNS, including total amount of mem-
ory used, standard allocations, and allocations from standard to the heap
Save the Stats to a File
Write the output of Dnscmd /Statistics to a ﬁle so that you don’t overﬂow the history
buffer in the command prompt. This also allows you to go through the stats at your
leisure. Type dnscmd ServerName /statistics > FileName, where ServerName is the
name or IP address of the DNS server and FileName is the name of the ﬁle to use, such as
dnscmd corpsvr02 /statistics > dns-stats.txt.
Examine Zones and Zone Records
Dnscmd provides several useful commands for helping you pinpoint problems with
records. To get started, list the available zones by typing dnscmd ServerName /enum-
zones, where ServerName is the name or IP address of the DNS server you want to
check. The output shows a list of the zones that are conﬁgured as follows:
Enumerated zone list:
Zone count = 4
Zone name Type Storage Properties
. Cache File
_msdcs.cpandl.com Primary AD-Forest Secure
1.168.192.in-addr.arpa Primary AD-Legacy Secure Rev
cpandl.com Primary AD-Domain Secure Aging
Chapter 24
The zone names you can work with are listed in the ﬁ rst column. The other values tell
you the type of zone and the way it is conﬁgured as summarized in Table 24-2.

820 Chapter 24 Implementing and Managing DNS
Table 24-2 Zone Entries and Their Meanings
Column/Entry Description
Type
Cache A cache zone (server cache).
Primary A primary zone.
Secondary A secondary zone.
Stub A stub zone.
Storage
AD-Forest Active Directory–integrated with forest-wide replication scope.
AD-Legacy Active Directory–integrated with legacy replication scope to all
domain controllers in the domain.
AD-Domain Active Directory–integrated with domain-wide replication scope.
File Indicates the zone data is stored in a ﬁle.
Properties
Secure Zone allows secure dynamic updates only and is a forward lookup
zone.
Secure Rev Zone allows secure dynamic updates only and is a reverse lookup
zone.
Secure Aging Zone allows secure dynamic updates only and is conﬁgured for
scavenging/aging.
Aging Zone is conﬁgured for scavenging/aging but isn’t conﬁgured for
dynamic updates.
Update Zone is a forward lookup zone conﬁgured to allow both secure and
nonsecure dynamic updates.
Update Rev Zone is a reverse lookup zone conﬁgured to allow both secure and
nonsecure dynamic updates.
Down Secondary or stub zone hasn’t received a zone transfer since startup.
After you examine the settings for zones on the server, you can print out the zone
records of a suspect zone by typing dnscmd ServerName /zoneprint ZoneName at the
command prompt, where ServerName is the name or IP address of the DNS server and
ZoneName is the name of the zone as reported previously.
Consider the following example:
dnscmd corpsvr02 /zoneprint cpandl.com
Chapter 24

CHAPTER 25
Implementing and Maintaining WINS
WINS Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823 Configuring and Maintaining WINS . . . . . . . . . . . . . . . . 832
Setting Up WINS Servers . . . . . . . . . . . . . . . . . . . . . . . . 826 Enabling WINS Lookups Through DNS . . . . . . . . . . . . . 839
Configuring Replication Partners . . . . . . . . . . . . . . . . . . 828
W indows Internet Naming Service (WINS) enables computers to register and
resolve NetBIOS names on IPv4 networks. WINS is not used with IPv6 net-
works. WINS is maintained primarily for backward support and compatibility with
legacy applications and early versions of Microsoft Windows, including Windows 95,
Windows 98, and Windows NT, that used WINS for computer name resolution; or
for networks running Windows 2000 or Windows Server 2003 that don’t have Active
Directory deployed and thus don’t require DNS. On most large networks, WINS is
needed to support legacy applications and computers running Windows 95, Windows
98, and Windows NT.
If you are setting up a new network, you probably don’t need WINS. On an existing
network running all Windows 2000, Windows XP, and Windows Server 2008 systems,
only the Domain Name System (DNS) is needed because these computers rely exclu-
sively on DNS for name resolution if Active Directory is deployed. Because WINS is not
required, WINS support could be removed from the network. Doing so, however, would
mean that legacy applications and services that rely on NetBIOS, such as the computer
Browser service, would no longer function.
WINS Essentials
Like DNS, WINS is a client/server protocol. All Windows servers have a WINS service
that can be installed to provide WINS services on the network. All Windows computers
have a WINS client that is installed automatically. The Workstation and Server services
on computers are used to specify resources that are available, such as ﬁle shares. These
resources have NetBIOS names as well.
NetBIOS Namespace and Scope
WINS architecture is very different from DNS. Unlike DNS, WINS has a ﬂat namespace
and doesn’t use a hierarchy or tree. Each computer or resource on a Windows network
has a NetBIOS name, which can be up to 15 characters long. This name must be unique
on the network—no other computer or resource can have the same name. Although
there are no extensions to this name per se that indicate a domain, a NetBIOS scope
can be set in Dynamic Host Conﬁguration Protocol (DHCP).
823

824 Chapter 25 Implementing and Maintaining WINS
The NetBIOS scope is a hidden 16th character (sufﬁ x) for the NetBIOS name. It is
used to limit the scope of communications for WINS clients. Only WINS clients with
Chapter 25
the same NetBIOS scope can communicate with each other. See “Conﬁguring TCP/IP
Options” on page 717 for details on setting the NetBIOS scope for computers that use
DHCP.
NetBIOS Node Types
The way WINS works on a network is determined by the node type set for a client.
The node type deﬁ nes how name services work. WINS clients can be one of four node
types:
B-Node (Broadcast Node) Broadcast messages are used to register and resolve
names. Computers that need to resolve a name broadcast a message to every host
on the local network, requesting the IP address for a computer name. Best for
small networks.
P-Node (Peer-to-Peer Node) WINS servers are used to register and resolve com-
puter names to Internet Protocol (IP) addresses. Computers that need to resolve
a name send a query message to the server and the server responds. Best if you
want to eliminate broadcasts. In some cases, however, resources might not be
seen as available if the WINS server isn’t updated by the computer providing the
resources.
M-Node (Mixed Node) A combination of B-Node and P-Node. WINS clients ﬁrst
try to use broadcasts for name resolution. If this fails, the clients then try using a
WINS server. Still means a lot of broadcast trafﬁc.
H-Node (Hybrid Node) A combination of B-Node and P-Node. WINS clients ﬁrst
try to use a WINS server for name resolution. If this fails, the clients then try
broadcasts for name resolution. Best for most networks that use WINS servers
because it reduces broadcast trafﬁc.
Small Networks Might Not Need a WINS Server
On a small network without subnets and a limited number of computers, WINS clients
can rely on broadcasts for name resolution. In this case, it isn’t necessary to set up a
WINS server.
WINS Name Registration and Cache
WINS maintains a database of name to IP address mappings automatically. Whenever
a computer or resource becomes available, it registers itself with the WINS server to
tell the server the name and IP address it is using. As long as no other computer or
resource on the network is using that name, the WINS server accepts the request and
registers the computer or resource in its database.

WINS Essentials 825
Name registration isn’t permanent. Each name that is registered has a lease period
associated with it, which is called its Time to Live (TTL). A WINS client must reregister
Chapter 25
its name before the lease expires and attempts to do so when 50 percent of the lease
period has elapsed or when it is restarted. If a WINS client doesn’t reregister its name,
the lease expires and is marked for deletion from the WINS database. During normal
shutdown, a WINS client will send a message to the WINS server requesting release of
the registration. The WINS server then marks the record for deletion. Whenever records
are marked for deletion, they are said to be tombstoned.
As with DNS clients, WINS clients maintain a cache of NetBIOS names that have
been looked up. The WINS cache, however, is designed to hold only names looked up
recently. By default, names are cached for up to 10 minutes and the cache is limited to
16 names. You can view entries in the NetBIOS cache by typing nbtstat -c at the com-
mand prompt.
WINS Implementation Details
On most networks that use WINS, you’ll want to conﬁgure at least two WINS servers
for name resolution. When there are multiple WINS servers, you can conﬁgure replica-
tion of database entries between the servers. Replication allows for fault tolerance and
load balancing by ensuring that entries in one server’s database are replicated to its
replication partners. These replication partners can then handle renewal and release
requests from clients as if they held the primary registration in the ﬁrst place.
WINS supports:
Persistent connections In a standard conﬁguration, replication partners establish
and release connections each time they replicate WINS database changes. With
persistent connections, replication partners can be conﬁgured to maintain a per-
sistent connection. This reduces the overhead associated with opening and clos-
ing connections and speeds up the replication process.
Automatic replication partners Using automatic replication partners, WINS can
automatically conﬁgure itself for replication with other WINS servers. To do this,
WINS sends periodic multicast messages to announce its availability. These mes-
sages are addressed to the WINS multicast group address (224.0.1.24), and any
other WINS servers on the network that are listening for datagrams sent on this
group address can receive and process the automatic replication request. After
replication is set up with multicast partners, the partners use standard replication
with either persistent or nonpersistent connections.
Manual tombstoning Manual tombstoning allows administrators to mark records
for deletion. A record marked for deletion is said to be tombstoned. This state is
then replicated to a WINS server’s replication partners, which prevents the record
from being re-created on a replication partner and then being replicated back to
the original server on which it was marked for deletion.
Record export The record export feature allows administrators to export the
entries in the WINS database to a ﬁle that can be used for tracking or reporting
on which clients are using WINS.

826 Chapter 25 Implementing and Maintaining WINS
Setting Up WINS Servers
Chapter 25
To make a computer running Windows Server 2008 into a WINS server, you must
install the WINS service. This service doesn’t require a dedicated server and uses lim-
ited resources in most cases. This means you could install the WINS service on a DNS
server, DHCP server, or domain controller. The only key requirement is that the WINS
service can be installed only on a computer with a static IPv4 address. Although you
can install WINS on a server with multiple IPv4 address or multiple network interfaces,
this isn’t recommended because the server might not be able to replicate properly with
its replication partners. In most cases, you won’t want to conﬁgure a domain controller
as a WINS server.
You can install the WINS service by following these steps:
1. In Server Manager, select the Features node in the left pane and then click Add
Features. This starts the Add Features Wizard.
2. On the Select Features page, select WINS Server and then click Next.
3. Click Install. When the wizard ﬁnishes installing the WINS service, click Close.
After you install the WINS service, the WINS console is available on the Administra-
tive Tools menu. Start the console by clicking Start, Administrative Tools, WINS. Then,
select the WINS server you are working with to see its entries, as shown in Figure 25-1.
Figure 25-1 The WINS console.
The only key postinstallation task for the WINS service is to conﬁgure replication part-
ners. However, you should check the Transmission Control Protocol/Internet Protocol
(TCP/IP) conﬁguration of the WINS server. It should have only itself listed as the WINS
server to use and shouldn’t have a secondary WINS server. This prevents the WINS
client on the server from registering itself with a different WINS database, which can
cause problems.
To set the server’s primary WINS server address to its own IP address and clear out any
secondaries from the list, click Start and then click Network. In Network Explorer, click
Network And Sharing Center on the toolbar. In Network And Sharing Center, click
Manage Network Connections. In Network Connections, right-click the connection you

Setting Up WINS Servers 827
want to work with and then select Properties. In the Properties dialog box, open the
Internet Protocol (TCP/IP) Properties dialog box by double-clicking Internet Protocol
Chapter 25
Version 4 (TCP/IPv4). Click Advanced to display the Advanced TCP/IP Settings dialog
box, and then click the WINS tab. Set the WINS server’s IP address as the WINS server
to use and remove any additional WINS server addresses. When you’re ﬁ nished, click
OK twice and then click Close.
You can remotely manage and conﬁgure WINS. Simply start the WINS console, right-
click the WINS node in the left pane, and select Add Server. In the Add Server dialog
box, select WINS Server, type the name or IP address of the WINS server, and then
click OK.
The command-line counterpart to the WINS console is Netsh WINS. From the com-
mand prompt on a computer running Windows Server 2008, you can use Netsh WINS
to perform all the tasks available in the WINS console as well as to perform some addi-
tional tasks that can’t be performed in the WINS console. To start Netsh WINS and
access a particular WINS server, follow these steps:
1. Start a command prompt, and then type netsh to start Netsh. The command
prompt changes to netsh>.
2. Access the WINS context within Netsh by typing wins. The command prompt
changes to netsh wins>.
3. Type server followed by the Universal Naming Convention (UNC) name or IP
address of the WINS server, such as \\wins2 or \\10.10.15.2. If the WINS server
is in a different domain from your logon domain, you should type the fully
qualiﬁed domain name (FQDN) of the server, such as \\wins2.cpandl.com.
4. The command prompt changes to netsh wins server>. You can now work with the
selected server. If you later want to work with a different server, you can do this
without having to start over. Simply type server followed by the UNC name or IP
address of that server.
Note
Technically, you don’t need to type the double backslashes (\\) when you specify an IP
address. You must, however, type \\ when you specify a server’s name or FQDN. Because
\
of this discrepancy, you might want to use \\ all the time so that you won’t leave it out by
accident when you need it.

828 Chapter 25 Implementing and Maintaining WINS
TROUBLESHOOTING
Resolving WINS replication errors
Chapter 25
Most WINS replication errors involve incorrectly conﬁgured WINS servers. If you see
replication errors in the event logs, check the TCP/IP conﬁguration of your WINS serv-
ers. Every WINS server in the organization should be conﬁgured as its own primary
WINS server, and you should delete any secondary WINS server addresses. This ensures
that WINS servers register their NetBIOS names only in their own WINS databases. If
you don’t conﬁgure WINS in this way, WINS servers might register their names with
other WINS servers. This can result in different WINS servers owning the NetBIOS
names that a particular WINS server registers and, ultimately, to problems with WINS
itself. For more information on this issue, see Microsoft Knowledge Base article 321208
(http://support.microsoft.com/default.aspx?scid=kb;en-us;321208).
Conﬁguring Replication Partners
When you have two or more WINS servers on a network, you should conﬁgure replica-
tion between them. When servers replicate database entries with each other, they are
said to be replication partners.
Replication Essentials
There are two replication roles for WINS servers:
Push partner A push partner is a replication partner that notiﬁes other WINS
servers that updates are available.
Pull partner A pull partner is a replication partner that requests updates.
By default, all WINS servers have replication enabled and replication partners are con-
ﬁgured to use both push and pull replication. After a replication partner notiﬁes a part-
ner that there are changes using push replication, the partner can request the changes
using pull replication. This pulls the changes down to its WINS database. In addition,
all replication is done using persistent connections by default to increase efﬁciency.
Because replication is automatically enabled and conﬁgured, all you have to do to start
replication is tell each WINS server about the other WINS servers that are available.
On a small network, you can do this using the automatic replication partners feature.
Because this can cause a lot of broadcast trafﬁc on medium or large networks that con-
tain many clients and servers, you’ll probably want to designate speciﬁc replication
partners to reduce broadcast trafﬁc.

Configuring Replication Partners 829
Conﬁguring Automatic Replication Partners
To conﬁgure automatic replication partners, follow these steps:
Chapter 25
1. Start the WINS console. Right-click the WINS node in the left pane, and select
Add Server. In the Add Server dialog box, select WINS Server, type the name or IP
address of the WINS server, and then click OK.
2. Expand the server entry, right-click the Replication Partners entry in the left
pane, and then select Properties. In the Replication Partners Properties dialog
box, click the Advanced tab, as shown in Figure 25-2.
Figure 25-2 Enable automatic replication.
3. Select the Enable Automatic Partner Conﬁguration check box.
4. Use the Multicast Interval options to set the interval between multicast
broadcasts to the WINS server group address. These broadcasts are used to tell
other WINS servers about the availability of the server you are conﬁguring. The
default interval is 0 minutes, which disables WINS broadcasts.
Registrations Remain Until Restart
After a server is discovered and added as a partner through multicasting, the server
remains as a conﬁgured partner until you restart the WINS service or until you restart the
server. When WINS is shut down properly, part of the shutdown process is to send mes-
sages to current replication partners and remove its registration.

830 Chapter 25 Implementing and Maintaining WINS
5. Use the Multicast Time To Live (TTL) combo box to specify how many links
multicast broadcasts can go through before being discarded. The default is 2,
Chapter 25
which would allow the broadcasts to be relayed through two routers.
6. Click OK.
Multicast Through Routers Is Possible
The Multicast TTL is used to allow the discovery broadcasts to be routed between sub-
nets. This means you could use automatic replication partners on networks with subnets.
However, routing isn’t automatic just because a datagram has a TTL. You must conﬁgure
the routers on each subnet to forward multicast trafﬁc received from the WINS multicast
group address (224.0.1.24).
Using Designated Replication Partners
To designate speciﬁc replication partners, start the WINS console. Right-click the WINS
node in the left pane, and select Add Server. In the Add Server dialog box, select WINS
Server, type the name or IP address of the WINS server, and then click OK.
Right-click the Replication Partners entry in the left pane, and select New Replication
Partners. In the New Replication Partner dialog box, type the name or IP address of the
WINS server that should be used as a replication partner, and then click OK. The repli-
cation partner is added and listed as available in the WINS console. As shown in Figure
25-3, replication partners are listed by server name, IP address, and replication type.
Figure 25-3 View replication partners in the WINS console.
By default, the replication partner is conﬁgured to use both push and pull replication
as well as persistent connections. After you conﬁgure a replication partner, the conﬁgu-
ration is permanent. If you restart a server, you do not need to reconﬁgure replication
partners.
To view or change the replication settings for a replication partner, start the WINS
console. Expand the server entry for the server you want to work with, and then select
the Replication Partners entry in the left pane. Double-click the replication partner in

Configuring Replication Partners 831
the details pane. This displays the replication partner’s Properties dialog box. Click the
Advanced tab, as shown in Figure 25-4.
Chapter 25
Figure 25-4 Configure replication partner settings.
The conﬁguration options are used as follows:
Replication Partner Type—Sets the replication type as push, pull, or push/pull.
Pull Replication
Use Persistent Connection For Replication—Conﬁgures pull replication so a
persistent connection is used. This reduces the time spent opening and
closing connections and improves performance.
Start Time—Sets the hour of the day when replication should begin using a
24-hour clock.
Replication Interval—Sets the frequency of replication. The default is every 30
minutes.
Push Replication
Use Persistent Connection For Replication—Conﬁgures push replication so a
persistent connection is used. This reduces the time spent opening and
closing connections and improves performance.
Number Of Changes In Version ID Before Replication—Can be used to limit rep-
lication by allowing replication to occur only when a set number of changes
have occurred in the local WINS database.

832 Chapter 25 Implementing and Maintaining WINS
Note
Chapter 25
By default Number Of Changes In Version ID Before Replication is set to 0, which allows
replication at the designated interval whenever there are changes. If you set a speciﬁc
value, that many changes must occur before replication takes place.
Conﬁguring and Maintaining WINS
WINS is fairly easy to conﬁgure and maintain after you set it up and replication part-
ners are conﬁgured. The key conﬁguration and maintenance tasks are related to the
following issues:
Conﬁguring burst handling as the network grows
Checking server status and conﬁguration
Checking active registrations and scavenging records if necessary
Maintaining the WINS database
Conﬁguring Burst Handling
If you conﬁgured the WINS server on a network with more than 100 clients, you should
enable burst handling of registrations. As your network grows, you should change the
burst-handling sessions as appropriate for the number of clients on the network. To
conﬁgure burst handling of registration and name refresh requests, start the WINS con-
sole. Right-click the server entry in the WINS console, and then select Properties. In the
Properties dialog box, click the Advanced tab, as shown in Figure 25-5.
Select the Enable Burst Handling check box, and then select a burst-handling setting.
The settings available are the following:
Low for handling up to 300 registration and name refresh requests
Medium for handling up to 500 registration and name refresh requests
High for handling up to 1,000 registration and name refresh requests

Configuring and Maintaining WINS 833
Set a Custom Threshold for Burst Handling
Chapter 25
You can also set a custom threshold value for burst handling. To do this, select Custom
and then enter a threshold value between 50 and 5,000. For example, if you set the
threshold to 5,000, up to 5,000 requests could be queued at once. Keep in mind that
you would do this only if your network environment needs this setting. If you set the
value to 5,000 but only need a queue that allows up to 100 name registration requests,
you would waste a lot of server resources maintaining a very large queue that you don’t
need.
Figure 25-5 Set burst handling for medium and large networks.
Checking Server Status and Conﬁguration
Using the WINS console, you can do the following:
View the status of all WINS servers on the network by clicking the Server Status
entry in the left pane. The status of the servers is then displayed in the right pane.
View the current replication partners for a server by expanding the server entry
and selecting Replication Partners in the left pane. The replication partners for
that server are displayed in the right pane.
View server statistics for startup, replication, queries, releases, registrations, and
replication partners by right-clicking the server entry in the left pane and select-
ing Display Server Statistics.

834 Chapter 25 Implementing and Maintaining WINS
Using Netsh WINS, you can view server statistics by typing the command
netsh wins server ServerName show statistics
Chapter 25
where ServerName is the name or IP address of the WINS server you want to work with,
such as \\WINS02 or 10.10.12.15. An example of the statistics follows:
***You have Read and Write access to the server corpsvr02.cpandl.com***
WINS Started : 3/10/2008 at 14:46:1
Last initialization : 3/12/2008 at 02:14:12
Last planned scavenging : 3/19/2008 at 12:30:25
Last admin triggered scavenging : 3/10/2008 at 16:52:24
Last replicas tombstones scavenging : 3/21/2008 at 09:12:26
Last replicas veriﬁcation scavenging : 3/23/2008 at 12:38:9
Last planned replication : 3/10/2008 at 16:20:39
Last admin triggered replication : 3/27/2008 at 08:27:30
Last reset of counter : 4/01/2008 at 18:23:45
Counter Information :
No of U and G Registration requests = (250 222)
No of Successful/Failed Queries = (812/67)
No of U and G Refreshes = (213 144)
No of Successful/Failed Releases = (68/12)
No of U. and G. Conﬂicts = (12 10)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WINS Partner IP Address -No. of Replication -No. of Comm Failure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
192.168.15.18 - 153 - 2
These statistics are useful for troubleshooting registration and replication problems.
Scavenging and replication are automatic once conﬁgured. Problems to look for include
the following:
Replication If there are problems with replication, you should see a high number
of communication failures relative to the number of replications. Check the links
over which replication is occurring to see if there are intermittent failures or
times when links aren’t available.
Name resolution If WINS clients are having problems with name resolution,
you’ll see a high number of failed queries. You might need to scavenge the data-
base for old records more frequently. Check the server statistics for the renew
interval, extinction interval, extinction timeout, and veriﬁcation interval or the
Intervals tab in the server’s Properties dialog box.
Registration release If WINS clients aren’t releasing registrations properly, you’ll
see a high number of failed releases. Clients might not be getting shut down
properly.

Configuring and Maintaining WINS 835
You can view the conﬁguration details for a WINS server by typing the command
netsh wins server ServerName show info
Chapter 25
where ServerName is the name or IP address of the WINS server. The output looks
like this:
WINS Database backup parameter
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Backup Dir :
Backup on Shutdown : Disabled
Name Record Settings(day:hour:minute)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Refresh Interval : 006:00:00
Extinction(Tombstone) Interval : 004:00:00
Extinction(Tombstone) TimeOut : 006:00:00
Veriﬁcation Interval : 024:00:00
Database consistency checking parameters :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Periodic Checking : Disabled
WINS Logging Parameters:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Log Database changes to JET log ﬁles : Enabled
Log details events to System Event Log : Enabled
Burst Handling Parameters :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Burst Handling State : Enabled
Burst handling queue size : 500
Checking Active Registrations and Scavenging Records
Using the WINS console, you can view the active registrations in the WINS database
by expanding the server entry, right-clicking Active Registrations, and choosing Dis-
play Records. In the Display Records dialog box, click Find Now without making any
selections to see all the available records or use the ﬁlter options to specify the types of
records you want to view, and then click Find Now. To tombstone a record manually,
right-click it, and then select Delete. This deletes it from the current server, and this
deletion is then replicated to other WINS servers; that is, the record will be replicated
marked as Tombstoned.
Netsh provides many ways to examine records in the WINS database. Because this is
something you won’t use that frequently, the easiest way to do it is to list all available

836 Chapter 25 Implementing and Maintaining WINS
records and write the information to a ﬁle that you can search. To do this, type the
command
Chapter 25
netsh wins server ServerName show database Servers={}
where ServerName is the name or IP address of the WINS server. The output shows you
the registration entries in the database as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NAME -T-S-VERSION -G- IPADDRESS - EXPIRATION DATE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Retrieving database from the Wins server 192.168.1.50
CPANDL [1Bh]-D-A- 2 -U- 192.168.1.50 -3/25/2008 2:46:01 PM
CORPSVR02 [00h]-D-A- 7 -U- 192.168.1.50 -3/25/2008 2:46:01 PM
CORPSVR02 [20h]-D-A- 6 -U- 192.168.1.50 -3/25/2008 2:46:01 PM
CPANDL [00h]-D-A- 4 -N- 192.168.1.50 -3/25/2008 2:46:01 PM
CPANDL [1Ch]-D-A- 3 -I- 192.168.1.50 -3/25/2008 2:46:01 PM
CPANDL [1Eh]-D-A- 1 -N- 192.168.1.50 -3/25/2008 2:46:01 PM
WINS automatically scavenges the database to mark old records for deletion. To see
when this is done, check the server statistics for the renew interval, extinction interval,
extinction timeout, and veriﬁcation interval on the Intervals tab in the server’s Proper-
ties dialog box.
You can initiate scavenging (referred to as an admin-triggered scavenging in the server
statistics) by right-clicking the server entry in the WINS console and selecting Scav-
enge Database. To initiate scavenging at the command prompt, type netsh wins server
ServerName init scavenge, where ServerName is the name or IP address of the WINS
server.
After scavenging, the renew interval, extinction interval, extinction timeout, and veriﬁ-
cation interval are used to mark each record as follows:
If the renew interval has not expired, the record remains marked as Active.
If the renew interval has expired, the record is marked as Released.
If the extinction interval has expired, the record is marked as Tombstoned.
If the record was tombstoned, it is deleted from the database. If the record is active and
was replicated from another server but the veriﬁcation interval has expired, the record
is revalidated.
Maintaining the WINS Database
The WINS database, like any database, should be maintained. You should routinely per-
form the following maintenance operations:
Verify the database consistency
Compact the database
Back up the database