This article was previously published under Q150737
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 serverpoints to for it's own name resolution (this parameter is set in theNetwork section of Control Panel, in the Configuration section of TCPIPProtocol).
We recommend that a WINS server point to itself as Primary WINS in the TCP/IP configuration. If you try to specify the same WINS address in the Secondary WINS address, you receive a "The WINS server is already in the list" error message. The configuration can be set by using the registry. However, because the address is already entered, you do not have to add it again.
We recommend that a WINS server always point to itself as Primary WINS only. This configuration avoids split registrations and other problems.
For additional information on some of these other problems, please see thefollowing articles in the Microsoft Knowledge Base:
135405 Repairing a corrupted WINS database w/ starting version count 168712 How to manually recreate a WINS database
150520 WINS server sporadically loses name resolution
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.
When any WINS enabled computer is booted it must register a variety ofservices with WINS. Commonly a computer has a Primary and Secondary WINSaddress configured in the TCP/IP setup. If the Primary WINS does notrespond to the registrations, the computer tries the Secondary WINS.
For additional information on the services that can be registered, pleasesee the following article(s) in the Microsoft Knowledge Base:
Generally, most clients and servers should be configured with a Primary andSecondary WINS address, however caution must be taken with how a WINSserver is itself configured. A WINS server eventually registers its servicesin its own local WINS database, regardless of whether it points to itselfor not (either Primary, Secondary, or none). Registering with itself andanother WINS server can cause problems when it comes to replication andrenewal of these entries.
For example, if you have a WINS server ("Srv1") that points to itself asPrimary and points to another WINS as Secondary ("Wins2"). When Srv1 isbooted, it usually tries to register its services before its own WINSService is started. Since those registrations fail, it tries to registerthem at Wins2. If Wins2 is available, it accepts the registration requests.However, not all the services are registered at Wins2, because as theseregistration requests are made, Srv1 continues to check its local WINSservice. Once the service is running, it switches back to it and continuesregistering locally.
After replication has occurred between Srv1 and Wins2, both databases showthis 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
This potentially problematic condition is referred to as "splitregistration."
At this point, Srv1 has reverted to re-registering locally, however ittakes a while before you can see it. Meanwhile, Srv1 and Wins2 arereplicating 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 haveoccurred, including the inability to connect to a WINS server that splitits registration (in this example, Srv1), or the inability to resolve thedomain<1c> name that Srv1 registered.
The exact conditions that lead to failure are varied. If your WINS serversare running Windows NT version 3.51 with Service Pack 4 (or greater), theseconditions should only be temporary. However, the problem may be moresevere 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 thisexample, Wins2) as Primary while setting the local WINS (Srv1) asSecondary. In this case, Srv1 will eventually stop refreshing its NetBIOSlease at Wins2, and will begin registering locally. Depending on your WINSreplication scheme, this may cause connection problems.
System error 53 occurred network path not found log logon ntfaqipr
Microsoft Windows NT Workstation 3.5, Microsoft Windows NT Workstation 3.51, Microsoft Windows NT Workstation 4.0 Developer Edition, Microsoft Windows NT Server 3.5, Microsoft Windows NT Server 3.51, Microsoft Windows NT Server 4.0 Standard Edition, Microsoft Windows Server 2003, Standard Edition (32-bit x86), Microsoft Windows 2000 Server