WINS Incorrect Version ID Assigned During Scavenging or Consistency Check

Article translations Article translations
Article ID: 187555 - View products that this article applies to.
This article was previously published under Q187555
This article has been archived. It is offered "as is" and will no longer be updated.
Expand all | Collapse all

SYMPTOMS

When scavenging or running a consistency check against WINS replication partners, a WINS server may assign local version IDs to records of the replicated database.

This may result in one of the following scenarios if you have the UseRplPnrs registry key enabled:

  • If there is a PUSH/PULL relationship between the WINS servers, the version ID of the server that is scavenging or consistency checking will be pulled to the replication partner and will cause an unnecessary version jump in the replicated database where the scavenge or consistency check is performed.
  • If there is a PUSH relationship between the WINS servers and the version ID of the server that is doing the scavenge or consistency check is higher than the PUSH partner, replication will stop until the version ID of the partner catches up to that of the replication partner. In the cases where the version ID of the partner is extremely high, the partner will never catch up or it would take years to catch up. To work around this problem you will have to do a "delete owner" on the replicated database to reset the version ID and then re-enable replication.
    NOTE: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\Wins\Paramete


    UseRplPnrs - REG_DWORD
    Range: 0 or 1 (nonzero)
    Default: 0
    Description: Determines which pull partners WINS uses when performing consistency checks. If the value of this entry is set to 0, WINS contacts the owner WINS server. If it is set to a nonzero value, WINS randomly picks a WINS from its list of pull partners unless the owner WINS server also happens to be a pull partner. In that case, the owner WINS is contacted.
If you DO NOT have the UseRplPnrs registry key, the symptoms will be the same, but the WINS server running the consistency check will contact the owner of the replicated database directly instead of the replication partner.

CAUSE

During a scavenge or consistency check, there is a problem where a replica record was flagged indicating that the WINS server should update a record. This results in a version ID increase. Record ownership is not verified and the version ID is incorrectly assigned.

Additionally, as a result of the check done on the records, another problem is addressed with group names that are in the released or tombstone state. There is a problem where group names in the released or tombstone state can cause symptoms similar to the symptoms stated above after a scavenge or consistency check was run against the WINS database.

RESOLUTION

There is now a check in place to ensure that only owned records are manipulated.

To resolve this problem, obtain the latest service pack for Windows NT 4.0 or Windows NT Server 4.0, Terminal Server Edition. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
152734 How to Obtain the Latest Windows NT 4.0 Service Pack

STATUS

Microsoft has confirmed that this is a problem in Windows NT 4.0 and Windows NT Server 4.0, Terminal Server Edition. This problem was first corrected in Windows NT 4.0 Service Pack 4.0 and Windows NT Server 4.0, Terminal Server Edition Service Pack 4.

Properties

Article ID: 187555 - Last Review: October 9, 2013 - Revision: 3.2
APPLIES TO
  • Microsoft Windows NT Server 4.0, Terminal Server Edition
  • Microsoft Windows NT Workstation 4.0 Developer Edition
  • Microsoft Windows NT Server 4.0 Standard Edition
Keywords: 
kbnosurvey kbarchive kbhotfixserver kbqfe kbbug kbfix kbqfe KB187555

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com