WINS Proposal

Executive Summary

Establish a new WINS service in DC/NS to supply WINS service for sites which choose to use it including those sites migrating into the UAB Windows 2000 Forest. The WINS service maps Microsoft-style machine names to IP Numbers. While, Windows 2000 reduces the dependency on Microsoft-style names towards Internet (DNS) names, WINS must continue to be supported to allow older machines to interoperate with Windows 2000. There are several WINS sites presently running including those in the Cancer Center, Engineering, and others. Many of these WINS servers share information to provide better cross-unit access as needed.

It is proposed that the new WINS be established as an infrastructure service, linked to the existing WINS network, and announced. It is anticipated that many units' administrators will migrate to the new WINS service in the course of doing other client maintenance so it is important to provide a long migration window.

This proposal is loosely associated with the Windows 2000 project since one of the Cancer Center's WINS servers is tied in with it's Exchange service.

Present system

The present WINS structure is approximately a hub-and-spoke model with the Comprehensive Cancer Center (CCC) as the hub.

Server	IPAddress	Comment
CCCADMIN	138.26.196.15	CCC Primary WINS(center hub)
CCCTECH	138.26.196.27	CCC Backup WINS, with Exchange Bridgehead
ENGWINS	138.26.84.2	ENG Primary WINS
ENGFS1	138.26.84.13	ENG Backup WINS
DMZW1	164.111.90.11	Behind firewall
DMZW2	164.111.90.12	Behind firewall
DMZS1	164.111.90.10	Behind firewall
INFSYSNT1	164.111.168.17	PEDS/Childrens, dark IP issues

All WINS servers perform both push/pull replication with CCCADMIN except DMZW1, DMZW2 and DMZS1 (which CCCADMIN pulls from).

Presently, the WINS database occupies about 23.6MB. CCCTECH is a 400MHZ dual processor machine with 256MB of RAM which is also supplying several other services.

Proposed system

It is proposed that two Windows 2000 member servers be brought up to run WINS. These machines should probably be on separate subnets similar to the DNS deployment (although WINS is only intended to support activities inside UAB.) The member servers essentially need to be large enough to run Windows 2000 . Proposed names: UABWINS1 and UABWINS2.

Over time, the retiring of other WINS servers should be encouraged. Those that remain should probably be re-sited to use the infrastructure WINS (UABWINS1) as the hub.

Figure 1: UAB WINS including proposed additions

The two UABWINS servers are proposed to be 900MHz single processor boxes with RAID drives and 100Mb/s network connections. They would run Windows 2000 Server and be housed in Rust in the machine room.

Process

1. Development of this document
2. Review of document by DC/NS
3. Review of document by larger group of affected folks including the Cancer Center.
4. Presentation to TIMGROUP members
5. Revisions
6. Identify or purchase two servers
7. Install WINS, Test. The two servers will be arranged as push/pull partners.
8. Establish connection with CCC WINS
9. Migrate early adopter (ENG?)
10. Announce availability for use with appropriate documentation
11. Use in Windows 2000 Project

Configuration Rules of Thumb

From http://www.windowsitlibrary.com/Content/155/09/4.html :

The following list includes some rules of thumb you can use when planning your WINS server configuration. We developed these rules from other resources and from personal experience.

• Microsoft recommends installing one WINS server and one backup server for every 10,000 computers on a network. For example, one of the Big 5 accounting firms, which has 86,000 Windows computers distributed across the United States, uses nine WINS servers. At some of our client sites, we have networks where administrators had installed WINS servers in each subnetwork. This many WINS servers caused extensive replication traffic. Reducing the number of WINS servers was the only solution.
• Consider using a dedicated disk and/or a two-processor computer as a WINS server to speed up name requests.
• Adding more network cards isn't a good option because, as we discussed earlier, WINS doesn't work well with multi-homed computers.
• In general, a dedicated server for WINS that isn't a domain controller or application server is recommended.

Operational Issues

Backup WINS Database (every n hours)

Automatic backup of the WINS database to another file on the WINS server is a feature of the Microsoft WINS product. This automatic backup to another file allows the copy to be sent off to tape without file-sharing issues with the continuously running WINS service.

Compact WINS Database

You can use the Jetpack.exe utility to compact a WINS server manually. In most medium-sized and large networks, you will want to do this every three months or when the WINS database size grows to 20 MB or more.

Follow these steps to compact a WINS server:

1. Log on as Administrator, preferably when no one is using the network or at least during a slack time.
2. From the command prompt, type net stop wins.
3. Change to the WINS directory: cd %systemroot%\system32\wins.
4. Copy wins.mdb to a new directory called something like wins.mdb.oct98. Although this step isn't absolutely required, running Jetpack in one instance clobbered our wins.mdb files. After that incident, we've been fairly paranoid about copying to a new directory.
5. Run Jetpack.exe by typing jetpack.exe wins.mdb. tmp.mdb. This command compacts the WINS database into a temporary database called tmp.mdb, deletes the original wins.mdb file, and renames tmp.mdb as wins.mdb.
6. Start the WINS Service by typing net start wins.