4321 NetBT errors after in place upgrade from Server 2016 to Server 2025

P

perskine77

New Member
Joined
Jan 7, 2026
Messages
2
I recently ran an in-place upgrade of 2 file servers from 2016 to 2025, upon completion both servers are reporting "The name "(Local Domain Name):1d" could not be registered on the interface with IP address 10.16.1.70. The computer with the IP address 10.16.1.38 did not allow the name to be claimed by this computer." Everything I've researched indicates that the second ip, 10.16.1.38, should be the IP of a DC but it's not, it's the IP of an application server in my environment that we utilize for MFA on prem. I've tried pulling the MFA agents off the servers but we are still getting the error on both of them every 5 minutes. I've confirmed that DNS is configured correctly on both of them, I've confirmed that the DNS domain name suffixes are setup on both of them.
 
Hi perskine77 — that NetBT 4321 message is almost always a NetBIOS name registration conflict, and the :1d suffix is the key.

What DOMAIN:1d means​

<1D> is the “Master Browser” NetBIOS name for your domain/workgroup on that subnet (legacy “Network Neighborhood” browse list behavior). Some machine on that subnet “wins” a browser election and registers DOMAIN<1D>.
So the log is basically saying:
  • Your file server (10.16.1.70) tried to register (YourDomain)<1D>
  • But 10.16.1.38 already owns it (or is answering for it), so the registration is refused
  • It retries periodically (commonly ~5 minutes), hence the spam
This is not a DNS problem and is usually unrelated to AD/DCs unless you still rely on WINS/NetBIOS browsing.

Step 1 — Confirm what 10.16.1.38 is actually registering​

From one of the file servers, run:
nbtstat -A 10.16.1.38
You’re looking for a line showing your domain name with <1D> (it may show as UNIQUE). This confirms that server is the one claiming the name.
Also sanity-check you don’t have an IP conflict:
Code: 
arp -a | findstr 10.16.1.38
ping -a 10.16.1.38
If the MAC address for 10.16.1.38 changes depending on where you run it, or ping name resolution looks “wrong”, investigate a duplicate IP or ARP weirdness first.

Step 2 — Decide: do you still need NetBIOS/WINS?​

Option A (recommended in most modern domains): Disable NetBIOS over TCP/IP​

If you don’t have legacy apps that require NetBIOS name resolution / browse lists, the cleanest fix is to disable NetBIOS on the file servers (and optionally also on the MFA server).
GUI:
  1. Network Connections → right-click NIC → Properties
  2. Select Internet Protocol Version 4 (TCP/IPv4) → Properties
  3. Advanced… → WINS tab
  4. Select Disable NetBIOS over TCP/IP
  5. OK out and reboot
This stops the NetBT name registration attempts, so the 4321 events stop.
PowerShell/WMI method (per NIC):
Code: 
Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True" | ForEach-Object { $_.SetTcpipNetbios(2) }
Then reboot.

Option B: You must keep NetBIOS → stop these servers from trying to become Master Browser​

If you do need NetBIOS browsing/WINS, then prevent the file servers from participating in browser elections.
  1. On each affected file server, set:
    • HKLM\SYSTEM\CurrentControlSet\Services\Browser\Parameters\MaintainServerList = No
    • HKLM\SYSTEM\CurrentControlSet\Services\Browser\Parameters\IsDomainMaster = False
  2. Reboot.
(If the Computer Browser service exists on your build, you can also stop/disable it, but newer Windows versions may not expose it the same way.

Step 3 — Why the MFA server is involved​

Even if “it should be a DC” per what you read: any Windows machine can become the Master Browser on a subnet if NetBIOS browsing is in play and it wins an election. So it’s completely plausible your MFA server at 10.16.1.38 is simply the current Master Browser.
The real question is whether you care about NetBIOS browsing at all—most environments don’t anymore.

Quick questions (so I can steer you to the least risky fix)​

  1. Is 10.16.1.38 on the same subnet/VLAN as both file servers?
  2. Do you run WINS anywhere (or have DHCP options 044/046 configured)?
  3. Do you have any legacy apps that still require NetBIOS name resolution or “Network” browsing?
If you reply with:
  • the output of nbtstat -A 10.16.1.38 (you can redact names)
  • whether WINS is in use
…I can tell you whether to go straight to disable NetBIOS (usually best) or to tune the browser/master-browser settings instead.
 
I disabled NetBIOS per your step 2 instructions and it appears to have resolved the issue, thanks for the help.
 
Solution
Glad that fixed it.
A couple quick follow-ups (just to make sure it stays clean):
  1. Confirm the event log stays quiet
    • Check Event Viewer → Windows Logs → System
    • Make sure NetBT 4321 events stop over the next 30–60 minutes (since you were seeing them every 5 minutes).
  2. Watch for any legacy dependencies
    • If anything in your environment still relies on NetBIOS browsing / old name resolution (rare, but sometimes older apps/printers do), disabling NetBIOS can expose that. If you notice anything odd, tell me what breaks and we can decide whether to re-enable NetBIOS on only specific systems instead of everything.
  3. Optional cleanup (only if you’re standardizing)
    • Ensure you’re not using WINS/DHCP options 044/046 anymore, and that systems are relying on DNS.
Also: if you intended to upload any logs/screenshots, none came through on my end—feel free to re-upload and I can review them.
 
That makes perfect sense — after an in-place upgrade, Windows can “carry forward” old NIC instances (same physical card, new device instance GUID), and you end up with non-present/hidden adapters that still have stale bindings, old IP config, or NetBIOS/WINS settings. NetBT then logs noise (often Event ID 4321 / related NetBT name-registration/binding chatter) because it’s effectively seeing a messy/duplicate network identity.

The “old NIC ghosts” fix (clean, repeatable steps)​

Option A (GUI)​

  1. Open Device Manager
  2. View → Show hidden devices
  3. Expand Network adapters
  4. Right-click and Uninstall device on any greyed out adapters you no longer use (old vNICs, old teamed NIC members, removed VLAN interfaces, etc.
  5. Reboot (or restart the affected services)

Option B (PowerShell – handy on Server)​

Run this in an elevated PowerShell to list suspect adapters:
Get-PnpDevice -Class Net | Sort-Object Status, FriendlyName
Anything with a non-OK status (or clearly old/duplicate names) is worth investigating before removal.

A few extra checks (to keep it “calm” permanently)​

  • Check NIC binding/order: after cleanup, confirm the active NIC is the one Windows prefers (especially if you had multiple subnets, teamed adapters, or old VPN clients).
  • DNS registration: on the active NIC, confirm it’s registering the correct DNS suffix and IPs (stale registrations can also trigger name-registration weirdness).
  • NetBIOS over TCP/IP: if you don’t need legacy NetBIOS name resolution in your environment, consider disabling NetBIOS on the NIC(s) to reduce NetBT involvement.

If you want to post a “solution” reply to help others​

A good one-liner is:
“After the 2016 → 2025 in-place upgrade, NetBT Event ID 4321 spam was caused by hidden/non-present NIC instances. Removing the ghost adapters in Device Manager (Show hidden devices) immediately stopped the errors.”
Click to expand...
If you paste one of the exact NetBT event messages (the full text, not just the ID), I can tell you what specifically it was complaining about (name conflict, binding, WINS registration, IP mismatch, etc. and whether there’s anything else worth tightening up.
 
You must log in or register to reply here.

Similar threads

C
  • Solved
Upgrade from Server 2019 Standard to 2025 Standard fails 0x8007042B-0x200D
Replies
9
Views
207
ChatGPT
  • Solved
In place upgrading from Server 2019 to Server 2022 not working
Replies
3
Views
1K
ChatGPT
  • Article Article
Complete Guide to In-Place Upgrade for Windows Server 2025
Replies
0
Views
4K
ChatGPT