The number of WINS servers that an enterprise requires is based on the number of WINS client connections per server and the network topology. The number of users that can be supported per server varies according to usage patterns, data storage, and processing capabilities of the WINS server computer.
Planning for WINS server implementation on the network typically requires consideration of the issues presented in the following table.
Table 5-1 WINS Server Implementation Planning Issues
Planning Issue |
Guideline |
---|---|
How many WINS servers are required to ensure distribution of name query and name registration loads throughout the network? |
One WINS server can handle NetBIOS name resolution requests for 10,000 computers. However, the location of routers on the network and the distribution of clients in each subnet should be considered when deciding how many WINS servers are required. See the following sections: "Planning for WINS Client Network Traffic," "Planning for WINS Server Performance," and "Planning Replication Partners and Proxies." |
Is the WAN bandwidth sufficient to support WINS server and WINS client name registration traffic? |
See the next section, "Planning for WINS Client Network Traffic." |
How many WINS servers are needed for disaster recovery, backup, and redundancy requirements? |
See "Planning for WINS Server Performance." |
How can a planned distribution of WINS servers throughout the network be validated before installation? |
When planning a network configuration, a generally accepted approach is to consider the consequences of two simultaneous failures at different points on the network. |
WINS clients generate the following types of network traffic:
Name registration
Name refresh
Name release
Name query
When a WINS-enabled client starts on the network, it sends a name registration request for the computer name, user name, domain name, and any additional Microsoft network client services running on the computer. In other words, when a WINS client starts on the network, it generates a minimum of three name registration requests and three entries in the WINS database.
A SunLink Server-based WINS client usually registers more NetBIOS names than other WINS-enabled clients. The name registration requests generated by a computer running under the SunLink Server program include the following:
Server component
Domain names
Replicator service name
Browser service name
Additional network program and service names
When planning for WINS client traffic on large routed networks, consider the effect of name query, registration, and response traffic routed between subnets.
Name requests and responses that occur at the daily startup of computers must pass through the traffic queues on the routers and may cause delays at peak times.
An active WINS client name registration in a WINS server database is replicated to all pull partners configured on that WINS server. (See "Configuring Replication Partners" for an explanation of pull partners and push partners.) After some time, the active name registration is replicated to all WINS servers on the network.
When a WINS client is turned off at the end of the day, it releases the name. When the computer is started the next morning, the WINS client registers the name again with the WINS server and receives a new version ID. This new, active name registration entry is replicated to the WINS server's pull partners as on the previous day.
Therefore, the number of name registration entries that are replicated each day is roughly equivalent to the number of computers started each day times the number of NetBIOS names registered at each computer.
On large networks (50,000 or more computers), the biggest traffic load may be the name registration requests generated when WINS clients start on the network. Fortunately, the difference in time zones in large enterprise networks provides some distribution of this WINS client startup load.
Name challenge traffic occurs when a user stops the computer and then moves and starts the computer on a different subnet with another primary WINS server.
Typically, the name registration request is answered with a Wait for Acknowledgment message (100 bytes), and the new WINS server, assuming the active entry was replicated, challenges the IP address that is currently in its database for this name (Name Query packet, 92 bytes).
When there is no reply, as can be expected in this case, the WINS server repeats the challenge two more times and then updates the name registration entry with the new IP address and a new version ID. The new version ID indicates that the entry must be replicated from its new "owning" WINS server to other WINS servers on the network.
You can estimate WINS client traffic based on the behavior of the WINS clients as described in the preceding sections.
However, when estimating WINS client traffic, you also must consider the network topology and the design or configuration of the routers in the network. In some cases it may not always be possible to predict the traffic load on a specific network router because the routers may be designed or configured to autonomously route traffic based on factors other than traffic load.
The frequency of WINS database replication between WINS servers is a major planning issue. You should replicate the WINS database frequently enough that the down-time of any WINS server will not affect the reliability of the mapping information in the database of other WINS servers.
However, when planning WINS database replication frequency, you do not want the frequency to interfere with network throughput. This could occur if replication frequency is set to a short time interval.
Consider the network topology when planning for replication frequency. For example, if your network has multiple hubs connected by relatively slow wide area network (WAN) links, you can configure WINS database replication between WINS servers on the slow links to occur less frequently than replication on the local area network or on fast WAN links. This reduces traffic across the slow link and reduces contention between replication traffic and WINS client name queries.
For example, WINS servers at a central local area network site may be configured to replicate every 15 minutes, while database replication between WINS servers in different WAN hubs might be scheduled for every 30 minutes, and replication between WINS servers on different continents might be scheduled to replicate twice a day.
When planning for a large-scale power outage where many computers will go on line simultaneously, the conservative recommendation is that you plan to include one WINS server and a backup server for every 10,000 computers on the network. A WINS server typically can service 1,500 name registrations per minute and 4,500 queries per minute.
Two factors enhance WINS server performance. WINS server performance can be increased by almost 25 percent on a computer with two processors. WINS server name replication response time can be improved measurably by using a dedicated disk.
After you establish WINS servers on an intranet, you can adjust the time between a WINS client name registration and name renewal. This is referred to as the Renewal Interval. Setting this interval to reduce the numbers of registrations can help tune server response time. (The Renewal Interval is specified in the WINS Server Configuration dialog box.)
Choosing whether to configure another WINS server as a push partner or pull partner depends on several facts, including the specific configuration of servers at your site, whether the partner is across a wide area network (WAN), and how important it is to distribute changes throughout the network.
You should install only one computer configured as a WINS proxy on each subnet. Configuring more than one WINS proxy per subnet can overload the WINS servers on the same subnet.
In one possible configuration, you can designate one WINS server as the central server, and all other WINS servers as both push partner and pull partner of this central server. Such a configuration ensures that the WINS database on each server contains addresses for every node on the WAN.
Another option is to set up a chain of WINS servers, where each server is both the push partner and pull partner with a nearby WINS server. In such a configuration, the two servers at the ends of the chain would be push and pull partners with each other. Other replication partners can be established for your site's needs.
You should configure multiple WINS servers on your network to increase the availability and balance the load among servers. When using multiple servers, each WINS server should be configured with at least one other WINS server as its replication partner. You should have multiple WINS servers installed on your network for the following reasons:
To distribute NetBIOS computer name query and registration processing load
To provide WINS database redundancy, backup, and disaster recovery
Configuring a WINS server includes specifying information about when database entries are replicated between partners. A pull partner is a WINS server that pulls in replicas of database entries from its partner by requesting and then accepting replicas. A push partner is a WINS server that sends update notification messages to its partner when its WINS database has changed. When its partner responds to the notification with a replication request, the push partner sends a copy of its current WINS database to the partner.
For each WINS server, you must configure threshold intervals for triggering database replication, based on a specific time, a time period, or a certain number of new records. If you designate a specific time for replication, this occurs one time only. If a time period is specified, replication is repeated at that interval.
Use WINS Manager to configure WINS server management of WINS client mappings by using the configuration options in the WINS Server Configuration - (Local) dialog box. The configuration options allow you to specify time intervals that govern WINS client behavior as described in the following table.
Table 5-2 WINS Server Time Interval Options
Configuration Option |
Description |
---|---|
Renewal Interval |
Specifies how often a client reregisters its name. The default is six days. |
Extinction Interval |
Specifies the interval between when an entry is marked as released and when it is marked as extinct. The default is dependent on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. The default is four days. |
Extinction Timeout |
Specifies the interval between when an entry is marked extinct and when the entry is finally scavenged from the database. The default is dependent on the renewal interval and, if the WINS server has replication partners, on the maximum replication time interval. The default is six days. |
Verify Interval |
Specifies the interval after which the WINS server must verify that old names it does not own are still active. The default is dependent on the extinction interval. The minimum allowable value is 24 days. |
The extinction interval, extinction timeout, and verify interval are derived from the renewal interval and the partner replication interval. The WINS server adjusts the values specified by the administrator to keep the inconsistency between a WINS server and its partners as small as possible.
You can change the following configuration parameters using the Advanced option in the WINS Server Configuration dialog box.
Table 5-3 WINS Server Advanced Configuration Options
Configuration Option |
Description |
---|---|
Logging Enabled |
Specifies whether logging of database changes to J50.log files should be turned on. (This option is ignored in SunLink Server WINS.) |
Log Detailed Events |
Specifies whether logging events is verbose mode. (This requires considerable computer resources and should be turned off if you are tuning for performance.) |
Replicate Only With Partners |
Specifies that replication occurs only with configured WINS pull or push partners. If this option is not checked, an administrator can ask a WINS server to pull or push from or to a non-listed WINS server partner. By default, this option is checked. |
Backup On Termination |
Specifies that the database will be backed up automatically when WINS Manager is stopped except when the computer is stopped. |
Migrate On/Off |
Specifies that static unique and multihomed records in the database 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. By default, this option is not checked. |
Starting Version Count |
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. In such a case, set this value to a number higher than appears as the version number counter for this WINS server on all the remote partners that earlier replicated the local WINS server's records. WINS may adjust the value you specify to a higher one to ensure that the database records are replicated quickly to the WINS servers. This value can be seen in the View Database dialog box in WINS Manager. |
Database Backup Path |
Specifies the directory where the WINS database backups will be stored. If you specify a backup path, WINS automatically performs a full backup of its database to this directory. WINS also uses this directory to perform an automatic restoration of the database in the event that the database is found to be corrupted when WINS is started. Do not specify a network directory. |
WINS servers communicate among themselves to replicate their databases fully, ensuring that a name registered with one WINS server is eventually replicated to all other WINS servers within the network. All mapping changes converge within the replication period for the entire WINS system, which is the maximum time for propagating changes to all WINS servers. All released names are propagated to all WINS servers after they become extinct, based on the interval specified in WINS Manager.
Use the Replication Partners command in WINS Manager to configure replication partners and replication partner properties. There are two types of replication partners: pull and push:
A pull partner is a WINS server that pulls (requests) WINS database entries from its push partners. The pull partner pulls new WINS database entries by requesting entries with a higher version number than the last entry it received during the last replication from that push partner.
A pull partner can notify push partners that replication is needed by using either of the following methods: an arbitrary time interval, as configured by the WINS administrator, or immediate replication, initiated by the WINS administrator using WINS Manager.
A push partner is a WINS server that sends a message to its pull partners that the WINS database has changed. When the pull partners respond to the message with a replication request, the push partner sends a copy of its new WINS database entries to the pull partners.
The push partner notifies pull partners of replication requirements by using either of the following methods: an arbitrary number of WINS updates (update count), as configured by the WINS administrator, or immediate replication initiated by the WINS administrator by using WINS Manager.
If you modify the update count using WINS Manager, you then can open the WINS Server Configuration dialog box and check the OK button. As a result, the new value will take effect immediately.
Choosing whether to configure another WINS server as a push partner or pull partner depends on several considerations, including the specific configuration of servers at your site, whether the partner is across a wide area network (WAN), and how important it is to propagate the changes.
Replication is triggered when a WINS server polls another server to get replicated information. This can begin when the WINS server is started, and is repeated based on the configured update count or time interval, or by using WINS Manager to start immediate replication.
Replication also is triggered when a WINS server reaches a threshold set by the administrator. This is an update count for registrations and changes. In this case, the server notifies its pull partners that it has reached this threshold, and the other servers can then decide to pull replicated information.
It is always a good idea for replication partners to be both push and pull partners of each other. The primary and backup WINS servers must be both push and pull partners with each other to ensure that the primary and backup databases are consistent.
Static mappings are non-dynamic database entries of NetBIOS computer name-to-IP address mappings for computers on the network that are not WINS-enabled or for special groups of network devices.
Use the Static Mappings command on the Mappings menu in WINS Manager to view, add, edit, delete, import, or filter static mappings.
Once a static name-to-IP address mapping is entered into the WINS server database, it cannot be challenged or removed except by an administrator who must remove it manually using WINS Manager. All changes made to the WINS server database using WINS Manager take effect immediately.
A DHCP reserved (or static) IP address for a unique name in a multihomed computer overrides an obsolete WINS static mapping if the WINS server advanced configuration option Migration On/Off is checked On.
Static NetBIOS name mappings can be any of the types listed in the following table.
Table 5-4 Static NetBIOS Name-Mapping Types
You can configure a WINS server to replicate only domain, Internet, and multihomed group to its replication partners, by manually changing the Replication Type Registry parameter to a value of 1.
This procedure eliminates the replication of information (unique names) that is not needed outside the local domain, while allowing replication of special group information. When a group spans multiple domains that are serviced by other WINS servers, it is desirable to reduce replication traffic
Table 5-5 Basic WINS Server Statistics Descriptions
Statistic |
Description |
---|---|
Server Start Time |
The time when this WINS server was started. |
Database Initialized |
The last time static mappings were imported into the WINS database. |
Statistics Cleared |
The time when statistics for the WINS server were last cleared with the Clear Statistics command from the View menu. |
Last Replication Times |
The times at which the WINS database was last replicated. |
Periodic |
The last time the WINS database was replicated based on the replication interval specified in the Preferences dialog box. |
Admin Trigger |
The last time the WINS database was replicated because the administrator chose the Replicate Now button in the Replication Partners dialog box. |
Net Update |
The last time the WINS database was replicated as a result of a network request, which is a push notification message that requests propagation. |
Total Queries Received |
The number of name query request messages received by this WINS server. Successful indicates how many names were successfully matched in the database, and Failed indicates how many names this WINS server could not resolve. |
Total Releases |
The number of messages received that indicate a NetBIOS application has shut itself down. Successful indicates how many names were successfully released, and Failed indicates how many names this WINS server could not release. |
Total Registrations |
The number of messages received that indicate name registrations for clients. |
You can display additional statistics by clicking Detailed Information on the Server menu. The following table describes these detailed information statistics.
Table 5-6 Detailed WINS Server Statistics Descriptions
Statistic |
Description |
---|---|
Last Address Change |
The time at which the last WINS database change was replicated |
Last Scavenging Times |
The last times that the database was cleaned for specific types of entries |
Periodic |
The time when the database was cleaned based on the renewal interval specified in WINS Server Configuration (Local) |
Admin Trigger |
The time when the database was last cleaned because the administrator chose the Initiate Scavenging command |
Extinction |
The time when the database was last cleaned based on the Extinction interval specified in the WINS Server Configuration dialog box |
Verification |
The time when the database was last cleaned based on the verify interval specified in WINS Server Configuration dialog box |
Unique Registrations |
The number of name registration requests that have been accepted by this WINS server |
Unique Conflicts |
The number of conflicts encountered during registration of unique names owned by this WINS server |
Unique Renewals |
The number of renewals received for unique names |
Group Registrations |
The number of registration requests for groups that have been accepted by this WINS server |
Group Conflicts |
The number of conflicts encountered during registration of group names |
Group Renewals |
The number of renewals received for group names |
WINS Manager allows you to view administrative and operational information about WINS servers. When you open WINS Manager, the title bar shows the IP address or computer name for the currently selected server, depending on whether you used the address or name to connect to the server. The right pane displays basic statistics about the selected WINS server.
You can view actual dynamic and static mappings stored in the WINS database, based on the WINS server that owns the entries. Use WINS Manager to choose the Show Database command from the Mappings menu.
By default, the Show Database dialog box shows all mappings for the WINS database on the currently selected WINS server. You can select a Sort Order option to sort by IP address, computer name, time stamp for the mapping, version ID, or type. To view only a range of mappings, choose the Set Filter button.
This process, called scavenging, is done automatically over intervals defined by the relationship between the Renewal and Extinct intervals defined in the WINS Server Configuration dialog box. You can also clean the database manually.
To scavenge the WINS database, choose the Initiate Scavenging command from the Mappings menu. The following table describes the results of scavenging a WINS database.
Table 5-7 Effects of Scavenging WINS Database
State Before Scavenging |
State After Scavenging |
---|---|
Owned active names for which the Renewal interval has expired |
Marked released |
Owned released name for which the Extinct interval has expired |
Marked extinct |
Owned extinct names for which the Extinct timeout has expired |
Deleted |
Replicas of extinct names for which the Extinct interval has expired |
Deleted |
Replicas of active names for which the Verify interval has expired |
Revalidated |
Replicas of extinct or deleted names |
Deleted |
This section presents configuration parameters that affect the behavior of WINS and that you can modify only through the Windows NT Registry Editor. For some parameters, WINS can detect Registry changes immediately. For other parameters, you must restart WINS for the changes to take effect.
You can impair or disable WINS if you make incorrect changes in the Registry while using Registry Editor. Whenever possible, use WINS Manager to make configuration changes rather than using Registry Editor. If you make errors while changing values with Registry Editor, you will not be warned because the Registry Editor does not recognize semantic errors.
The following sections describe the value entries for WINS parameters that can only be set by adding an entry or changing values in Registry Editor.
The Registry parameters for WINS servers are specified under the following key:..\SYSTEM\CurrentControlSet\Services\Wins\Parameters
This lists all of the non-replication-related parameters needed to configure a WINS server. It also contains a \Datafiles subkey, which lists all the files that should be read by WINS to initialize or reinitialize its local database.
DoStaticDataInit
Data type = REG_DWORD Range = 0 or 1 Default = 0 (false--that is, the WINS server does not initialize its database) If this parameter is set to a non-zero value, the WINS server will initialize its database with records listed in one or more files listed under the \Datafiles subkey. The initialization is done at process invocation and whenever a change is made to one or more values of the \Parameters or \Datafiles keys (unless the change is to modify the default value of DoStaticDataInit to 0).
The following parameters in this subkey can be set using the options available in the WINS Server Configuration dialog box:
BackupDirPath
DoBackupOnTerm
LogDetailedEvents
LoggingOn
MigrateOn
RefreshInterval
RplOnlyWCnfPnrs
TombstoneInterval (extinction interval)
TombstoneTimeout (extinction timeout)
VerifyInterval
Also, the \Wins\Parameters\Datafiles key lists one or more files that the WINS server should read to initialize or reinitialize its local database with static records. If the full path of the file is not listed, the directory of execution for the WINS server is assumed to contain the data file. The parameters can have any names (for example, DF1 or DF2). Their data types must be REG_EXPAND_SZ or REG_SZ.
The \Wins\Partners key has two subkeys, \Pull and \Push, under which are subkeys for the IP addresses of all push and pull partners, respectively, of the WINS server.
A push partner, listed under the \Partners\Pull key, is one from which a WINS server pulls replicas and from which it can expect update notification messages. The following parameter appears under the IP address for a specific push partner. You can set this parameter only by changing the value in the Registry:
MemberPrec
Data type = REG_DWORD Range = 0 or 1 Default = None
Specifies the order of precedence for this WINS partner, with 0 indicating low precedence and 1 indicating high precedence. Notice that dynamically registered names are always high precedence. When a 1C name is pulled from this WINS partner, the addresses contained in it are given this precedence level. The value can be 0 (low) or 1 (high). Set this value to 1 if this WINS server is serving a geographic location that is nearby.
The following parameters appear under this subkey and can be set in the WINS Server Configuration dialog box:
..\SYSTEM\CurrentControlSet\Services\Wins\Partners\Pull
InitTimeReplication
CommRetryCount
The following parameters appear under this subkey and can be set using the Preferences dialog box:
..\SYSTEM\CurrentControlSet\Services\Wins\Partners \Pull\<IP Address>
SpTime (Start Time for pull partner default configuration)
TimeInterval (Replication Interval)
For SpTime, WINS replicates at the set time if it is in the future for that day. After that, it replicates every number of seconds specified by TimeInterval. If SpTime is in the past for that day, WINS replicates every number of seconds specified by TimeInterval, starting from the current time (if InitTimeReplication is set to 1).
A pull partner of a WINS server, listed under the \Partners\Push key, is one from which it can expect pull requests to pull replicas and to which it sends update notification messages. The following parameters appear under this subkey and can be set using the options available in the WINS Server Configuration dialog box:
..\SYSTEM\CurrentControlSet\Services\Wins\Partners\Push
InitTimeReplication
RplOnAddressChg
The following parameter appears under this subkey and can be set using the options available in the Preferences dialog box:
..\SYSTEM\CurrentControlSet\Services\Wins\Partners\Push\<IP Address>
UpdateCount