WINS Replication in Windows 2003
If a job’s worth doing, then its worth doing well. In situations where you must have WINS, then configure it properly and have multiple WINS servers for load balancing and fault tolerance. Once you have a second WINS server, then you need to configure replication. Actually it’s good fun setting up Push and Pull replication.
Topics for WINS Replication
The scenario, you need to configure a WINS server for Push and Pull replication. Assuming that you have installed WINS and the clients have registered their records, its time to pair up the servers for WINS Replication. So, launch the WINS snap-in. Click on the server icon and expand the folders. right-click on Replication Partners and choose ‘New Replication Partner’.
Of all the exam questions that I have ever answered, WINS Push / Pull replication just will not stop whizzing around my brain. The rule for WINS replication is Push on number of changes, Pull on time is the rule that drums in my head.
As luck would have it, I applied my exam knowledge to a client who could not get replication to work. They set the number of changes to 999 and as they only had a small number of clients, WINS changes was never going to approach such a high threshold.
The real moral of the story is to always configure both Push and Pull, that way you hedge your bets that sooner or later the WINS severs will replicate and so each will maintain an up-to-date database.
Once you have added all the other WINS servers, go back to the Replication Partners folder and this time right-click properties. Now select the Push Replication or Pull Replication and choose the appropriate settings, for example 20 changes for Push, 30 minutes for Pull replication.
The only advantage of configuring just Pull replication is that you can control the timing and schedule replication when network traffic is low.
Tombstoning is a concept that I first learnt many years ago in WINS and applied to other topics such as Active Directory restore. The best way to understand tombstoning is to take the negative angle and say, what would happen if there was no tombstoning? The answer is that if you just deleted a WINS (or Active Directory) record, then a replication partner would replace or re-instate that record, so it could never be deleted. In other circumstances this ‘self heal’ would be an advantage, but with deleted records it would be a liability.
Think of tombstoning as marking the WINS record – inactive. After a few replication cycles, all the WINS servers know about these inactive records. Then later after a time delay called the Extinction Interval, the operating system removes the tombstoned records. The key point is that the replication partners know not to try and resuscitate those deleted records.
SolarWinds’ Network Performance Monitor will help you discover what’s happening on your network. This utility will also guide you through troubleshooting; the dashboard will indicate whether the root cause is a broken link, faulty equipment or resource overload.
Perhaps the NPM’s best feature is the way it suggests solutions to network problems. Its second best feature is the ability to monitor the health of individual VMware virtual machines. If you are interested in troubleshooting, and creating network maps, then I recommend that you give this Network Performance Monitor a try.
It’s easy to configure each WINS server with a Push Pull partner. Remember to Pull on time and Push on number of changes. The benefit is an up-to-date database so the clients get name resolution of their resources.
If you like this page then please share it with your friends