Everything You Ever Wanted to Know About WINS

Plus some things you didn’t.

By Russ Bishop

http://www.boneville.net/lanadmin/

 

 

 

 

            WINS, short for Windows Internet Naming Service, was the core name resolution backbone of Windows 95/98 and NT 4, before Microsoft adopted DNS in Windows 2000. Without a proper and reliable WINS setup, your clients will behave unpredictably when attempting to locate other computers and services on the Network.

 

            The first step is to choose a central WINS hub, to which all other WINS servers will connect. Never setup a replication loop with WINS, or you will severely regret it. Once you have selected a server as the central hub, install WINS on it. This must be the PDC Emulator “fismo” role holder, or the PDC Emulator role holder must point to this server. NO EXCEPTIONS. Be sure that you go into the TCP/IP Properties for the server and point its own WINS settings to itself (using its external IP address – not a 127.0.0.1 address. This goes for DNS as well – the DC should always point to itself as the primary DNS using its external IP address.) Once this server is setup and working properly, you can move on to the “spokes.” To verify that it is working, open up the WINS snapin. Right-click “Active Registrations”, then click Find by Owner. Select All Owners, then hit OK. You should see several records under the name of the DC, as well as several records under the name of the domain. If you chose to ignore my instructions above and the PDC Emulator isn’t pointing to this central WINS server, then you won’t find the 1Bh record (Domain Master), which is critical.

 

            Now to setup your spokes, install WINS on them. Once again, point the WINS tab of TCP/IP on the local machine to the machine itself. Do not enter any secondary WINS servers in this tab. If a machine running WINS does not register its own WINS information on itself, you are begging for trouble. Then, you must setup replication. Setup the central server to peer with this “spoke” using PUSH/PULL, and do the same on the spoke. None of the spokes should have more than one replication partner, but the central server should have all the 1st level spokes listed as replication partners.

 

            You can verify that WINS is working by going to a client, ensuring that it is pointing to a proper WINS server, then running this command: “nbtstat –a [hostname]”. A good idea is to test the names of all your DCs in the [hostname] space. They should all resolve properly. You may need to wait up to three hours for all of the WINS servers to replicate among themselves, but once the initial replication has completed, only changes are sent so things should move quickly.

 

 

 

Troubleshooting:

 

 

Q. When I check the WINS database, I do not see my DCs registered, or only one or two services are registered, out of all the ones available. Or, my DC is registered, but it does not show up in the DC record (1Ch).

A. Make sure the DC can ping the WINS server it is registering with, unless it is running WINS itself. Then, ensure that the WINS tab on TCP/IP is setup to point to this WINS server, and no others. Lastly, you can force a re-registration by running “nbtstat –RR” at the command prompt.

 

 

Q. Should our DCs run WINS?

A. That depends. If you only have one server at a location, you have no choice. At a larger location, you could dedicate a single desktop-class workstation to act as the main WINS server (an average desktop unit could service thousands of WINS clients; the WINS packets are not very large, and the registration process isn’t very resource intensive). You are better off just having two WINS servers, a primary and a backup, and possibly one additional at each remote location. If you have a backup server at the main location, it should NOT be setup to replicate with any other servers besides the central hub server. Let me repeat this once more: No WINS server should have more than one replication partner besides the central hub server.

 

 

Q. My client can ping the WINS server and our DCs, but it cannot find the domain and/or cannot resolve WINS names

A. First, run “nbtstat –a [hostname]” on several of your DC names and see if they are resolved. If not, check the TCP/IP configuration of the clients and ensure that they are pointing to the WINS server. If they are, ensure that your router isn’t blocking SMB or NetBIOS IP packets.

 

 

Q. WINS won’t replicate. What should I do?

A. Both servers must be configured to replicate to each other, and in the same format (Push/Pull usually.) If only one server is configured, then it will not replicate with the other one, even if Pull replication is setup.

 

 

Q. WINS is totally messed up, and I can’t fix it. How can I start with a fresh slate?

A. Go one by one to each of the “spoke” servers and remove its replication partner. Then, delete ALL the records (do not tombstone them. Delete them completely.) Once this is done, stop the WINS service quickly. This should ensure that the WINS database on that machine is clean. Once this is done, go to the central hub server and delete everything in its WINS database, then restart the WINS service. Now run “nbtstat –RR” on that machine. Now go back to each of your spokes one by one and restart the WINS service and run “nbtstat –RR” then reconfigure replication. You should have a WINS database that is fairly clean, with only the registrations for each of the servers, plus a few clients that may have reregistered while all of this was going on. This might also be required if you want to change which server is your “central hub”.