Compartilhar via

Configuring WINS replication

  • Artigo

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 8 Beta

Configuring WINS replication

Before configuring replication, you should first carefully design and review your WINS replication topology. For wide area networks (WANs), this planning can be critical to the success of your deployment and use of WINS. In general, WINS offers you the following options and possibilities to choose from when you are configuring replication:

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

  • For some larger campus networks, you might also configure WINS to replicate within a LAN environment.

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

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

Replication across wide area networks

When configuring WINS replication, the two most important planning 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 planning issue. The WINS server database should 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 should not 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 local area network or on fast WAN links. This reduces traffic across the slow link and reduces contention between replication traffic and WINS client name queries.

For example, as shown in the following figure, the intervals used for configuring pull replication for WINS servers could be set according to proximity between servers and the likelihood of a high-speed link connecting servers configured as replication partners of each other.

WINS convergence in a wide area network (WAN)

In this example, two WINS servers--SEA-WINS and ATL-WINS--are located in Seattle and Atlanta. Another two servers--MEX-WINS and SYD-WINS--are located outside the United States in Mexico City and Sydney. Because SEA-WINS and ATL-WINS are located across a higher-speed WAN link, they are configured to replicate once every hour. For the servers outside the United States, replication intervals might be set higher, such as either 3 or 12 hours, because lower-speed links are associated with these connections.

Planning the convergence time

Convergence time is 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. When planning for WINS servers, you must decide what is acceptable as the convergence time for your network.

Using the previous example, if a WINS client in Seattle registers its name with the WINS server in the figure labeled SEA-WINS, other WINS clients in remote locations might query for the client name and not find it in WINS. In some cases, if the address of the client has been changed, the remote locations would only have a mapping for the previous IP address of the client in their local server databases.

WINS clients that query any of the other WINS servers in the figure (that is, ATL-WINS, MEX-WINS, SYD-WINS) only receive a positive and correct response when the new or updated mapping for the client has been fully replicated from the owning WINS server, SEA-WINS, to all of the other servers. Replications from SEA-WINS could be triggered in one of two ways:

  • A push replication trigger is sent based on the frequency of updates made at SEA-WINS.

  • A pull replication trigger is sent to other WINS servers based on the configured Replication interval set in Replication Partners Properties at SEA-WINS.

Given this configuration, a new or updated entry at SEA-WINS is only replicated when the pull replication interval expires, but queries at remote sites for the new name mapping might not succeed until later. This is because the time interval for replication to ATL-WINS is one hour; it is three hours for MEX-WINS; and it is 12 hours for SYD-WINS. In this case, WINS convergence time is calculated as:

12 hours + 2 * (1 hour) = 14 hours

In reality, name query requests can succeed before the convergence time elapses. This happens when the entries replicate over a shorter path than the worst-case path. It also happens when the Number of changes in version ID before replication threshold in push replication settings passes before the Replication Interval expires in pull replication settings. This results in earlier replication of the new entry. The longer the replication path, the longer the convergence time.

Notes

  • After each administrator configures the respective WINS server, you can use Replicate Now (in the WINS console) to start immediate replication between the configured WINS servers.

  • When replication occurs, you can use Display Records to view records for the remote WINS server database. However, to make changes to the remote WINS database, you must be logged on under an account with required user rights in the respective domains for both servers involved.

  • Replication can also occur between two separate stand-alone servers that participate in a workgroup.

Replication across local area networks

When configuring WINS replication for local area networks (LANs), the issues are similar to those that occur in WAN environments, although less critical.

Because the speed of the underlying network links for LANs are much greater than for WANs, it might be acceptable to increase the frequency of WINS database replication, by optimizing 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 accordingly, from what you would 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. If a persistent connection was not used, the normal update count threshold would default to a minimum of 20. With persistence, a smaller update count value can be specified.

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

As in WAN replication planning, the WINS server database should 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 should not be so small that it interferes with network throughput.

For network-intensive environments, 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.

Automatic partner configuration

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

Automatic configuration is possible because each WINS server announces its presence on the network through periodic multicasts. These announcements are sent as IGMP messages for the multicast group address of 224.0.1.24 (the well-known multicast IP address reserved for WINS server use).

Automatic replication configuration monitors multicast announcements from other WINS servers and automatically 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 both push and pull partners.

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

If a remote server is discovered and added as a partner through 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 console to specify roles for each partner and any related information.

Notes

  • Automatic partner configuration is typically useful in small networks, such as single subnet LAN environments. It can, however, be used 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 multicast traffic for the reserved WINS server multicast group. The destination IP address for this group is 224.0.1.24 between routed subnets.

  • 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) on the reachable network.

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 console to manually configure that server to permit this replication.