One of the things I perhaps should have covered in my Article and previous blog entries on DHCP and WINS design is the process of cleaning up a WINS database of extraneous entries.
When migrating to a new WINS solution, you can go 2 ways: Either start afresh or migrate the old data and clean it up. Starting afresh means no cleanup, but it does mean that for a short while you may find certain machines and services are unavailable on the network and things like legacy trusts may fail. Most Technical Architects will choose to migrate and cleanup.
I will use as an example a recent client, who had a legacy WINS solution running on a large number of Windows NT4 boxes spread across Europe. This was to be centralised to 2 UK based hub sites. When we started the exercise all WINS Servers in all sites replicated with each other in multiple push/pull relationships. There were a number of replication relationships with servers that no longer existed and servers in the parent company that were pointless as the routing model wouldn't allow you access to those hosts regardless. For an organisation with less than 2000 seats, 44000 WINS records was a little high 
The first action (kindly performed by Mecsi) was to hub and spoke the replication model such that ALL WINS Servers only had replication relationships with a single, central server. Mecsi did this to ensure that during the cleanup, records that had been deleted did not accidentally re-replicate back into the database.
The next stage is to remove the "foreign" WINS Servers from the replication model and those which appeared to be errors (there was one with the IP of 0.0.9.1). Once these are gone it is possible to delete owners and remove the records owned by those servers. This should perform most of the cleanup work in terms of bulk and reduce the size of the database to more manageable levels.
Mecsi then moved to get rid of those static entries that were not required. There was a large number of static entries in the database for servers that would normally and reliably self-register. Removal of these would make the database easier to support going forward and allow the WINS Scavenging function to keep the database as small as possible.
During this time we have been deploying the IP Helpers needed to support the new DHCP and WINS Solution and have been able to decommission a number of localised DHCP and WINS Servers in the remote sites. As each one of these servers is shutdown, its WINS Server can be removed from the WINS replication model and its records re-owned by the single server at the centre of the hub. Eventually all remote WINS Servers will be removed and only those in the 2 UK Hub sites will exist. At this point our database should be down to around 5-6000 records in total and is as clean as it is likely to get. This is a far more manageable size for a WINS database and it will mean that an offline defrag will have to be performed on the database file to remove the whitespace left by 34000 deleted records.
Page : 1/1
