Planning, Migrating, and Maintaining WINS

As previously mentioned, WINS is necessary in most production environments because the overriding dependencies on NetBIOS that were built into Windows have not entirely been shaken out. In fresh installations of Windows Server 2003, WINS might not be necessary, but for older, upgraded environments, plans should be made for WINS being around for a few years.

Designing a WINS Environment

There are two key factors to consider when designing a WINS environment. The first factor is accessibility. Having a local, fast connection to a WINS server will aid in the processing of client requests. Because WINS has low overhead for servers, it is consequently a good idea to include at least one WINS server in all locations with more than 510 users. In smaller environments, WINS can be installed as part of a local file server; whereas in larger environments, dedicated multiple utility servers running WINS are recommended.

The replication topology to be established should normally follow the lines of a network infrastructure, as previously mentioned. If a network utilizes a hub-and-spoke design, WINS should follow the same basic topology.

Upgrading a WINS Environment

The WINS service itself is one of the more straightforward services to migrate to a separate set of servers as part of an upgrade to Windows Server 2003. A simple upgrade of the existing WINS server will do the trick for many environments; however, migrating to a separate server or set of servers may be beneficial if changing topology or hardware.

Migration of an existing WINS environment is most easily accomplished through the procedure described in this section. This procedure allows for the migration of an entire WINS database to a new set of servers, but without affecting any clients or changing WINS server settings. Figure 10.19 illustrates a WINS migration using this procedure.

Figure 10.19. The first step in the WINS migration procedure.

In Figure 10.19, the existing servers, OldServer1 and OldServer2, handle WINS traffic for the entire network of fictional CompanyABC. They are configured with IP addresses 10.1.1.11 and 10.1.1.12, which are configured in all clients' IP settings as Primary and Secondary WINS, respectively. OldServer1 and OldServer2 are configured as push/pull partners.

The new servers, NewServer1 and NewServer2, are added to the network with the WINS service installed and configured as push/pull partners for each other. Their initial IP addresses are 10.1.1.21 and 10.1.1.22. OldServer1 and NewServer1 are then connected as push/pull partners for the network. Because the servers are connected this way, all database information from the old WINS database is replicated to the new servers, as illustrated in step 1 shown in Figure 10.19.

After the entire WINS database is replicated to the new servers, the old servers are shut down (on a weekend or evening to minimize impact), and NewServer1 and NewServer2 are immediately reconfigured to take the IP addresses of the old servers, as illustrated in step 2 shown in Figure 10.20.

Figure 10.20. The second step in the WINS migration procedure.

The push/pull partner relationship between NewServer1 and NewServer2 is then reestablished because the IP addresses of the servers changed. The entire downtime of the WINS environment can be measured in mere minutes, and the old database is migrated intact. In addition, because the new servers assume the old IP addresses, no client settings need to be reconfigured.

There are a few caveats with this approach, however. If the IP addresses cannot be changed, WINS servers must be changed on the client side. If you're using DHCP, you can do this by leaving all old and new servers up in an environment until the WINS change can be automatically updated through DHCP. Effectively, however, WINS migrations can be made very straightforward through this technique, and they can be modified to fit any WINS topology.

Maintaining the WINS Database

As with the DHCP database, the WINS database is based on the Microsoft JET database technology and subsequently requires regular maintenance. Scheduling maintenance for each WINS database is recommended on a quarterly or semi-annual basis at least. The WINS database file, wins.mdb, is stored in the %systemroot%\system32\wins directory. You can run maintenance against the database by entering the following commands at the command line:

• cd %systemroot%\system32\wins

• net stop wins

• jetpack wins.mdb tmp.mdb

• net start wins