Transcript cxTesting TCP/IP with Ping

Module 10B:
The Windows Internet
Name Service
10
1
 Overview

Describe the function of WINS.

Explain how a WINS server resolves NetBIOS names.

Install and configure a WINS server for an internetwork.

Configure a computer to use primary and secondary WINS servers.

Backup and restore the WINS database.

Use the JETPACK utility to compact the WINS database.

Configure WINS to automatically remove obsolete database entries.

Configure a WINS server to replicate its database entries with
another WINS server.
10
2
Objectives

After completing this module, you will be able to:

Describe the function of WINS.

Explain how a WINS server resolves NetBIOS names.


Configure a client to use primary and secondary WINS
servers.
Install and configure a WINS server for an internetwork.
10
3
What Is WINS?
WINS Server
What Is the IP Address
for \\STUDENT3?
\\STUDENT3 = 131.107.3.13
10
4

The Windows Internet Name Service (WINS) is an
enhanced NetBIOS Name Server (NBNS) designed by
Microsoft to eliminate broadcast traffic associated with
the b-node implementation of NetBIOS over TCP/IP. It is
used to register NetBIOS names and resolve them to IP
addresses for both local and remote hosts.

Before two NetBIOS-based hosts can communicate, the
destination NetBIOS name must be resolved to an IP
address. This is necessary because TCP/IP requires an
IP address to communicate. It cannot establish
communication using a NetBIOS computer name. The
procedure is as follows:
10
5
What is WINS?
10
6
1.
In a WINS environment, each time a WINS client starts,
it registers its NetBIOS names and its IP address with
a WINS server.
2.
When a WINS client initiates a Windows NT command
to communicate with another NetBIOS name (such as
the NET USE command), the NetBIOS name query
request is sent directly to the WINS server instead of
broadcasting it on the local network.
3.
If the WINS server finds an IP address associated with
the requested NetBIOS name in its database, it returns
the IP address to the WINS client. Because the WINS
database obtains NetBIOS name/IP address mappings
dynamically, it is always current.
10
7
Why Use WINS?

Request Are Sent Directly to WINS Server


The WINS Database Is Updated Dynamically


Reduces broadcast traffic
No LMHOSTS file is necessary
Provides the Ability to Browse:

WAN resources

Interdomain resources
10
8
Why Use WINS?

WINS provides the following advantages:




Client requests for name resolution are sent directly to a WINS
server. If the WINS server can resolve the name, it sends the IP
address directly to the client. As a result, a broadcast is not needed,
and network traffic is reduced. However, if the WINS server is
unavailable, the WINS client can still use a b-node broadcast in an
attempt to resolve the name.
The WINS database is updated dynamically, so it is always current.
This eliminates the need for an LMHOSTS file to be maintained at
any TCP/IP host that uses WINS.
WINS provides internetwork and inter-domain browsing capabilities
without configuring and maintaining an LMHOSTS file at each
computer.
How WINS aids in internetwork browsing and domain logon
functions is discussed in Module 9, Internetwork Browsing.
10
9
How WINS Works?

WINS is an extension of RFC 1001 and RFC 1002. WINS
uses standard methods of name registration, name
discovery, and name release. The method used to renew
a name registration is unique to WINS clients.
10
10
How WINS Works
10
11
• Name Registration

Each WINS client is configured with the IP address of a
primary WINS server and optionally, a secondary WINS
server. When a client starts, it registers its IP address
and NetBIOS names with the primary WINS server. The
secondary WINS server is only used if the primary WINS
server is unavailable. The WINS server stores the
client's IP address and NetBIOS names as multiple
records, one record for each NetBIOS name of the WINS
client, in its database.
10
12
• Name Renewal

All NetBIOS names are registered on a temporary basis
so the same name can be used later by a different host
if the original owner stops using it or does not renew
the registration.
10
13
• Name Release

Each WINS client is responsible for maintaining its
registered NetBIOS names. When the NetBIOS name will
no longer be used because the NetBIOS application or
service is not running the WINS client sends a message
to the WINS server to release it. For example, when the
computer is shut down the WINS client releases all
registered NetBIOS names.
10
14
• Name Query and Name Resolution

If all WINS clients have registered their IP address and
NetBIOS names with a WINS server, any WINS client can
resolve the IP address of any other NetBIOS name by
querying the WINS server. A typical use is to resolve a
NetBIOS name corresponding to a computer name
(SERVERNAME <20>) during a NET USE operation.

All WINS communications are done over UDP Port 137,
the NetBIOS Name Service. Each communication is
directed to and from the WINS client and WINS server
and is not broadcast traffic. If configured properly, the
need for broadcasts to resolve NetBIOS names to IP
addresses should be minimal.
10
15
Name Registration

When a WINS client initializes, it registers its NetBIOS
names by sending a series of name registration
requests directly to the configured WINS server.
NetBIOS names are registered when services or
applications start, such as the Redirector, Server, and
Messenger.

If the WINS server is available and the name is not
already registered by another WINS client, a successful
registration message is returned to the client. This
message contains the amount of time the NetBIOS
name is registered to the client, specified as the Time To
Live (TTL).
10
16
Name Registration
10
17
• When a Duplicate Name Is Found

If there is a duplicate name registered in the WINS
database, the WINS server sends a challenge to the
currently registered owner of the name. The challenge is
sent as a name query request. The WINS server sends
the challenge three times in 500 milliseconds intervals.

If the registered computer is a multihomed computer,
the WINS server tries each IP address it has for the
computer until it receives a response or until all of the
IP addresses have been tried.

If the current owner of the registered name responds
successfully to the WINS server, the WINS server sends
a negative name registration response to the WINS
client that is attempting to register the name.
10
18
• When the WINS Server Is Unavailable

A WINS client will make three attempts to find the
primary WINS server. If it fails after the third attempt, the
name registration request is sent to the secondary
WINS server (if configured). The WINS client will make
three attempts to find the secondary WINS server. If
neither server is available, the WINS client will initiate a
b-node broadcast to register its name.
Note:

LAN Manager 2.2c for MS-DOS and Microsoft Network
Client 3.0 clients do not register NetBIOS names with
WINS, although they use WINS for name resolution.
10
19
Name Renewal

To continue using the same NetBIOS name, a client
must renew its registration before its Time To Live
expires. If a client does not renew the registration, the
WINS server removes it from its database, effectively
making that NetBIOS name available for another WINS
client.
10
20
Name Renewal
10
21
• Name Refresh Request

Here is a step by step description of WINS name renewals.

On the initial name refresh:
1.
A WINS client first attempts to refresh its name registrations after one eighth
of the TTL has expired. If the WINS client does not receive a Name Refresh
Response, it will keep attempting to refresh its registrations every two
minutes, until half of the TTL has expired.
2.
When 1/2 of the TTL for a registered NetBIOS name has expired, the WINS
client attempts to renew the name with the primary WINS server.
3.
If this succeeds the TTL expiration timer is reset to 1/2 of the TTL specified in
the refresh acknowledgment from the WINS server.
4.
If the name refresh fails at 1/2 of the TTL, the client changes its refresh
interval to 1/8 of the TTL until its names are refreshed (the next attempt for
refresh is 1/2 +1/8 or 5/8 of the total TTL). Note that the WINS client verifies
that 1/8 TTL is least 10 minutes or longer to avoid excessive network traffic.
5.
If the WINS client does not reach the WINS server by 3/4 of the TTL, it starts
trying to contact the secondary WINS server as well as the primary WINS
server. This will continue indefinitely until a WINS server is contacted.

For subsequent name refreshes, the WINS client starts at Step 2 above.
10
22
• Name Refresh Response

When a WINS server receives the name refresh request,
it sends the client a name refresh response with a new
TTL.
10
23
Name Release
10
24
Name Release Request

When a WINS client is properly shut down, it sends a
name release request directly to the WINS server for
each registered name. The name release request
includes the client's IP address and the NetBIOS name
to be removed from the WINS database.
10
25
Name Release Response

When the WINS server receives the name release request, it checks
its database for the specified name. If the WINS server encounters a
database error, or if a different IP address maps the registered
name, it sends a negative name release to the WINS client.

Otherwise, the WINS server sends a positive name release and then
designates the specified name as inactive in its database. The
name release response contains the released NetBIOS name and a
TTL value of zero.

WINS clients assume the name release response is positive, and
stop responding to the name requests from other hosts for the
name. If it does not receive a response, the WINS client resends the
name release request (up to three times).

Receiving a negative release response or no response at all does
not stop the client from shutting down.
10
26
Name Query and Name Response
10
27

By default WINS clients uses the h-node
implementation of NetBIOS over TCP/IP. The NetBIOS
Name Server is always checked for a NetBIOS name/IP
address mapping before initiating a b-node broadcast.
The process is as follows:
10
28
1. When a user initiates a Windows NT command, such as
NET USE, the NetBIOS name cache is checked for the
NetBIOS name/IP address mapping of the NetBIOS
name.
10
29
2. If the name is not resolved from cache, a name query
request is sent directly to the client's primary WINS
server.


If the primary WINS server is unavailable, the client
resends the request two more times before switching
to the secondary WINS server.
When either WINS server resolves the name, a
success message with the IP address for the
requested NetBIOS name is sent to the source host.
10
30
3. If neither WINS server can resolve the name, a name
query response is sent back to the WINS client with
the message "Requested name does not exist", and bnode name resolution is implemented. Note that the
WINS client does not check the secondary WINS sever
if the primary WINS server returns a "Requested name
does not exist" message. The secondary WINS server
is only checked if the primary WINS server is
unavailable.

If the name is not resolved from cache, by a WINS
server, or b-node broadcast, the name may still be
resolved by parsing the LMHOSTS or HOSTS files, or
by using a DNS.
10
31
Note:

When a WINS client requests the IP address for a
multihomed computer, the WINS server will send a
response listing all of the IP addresses for the
multihomed computer. The list is ordered by the order in
which the IP addresses were registered/refreshed with
WINS (most recent to least recent). MS-DOS TCP/IP
clients will only use the first address in the list returned
to it. WFW and Windows NT clients select an address
based on the following priorities: 1) the IP address is on
the same subnet 2) the IP address is on the same
network 3) if neither of the above, the client randomly
select an address from the list.
10
32
Implementation Considerations

Before you implement WINS in an internetwork,
consider the following:
10
33
• The number of WINS servers on an internetwork.

Only one WINS server is required for an internetwork,
because requests for name resolution are directed
datagrams that can be routed.

Two WINS servers ensure a backup system for fault
tolerance. If one server becomes unavailable, the
second server can be used to resolve names.
10
34
• WINS Server Recommendations.

There is no built-in limit to the number of WINS requests
that can be handled by a WINS server, but typically it
can handle 1500 name registrations and about 750 name
queries per minute.



A conservative recommendation is one WINS server
and a backup server for every 10,000 WINS clients.
Computers with multiple processors have demonstrated
performance improvements of approximately 25 percent
for each processor, as a separate WINS thread is
started for each processor.
If logging is turned off (through WINS Manager), name
registrations are much faster, but if a crash occurs, there
is a risk of losing the last few updates.
10
35
WINS Requirements

To implement WINS, both the server and client require
configuration.
10
36
• Server Requirements

A WINS server requires:



The WINS Server service configured on at least one computer
within the TCP/IP internetwork running Windows NT Server 3.5 and
above (it does not have to be a domain controller).
A static IP address, subnet mask, default gateway, and other
TCP/IP parameters. These parameters must be manually entered
and cannot be assigned as a client reservation by DHCP. This is
necessary because if the computer is configured to use DHCP and
the DHCP server is not immediately available, WINS will fail to load
since the computer will not have an IP address.
The first TCP/IP binding under the Bindings button in Control Panel
Networks must have an IP address (i.e. it can not be a RAS
binding). This is required because WINS binds to the first entry
under the TCP/IP bindings.
10
37
• Client Requirements

A WINS client requires:

A computer running any of the following supported operating systems:
Windows NT Server 3.5 and above
Windows NT Workstation 3.5 and above
Windows™ for Workgroups 3.11 running Microsoft
TCP/IP-32 (provided on the Windows NT Server
3.5 and above CD)
Windows 95 with TCP/IP protocol
Microsoft Network Client 3.0 for MS-DOS with
the real mode TCP/IP driver included on the
Windows NT Server 3.5 and above CD
LAN Manager 2.2c for MS-DOS included on the
Windows NT Server 3.5 and above CD. LAN
Manager 2.2c for OS/2 is not supported.

An IP address of a WINS server configured, for a primary WINS
server, or for primary and secondary WINS servers.
10
38
WINS Client Platforms
Windows for
Workgroups 3.11
Microsoft
Network Client or
LAN Manager 2.2c
Windows NT
Workstation
Windows 95
WINS
Server
10
39
Configuring a Client to Use WINS

Configuring a computer to be a WINS client requires
that you add the IP address of a primary WINS server,
and optionally, the IP address of a secondary WINS
server.
10
40
Windows NT Clients

The following steps assume that the TCP/IP transport
is already installed.
1.
Use the Control Panel Network application to access
the Network Settings dialog box.
2.
In the list of installed Network Software, select TCP/IP
Protocol, and then choose Configure.
3.
In the TCP/IP Configuration dialog box, type the IP
address of a primary WINS Server and secondary
WINS Server (if applicable), and then choose OK.
4.
Exit the Network application, and then shut down and
restart the computer.
10
41
Windows 9x Clients

The following steps assume that the TCP/IP transport
is already installed.
1.
From Control Panel Network, bring up the properties
of the TCP/IP protocol.
2.
From the WINS Configuration property page, select
"Enable WINS Resolution" and enter the IP addresses
of the primary and secondary WINS servers. If you
want the DHCP server to allocate WINS server
configuration information, select "Use DHCP for WINS
Resolution".
3.
Click OK and then shut down and restart the computer.
10
42
Configuring a WINS Client Using DHCP

If the computer is a DHCP client, WINS support can be configured by
adding and configuring two DHCP Scope options:



044 WINS/NBNS Servers - Configure the address of primary and
secondary servers.
046 WINS/NBT Node - Configure to 0x8 (H-node).
When the DHCP client leases or renews an address lease, it will
receive these two DHCP Scope options, and the client will be
configured for WINS support.
Note:

The IP addresses that you configure in the Primary WINS Server and
Secondary WINS Server boxes take precedence over the same
parameters configured using DHCP.
10
43
Maintaining the WINS Server Database
10
44

WINS Manager provides the ability to view the contents
of the WINS database and search for specific entries.
10
45

To open the WINS database:
1.
Start WINS Manager.
2.
From the Mappings menu, choose Show Database. The Show
Mappings dialog box appears. By default, all mappings for the
current WINS server appear.
3.
To view mappings for a specific WINS server, select Show Only
Mappings from Selected Owner, and then from the Select Owner
list, select the WINS server you want to view.
4.
Select a Sort Order option to sort by IP address, computer name,
timestamp for the mapping, version ID, or type. Under Sort Order,
select how you want mappings sorted.
5.
If you want to view only a range of mappings, choose the Set Filter
button, and then specify the IP addresses or NetBIOS names.
6.
View the mappings in the Mappings box. Each mapping includes
the following elements:
10
46
Element
Description
Single Computer
Icon
Indicates that the entry is unique name.
Multiple
Computer Icon
Represents a group, internet group, or multihomed computer.
Name
The registered NetBIOS name.
IP address
The IP address that corresponds to the registered name.
A or S
Indicates whether the mapping is active (dynamic) or static. If there is a
cross symbol in the A column, it indicates that the name is no longer
active and will soon be removed from the database.
Expiration Date
Shows when the entry will expire. When a replica is stored in the
database, its expiration data is set to the current time on the receiving
WINS server, plus the renewal interval.
Version ID
A unique hexadecimal number assigned by the WINS server during name
registration, which is used by the server's pull partner during replication
to find new records.
10
47
7.
To delete a WINS server and all database entries
owned by that server, select a WINS server in the
Select Owner list, and then choose the Delete Owner
button.
8.
When finished, choose the Close button.
10
48
Common NetBIOS Names

Viewing the registered names can be helpful in
determining which services are running on a computer.
The following table describes common NetBIOS names
that you will see in the WINS database.
10
49
Registered name
Description
\\computer_name[00h] The name registered for the Workstation service on the WINS
client.
\\computer_name[03h] The name registered for the Messenger service on the WINS
client.
\\computer_name[20h] The name registered for the Server service on the WINS
client.
\\username[03h]
The name of the user currently logged on to the computer.
The username is registered by the Messenger service so that
the user can receive NET SEND commands sent to their
username. If more than one user is logged on with the same
username (such as Administrator), only the first computer
from which a user logged on will register the name.
\\domain_name[1Bh]
The domain name registered by the Windows NT™ Server
primary domain controller (PDC) that is functioning as the
Domain Master Browser. This names is used for remote
domain browsing. When a WINS server is queried for this
name, it returns the IP address of the computer that
registered this name.
10
50
Note:

The value in the brackets [ ] after each name registered
in the WINS database is always the 16th byte of the
name that was registered, as specified by the LAN
Manager naming convention.
10
51
Backing Up and Restoring the WINS Database

Backing Up the WINS Database

It is important to back up the WINS database in the
event of system failure or database corruption.
10
52
• Specifying a Backup Directory

The WINS database is backed up every 24 hours after you specify
the backup directory. To specify the backup directory:
1.
From the WINS Manager Mappings menu, choose Backup
Database. The Select Backup Directory dialog box appears.
2.
Specify the location for saving backup files.
3.
If you want to back up only the changes that have occurred since
the last backup, select Perform Incremental Backup. You must
have already performed a complete backup before you can
perform an incremental backup.
4.
Choose OK.
10
53
Backing up the WINS Registry Key

You should also periodically back up the Registry
entries for the WINS server. To backup the WINS
Registry entries:
1.
Use the Registry Editor to open
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\WINS
2.
From the Registry menu, choose Save Key.
3.
In the Save Key dialog box, specify the path where you
store backup versions of the WINS database file.
10
54
• Restoring a Corrupt WINS Database

In the event that the WINS database becomes corrupt, use one of the
following three methods to restore the backup database:



Stop and restart the WINS Server service. If the WINS Server service
detects a corrupt database, it automatically restores a backup copy.
From the WINS Manager Mappings menu, choose Restore
Database. You will be required to specify the directory where the
backup copy is located.
Manually delete and restore the database files using the following
steps:
a. From the \systemroot\SYSTEM32\WINS
directory, delete the JET*.LOG, WINSTMP.MDB
and SYSTEM.MDB files.
b. Copy the SYSTEM.MDB from the Windows NT
Server CD to the \systemroot\SYSTEM32\WINS
directory.
c. Copy an uncorrupted backup version of the
WINS.MDB database file to
\systemroot\SYSTEM32\WINS directory.
10
55
The WINS Database Files
The following files are stored in the \systemroot\SYSTEM32\WINS
directory:

File
Description
WINS.MDB
The WINS database file.
WINSTMP.MDB A temporary file that WINS creates. This file may
remain in the \WINS directory after a crash.
JET.LOG
A log of all transactions done with the database. This
file is used by WINS to recover data if necessary.
SYSTEM.MDB The database structure file.
Caution:

Do not tamper with or remove these files, except to manually
restore a corrupted WINS database.
10
56
Compacting the WINS Database

It is recommended that the WINS database is
compacted if it grows to over 30 MB in size. The amount
of space used for each entry in the WINS database
depends on the type of registration, for example:



A unique or group entry uses 50 to 70 bytes.
An internet group or multihomed entry uses 50 to 300
bytes, depending on the number of members/IP
addresses.
There is between 50 and 100 bytes of database
overhead per record in the WINS database.
10
57

The JETPACK utility is used to compact the WINS database.To compact the
database:
1. Stop the WINS server service. This can be done from Control Panel
Services, Server Manager, or a command prompt. To stop the service from
a command prompt, use the following command syntax:
net stop wins
2. From the \systemroot\SYSTEM32\WINS directory, run the JETPACK using
the following command syntax (assign any filename to temporary_name):
jetpack wins.mdb temporary_name.mdb
The contents of WINS.MDB are compacted in temporary_name, and then
the temporary file is copied to WINS.MDB, and the temporary name is
deleted.
3. Restart the WINS Service from Control Panel Services, Server Manager, or
a command prompt, To restart the service from a command prompt, use
the following command syntax:
net start wins
10
58
Configuring Automatic Database Cleanup

Each WINS database should be periodically cleared of
entries that were released and entries that were
registered at another WINS server but were never
removed. This process can be done manually by the
WINS administrator or be automatically done at
configured intervals
10
59

NetBIOS names go through different phases before
they are removed from the database. To configure the
length of time a NetBIOS name is in each phase:
1.
From the WINS Manager Server menu, choose
Configuration. The WINS Server Configuration dialog
box appears.
2.
To view all the options in the dialog box, choose
Advanced.
3.
Under WINS server configuration, specify the intervals
for each option as described in the following table.
10
60
Interval
Description
Renewal
Interval
The frequency a WINS client will renew its name registration
with the WINS server. The default value is 96 hours.
Extinction
Interval
The interval between when an entry in the WINS database is
marked as released (no longer registered) and when it is
marked as extinct. The default value is 96 hours.
Extinction
Timeout
The interval between when an entry is marked extinct and when
the entry is scavenged (removed) from the WINS database. The
default is the same as the renewal interval, and cannot be less
than 24 hours.
Verify
Interval
The time after which the WINS server will verify that names it
does not own (those replicated from other WINS servers) are
still active by contacting the originating server via RPC. The
default value is 576 hours (24 days). This is the minimum value
that WINS Manager will save.
10
61
Configuring Automatic Database Cleanup
10
62
4.
If you want this WINS server to pull replicas of new
WINS database entries from its partners when the
computer initializes or when replication-related
parameter changes, select initial replication under Pull
Parameters.
5.
To inform partners of the database status when the
computer is initialized, select Initial Replication under
Push Parameters.
6.
Under Advanced WINS Server Configuration, select
any of the following options.
10
63
Advanced option
Description
Logging Enabled
Specifies whether logging of database changes should be turned
on.
Specified whether logging events is verbose. If you are tuning for
performance, this should be turned off.
Log Detailed
Events
Replicate Only
With Partners
Backup On
Termination
Migrate On/Off
Starting Version
Count
Specifies that replication will be done only with WINS pull or push
partners, and not with a non-listed WINS server partner. This is
selected by default.
Specifies that the database will be backed up automatically when
WINS Manager is closed.
Specifies that static unique and multihomed entries are treated as
dynamic when they conflict with a new registration or replica. This
means that if they are no longer valid, they will be overwritten by
the new registration or replica. Check this option if you are
upgrading non-Windows NT computers to Windows NT.
Specifies the highest version ID number for the database. Usually,
you will not need to change this value unless the database
becomes corrupted and needs to start fresh.
Database Backup Specifies the directory where the WINS database backup will be
Path
stored. This directory is also used for automatic restoration of the
database. Do not specify a network directory.
64
10
7.
When finished, choose OK
10
65
Database Replication Between WINS Servers
10
66

All of the WINS servers on a given network can be
configured to communicate with each other so that a
name registered with one WINS server will eventually be
known by all WINS servers. In addition to being aware of
all name registrations on the network, all of the WINS
servers will also be notified when a name is released.
Having all of the WINS servers communicate with each
other in this manner is done by configuring the WINS
servers to replicate their WINS database entries with
each other.
10
67

Configuring WINS servers to replicate their WINS
database entries with each other extends the benefit of
WINS across the entire network. For example, WINS
clients on network 1 register their computer name with
WINS Server1 and WINS clients on network 2 register
their computer name with WINS Server2. When WINS
clients on network 1 need to resolve a computer name to
IP address, they contact WINS Server1. Because WINS
Server1 and WINS Server2 replicate their WINS Database
entries with each other, WINS Server1 can resolve a
NetBIOS name to its IP address from network 2.

If WINS Server1 and WINS Server2 did not replicate their
WINS database entries with each other, WINS Server1
would not be able to resolve a NetBIOS name to its IP
address from network 2.
10
68
Push and Pull Partners
10
69

To configure WINS servers to replicate their WINS
database entries amongst each other requires each
WINS server to be configured as a 'Pull' or 'Push'
partner with at least one other WINS server:
10
70
Pull Partners

A Pull partner is a WINS server that 'pulls' WINS
database entries (also known as replicas) from its Push
partners. This is done by requesting any new WINS
database entries that the Push partners have. The Pull
partner requests the new WINS database entries by
requesting entries with a higher version number than
the last entry it received during the last replication.
10
71
Push Partners

A Push partner is a WINS server that sends a message
to its Pull partners notifying them when its WINS
database has changed. When the WINS server's Pull
partner(s) respond to the message with a replication
request, the WINS server sends a copy ('pushes') of its
new WINS database entries (replicas) to its Pull
partner(s).
10
72

While there are separate designations of pull and push
partners during the configuration of WINS replication, it
is generally assumed that two WINS servers want to
exchange information both ways. In this case, both
WINS servers will be both push and pull partners with
each other.

In the example above, if Sydney and Seattle want to
exchange two-way NetBIOS name mappings, Sydney is
configured as a push and pull partner with Seattle and
Seattle is configured as a push and pull partner with
Sydney.
10
73
Push and Pull Operations
10
74

The initiation of information being exchanged between
two WINS servers can either happen through a push or
pull operation. For simplicity, the above drawing only
shows database entries flowing one way.
10
75
Push Operation

In a push operation, a WINS server notifies its pull partners that it has
new entries which it wishes to send. The WINS server sends out a
directed "Have new entries" notification to all pull partners. This
notification is received by the pull partners who then send a "Send
new entries" notification to the push partner from which it received
the "Have new entries" notification. The originating WINS server then
sends the new entries.

To initiate a push operation, a push trigger is configured. A push
trigger is based on a threshold of a certain number of entries that
have changed regardless of the time. Push triggers are configured
during the configuration of WINS replication.

Using the example above, Sydney is configured with a push trigger of
1000 entries. When 1000 entries in the Sydney WINS database have
changed, it initiates a push operation with Seattle.
10
76
Pull Operation

In a pull operation, pull partners send a "Send new entries"
notification to their push partners. The push partners then sends all
the new entries to the pull partners from which they received a
"Send new entries" notification.

To initiate a pull operation, a pull trigger is configured. A pull trigger
is based on scheduled times regardless of the amount of entries to
be sent. Pull triggers are configured during the configuration of
WINS replication.

Using the example above, Seattle is configured with a pull trigger of
every day at 12:00 AM. At 12:00 AM each day, Seattle initiates a pull
operation with Sydney.

Note that in both cases, push and pull operations, the data flows
from push partner to pull partner. The actual replicated entries are
always pushed from the push partner down to the pull partner. The
main difference between push and pull operations is the nature of
the trigger (number of changed entries vs. scheduled) and who
initiates the first notification.
10
77
WINS Database Replication Considerations
10
78

Some general rules to keep in mind when configuring
WINS server replication are:


Use a pull operation between sites, especially across
slower links, since pull triggers can be configured to
occur at specific times when the slow link is less busy.
Use a push operation between servers within a site that
are connected by faster links, since push triggers are
based on the number of changes entries and can be
more frequent.
10
79

These rules are applied in the above example:



In both Sydney and Seattle, all of the WINS servers at each site
implement push triggers to push their new WINS database entries
to a single server at their site.
The WINS servers in Sydney and Seattle that receive all of the
push replication are configured with a pull trigger for pull replication
between each other. This is done because the network link between
Sydney and Seattle is relatively slow. Therefore, the network
administrators only want the replication to occur at times when the
link is the least used, such as late at night.
When replication occurs between the two WINS servers in Sydney
and Seattle, the servers then push the WINS database entries they
receive to the local WINS servers using a push operation.
10
80
Configuring Database Replication
10
81

There are four methods of starting the replication of the WINS
database:




At system startup. Once a replication partner is configured, WINS
automatically pulls each time the WINS Server service is started.
At a configured interval, such as every five hours (pull trigger).
When a WINS server has reached a configured threshold for the
number of registrations and changes to the WINS database (push
trigger). When the threshold (the update count setting) is reached, the
WINS server notifies all of its pull partners who will then request the
new entries.
By forcing replication through WINS Manager Replication Partners
dialog box (manual override of push or pull trigger).
10
82

To add a replication partner for a WINS server:
1.
From WINS Manager window, choose Replication Partners from
the Server menu. The Replication Partners dialog box appears.
2.
Choose Add. The Add WINS Server dialog box appears.
3.
In the Add WINS Server dialog box, type the name or IP address of
the WINS server you want to add, and then choose OK. If WINS
Manager can find this server, it will add it to the WINS server list in
the Replication Partners dialog box.
4.
From the Windows Server list, select the server you want to
configure.
5.
Under Windows Server To List, select either Push Partner or Pull
Partner or both to indicate the replication partnership you when,
and then choose the related Configure button.

Either the Push Partner Properties or Pull Partner Properties
dialog box appears, depending on your selection.
10
83
6.
For a push partner, type a number in the Update Count box for how many
new database entries that the WINS server must reach before it will send
a push message, and then choose OK.
An appropriate update count should be based on the number of
registrations a server handles. A WINS server that receives hundreds of
name registrations when users first log on should not be configured to
replicate a small number of registrations. The minimum value is 5.
7.
For a pull partner, type a start time and replication interval for the
selected partner, and then choose OK.
8.
Under Send Replication Trigger Now, select Push or Pull to send
messages to only the selected WINS servers (whereas the Replicate Now
button will initiate replication with all partners).
9.
Select the Push With Propagation check box. This causes the selected
WINS servers to obtain any new database entries from the WINS server
that sent the message. If the selected WINS servers received any new
entries, they will propagate the push message to all their pull partners. If
the selected WINS servers did not receive any new entries, they will not
propagate the push message.
10.
When finished, choose OK.
10
84
Automatic WINS Replication Partner

Windows NT 3.51 WINS servers can be configured
through the Registry so that they automatically
configure themselves for replication. If so configured,
the WINS servers periodically, every 40 minutes by
default, announce their presence through an IP
multicast packet. These WINS servers also listen for
these announcements and add the IP addresses of new
WINS servers detected as both push and pull partners
with pull replication occurring every 2 hours.
10
85

To configure a WINS server so that it will automatically
configure itself for replication, the following Registry
entries must be added under:
HKEY_LOCAL_MACHINE
\SYSTEM
\CurrentControlSet
\Services
\Wins
\Parameters
10
86
• UseSelfFndPnrs

This parameter must have a type of REG_DWORD and
should be set to either 0, disabled, or 1, enabled. If this
parameter is set to 1 and the routers on the network
support multicasting, then the WINS server will
automatically find other WINS servers on the network
and configure replication with them. If this parameter is
set to 1 and the network routers do not support
multicasting, then the WINS server will only find WINS
servers on its subnet.
10
87
• McastIntvl

This parameter must have a type of REG_DWORD and
has a minimum allowed value of 2400 seconds (40
minutes). This parameter specifies the time interval at
which the WINS server sends its multicast
announcements, so that it can be found by other WINS
servers.
10
88
• McastTtl

This parameter must have a type of REG_DWORD and
has a valid range of 1 to 32, with a default of 6. This
specifies the number of hops, or jumps across a router,
that a WINS multicast announcement will make.
10
89