Share via

Troubleshooting WINS replication

  • Article

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

Troubleshooting WINS replication

What problem are you having?

  • I can't locate the source of "duplicate name" error messages.

  • I need to locate the source of "network path not found" error messages on a WINS client.

  • The WINS server cannot pull or push replications to another WINS server.

  • I am having intermittent problems with WINS not replicating between servers on my network.

I can't locate the source of "duplicate name" error messages.

Cause:  You might need to manually remove static records, or enable static mappings to be overwritten during replication.

Solution:  If the duplicate name exists already as a static mapping, you can tombstone or delete the entry. If possible, this should be done at the WINS server that owns the static mapping for the duplicate name record. As a preventive measure, in cases where a static mapping needs to be replaced and updated by a dynamic mapping, you can also enable Overwrite unique static mappings at this server (migrate on) in Replication Partners Properties.

See also:  Delete or tombstone an entry in the WINS database; Enable static mappings to be overwritten during replication

I need to locate the source of "network path not found" error messages on a WINS client.

Cause:  The network path might contain the name of a server computer configured as a p-node, m-node, or h-node and its IP address is different from the one in the WINS database. In this case, the IP address for this computer might have changed recently and the new address has not yet replicated to the local server.

Solution:  Check the WINS database for the name and IP address mapping information. If they are not current, you can start replication at the WINS server that owns the name record requiring an update at other servers.

See also:  Manage Replication

Cause:  If the computer name is configured as b-node, its name might be missing in the WINS database.

Solution:  Check the WINS database for the name. If the name is not present in WINS and clients on other subnets need to locate the b-node computer by name, you can add a static mapping in WINS for the computer name and IP address.

See also:  Manage Static Mappings

The WINS server cannot pull or push replications to another WINS server.

Cause:  If the other WINS server is located across a router, there might be a failed router or other network problem.

Solution:  Check for network connectivity to the server. Ping the other WINS server and troubleshoot any network or TCP/IP-related problems.

See also:  Troubleshooting TCP/IP

Cause:  If the other WINS server is located on the same network or can be successfully pinged, the server might not be configured correctly as either a push or pull partner of the other server.

For example, suppose the two WINS servers are called WINS-A and WINS-B. If WINS-A needs to perform pull replications with WINS-B, make sure it is a push partner of WINS-B. Likewise, if WINS-A should push replications to WINS-B, it should be a pull partner of WINS-B.

Solution:  Determine the current configuration of replication partners between the servers. If partnerships are missing at either server, add the missing partner IP addresses as needed for the appropriate server. If needed, you can also change the replication partner type, such as from either Pull only or Push only, to Push/Pull.

See also:  Configure Replication; Change a replication partner type

I am having intermittent problems with WINS not replicating between servers on my network.

Cause:  The replication pattern in use on your network might not be correct or appropriate to use.

Solution:  In general, deployments of more than 20 WINS servers are strongly discouraged. Also, for best results and simpler administration, follow a hub-and-spoke replication topology when designing your replicated WINS network that utilizes push/pull partnerships between each WINS hub server and its member spoke servers.

If a single hub-and-spoke exceeds the recommended total of 20 WINS servers for a single enterprise, you should contact Microsoft Consulting Services or Microsoft Product Support Services about how to better revise or reduce your current WINS installation. For larger or enterprise installations, multiple hub-and-spoke designs are acceptable to use.

In rare cases, the limited use of push-only and pull-only partner relationships might be needed. You should, however, carefully review added WINS administration issues when these configurations are deployed. At a minimum, establish reliable support procedures for occasions when you might need to manually trigger replication between WINS servers configured to operate using these types of limited replication partnering.

Cause:  The version ID might not be incrementing for WINS entries when replicating on all servers.

Solution:  The version ID is incremented in the WINS database by each server that owns and registers a name record. This identifier is a hexadecimal value stored with each name record in the database and is used for version tracking when the record is replicated to other servers.

Version IDs are only incremented for certain types of record changes. For example, a typical refresh of a name in WINS does not increment the version ID, but other changes, such as an updated IP address, can cause the version ID to increment in most cases.

When the version ID is not consistently incrementing for a name record at all servers in the replicated WINS network, you can use either the WINS console or command-line options to administratively increase the starting version count for the server and correct the problem.

See also:  Increase the starting version count; WINS Best Practices