Implementing Enterprisewide WINS

Expiration Dates
The expiration date associated with a WINS record tells WINS how long to keep a given record active. Referring again to Screen 3, you'll notice two columns in the database display window--column A and column S. Column A shows that the record is active, and column S shows that the record was statically mapped. Active means that the record is still valid in the database, that it has been renewed, and that it is a live record. Static records are those that have been manually added to the WINS database. Normal records are dynamically registered with WINS. If a record has been dynamically registered, column S will be blank. Column A can have three different indicators--a check mark to indicate active, a dash to indicate released, or a cross to indicate the record was tombstoned, or extinct. The expiration date for records registered with a given WINS server is derived from the WINS configuration parameters for that server.

To configure the WINS server, go to the WINS Administrator tool main menu, select Server, Configuration, to view the basic and advanced configuration options (as shown in Screen 4). The basic portion of the screen includes four time intervals you need to configure on a WINS server--the Renewal Interval, Extinction Interval, Extinction Timeout, and Verification Interval. These values control how often your WINS clients need to reregister with the WINS server and how long a given registration is good. Also, they control how long a record remains active in the database.

A dynamic WINS record will go through three phases of life before it is scavenged, or removed, from the database. When a machine first registers, the records associated with it are marked active. A machine will then reregister with WINS at half the time set for the Renewal Interval. If the machine fails to reregister by the end of the Renewal Interval or if you shut down the machine, the records associated with it will be marked released (the second phase). After a record has been marked released, the Extinction Interval specifies how long that record is to remain in released mode before being marked tombstoned. Finally, the Extinction Timeout specifies how long tombstoned records are to remain in the database before they are scavenged. The delay between releasing a record and marking it tombstoned is useful, because often a machine may simply be powered down for a short period, and when the machine comes back up, it can reregister using the existing, released records.

These intervals are important in replication, because a partner of a WINS server will not pull records if those records will become extinct as a function of replication. Suppose that a set of records on WINS Server A are due to expire in one day, and you're replicating those records to WINS Server B. WINS Server B's system clock thinks it is already one day later. Server B fails to replicate the records because it believes the records are extinct. You need to time synchronize WINS servers in your environment as closely as possible to avoid such problems.

Designing a Replication Scheme
Before you design a replication pattern for all WINS servers in your environment, you need to consider a couple of things. First, the goal in any enterprise WINS configuration is to have as few WINS servers as possible. In a large network, WINS can be a very problematic service, and you will thank yourself later if you simplify your design. How many servers are too many? Depending on your network topology, you wouldn't be out of line to have four WINS servers for 20,000 devices. The prime driver behind your design should be to balance availability of name resolution services related to your network topology vs. the need to minimize the number of WINS servers in the environment. You also need to know that all of your WINS servers must replicate with each other if you want every machine in your environment to be able to resolve every other machine. Even if you don't want this resolution, you're probably asking for trouble if you try to segment WINS servers for purposes of securing certain machine names. There are better ways to provide security.

Once you have decided how many WINS servers you will need to support, keep in mind two important goals when creating a WINS replication plan. First, keep a replication path no more than two "hops" deep. That is, if WINS Server A replicates with WINS Server B, and WINS Server B replicates with WINS Server C, then WINS Server D needs to replicate with WINS Server B. The second design goal is to create a replication scheme that meets the minimum convergence required to keep your environment consistent. Convergence is the time necessary for changes to the database of one WINS server to propagate to all other WINS servers.

In addition to these design goals, several best practices have come about since WINS has been around. First, when you establish replication between two partners, the partners must be both push and pull partners with each other. I haven't found a configuration that yields a consistent result if it isn't using two-way push-pull. Second, make sure that between a given pair, the push-pull configurations are the same. For example, if the pull interval on Server A is every 3 hours starting at midnight, the interval must be the same on its partner.

Finally, forget about installing WINS on a multihomed server. You can do this installation, but you're asking for trouble. WINS wasn't designed to work well with multihomed configurations, and it can cause some weird problems with replication, such as failing to replicate.

So, what does a replication design look like that takes into consideration no more than two hops and quick convergence? Figure 1 shows an example of a replication design for five WINS servers. WINS Server A acts as the hub server. All WINS client machines will point to this server as their secondary WINS server. All the other WINS servers--Server B through Server E--will act as primary servers. In this hub-and-spoke design, each WINS server replicates the records that it owns to Server A, which in turn, replicates them to its partners. When replication is complete, each WINS server will have the entire database of WINS registrations for the enterprise.

In this design, convergence becomes a function of the push-pull parameters you define on each partner. For example, if you set the Push count to be 20 (the minimum) between Server A and Server B, but 40 between Server A and Server C, then Server C will take longer to replicate changes with Server A. You can adjust the pull interval to reduce or increase convergence time. For example, WINS Server C needs to know as soon as possible when new records are registered on Server D. You can set the pull interval between Server C and Server A and Server D and Server A to be small, such as every 30 minutes. This adjustment means that the maximum time for a new registration to get from Server D to Server C is 1.5 hours.

Of course, you need to balance replication intervals with the network bandwidth consumed and the amount of changes your WINS servers are experiencing. By monitoring your WINS servers and network with a tool such as Performance Monitor, you can establish a baseline from which to adjust replication as needed.

Maintenance of WINS
Establishing replication between your WINS servers is the easy part. Keeping them up and running with a consistent database is tricky. If you're maintaining NT 3.51 (or NT 3.50) WINS servers, you probably know you must jetpack the WINS database periodically. Jetpacking is the process by which you compact and rewrite the WINS database. The jetpacking process in NT 3.5x requires you to manually stop the WINS service, run jetpack.exe, then restart the service. This process needs to occur frequently (once a week on an active WINS server), to keep the database consistent. The easiest way to jetpack in NT 3.5x is to create an AT scheduler job to perform the activity after hours. However, with NT 4.0, Microsoft added online jetpacking to WINS. Now NT jetpacks the WINS database automatically. This automation is a boon, because it means that the database is always consistent. However, if you need to jetpack an NT 4.0 WINS server, you can still do it manually.

If you're considering static mappings, think carefully about this decision. Do everything you can to avoid using them. In a multiple WINS server environment, after you replicate static mappings, getting rid of them can be very difficult. This problem occurs because static mappings effectively have no expiration date--most expire in the year 2038. They don't expire out of the database on replicas, even if you remove them from the server that created them.

Because NT bases replication on version ID and NT never increments a statically mapped record's versions, the best way to remove the statically mapped records from replicas is with the Delete Owner function in the Show Database view of the WINS Administrator tool (or manually delete the statically mapped records individually, using the WINSCL tool in the Microsoft Windows NT Server Resource Kit). Delete Owner tells a WINS server to delete all the records of a selected owner. For example, suppose Server A push-pull replicates with Server B, and you've statically mapped several records on Server B. You decide you want to remove the static mappings on Server B. To remove them from Server A, you need to perform a Delete Owner operation on Server A for Server B's records. This operation has the effect of removing all the records owned by Server B, which means that these records won't be available on Server A until they have been repulled from Server B.

Use static mappings only as a last resort when you can't get a device or service to register dynamically. Some people use static mappings to register clients that are incapable of being WINS aware, such as UNIX-based systems. However, you're probably better off using DNS or even the hosts file in %systemroot%\system32\drivers\etc rather than keeping the static mappings in WINS.

Troubleshooting WINS
Several problems manifest themselves if your WINS databases are corrupt or in need of jetpacking. Examples include devices that cannot register with the database, or records that aren't replicating properly. You may also see evidence of corruption from the WINS Administrator tool if you view the database. Records that contain garbage characters or invalid expiration dates are good indications of problems with the database. To deal with these problems, you may have to explicitly stop WINS and jetpack the database. (Be aware that static mappings, by default, appear in the database with an expiration date of 1-18-38--this date is 2038, and is OK.) You may also need to perform a Delete Owner operation on the offending records to remove them from the database. Delete Owner can be a tricky operation in a replicated WINS environment. Before you perform this operation on a WINS server, turn off replication between the server and all of its replication partners. Then perform the operation, and reestablish replication. Finally, you will need to perform this operation on all servers that contain the offending owner. If you don't, you'll find the bad records replicating again. After you perform a Delete Owner, stop WINS and jetpack the database to ensure the records were removed.

You can use the WINSCL tool to remove individual corrupt records or groups of them from a WINS database. You can use the resource kit utility WINS CHK to test your WINS server's health on an ongoing basis. WINSCHK can take two text files as input (servers.txt and names.txt) and check the contents of names.txt (a set of names that you want to verify is in the database) against a list of WINS servers in servers.txt. It can also perform periodic communications checks against WINS servers, or verify version number consistency.

Microsoft recommends that a WINS server reference itself only in its WINS client configuration. Failure to do so can actually cause database corruption problems. For example, if you have a WINS server whose IP address is 192.168.100.10, the Primary and Secondary WINS server reference that you configure in that server's TCP/IP properties must each point to itself--192.168.100.10.

Replication Problems
If you find that records simply aren't replicating between WINS servers, you can do several things. First, look at the system event logs on the servers involved to check for any useful messages. You can turn on Log Detailed Events in the WINS Administrator configuration screen while you're troubleshooting problems. This step will let you get more detail in the event logs for problems. Make sure you turn off this event log after testing--it can be quite a CPU drain. Second, you can force replication manually from the Replication Partners menu item in the WINS Administrator tool. As a final test, make sure that the WINS servers involved can resolve their partners by name. I have seen a situation where replication fails because the partners were not resolvable by name.

If you search Microsoft's Knowledge Base with the keyword WINS, the number of problems that Microsoft documents with this service will amaze you. The best advice I can give for designing an enterprisewide WINS implementation is to keep it as simple as possible, with as few WINS servers as possible. Keep all replication parameters between pairs consistent, and monitor the WINS servers closely using both event logs and Performance Monitor.