Designing a NetBIOS Name Resolution Strategy

NetBIOS name resolution will still be necessary in a network as long as there are any clients and/or applications that use it. All Microsoft clients prior to Windows 2000 Professional use NetBIOS name resolution. Many legacy types of applications are written to use NetBIOS name resolution as well. NetBIOS names can be resolved within a single subnet by broadcasting, although this is certainly not the preferred method.

A well-designed network has a NetBIOS name resolution system that eliminates broadcasts within subnets and allows NetBIOS names to be resolved across routers. This could include the use of an LMHosts file that is replicated to all servers and clients.

A more efficient method in a Windows Server 2003 design would be the use of WINS. Clients can be configured to use a WINS server for NetBIOS name resolution. This configuration can be set manually by administrators or automatically by a DHCP server as part of the IP address lease process. Clients can be configured with one primary WINS server and up to 11 secondary WINS servers.

WINS servers in the same network can replicate their databases so that all WINS server databases are the same. This improves the efficiency of the NetBIOS name resolution process in a network. If one WINS server fails, the clients can use a secondary (or many secondaries) to resolve NetBIOS names. WINS servers can be configured to replicate their databases at a particular time, after a certain number of changes, or both. There are basically three settings for WINS replication as illustrated in Figure 5.5.

Figure 5.5. You can configure replication for WINS servers.

The WINS replication settings include the following:

• Push

• Pull

• Push/pull

Each option has advantages and disadvantages. It's important for proper network design to understand these differences. We will now examine each method and discuss how each relates to an efficient network design.

Push Replication

Push replication occurs after a specified number of changes on a database. The database changes are pushed out to all the specified partners. Push replication is the right choice if one of the key goals is to minimize the use of a link between the servers to conserve bandwidth. Push replication does not guarantee that the databases will replicate within any particular period of time. Push replication should not be used alone when one of the goals is to maintain a high degree of accuracy between WINS servers. Figure 5.6 illustrates WINS configured to push after 50 changes to the database.

Figure 5.6. You can configure WINS for push replication after 50 changes to the database.

Pull Replication

Pull replication occurs at the specific interval set by the administrator. It should be used to force the WINS servers to replicate at a certain time. Pull replication is often used to conserve bandwidth by setting the servers to replicate at a time when the network is not busy. For example, if you want to make sure that the WINS servers replicate once per night at midnight, you could configure the server for pull replication, as shown in Figure 5.7. In this example, the current time is 6:00 p.m.

Figure 5.7. You can configure WINS for pull replication at midnight.

Push/Pull Replication

As its name implies, push/pull replication is a combination of push replication and pull replication. In other words, both an interval and a number of changes can be set. With this setting, pull replication will always happen on the interval, but push replication will also occur if the number of changes exceeds the set number. For example, you could configure a server to pull from its partners every night at midnight but also to push to its partners after 50 changes to the database, as illustrated in Figure 5.8.

Figure 5.8. You can configure WINS for push/pull replication.