| Downloads |
|---|
| 21284.zip |
Administrators of globally dispersed Windows NT networks often face WINS-related operational and maintenance problems. Administrators install WINS on selected servers to make resources outside local network segments visible. Without WINS, servers can't propagate the identities of domain controllers (DCs) that exchange browser information. The NT browser service provides the domain and computer icons that appear when you use Network Neighborhood to explore the network. WINS provides the browser service with the names, IP addresses, and services of those computers configured to register their information with the local WINS server. WINS stores this information in a database.
WINS servers exchange their information with other WINS servers by replicating their databases with assigned partners. After replication has been active for a while, the databases participating in WINS replication are almost identical. Although the replication of databases is one of WINS's most appealing features, WINS replication can make network management and troubleshooting difficult, especially when you have many WINS servers. WINS provides mechanisms to automatically eliminate inactive entries that result from computer removal, relocation, and configuration changes. However, you'll invariably need to clean up your WINS databases once or twice a year so that they provide accurate information.
Forget the Broom—Grab the Vacuum
Manually cleaning up WINS databases on a few servers in a small LAN is easy and has little or no effect on users. If you have one server, you just need to stop WINS and delete all the files from the %windir%\system32\wins directory (typically, the C:\winnt\system32\wins directory). After you restart WINS, the service creates a new database that contains the server's registration data.
If you have two or three servers that replicate with one another, you need to stop WINS on all the servers, delete all the old database files, then coordinate the restart of WINS on all the servers. Before you restart WINS, you need to make sure you've deleted all the old database files. Otherwise, WINS will replicate the old files to all the WINS databases.
Although manually cleaning up databases is easy if you have only a few WINS servers, you need to trade in the broom for a vacuum if you have many WINS servers. To automate the process of cleaning up databases, I've developed a cleaning process in which you run a series of scripts. The cleaning process I developed minimizes network interruption for users and saves time for administrators.
I've used this cleaning process at my company, which has large WINS networks in the United States, Asia, and Europe. Bridgehead servers segment the large WINS networks into smaller segments for replication control and troubleshooting. I used the process to clean up 15 WINS databases in the United States and Asia, then let the resulting databases replicate with the other WINS databases in Europe.
The Scripts
The cleaning process uses seven short scripts: PingAll.cmd, DoNbt.cmd, CopyDoNbt.cmd, SchedNbt.cmd, StopWins.cmd, DelWins.cmd, and StartWins.cmd, which you can find in the Code Library on the Windows Scripting Solutions Web site (http://www.winscriptingsolutions.com). You use PingAll.cmd to create an input file that several other scripts use, so you need to run this script first. (For information about the scripts' input files, see the sidebar "Creating the Input Files.") Next, you need to work with the DoNbt.cmd, CopyDoNbt.cmd, and SchedNbt.cmd scripts. Finally, you use the StopWins.cmd, DelWins.cmd, and StartWins.cmd scripts, which are the heart of the cleaning process.
The seven scripts use basic NT shell commands and the Service Communications (sc.exe) utility in the Microsoft Windows NT Server 4.0 Resource Kit. Thus, these scripts are good examples of how a little scripting knowledge and a willingness to experiment with resource kit utilities can help you reduce the time you spend—and your stress level—when you perform maintenance procedures. I wrote the scripts for machines that run NT Server 4.0 Service Pack 5 (SP5). The system root on all the servers is C:\winnt.
PingAll.cmd. A script that pings computers probably exists on every administrator's workstation. As Listing 1 shows, PingAll.cmd uses the Ping command to perform a one-time ping of the servers listed in the input file called servlist.txt. The script redirects the Ping command's output to the output file pinglist.txt, which you use to create the input file winsiplist.txt. You can run PingAll.cmd anytime before the actual cleaning begins. To use this script, you need to customize the servlist.txt and pinglist.txt paths.
DoNbt.cmd. The script that Listing 2 shows uses the Nbtstat command to force a computer to immediately register with the WINS server that's either defined statically in the TCP/IP configuration or defined dynamically by the DHCP service. The Nbtstat command is available only on NT 4.0 computers running SP4 or later. The two Rs in the switch must be uppercase.
You use CopyDoNbt.cmd to place the DoNbt.cmd on each computer and SchedNbt.cmd to schedule DoNbt.cmd to run. You want this script to run after you've cleaned all the WINS databases and restarted WINS on all the servers. If you don't use this script to force the computers to register, they'll register at the standard time intervals that WINS sets, which means that the registration process might take hours. In my case, the registration process would have taken about 6 hours to complete without this script.
CopyDoNbt.cmd. As Listing 3 shows, CopyDoNbt.cmd uses the Copy command to place a copy of the DoNbt.cmd script on all the servers you list in servlist.txt. CopyDoNbt.cmd redirects the Copy command's output to a log called copynbt.log. You can review this log to verify that all the servers in servlist.txt were online when CopyDoNbt.cmd executed and therefore have a copy of DoNbt.cmd.
You can run CopyDoNbt.cmd anytime before the actual cleaning begins. To use CopyDoNbt.cmd, you need to customize the servlist.txt, \winnt\system32, and copynbt.log paths. CopyDoNbt.cmd must reside in the same directory as DoNbt.cmd.
SchedNbt.cmd. As Listing 4 shows, SchedNbt.cmd uses the At command to schedule the DoNbt.cmd script to run on the computers at the same time regardless of the time zone. The At command's /next parameter specifies the day of the month to accommodate the 13-hour time difference between Eastern time and Asia.
I configured SchedNbt.cmd to run DoNbt.cmd at 6:00 p.m. Eastern time. You can easily change this time by customizing SchedNbt.cmd, but you must make sure that the corresponding times in the other time zones are correct. You should run SchedNbt.cmd the same day that you plan to clean the WINS databases.
StopWins.cmd. As Listing 5 shows, StopWins.cmd uses sc.exe's Stop command to stop WINS on each server. Although the syntax for the Stop command uses NetBIOS names as the primary parameter, the command also works with IP addresses, as do many other NT commands and GUI tools. The input file winsiplist.txt provides StopWins.cmd with the IP addresses of the WINS servers.
DelWins.cmd. DelWins.cmd deletes the WINS databases. As Listing 6 shows, winsiplist.txt provides the IP addresses that the script needs to connect to the WINS servers. The script then deletes the WINS database files and creates a log called deletewins.log. You can review this log to verify that DelWins.cmd has deleted all the WINS databases. The Pause commands let you view the deletions on screen.
About 5 minutes after you launch DelWins.cmd, the computers' NetBIOS caches start to flush and the named resources outside of the local network begin to disappear. Losing sight of these familiar domain icons can be an uncomfortable experience, but rest assured, their disappearance is intentional.
StartWins.cmd. After you review deletewins.log to verify that DelWins.cmd has deleted all the WINS databases, you can use StartWins.cmd, which Listing 7 shows, to restart WINS. Like DelWins.cmd and StopWins.cmd, StartWins.cmd uses the IP addresses in winsiplist.txt. However, unlike the other scripts, StartWins.cmd would fail if you were to substitute server names for the IP addresses because, at this point, you don't have any WINS databases to resolve the server names to IP addresses.
In my company's case, I ran StopWins.cmd followed by DelWins.cmd at 5:30 p.m. By 5:45 p.m., I had verified that DelWins.cmd had deleted all the WINS databases. With all the databases gone, I ran StartWins.cmd, which required only 2 minutes to restart WINS on all 15 WINS servers. After DoNbt.cmd ran on each server at 6:00 p.m, I performed a manual WINS replication between all the partners in the network. By 6:30 p.m., all the servers and their domains were fully operational. The total blackout period was less than an hour.
One More Script
Depending on the type of authentication you use in your network, you might need to perform one more task to finish the cleaning process. If you use pass-through authentication, you need to reset the account DCs that each resource DC uses. In large networks that use the master-domain model architecture, you place account DCs at resource domain locations to allow authentication locally instead of across WAN links. This setup is especially important if logon scripts are extensive or require applications such as Microsoft Systems Management Server (SMS) to run properly. If the account DC becomes unavailable at a resource site, the system forces authentication to proceed at an account DC in another remote location. The system continues to direct authentication to the secondary account DC until you reboot the primary account DC or you use the Set Preferred Domain Controller (setprfdc.exe) utility to reset the primary account DC. (SP4 includes this utility.)
Listing 8 contains the script SetDc.cmd, which uses setprfdc.exe to reset the primary account DC. This script contains the names of the locally available account DCs for distribution to each resource DC. Because each resource domain is typically at a different location, the parameters (e.g., ADC1) point to different servers. Thus, SetDc.cmd differs for every site.
To use SetDc.cmd, you need to replace AccountDomainName with the name of the domain in which the primary account DC exists and ADC1, ADC2, and ADC3 with your account DCs in order of preference. You can add or remove account DCs as needed. After you customize SetDc.cmd for each site, you can run the scripts. You can even schedule the scripts to run regularly to minimize logon times and keep authentication traffic local.
Let the Cleaning Begin
Cleaning up WINS databases once or twice a year is essential for a dependable, efficient network, especially if you have many WINS servers. If you use the cleaning process I developed, you can minimize disruptions to users, save time, and reduce stress.
