Fix 0x000008EE NERR_NoForwardName: Message Alias Not Found

This error is maddening because it sounds so vague. "The forwarded message alias NERR_NoForwardName could not be found on the network" — thanks, Windows, that clears everything up. What it actually means is that your machine sent out a NetBIOS name query and nothing on the LAN answered with a matching alias. The alias itself doesn't exist anywhere on the network, or the box that owns it is unreachable.

If you hit this while running net send, a legacy app that talks over the Messenger service, or a domain logon script from 2004, you're in the right place. The fix depends on which of these three root causes is biting you.

Cause 1: The alias (or machine) genuinely doesn't exist anymore

Nine times out of ten, this is it. Someone ran net send PAYROLL01 or a scripted message to a workstation that got decommissioned, renamed, or is simply powered off. Windows broadcasts a NetBIOS name query, gets radio silence, and throws 0x000008EE.

I saw this constantly at a manufacturing client — their old ERP app pushed status pings to terminals by hardcoded NetBIOS name. Half those terminals had been retired years earlier, but the app was still firing off messages to ghosts.

Check whether the alias is actually alive

From a command prompt on the source machine:

nbtstat -a ALIASNAME

Replace ALIASNAME with the target. If you get "Host not found," the alias isn't on the network — that's your answer. If you do get a response with an IP, jump to Cause 2.

The fix

1. Confirm the target machine is powered on and connected to the same subnet or has a route.
2. On the target, run net config workstation and check the "Computer name" and "Messenger service" status.
3. If the Messenger service is disabled (it is by default on anything after Windows XP SP2), the alias won't respond to message queries even if the machine is up. Enable it only if you actually need legacy messaging — otherwise, replace the app's messaging path with something modern.
4. If the alias is dead, update the script or app config. Don't try to resurrect a retired name.

Real talk: if you're still using net send in production, the real fix is replacing it. Windows killed the Messenger service for good reason. But that's a project, not a Tuesday afternoon fix.

Cause 2: Stale NetBIOS name cache or bad LMHOSTS entry

Windows caches NetBIOS name resolutions for about 10 minutes by default. If a machine was renamed or moved, the source box may still be shouting into the void using an old cached entry. A hand-edited LMHOSTS file with a wrong IP does the same thing — the alias resolves, but to a machine that doesn't own it, so the response never comes back.

Clear the cache and check LMHOSTS

nbtstat -R
nbtstat -c

The first command purges and reloads the NetBIOS name cache. The second displays what's currently cached. If you see the alias pointed at an IP that's wrong, you found the culprit.

Now check for a rogue LMHOSTS file:

%SystemRoot%\System32\drivers\etc\LMHOSTS

Open it in Notepad. Look for the alias. If it's mapped to a stale IP, either correct it or delete the line. The LMHOSTS file is read every time the cache reloads, so a bad entry will keep coming back.

The fix

1. Run nbtstat -R to purge the cache.
2. Open LMHOSTS (if it exists) and remove or correct bad mappings.
3. If you're on a WINS-managed network, don't edit LMHOSTS at all — check the WINS console for stale static mappings instead. Static entries are a classic source of this exact error because nobody ever cleans them up.
4. Retry the message. If it works, great. If not, move to Cause 3.

Cause 3: WINS or domain trust is broken

In a routed environment (multiple subnets, no broadcast reach), NetBIOS names resolve through WINS. If the WINS server is down, misconfigured on the client, or the alias was registered on a WINS server that the source machine can't reach, you'll get NERR_NoForwardName every time.

The "forwarded" part of the error name is a hint — the query was forwarded to another WINS server or across a trust boundary and died there. Broken domain trusts between two forests cause this too, because the alias lookup crosses a boundary nobody has authenticated.

Check WINS config on the source

ipconfig /all | findstr /i "WINS"
nbtstat -n

The first shows which WINS servers you're pointed at. The second shows what your own machine has registered. If you're registering with a WINS server that the target subnet can't reach, that's the problem.

The fix

1. Verify the WINS server is online and reachable (ping it, then check the WINS service on the server itself).
2. On the source machine, confirm WINS server addresses under IPv4 Properties → Advanced → WINS. Remove any decommissioned WINS entries.
3. On the WINS console, look for the alias under Active Registrations. If it's not there but the machine is up, force re-registration on the target: nbtstat -RR.
4. If you're crossing domains, verify the trust is healthy with nltest /sc_verify:DOMAIN from an elevated prompt. A broken trust means the forwarded query dies without a response.
5. As a nuclear option for a lab or a stubborn pair of subnets, add a static LMHOSTS entry on the source pointing directly at the target IP. It's not elegant, but it bypasses WINS entirely.

Also worth knowing: if you've got IPv6 enabled and a dual-stack setup where the target registers an AAAA but not an A record, some legacy NetBIOS paths stall. Disable IPv6 on the NIC as a test if nothing else works. I've seen that resolve this error exactly twice in fifteen years, but both times it was the fix after hours of dead ends.

Quick-reference summary

Start with nbtstat -a on the alias. That one command tells you whether you're chasing a dead name (Cause 1) or a resolution problem (Cause 2 or 3). Everything else follows from that answer.