Designing Your WINS Replication Strategy

A good replication design is essential to your WINS availability and performance. Designs encompassing multiple WINS servers distribute NetBIOS name resolution across LAN and WAN environments, confining WINS client traffic to localized areas. To ensure consistent, network-wide name resolution, WINS servers must replicate their local entries to other servers. For more information about a WINS replication strategy, see the examples later in this section.

Figure 4.5 shows the process for designing your WINS replication strategy.

Figure 4.5: Designing Your WINS Replication Strategy

Before configuring replication, carefully design and review your WINS replication topology. For WANs, this planning can be critical to the success of your deployment and use of WINS.

WINS provides the following choices when you are configuring replication:

• You can manually configure WINS replication for a WAN environment.

• For larger networks, you can configure WINS to replicate within a LAN environment.

• In smaller or bounded LAN installations, consider enabling and using WINS automatic partner configuration for simplified setup of WINS replication.

• In larger or global installations, you might have to configure WINS across untrusted Windows NT domains.

If your network uses only two WINS servers, configure them as push/pull replication partners to each other. When configuring replication partners, avoid push-only or pull-only servers except where necessary to accommodate slow links. In general, push/pull replication is the most simple and effective way to ensure full WINS replication between partners. This also ensures that the primary and secondary WINS servers for any particular WINS client are push/pull partners of each other, a requirement for proper WINS functioning in the event of a failure of the primary server of the client.

In most cases, the hub-and-spoke model provides a simple and effective design for organizations that require complete convergence with minimal administrative intervention. For example, this model works well for organizations with centralized headquarters or a corporate data center (the hub) and several branch offices (the spokes). Also, a second or redundant hub (that is, a second WINS server in the central location) can increase the fault tolerance for WINS.

In some large enterprise WINS networks, limited replication partnering can effectively support replication over slow network links. However, when you plan limited WINS replication, ensure that each server has at least one replication partner. Furthermore, balance each slow link that employs a unidirectional link by a unidirectional link elsewhere in the network that carries updated entries in the opposite direction.

Specifying Automatic Partner Configuration

You can configure a WINS server to automatically configure other WINS server computers as replication partners. By using this automatic partner configuration, other WINS servers are discovered when they join the network and are added as replication partners.

When using automatic partner configuration, each WINS server announces its presence on the network by using periodic multicasts. These announcements are sent as Internet Group Management Protocol (IGMP) messages for the multicast group address of 224.0.1.24, which is reserved for WINS server use.

Automatic partner configuration is typically useful in small networks, such as single subnet LAN environments. However, you can use automatic partner configuration in routed networks. For WINS multicast support in routed networks, the forwarding of multicast traffic is made possible by configuring routers for each subnet to forward traffic to the WINS multicast group address of. 224.0.1.24.

Because periodic multicast announcements between WINS servers can add traffic to your network, automatic partner configuration is recommended only if you have a small number of installed WINS servers (typically, three or fewer).

Automatic partner configuration monitors multicast announcements from other WINS servers, and performs the following configuration steps:

• Adds the IP addresses for the discovered servers to its list of replication partner servers.

• Configures the discovered servers as push/pull partners.

• Configures pull replication at two-hour intervals with the discovered servers.

If a remote server is discovered and added as a partner by means of multicasting, it is removed as a replication partner when WINS shuts down properly. To have automatic partner information persist when WINS restarts, you must manually configure the partners.

To manually configure replication with other WINS servers, use the WINS Microsoft Management Console (MMC) snap-in or the Netsh command-line tool to specify roles for each partner and any related information.

For more information about the Netsh command-line tool, see "Netsh" and "Netsh commands for WINS" in Help and Support Center for Windows Server 2003.

Determining Replication Partners

Choosing whether to configure a WINS server as a push partner, pull partner, or push/pull partner depends on several considerations, including the specific configuration of servers at your site, whether the partner is across a WAN, and how important it is to distribute changes immediately throughout the network.

In the hub-and-spoke configuration, you can configure one WINS server as the central server and all other WINS servers as push/pull partners of this central server. Such a configuration ensures that the WINS database on each server contains addresses for every node on the WAN. Figure 4.6 shows replication using a hub-and-spoke topology.

Figure 4.6: WINS Replication in a Hub-and-Spoke Topology

You can select other configurations for replication partner configurations to meet the particular needs of your site. For example, Figure 4.7 shows replication in a T network topology, in which Server1 has only Server2 as a partner, but Server2 has three partners. So Server1 gets all the replicated information from Server2, but Server2 gets information from Server1, Server3, and Server4.

Figure 4.7: Replication in a T Network Topology

If Server2 needs to perform pull replications with Server3, make sure it is a push partner of Server3. If Server2 needs to push replications to Server3, configure it as a pull partner of Server3. Determine whether to configure WINS servers as either pull or push partners, and set partner preferences for each server.

Determining Convergence Time

The time needed to replicate a new entry in a WINS database, from the WINS server that owns the entry to all other WINS servers on the network is defined as convergence time. When planning for WINS servers, you must decide what is acceptable as the convergence time for your network; the longer the replication path, the longer the convergence time.

Name query requests can succeed before the convergence time elapses, resulting in earlier replication of the new entry. This happens when:

• The entries replicate over a shorter path than the worst-case path.

• The Number of changes in version ID before replication threshold expires in the push replication settings before the Replication Interval expires in the pull replication settings in the Replication Partners Properties dialog box in the WINS snap-in.

Configuring Replication Across WANs

When configuring WINS replication across WANs, the two most important issues are:

• Whether your WINS replication occurs over slower WAN links.

• The length of time required for all replicated changes in the WINS database to converge and achieve consistency on the network.

The frequency of WINS database replication between WINS servers is a major design issue. The WINS server database must be replicated frequently enough to prevent the downtime of a single WINS server from affecting the reliability of the mapping information in other WINS servers. However, the time interval between replications cannot be so small that it interferes with network throughput.

Network topology can influence your decision on replication frequency. For example, if your network has multiple hubs connected by relatively slow WAN links, you can configure WINS database replication between WINS servers on the slow links to occur less frequently than replication on the LAN or on fast WAN links. This reduces traffic across the slow link and reduces contention between replication traffic and WINS client name queries.

After determining the replication strategy that works best for your organization, map the strategy to your physical network. For example, if you have chosen a hub-and-spoke strategy, indicate on your network topology map which sites have the "hub" server, and which have the "spoke" servers. Also indicate whether the replication is push/pull, push-only, or pull-only.

Document the configurations of each WINS server, including the hardware configuration, IP address, replication configuration, and replication partners.

For more information about WIN configuration across WANs, see "Configuring WINS replication" in Help and Support Center for Windows Server 2003.

Configuring Replication Across LANs

When configuring WINS replication across LANs, the issues are similar to those that occur in WAN environments, although less critical.

Because the data throughput of the underlying network links for LANs is much greater than for WANs, it might be acceptable to increase the frequency of WINS database replication by specifying push and pull parameters for LAN-based replication partners. For push/pull partners, you can do this by decreasing the Number of changes in version ID before replication and Replication interval settings from what you use for WAN-based partners on slower links.

For example, between LAN-based replication partners it often works to enable WINS to use a persistent connection between the servers. Without a persistent connection, the normal update count threshold defaults to a minimum of 20. You can specify a smaller update count with a persistent connection.

Next, you can specify a much smaller number, such as a value of one to three in the Number of changes in version ID before replication setting before WINS sends a push replication trigger to the other partner. For pull partners, you might also consider setting the Replication interval setting to a value in minutes, instead of hours.

As in WAN replication planning, the WINS server database must replicate frequently enough to prevent the downtime of a single WINS server from affecting the reliability of the mapping information in other WINS servers. However, the time interval between replications cannot be so small that it interferes with network throughput.

In environments with a large amount of network traffic it is a good idea to use a network monitoring tool, such as Network Monitor, to help measure and determine how to optimize your WINS replication strategy.

For more information about WINS configuration across LANs, see "Configuring WINS replication" in Help and Support Center for Windows Server 2003. For more information about the Network Monitor tool, see "Network Monitor" in Help and Support Center for Windows Server 2003.

Configuring Replication Between Untrusted Domains

It is possible to set up WINS replication between one or more WINS servers in domains that do not have a trust relationship. You can do this without a valid user account in the untrusting domain. To configure replication, an administrator for each WINS server must use the WINS snap-in or Netsh commands to manually configure each server to permit this replication.

Important

If you require replication across a firewall, keep in mind that WINS replication occurs over TCP port 42. Therefore, this port must not be blocked on any network device between two WINS replication partners.

For more information about WINS configuration across domains that do not have trust relationships, see "Configuring WINS replication" in Help and Support Center for Windows Server 2003. For more information about domain trusts, see the Distributed Services Guide of the Windows Server 2003 Resource Kit (or see the Distributed Services Guide on the Web at http://www.microsoft.com/reskit).

Mapping the Replication Architecture to the Physical Network

After determining the replication strategy that works best for your organization, map the strategy to your physical network. For example, if you have chosen a hub-and-spoke strategy, indicate on your network topology map which sites will have the "hub" server, and which will have the "spoke" servers. Also indicate whether the replication is push/pull, push-only, or pull-only.

Document the configurations of each WINS server, including the hardware configuration, IP address, replication configuration, and replication partners.

The convergence time for the system is the sum of the two longest convergence times to the hub. For example, in an organization that has five WINS servers (WINS-A through WINS-E), if WINS-B and WINS-D replicate with WINS-A (the hub) every 30 minutes, and WINS-C and WINS-E replicate with the hub every 4 hours, the convergence time is 8 hours.

The following examples show three different types of replication.

Example 1: Deploying WINS Over a Large Number of Branch Offices

In this example, a medium-sized company has two main sites: a New York and a Los Angeles office with 500 computers in each office, connected through high-speed links. The company also has more than 160 small branch offices, including local sales offices. To save on the costs of the links, some branches act as concentrators for a region. Figure 4.8 shows a WINS server placement strategy for an organization with many small branch offices.

Figure 4.8: Deploying WINS Over a Large Number of Branch Offices

In most cases, the branches do not have local WINS servers — there is simply no need for a separate server for each branch. Instead, the company adds regional WINS servers when the costs of registration and query traffic increase above the cost of deploying the additional server. When the link to a regional WINS server fails, local names can still be resolved by the broadcast mechanism.

The regional WINS servers are not required for this configuration to function correctly, but they do provide a cost optimization. The company's network administrators avoid deploying the regional servers whenever possible because the added servers increase the convergence time. Administrators configure regional WINS servers as replication partners of the WINS servers in the main sites.

Clients in the main site are configured with the IP address of their local WINS server as primary, and the IP address of the WINS server in the other main site as secondary. Clients in the regional branches are configured with the IP address of the regional WINS server as primary, and the address of the closest main site WINS server as secondary. The replication interval is set to 15 minutes between sites; therefore, all computers are reachable within 15 minutes of an address registration or change.

Example 2: Deploying WINS with a Concentrated User Base

Figure 4.9 shows the network configuration of another example company that is very different. The network serves a larger company with three sites, Philadelphia, Seattle, and Houston, each with 5,000 users. The number of users justifies two WINS servers at each site.

Figure 4.9: Deploying WINS Over a Few Large Sites

The clients are configured with a local primary and secondary WINS server. Half of the clients have one local WINS server as primary and the other as secondary. The other half has exactly the opposite configuration. This balances the registration and query load over both WINS servers, and it provides a backup for maintenance purposes and in case of a server failure.

The local WINS servers use a very short replication interval of 10 minutes; therefore, all computers within the same site are reachable within 10 minutes of an address registration or change. The replication interval between the sites can be longer — about 30 minutes — because most users work with resources within their site.

Example 3: A Large Hub-and-Spoke Design

Figure 4.10 shows an extremely large WINS implementation, serving more than 100,000 nodes. In a configuration with so many WINS servers, a common error is to create many push/pull relationships for redundancy. This can lead to a system that, while functional, is overly complex and difficult to understand and troubleshoot.

Figure 4.10: Large-Scale WINS Deployment Using Hub Topology

Four major hubs are located in Seattle, San Francisco, Chicago, and Los Angeles. These hubs serve as secondary WINS servers for their regions while connecting the four geographic locations. All primary WINS servers are configured as push/pull partners with their hubs, and the hubs are configured as push/pull partners with other hubs.

The primary WINS servers replicate with the hubs every 15 minutes, and the hub-to-hub replication interval is 30 minutes. The convergence time of the WINS system is the time it takes for a client registration to be replicated to all WINS servers.

In this case the longest convergence time would be 1.5 hours from a Seattle primary server to a Chicago primary server. The total convergence time can be calculated by adding up the maximum time between:

• Seattle primary to Seattle secondary, 15 minutes

• Seattle secondary to San Francisco secondary, 30 minutes

• San Francisco secondary to Chicago secondary, 30 minutes

• Chicago secondary to Chicago primary, 15 minutes

However, the convergence time might be longer for WINS servers connected across slow links. It is probably not necessary for the servers in Paris or Berlin to replicate every 15 minutes. You might configure them to replicate every two hours or even every 24 hours, depending on the volatility of names in the WINS system.

This network contains low redundancy. If the link between Seattle and Los Angeles is down, replication still occurs through San Francisco. If, for example, the Seattle hub fails, the Seattle area can no longer replicate with the rest of the WINS system. Network connectivity, however, is still functional — all WINS servers contain the entire WINS database, and name resolution functions normally. All that is lost are changes to the WINS system that occurred since the Seattle hub failed. A Seattle user cannot resolve the name of a file server in Chicago that comes online after the Seattle hub fails. When the hub returns to service, all changes to the WINS database are replicated normally.