Section/Entry (Command) Description Example/Accepted Values
fAutoCacheUpdate
(/secureresponses)
Indicates how server caching
works.
0; default, saves all responses
to name queries to cache.
1; saves only records in same
DNS subtree to cache.
fSlave (/isslave) Determines how the DNS
server responds when
forwarded queries receive no
response.
0; default, recursion is
enabled. If the forwarder
does not respond, the server
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
(/norecursion)
Indicates whether the server
performs recursive name
resolution.
0; default, DNS server
performs if requested.
1; DNS server doesn’t perform

recursion.
fRoundRobin (/roundrobin) Indicates whether server
allows round robin load
balancing when there are
multiple A records for hosts.
1; default, automatically load
balances using round robin
for any hosts with multiple A
records.
0; disables round robin.
fStrictFileParsing
(/strictfi leparsing)
Indicates server behavior
when it encounters bad
records.
0; default, continues to load,
logs error.
1; stops loading DNS fi le and
logs error.
fBindSecondaries
(/bindsecondaries)
Indicates the zone transfer
format for secondaries.
By default, DNS server is
confi gured for compatibility
with other DNS server types.
1; default, for pre-BIND 4.9.4
compatibility.
0; enables compression and
multiple transfers on Windows

secondaries and others with
BIND 4.9.4 or later.
fWriteAuthorityNs
(/writeauthorityns)
Indicates whether the
server writes NS records in
the authority section of a
response.
0; default, writes for referrals
only.
1; writes for all successful
authoritative responses.
fLocalNetPriority
(/localnetpriority)
Determines the order in
which host records are
returned when there are
multiple host records for the
same name.
1; returns records with similar
IP addresses fi rst.
0; returns records in the order
in which they are in DNS.
Troubleshooting the DNS Server Service 817
Chapter 24
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Section/Entry (Command) Description Example/Accepted Values
Aging Confi guration
ScavengingInterval
(/scavenginginterval)

Indicates the number of
hours between scavenging
intervals.
0x0; scavenging is disabled.
DefaultAgingState
(/defaultagingstate)
Indicates whether scavenging
is enabled by default in new
zones.
0; default, scavenging is
disabled.
1; scavenging is enabled.
DefaultRefreshInterval
(/defaultrefreshinterval)
Indicates the default refresh
interval in hours.
168 (set in hexadecimal)
DefaultNoRefreshInterval
(/defaultnorefreshinterval)
Indicates the default no-
refresh interval in hours.
168 (set in hexadecimal)
ServerAddresses
Addr Count The number of IP addresses
confi gured on the server and
the IP address used.
1
Addr[0] => 192.168.1.50
ListenAddresses
Addr Count The number and value of

IP addresses confi gured for
listening for requests from
clients. NULL IP Array when
there are no specifi c IP
addresses that are designated
for listening for requests
from clients.
1
Addr[0] => 192.168.1.50
Forwarders
Addr Count The number and value
of IP addresses of servers
confi gured as forwarders.
NULL IP Array when there are
no forwarders.
1
Addr[0] => 192.168.12.8
Forward timeout
(/forwardingtimeout)
Timeout for queries to
forwarders in seconds.
3
Slave Indicates whether recursion is
enabled.
0; recursion is 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

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
Chapter 24
818 Chapter 24 Implementing and Managing DNS
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
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 fi le so that you don’t overfl 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 fi 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 confi 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
The zone names you can work with are listed in the fi rst column. The other values tell
you the type of zone and the way it is confi gured as summarized in Table 24-2.
Save the Stats to a File
Write the output of Dnscmd /Statistics to a fi le so that you don’t overfl 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 fi le to use, such as
dnscmd corpsvr02 /statistics > dns-stats.txt.
Troubleshooting the DNS Server Service 819
Chapter 24
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
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 fi 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 confi gured for
scavenging/aging.
Aging Zone is confi gured for scavenging/aging but isn’t confi gured for
dynamic updates.
Update Zone is a forward lookup zone confi gured to allow both secure and
nonsecure dynamic updates.
Update Rev Zone is a reverse lookup zone confi 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
820 Chapter 24 Implementing and Managing DNS
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Here, you want to examine the cpandl.com zone records on the CORPSVR02 server.
The output from this command shows the records in this zone and their settings. Here
is a partial listing:

;
; Zone: cpandl.com
; Server: corpsvr02.cpandl.com
; Time: Wed Mar 10 18:38:14 2008 UTC
;
@ [Aging:3534235] 600 A 192.168.1.50
[Aging:3534235] 3600 NS corpsvr02.cpandl.com.
3600 SOA corpsvr02.cpandl.com. hostmaster. 383 900 600 86 400 3600
3600 MX 10 exchange.cpandl.com._msdcs 3600 NS
corpsvr01.cpandl.com._gc._tcp.Default-First-Site-Name._sites
[Aging:35265] 600 SRV 0 100 3268
corpsvr02.cpandl.com._kerberos._tcp.Default-First-Site-Name._sites
[Aging:35235] 600 SRV 0 100 88
corpsvr02.cpandl.com._ldap._tcp.Default-First-Site-Name._sites
[Aging:35335] 600 SRV 0 100 389
corpsvr02.cpandl.com._gc._tcp [Aging:3534265] 600 SRV 0 100 3268
corpsvr02.cpandl.com._kerberos._tcp [Aging:3534235] 600 SRV 0 100 88
corpsvr02.cpandl.com._kpasswd._tcp [Aging:3534235] 600 SRV 0 100 464
corpsvr02.cpandl.com.corpsvr02 [Aging:3534281] 3600 A 192.168.1.50
corpsvr17 3600 A 192.168.15.22
DomainDnsZones [Aging:3534265] 600 A 192.168.1.50
_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones
[Aging:35365] 600 SRV 0 100 389
corpsvr02.cpandl.com._ldap._tcp.DomainDnsZones [Aging:3534265] 600 SRV 0 100 389
corpsvr02.cpandl.com.ForestDnsZones [Aging:3534265] 600 A 192.168.1.50
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
[Aging:35365] 600 SRV 0 100 389
corpsvr02.cpandl.com._ldap._tcp.ForestDnsZones [Aging:35365] 600 SRV 0 100 389
corpsvr02.cpandl.com.ny 3600 NS
ns1.ny.cpandl.com.ns1.ny 3600 A 10.10.10.52

www 3600 CNAME corpsvr17.cpandl.com.
As you can see from the listing, Dnscmd /Zoneprint shows all the records, even the
ones created by Active Directory. This is particularly useful because it means you don’t
have to try to navigate the many subfolders in which these SRV records are stored.
Troubleshooting the DNS Server Service 821
Chapter 24
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
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 fi 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 fl 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 Confi guration Protocol (DHCP).
WINS Essentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823
Setting Up WINS Servers . . . . . . . . . . . . . . . . . . . . . . . . 826
Configuring Replication Partners . . . . . . . . . . . . . . . . . . 828
Configuring and Maintaining WINS . . . . . . . . . . . . . . . . 832
Enabling WINS Lookups Through DNS . . . . . . . . . . . . . 839
CHAPTER 25
Implementing and Maintaining WINS
823
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
The NetBIOS scope is a hidden 16th character (suffi x) for the NetBIOS name. It is
used to limit the scope of communications for WINS clients. Only WINS clients with
the same NetBIOS scope can communicate with each other. See “Confi 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 defi 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 fi 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 traffi c.

H-Node (Hybrid Node)
A combination of B-Node and P-Node. WINS clients fi 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 traffi 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.
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.
Chapter 25
824 Chapter 25 Implementing and Maintaining WINS
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
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
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 confi gure at least two WINS servers
for name resolution. When there are multiple WINS servers, you can confi 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 fi rst place.
WINS supports:


Persistent connections
In a standard confi guration, replication partners establish
and release connections each time they replicate WINS database changes. With
persistent connections, replication partners can be confi 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 confi 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 fi le that can be used for tracking or reporting
on which clients are using WINS.
WINS Essentials 825
Chapter 25

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Setting Up WINS Servers
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 confi 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 fi 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 confi gure replication part-
ners. However, you should check the Transmission Control Protocol/Internet Protocol
(TCP/IP) confi 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

Chapter 25
826 Chapter 25 Implementing and Maintaining WINS
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
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
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 fi nished, click
OK twice and then click Close.
You can remotely manage and confi 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 \\w i n s2 or \\10 .10.1 5 . 2 . If the WINS server
is in a different domain from your logon domain, you should type the fully
qualifi ed domain name (FQDN) of the server, such as \\w i n s 2 .c p a nd l . c om .
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.
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.
Setting Up WINS Servers 827
Chapter 25
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
TROUBLESHOOTING
Resolving WINS replication errors
Most WINS replication errors involve incorrectly confi gured WINS servers. If you see
replication errors in the event logs, check the TCP/IP confi guration of your WINS serv-
ers. Every WINS server in the organization should be confi 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 confi 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
(
Confi guring Replication Partners
When you have two or more WINS servers on a network, you should confi 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 notifi 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-
fi gured to use both push and pull replication. After a replication partner notifi 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 effi ciency.
Because replication is automatically enabled and confi 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 traffi c on medium or large networks that con-
tain many clients and servers, you’ll probably want to designate specifi c replication
partners to reduce broadcast traffi c.
TROUBLESHOOTING
Chapter 25
828 Chapter 25 Implementing and Maintaining WINS
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Confi guring Automatic Replication Partners
To confi gure automatic replication partners, follow these steps:
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 Confi 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 confi 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 confi 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.
Registrations Remain Until Restart
After a server is discovered and added as a partner through multicasting, the server
remains as a confi 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.
Configuring Replication Partners 829
Chapter 25
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
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,
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 confi gure
the routers on each subnet to forward multicast traffi c received from the WINS multicast
group address (224.0.1.24).

Using Designated Replication Partners
To designate specifi 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 confi gured to use both push and pull replication
as well as persistent connections. After you confi gure a replication partner, the confi gu-
ration is permanent. If you restart a server, you do not need to reconfi 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
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 confi gure
the routers on each subnet to forward multicast traffi c received from the WINS multicast
group address (224.0.1.24).
Chapter 25
830 Chapter 25 Implementing and Maintaining WINS
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
the details pane. This displays the replication partner’s Properties dialog box. Click the
Advanced tab, as shown in Figure 25-4.
Figure 25-4 Configure replication partner settings.
The confi 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—Confi 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—Confi 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.
Configuring Replication Partners 831
Chapter 25
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Note
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 specifi c

value, that many changes must occur before replication takes place.
Confi guring and Maintaining WINS
WINS is fairly easy to confi gure and maintain after you set it up and replication part-
ners are confi gured. The key confi guration and maintenance tasks are related to the
following issues:

Confi guring burst handling as the network grows

Checking server status and confi guration

Checking active registrations and scavenging records if necessary

Maintaining the WINS database
Confi guring Burst Handling
If you confi 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
confi 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
Note
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 specifi c
value, that many changes must occur before replication takes place.
Chapter 25
832 Chapter 25 Implementing and Maintaining WINS
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Set a Custom Threshold for Burst Handling
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 Confi 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.
Set a Custom Threshold for Burst Handling
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.
Configuring and Maintaining WINS 833
Chapter 25
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Using Netsh WINS, you can view server statistics by typing the command
netsh wins server ServerName show statistics
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 verifi 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. Confl 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 confi 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 verifi 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.
Chapter 25
834 Chapter 25 Implementing and Maintaining WINS
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
You can view the confi guration details for a WINS server by typing the command
netsh wins server ServerName show info
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
Verifi cation Interval : 024:00:00
Database consistency checking parameters :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Periodic Checking : Disabled
WINS Logging Parameters:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Log Database changes to JET log fi 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 fi 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
Configuring and Maintaining WINS 835
Chapter 25
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
records and write the information to a fi le that you can search. To do this, type the
command
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 verifi 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 verifi -
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 verifi 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
Chapter 25
836 Chapter 25 Implementing and Maintaining WINS
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.