Fix 0X0000089D: Logon Processor Can't Add Message Alias

Quick answer for advanced users

Reset NetBIOS over TCP/IP or rename the server. Check no duplicate names on the network. If that fails, disable and re-enable NetBIOS on the NIC.

What's actually happening here

You'll see error 0X0000089D pop up in Event Viewer under System or Application logs, or during server boot. The logon processor (part of the LanmanServer service) can't register the server's NetBIOS name as a message alias. Translation: Windows Server tries to announce its name over the network using NetBIOS, but something blocks it. Most common cause? Another machine on the same subnet already claimed that name. Could also be a corrupted NetBIOS cache or the NetBIOS stack on your NIC got hung up. I've seen this mostly on Windows Server 2019 and 2022, but also occasionally on Windows 10/11 Pro machines acting as file servers. Last month I walked through this on a client's 2019 server after they restored a VM snapshot — the duplicate name came from the old snapshot still broadcasting.

How to fix 0X0000089D — step by step

Check for duplicate NetBIOS names. Open Command Prompt as admin on the affected machine, then run:
```
nbtstat -n
```
Look for the server's computer name under the NetBIOS name table. If you see a conflict flag (like <00> UNIQUE with a status of Conflict), you've got a duplicate. Use
```
nbtstat -a <IP>
```
on other machines to see who's claiming the name. The fix is to rename one of the machines or remove the old one from the network.
Flush and reload NetBIOS cache. Still in admin CMD, run:
```
nbtstat -R
```
(uppercase R). Then:
```
nbtstat -RR
```
(release and renew). The first clears the local cache, the second reregisters the name with WINS or broadcast. After that, restart the Server service:
```
net stop lanmanserver && net start lanmanserver
```
Check Event Viewer again.
Reset NetBIOS over TCP/IP on the NIC. Open Network Connections, right-click your active NIC and choose Properties. Find Internet Protocol Version 4 (TCP/IPv4), click Properties, then Advanced, go to the WINS tab. Under NetBIOS setting, select Disable NetBIOS over TCP/IP. Click OK all the way out. Reboot. Then go back and set it to Enable NetBIOS over TCP/IP. Reboot again. This forces a clean re-enumeration of the NetBIOS stack. I've had this work when nothing else would.
Manually add the name to LMHOSTS (if you run a big network). If you know the IP is unique and the name should work, you can force it. Open C:\Windows\System32\drivers\etc\lmhosts in Notepad as admin. Add a line like:
```
192.168.1.50   YOURSERVERNAME   #PRE
```
Then run:
```
nbtstat -R
```
and restart the Server service. Don't use this as a permanent hack — it's a diagnostic step.

Alternative fixes if the main steps don't work

Check the Server service dependencies. Open Services.msc, find the Server service. Make sure these services are running: NT LM Security Support Provider (NtLmSsp), Remote Procedure Call (RPC), and TCP/IP NetBIOS Helper. If the NetBIOS helper is disabled, NetBIOS names won't register. Set it to Automatic and start it.
Look for a stuck WINS registration. If you use WINS, the server might have a tombstoned name record. On a WINS server (or via the console), check under Active Registrations for the server name. Delete the record, then run nbtstat -RR on the affected machine to reregister. I've seen this on old WINS servers that never cleaned up after a rename.
Rename the server as a nuclear option. If all else fails, rename the machine. Right-click This PC > Properties > Rename this PC. Give it a new name, reboot. The old name conflict disappears. Make sure to update DNS and any file shares pointing to the old name. This is brute force but works 100% of the time when the conflict is unresolvable.

Prevention tip

Don't let your server name collide with workstation names. On any network with more than 10 machines, keep a spreadsheet or a simple DNS zone with your server hostnames. Avoid generic names like FILE-SERVER or DC01 — they get reused. Also, if you clone VMs, always run sysprep or at least rename the cloned machine before bringing it online. That VM snapshot mistake I mentioned earlier? Happens way more often than you'd think. A quick automation script that checks for duplicate NetBIOS names on boot can save you this headache — I've got a PowerShell one-liner that runs at startup and logs a warning if it finds a conflict.