Fix 0X000008DE Computer Name Not Added as Message Alias

You'll see error 0X000008DE (NERR_NoComputerName) in the System event log or when running nltest /dsregdns right after joining a domain or rebooting a domain-joined machine. The exact trigger: Windows tries to register its NetBIOS computer name as a message alias via the Netlogon service, but the domain controller can't add it. This usually happens on Windows Server 2016/2019, Windows 10/11, or older domain controllers still running Windows Server 2008 R2. I've seen it most often when someone renamed a computer but didn't reboot, or when DNS scavenging deleted the machine's A/PTR records.

What's Actually Going On?

The root cause is simple: the domain controller's Netlogon service can't register the computer's NetBIOS name in its local database of trusted aliases. Think of it as the DC saying "I don't have a spot for that name." The usual suspects are:

Stale DNS records — the old computer name or IP still exists in the forward lookup zone.
Duplicate SPN — another object in AD already has the service principal name for the computer's FQDN.
NetBIOS scope mismatch — the computer's NetBIOS name doesn't match what the DC expects.
Clock skew — Kerberos tickets expire if the system time is off by more than 5 minutes from the DC.

The Fix: Step by Step

Step 1: Check DNS Registration

Open an elevated command prompt and run:

nslookup %computername%.%userdnsdomain%

If it returns the wrong IP or nothing at all, you've got a DNS problem. Run:

ipconfig /registerdns

Then check the DNS server — remove any stale records for the old computer name if the machine was renamed.

Step 2: Verify the Computer Account in AD

On the domain controller, open AD Users and Computers. Find the computer object. Right-click it, select Properties, then go to Attribute Editor. Look for servicePrincipalName. If there are duplicate entries for the same hostname, remove the duplicates using adsiedit.msc or PowerShell. A clean SPN set should have exactly one entry for each service type (like HOST/machine.domain.com).

Step 3: Reset the Machine Account Password

On the problem machine, run these commands as admin:

netdom resetpwd /s:<your_dc_name> /ud:<domain_admin> /pd:*

Then reboot. This forces the DC to re-register the computer name. Don't skip the reboot — the Netlogon service caches the old credentials.

Step 4: Check NetBIOS Scope

This one's rare but I've hit it. Open the registry editor and go to:

HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters

If ScopeID exists and is not blank, delete it. A non-empty ScopeID prevents NetBIOS name registration entirely. Reboot after changing it.

Step 5: Verify Time Sync

Run on the client:

w32tm /query /status

If the time is off by more than 5 minutes, reconfigure the time source:

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time

Still Failing? Check These

Firewall rules — make sure UDP ports 137-138 and TCP 139 are open between the client and the domain controller. NetBIOS name registration uses NetBIOS over TCP/IP.
Event ID 5789 — look in the System log on the DC for this event. It points directly to the failing registration.
SMB signing — if SMB signing is required but not enabled on the client, name registration can fail. Enable it via Group Policy: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > "Microsoft network server: Digitally sign communications (always)".
Domain controller version — older DCs (2003, 2008) have a nasty habit of filling up their Netlogon alias table. On the DC, run nltest /dbflag:2080FFFF and check the log for "no more entries" messages. If that's the case, promote a newer DC.

Most of the time, it's DNS. Clean those stale records, reset the machine account, and reboot. That resolves 9 out of 10 cases. If not, dig into SPN duplicates — that's the second most common culprit.