Tombstones Mark the Coming of the End for WINS

Improvements in WINS foretell the death of this protocol

Whether you love or hate Windows Internet Naming Service (WINS), TCP/IP is the de facto Internet protocol. Therefore, Microsoft has decided that TCP/IP is the protocol of the future and that NetBIOS name resolution using WINS should die. So the fact that Microsoft is revamping WINS in Windows 2000 (Win2K—formerly Windows NT 5.0) with a host of new features that we could have used a long time ago seems odd. WINS is finally coming into its own with a good set of tools. Unfortunately, Microsoft designed those tools to help you move away from WINS. However, Microsoft acknowledges that any enterprise with a large number of non-Win2K or Windows 98 OSs needs to use WINS for the foreseeable future. Those sites will find that the new utilities and features in Win2K's WINS make managing WINS easier. Those utilities and features will facilitate a site's move away from WINS (which Microsoft terms decommissioning) when Active Directory (AD) arrives. This article will introduce you to some new WINS tools, such as tombstones, that you can expect in Win2K.

General Improvements
The WINS interface in Win2K incorporates many simple but effective changes. When you introduce your first Win2K server running WINS onto your network, you notice the WINS management tool's loose integration with the Microsoft Management Console (MMC). Microsoft has migrated every tool in Win2K to an MMC version. WINS Manager can function as a snap-in tool with your favorite MMC tools. WINS Manager, integrated with MMC, functions similarly to the WINS Manager in NT 4.0. Screen 1, page 100, shows WINS Manager's main window for MOOSE server. Using WINS Manager, you can easily select multiple records and delete them, even if the records have nonalphanumeric characters as part of the name. With WINS and the MMC integrated, the user interface (IU) constantly updates to display a current view of WINS events.

Sites that perform analysis and reporting or track the decommission proceedings of WINS on clients and servers can use a new task called Export WINS Entries to export WINS data to a Comma Separated Values (CSV) file. In NT 4.0 you can do this with the Microsoft Windows NT 4.0 Resource Kit utility WINSDUMP. The Win2K resource kit might not have this utility available. Even if the utility isn't available, you can right-click the Active Registrations folder to access Export WINS Entries. After you export your data, you can use Windows Scripting Host (WSH), Microsoft Excel, or another tool to manipulate the file you created.

WINS Manager has an improved search facility called Quick Find, and a Set Filter facility. You can access both facilities by right-clicking the Active Registrations folder, which you see in Screen 1. The facilities create different views of existing data, letting you easily switch between subsets of your WINS database. Quick Find is basic; it prompts you for the beginning letters of the NetBIOS names you want to find and uses the results pane to display matching names. Although Quick Find uses a drop-down box to let you select a previous search without retyping the entry, NT 5.0 Beta 2 doesn't preserve these searches after you exit the application.

When you select Set Filter, the Type Filter window opens, as Screen 2 shows, letting you filter by type of entry. By default, all Type Filter check boxes are clear. If you check some of the boxes and click OK, the results pane displays only items that match the filter. Screen 3 shows filtered records for the check boxes selected in Screen 2. The drop-down menu that you see in Screen 3, which you open by right-clicking the results pane, lets you switch between views of the results of your filtered records, the filter database, or the whole database.

To set up your own filter for a NetBIOS machine type, you need to add a hexadecimal entry to filter against. To create a new hex entry, use the Add key you see in Screen 2. Specify the entry and a description to filter against. An example of an added entry is the 30H entry called My own Filter. Unfortunately, added filter items remain after you close WINS Manager, and in Beta 2 this tool doesn't delete entries.

Two other MMC snap-in tools, Check WINS Database Consistency and Check Version Number Consistency, let you check the consistency of your WINS database. WINS database consistency checks force the server to compare its IP address database with the IP address databases of every WINS server on the network. To do so, the server transmits NetBIOS name-query check requests to every object's host server. This process generates network traffic and uses processing power, so you wouldn't want to do consistency checks during normal network operation. Scheduling consistency checks during lighter hours of network operation simplifies maintenance. Screen 4, page 102, shows the Name Record tab for the WINS server MOOSE. The tab's lower section lets the check operation start at a particular time and at periodical intervals. You can also specify how many records to search, to limit how much time a check will take.

Version number consistency checks force the WINS server to examine every entry in its IP address database to ensure that each entry has the most recent version number. This operation can take time, and a message notifying you of the time requirement appears before the process starts, giving you an opportunity to cancel the check. Once the check begins, the Consistency Check Status window opens and displays process information.

Win2K and Win98 let systems administrators specify up to 12 failover WINS servers for each client. Having 12 WINS servers for failover seems unusual. But the larger number ensures WINS server availability and makes this level of fault tolerance useful.

Persistent Connections
In the past, whenever a WINS server needed to initiate replication, the server opened a connection to another server. WINS in Win2K offers you the option to let WINS servers keep persistent connections open with one another. At first glance, the act of opening and closing connections doesn't seem as if it would take much time, but systems administrators who manage large WINS environments know that this process does take time. Most administrators group WINS updates, so that a server replicates data to its replication partners only after achieving a certain number of updates or after a certain amount of time passes. However, some systems administrators find that the act of opening a connection to a replication partner can take a while even with grouped updates, and by the time the server replicates information, data might already have changed. A more sensible approach is to maintain persistent connections—idle connections that remain open between servers—so that a WINS server can replicate required updates.

Setting persistent connections is easy. Left-click Replication Partners from WINS Manager, and from the servers list, select a server with which to replicate data. Right-click the server name to obtain a drop-down menu to select replication properties. The Advanced tab of the Properties page that Screen 5 shows lets you set Replication partner type. Screen 5 shows the parameters for both the push and the pull replication partners. The push partner's parameter is a selected number of updates to store before initiating replication, whereas the pull partner's parameter is a set start time and replication interval. The option to set a persistent connection is available for both push and pull replication partner types.

Burst Handling
WINS in Win2K goes a long way toward solving the overload that occurs when many clients register their NetBIOS names with a new WINS server at the same time. A WINS server can easily become overloaded and labor under the load of many clients attempting to register, and the clients must wait for the server to register their names. With Win2K, you can enable burst handling to overcome this problem. Burst handling uses a mode that lets the WINS server detect high registration levels and efficiently process high volumes of incoming registrations. After you enable a server for burst handling, a server that detects a heavy registration load will begin burst handling according to the default set. When the server begins burst handling, consider WINS registration as effectively split into two processes. In the first process, incoming name registrations form into a queue, and the server sends the clients a positive registration response and a Time to Live (TTL). The second process registers items from the queue in order of receipt.

The TTL values vary according to when WINS receives the client name requests. The Low setting is for a burst queue size of 300, which Screen 6 shows. The default WINS burst queue of 500 is the Medium setting, and the High setting is for a burst queue size of 1000. Alternatively, you can enter a Custom value between 50 and 5000 for the queue size. When you use the burst queue default of 500, entries 501-600 receive a TTL value of 5 minutes, as Table 1 lists. Once burst mode reaches 50 minutes, the TTL value resets to 5 minutes with increments of five for every hundred registrations. If the number of registrations reaches 25,000, then the server drops incoming registrations. When you use burst handling, you slow down the client bombardment of WINS servers and stagger incoming requests over an hour or so.

Burst handling solves the problem of the server registering clients close together with standard TTLs that require the clients to return at roughly the same time to renew their registration, and cause server slowdowns. Client returns at staggered intervals lessen the impact on the server. For this reason, staggered TTLs are best for batches of machine registrations. Clients then renew in batches at 5-minute intervals, not at the same time. The client needs a quick confirmation of WINS registration, or the user will become annoyed at the delay. Therefore, the server sends an immediate registration confirmation to the client. Now the satisfied client appears registered, but the server merely appended the request to the processing queue. As long as less than 25,000 registration requests come in at a time, the server continues to add requests to the queue and processes them sequentially, seeing that none become lost.

Tombstones
The most profound change to WINS in Win2K and NT 4.0 Service Pack 4 (SP4) is the inclusion of tombstones. To understand tombstones, consider the reason for their existence. If you have a WINS database in pre-SP4 NT 4.0 and want to delete a static record, you must identify the host WINS server for the record and delete the record from the host server. If you want to delete a dynamic record, you're out of luck. You can try to delete a dynamic record from any one server, but another server might restore the entry by replication. After all, replication is what WINS is all about.

Tombstones let you delete dynamic records by flagging a record as extinct. Using WINS Manager, you can select a dynamic record from the WINS server that hosts the record and mark the record with a tombstone. Deleting the record triggers a dialog box that asks whether you want to delete the record locally, or flag it as a tombstone. When you flag a record as a tombstone, the WINS database doesn't instantly remove the record. However, the tombstone marks the record extinct, so other clients that attempt to resolve the record's NetBIOS name get a failure response. A tombstone marks a record for later deletion in the database and prevents clients from using it in the meantime.

As soon as replication occurs on the server hosting a record marked as a tombstone, the tombstone entry propagates to the server's replication partners. When partners receive the tombstone, they stop responding to queries for that record and mark the dynamic entry with a tombstone in their database. This process continues throughout the network of WINS servers until every server marks the record with a tombstone and stops resolving the record's name-query requests.

You use four key values to specify how much time transpires before WINS removes a record marked with a tombstone from the database. You can see these values under Name Record Settings in Screen 4 and can modify all the default values. Renew interval, also known as the TTL, states the length of time allowed before a client must renew its WINS database entry with its host server. The default TTL is 96 hours, and clients try to renew at one-half TTL, or 48 hours. If the client doesn't renew in the set time (i.e., between the beginning of day 3 and the end of day 4 under the default settings), the WINS server releases the record from database use. Extinction interval is the number of days required before the server marks an entry as a tombstone. The Extinction interval value must be greater than or equal to the Renew interval. Extinction timeout is the set length of time—6 days as the default—between when the server marks an entry as a tombstone and when the server marks the entry expired. After a preset Verification interval, WINS deletes the record from the database during a scavenging operation.

You can accept the Name Record Settings default settings. If you accept the default settings, and a client releases a record manually or fails to renew the record within the 4-day Renew interval, the database marks the record released. Because the Extinction interval is also 4 days, the database immediately marks a released record extinct and adds a tombstone. During the next 6 days of the Extinction timeout, the tombstone replicates to the WINS server's replication partners. After 6 days, WINS marks the record expired, preventing further replication. Then, 24 days later, the default length of the Verification interval, a full scavenging operation occurs and permanently removes expired records from the WINS database. This entire process takes 36 days.

The new WINS Manager snap-in tool for the MMC helps you to mark entries as tombstones. You can select as many entries as you want to flag as tombstones. In addition, you can choose to flag all the entries on a specific server as tombstones. One word of caution: You must always flag records as tombstones on the client's host server (i.e., the server that accepted the client's original registration). Entries you flag as tombstones on any server other than the client's host server won't replicate to the host server with the tombstone flag. Also, leaving records unmarked on a host server lets that server replicate the records to other WINS servers, removing that record's tombstones as it goes.

Decommissioning
Client machines must drive decommissioning, because administrators configure the clients to use WINS. When you prevent WINS client configuration and convert clients to the Domain Name System (DNS), decommissioning obsolete WINS servers is simple. To prevent WINS client configuration, remove any WINS server addresses from Dynamic Host Configuration Protocol (DHCP) and configure clients with the correct DNS server. If you manually set up clients, remove the primary and secondary WINS addresses on the client and verify that the client's configuration is for the correct DNS server. To begin decommissioning, go to WINS Manager and select the server to decommission. Next, flag all entries on that server as tombstones, and choose replicate from the Task menu. Once replication completes, you can remove WINS from that server.

Although WINS Manager and the MMC in Win2K can manage any WINS server, the server you want to decommission might not be a Win2K or NT 4.0 SP4 server. Pre-SP4 NT 4.0 or NT 3.5x servers can't receive tombstone entries, and those servers' records require you to manually delete them using the WINSCL application from the resource kit.

Dynamic Decommissioning
The last great new ability is the dynamic re-registration of clients without your having to reboot. Now you can use the nbtstat command-line utility and carry out a nbtstat-Resource Record (RR) to get a newly updated WINS server and client. This ability is a great bonus for WINS Manager users.

Microsoft made WINS in Win2K a more useful and configurable tool for systems administrators. WINS integration with the MMC and the easy-to-handle settings eliminate the need to delve into the Registry. Burst mode and persistent connections help prevent network slowdowns from bulk registrations and replication traffic. Tombstones are a key new technology, and a new feature in NT 4.0 SP4. Everyone using WINS in NT 4.0 SP4 can easily remove WINS from their networks by replicating tombstones throughout the network when Win2K comes. With WINS flagged as a tombstone in Win2K, Microsoft nevertheless acknowledges that you might wait longer than 36 days after the release of Win2K before WINS finally disappears.