Cause 1: The server is already registered as local (by far the most common)
I know this one is infuriating. You're in the WINS MMC snap-in, you right-click Replication Partners, you pick New Replication Partner, you type in a server name, and Windows slaps you with 0X00002619 — which the UI translates to something like "The WINS server you are trying to add is already configured as the local WINS server."
You didn't add it as local. Or did you? The trick is that WINS stores the local server's identity in more than one place, and if any of those places already contain the name you're typing, the add fails. It happens most often after a clone, a VM template rollout, or a hostname change — you spin up SRV-WINS02 from a template that was built off SRV-WINS01, and now the old local entry never got scrubbed.
The real fix is to look at how WINS classifies the local server before you try to add anything.
- Open the WINS console (
winsmgmt.msc). - Expand the server node, right-click the top-level server name, and choose Properties.
- Compare the name in the Advanced tab's Name field to the server you're trying to add.
If they match, you're trying to add the server to itself. That's not a replication partner — that's a loop. WINS won't let you do it, and it shouldn't.
If they don't match but the error still fires, the local identity is stale in the registry. Stop the WINS service and check this key:
net stop wins
reg query HKLM\SYSTEM\CurrentControlSet\Services\WINS\Parameters /v LocalServerName
If LocalServerName is pointing at the box you're trying to add, that's your culprit. You can either rename the server so it doesn't collide, or — if you actually meant to add a different partner — remove the stale registration:
reg delete HKLM\SYSTEM\CurrentControlSet\Services\WINS\Parameters /v LocalServerName /f
net start wins
Restart WINS, then re-add the partner. Nine times out of ten, it goes through clean.
Cause 2: A tombstoned record is blocking the re-add
This one trips up people who've already removed and re-added a partner before. WINS doesn't delete records — it tombstones them. A tombstoned record sticks around for the Extinction Interval, which defaults to 4 days on Windows Server 2016 and 2019, and 6 days on 2012 R2. During that window, the record still exists in the database, and when you try to re-add the same server, WINS sees the tombstone and interprets the add as a conflict.
You'll usually spot this when the error appears immediately after you removed and re-added the same partner within a day or two. Classic scenario: you decommissioned a replication partner, changed your mind, and tried to bring it back the same afternoon. WINS is still holding the old tombstone.
Two ways to handle it. The clean way is to wait out the Extinction Interval. The fast way is to manually purge the tombstone from the database:
winscl /p /tombstone /server:SRV-WINS01
If the tombstone is stubborn, force the tombstone reaper to run immediately by issuing a scavenge from the console: right-click the server, choose Initiate Scavenging, then confirm. Give it 30 seconds, then try the add again.
One caveat — if this server had replication partners pushing records into it, don't purge blindly. Tombstone cleanup can undo a deliberate record removal you were relying on. Check the Owners tab of the affected records first.
Cause 3: Duplicate SPN or NetBIOS name collision on the network
Less common, but nastier. If another machine on the network is answering to the same NetBIOS name as the server you're adding — even briefly, even if it's a rogue laptop someone renamed — WINS will resolve that name to a different IP and refuse the add. The local server identity and the name you typed collide at the NetBIOS layer, not the WINS database layer.
This shows up in environments where a server was renamed but the old computer account is still hanging around, or where someone stood up a test VM with a name copied from production. I've seen it in lab networks more than anything else — always the person who cloned a DC and forgot to sysprep.
Check for a live name conflict:
nbtstat -A SRV-WINS02
nbtstat -a SRV-WINS02
If either command returns more than one IP, you've got a collision. Track down the rogue machine with nbtstat -c on a few machines in the same subnet, or check your DHCP leases and DNS records for stale entries.
You also want to rule out a duplicate SPN, which won't directly cause 0x2619 but will cause replication to fail after the add succeeds, and you'll waste an hour chasing the wrong error. Run this on the WINS server:
setspn -L SRV-WINS02
If you see WINS/ SPNs registered to more than one computer account, clean them up with setspn -D before retrying.
Quick-reference summary
| Cause | Most likely trigger | Fix |
|---|---|---|
| Server already listed as local | Cloned VM, hostname change, wrong name typed | Check LocalServerName in registry; remove if stale, restart WINS |
| Tombstoned record blocking re-add | Removed and re-added a partner within the Extinction Interval | Purge tombstones with winscl /p /tombstone or initiate scavenging |
| NetBIOS or SPN name collision | Rogue host, un-sysprepped clone, stale computer account | Find and rename the conflicting host, clean duplicate SPNs |
If you're still stuck after all three, capture a WINS trace with winscl /t and check the system event log for entries from source WINS. The event log usually names the offending record directly, which saves you the guessing game.
And one last thing — if this is happening on a server you inherited, don't assume the previous admin left things clean. I've seen WINS databases with replication partners from three acquisitions ago still registered. Purge what you don't recognize, then rebuild the partnerships properly. It'll save you a headache next quarter.