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.
Previous
