Fix NERR_BadUsername 0X0000089A on Windows

Cause 1: You Typed the Username Wrong (Honestly, This Is It Most of the Time)

I know it sounds dumb, but 0X0000089A (NERR_BadUsername) almost always means the username you're typing doesn't exist on the machine you're connecting to. Not that the password is wrong — that would be a different error. This one specifically says the name is invalid.

So before you blame Active Directory or your network team, check the obvious.

What to check:

• Spelling, including capitalization. Windows usernames are case-insensitive, but typos are typos.
• Whether you're typing DOMAIN\username or MACHINENAME\username when needed. For a local account, you can't just type username — you need the machine name prefix.
• On Windows 10/11, the login screen sometimes shows a Microsoft account email instead of a local username. If you're trying to map a drive with a local username but the account is linked to an email, that's your problem.

The fix:

Open Command Prompt and check what accounts exist on the local machine:

net user

That lists everything. If your username isn't there, you're using the wrong name. For domain accounts, you can't query without AD tools, but you can test with:

net use \\server\share /user:DOMAIN\username

If the username really exists and you're still getting 0X0000089A, move to the next cause.

Cause 2: You're Mixing Up Local vs. Domain Accounts

This is a close second. The error pops up when you try to authenticate with a local account on a domain-joined PC, or a domain account on a machine that's not joined. The username you're providing is perfectly valid — just not on that target.

What's actually happening here is the target machine tries to resolve the username against its local SAM database or the domain it's joined to. If it can't find it, you get NERR_BadUsername. It doesn't even bother checking the password.

How to fix it:

1. Determine if the target PC is domain-joined. Run systeminfo from a command prompt and look at the "Domain" line. If it says the full domain name, it's joined.
2. If the target is domain-joined, use DOMAIN\username. If it's not, use MACHINENAME\username or just MACHINENAME\Administrator.
3. For Microsoft accounts (like you@outlook.com), the local username is often the first five characters of the email, minus the domain. Checking net user on the target machine is the fastest way to confirm.

I've seen people waste an hour because they kept typing COMPANY\jsmith when the PC wasn't domain-joined at all. Don't be that person.

Cause 3: The Target Machine Has a Broken Network or Password Policy

Less common, but real. Sometimes the username is correct, the domain is correct, but the machine can't validate it because of a network hiccup or a locked-out account.

Here's the thing: NERR_BadUsername doesn't always mean the username doesn't exist. If the Security Accounts Manager (SAM) is corrupted or the Netlogon service is down, the machine might report a bad username when it actually just failed to query the database.

What to try:

• Restart the target machine. Seriously. It clears a lot of transient garbage.
• Check the Netlogon service. Run services.msc, find "Netlogon", and make sure it's running. If it's stopped, start it.
• Check for a locked account. On the target machine, run net user username and look at "Account active". If it says No, that's a problem.

Also, if you're connecting over a VPN or a flaky network, the target might time out looking up the user and return this generic error. Try pinging the target and check your DNS:

ping targetname

If ping fails, you've got a connectivity issue, not a username issue.

One More Thing: The Registry Hack That Sometimes Fixes It

This is for advanced users who've verified everything and still get the error. There's a known quirk where Windows caches bad username lookups. You can clear it by restarting the Workstation service:

net stop workstation && net start workstation

That forces Windows to drop its local cache and re-query the server. If that doesn't help, you can try lowering the LAN Manager authentication level (not recommended, but it fixes some legacy scenarios).

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LmCompatibilityLevel /t REG_DWORD /d 1 /f

Then reboot. This makes Windows send LM and NTLM responses, which older systems expect. I'd only do this if you're connecting to an old NAS or a legacy share.

Quick Reference

That's the whole playbook. Most people fix this by simply typing the username right — the other cases are rare. If you've tried all this and still get 0X0000089A, you're probably dealing with a domain controller issue that needs your IT admin.