Setting Primary and Secondary WINS Server Options

• Microsoft Windows NT Workstation versions 3.5, 3.51, and 4.0
• Microsoft Windows NT Server versions 3.5, 3.51, and 4.0

SUMMARY

If a Windows NT server is running the Windows Internet Naming Service (WINS) and is participating in WINS database replication on the network, special consideration must be taken configuring where the WINS server points to for it's own name resolution (this parameter is set in the Network section of Control Panel, in the Configuration section of TCPIP Protocol).

It is highly recommended that a WINS server point to itself as Primary and Secondary WINS in the TCP/IP configuration. If another configuration is used, you may experience random instability in making certain network connections.

MORE INFORMATION

When any WINS enabled computer is booted it must register a variety of services with WINS. Commonly a computer has a Primary and Secondary WINS address configured in the TCP/IP setup. If the Primary WINS does not respond to the registrations, the computer tries the Secondary WINS.

For additional information on the services that can be registered, please see the following article(s) in the Microsoft Knowledge Base:

   ARTICLE-ID: Q119495
   TITLE     : List of Names Registered with WINS Service

For example, if you have a WINS server ("Srv1") that points to itself as Primary and points to another WINS as Secondary ("Wins2"). When Srv1 is booted, it usually tries to register its services before its own WINS Service is started. Since those registrations fail, it tries to register them at Wins2. If Wins2 is available, it accepts the registration requests. However, not all the services are registered at Wins2, because as these registration requests are made, Srv1 continues to check its local WINS service. Once the service is running, it switches back to it and continues registering locally.

After replication has occurred between Srv1 and Wins2, both databases show this ownership:

   Srv1:  Owns his Srv1<20>, and Domain<1c> (if it is a domain controller)
   Wins2: Owns all other Srv1 registrations, and also owns Domain<1c> from
          Srv1

At this point, Srv1 has reverted to re-registering locally, however it takes a while before you can see it. Meanwhile, Srv1 and Wins2 are replicating the split registration mappings to other WINS servers. Eventually these replicas should be reconciled at the remote WINS (that is, the Wins2 replicas are replaced by the newer Srv1 replicas). However, before reconciliation is finished, client connection problems may have occurred, including the inability to connect to a WINS server that split its registration (in this example, Srv1), or the inability to resolve the domain<1c> name that Srv1 registered.

The exact conditions that lead to failure are varied. If your WINS servers are running Windows NT version 3.51 with Service Pack 4 (or greater), these conditions should only be temporary. However, the problem may be more severe depending on your replication scheme or if you are running pre- Service Pack 4 WINS servers.

Another faulty configuration is setting a remote IP address (in this example, Wins2) as Primary while setting the local WINS (Srv1) as Secondary. In this case, Srv1 will eventually stop refreshing its NetBIOS lease at Wins2, and will begin registering locally. Depending on your WINS replication scheme, this may cause connection problems.

WORKAROUND

It is recommended that a WINS server point to itself as Primary WINS and as Secondary WINS. This will avoid split registrations and other problems.

For additional information on some of these other problems, please see the following articles in the Microsoft Knowledge Base:

   ARTICLE-ID: Q135405
   TITLE     : Repairing a Corrupted WINS Database w/ Starting Version
               Count

   ARTICLE-ID: Q168712
   TITLE     : How to Manually Recreate a WINS Database

   ARTICLE-ID: Q150520
   TITLE     : Server Sporadically Loses Name Resolution

STATUS

Microsoft has confirmed this to be a problem in Windows NT versions 3.5, 3.51, and 4.0. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.