Fix 0X0000099C NERR_NoSuchServer Error

Quick answer: 0X0000099C (NERR_NoSuchServer, decimal 2310) means Windows can't resolve the server name you typed into a live machine on the network — fix your name resolution (DNS, WINS/NetBIOS, hosts file) or correct the server name itself before chasing anything else.

I know this error is infuriating because it shows up looking like a permissions problem when it's really a plumbing problem. You'll be mid-migration, run net use Z: \\FILESRV01\data from a perfectly healthy workstation, and Windows just shrugs with "The server identification does NERR_NoSuchServer not specify a valid server." Nothing about your credentials, nothing about SMB signing, nothing about the share — the machine never even got to that conversation. The name you typed didn't turn into an IP address it could reach.

Happens all the time after a DNS server swap, a VPN split-tunnel change, or when someone renames a server but leaves the old A record in DNS. It also pops up on fresh Hyper-V or Azure VMs where NetBIOS is turned off and the DNS suffix search list is empty. The client literally has no way to turn "FILESRV01" into "10.20.30.40."

Fix it in this order

Ping the name first, not the IP. Open a command prompt and run:
```
ping FILESRV01
nslookup FILESRV01
nslookup FILESRV01 10.20.30.10
```
If the first ping fails but the nslookup against your real DNS server works, your client's DNS config is wrong. If both fail, the record is missing or the server is off. If the second nslookup fails but the third succeeds, your client is pointing at the wrong DNS server. That's your answer — don't keep digging.
Verify the name spelled in the script or mapped drive is actually correct. I've watched three-hour outages caused by a trailing dot, a smart quote pasted from Outlook, or "FILE-SRV01" vs "FILESRV01." Copy the name straight from hostname on the target server.
Check the DNS record on the server side. On your DNS server (or in DNS Manager on a DC), look for the A record for the target host in the forward lookup zone that matches your client's suffix. If the server recently changed IP, the record may still point to the old address. Flush the client cache too:
```
ipconfig /flushdns
ipconfig /registerdns
```
On the server itself, ipconfig /registerdns forces it to re-register its own A and PTR records. Do that before you blame the client.
Confirm NetBIOS isn't the fallback you're accidentally relying on. Run nbtstat -A 10.20.30.40 against the target's real IP. If that returns a name but plain ping FILESRV01 fails, you have a suffix search problem. Add the DNS suffix to the client's adapter under IPv4 properties → Advanced → DNS tab → "Append these DNS suffixes." On a domain-joined machine, also tick "Register this connection's addresses in DNS."
For workgroup or legacy environments, check WINS. Yes, WINS still exists in 2025 on more networks than anyone admits. If your client has WINS servers listed but the target isn't registered, you'll get 0X0000099C every time. Point the client's WINS at the correct server, or push the target to register with nbtstat -RR.
Test SMB directly by IP.
```
net use Z: \\10.20.30.40\data /user:DOMAIN\you
```
If this works but the hostname version doesn't, you've 100% confirmed NERR_NoSuchServer is a naming issue and nothing deeper. Stop messing with SMB version toggles — they won't help.

If that still doesn't fix it

Check the hosts file. C:\Windows\System32\drivers\etc\hosts — a stale entry here overrides DNS. I've seen a single line from 2019 cause this exact error on a fresh Windows 11 23H2 box.
Look at your VPN. Split-tunnel VPNs routinely hand out the corporate DNS server but route traffic around it. Kill the VPN and retest. If it works, your VPN client's DNS push is broken.
Windows Firewall on the target. File and Printer Sharing (SMB-In) needs to be allowed on the private profile. If it's blocked, DNS resolves fine but SMB never answers and some tools report NERR_NoSuchServer anyway.
Computer Browser / Function Discovery. On very old flat networks, if the Computer Browser service is dead on every machine, name browsing via net view fails. This isn't usually the root cause of 0X0000099C but it disguises itself as one.

Prevent it next time

Make DNS the single source of truth on your network and turn off NetBIOS on modern subnets. Push DNS suffixes via DHCP option 119 or Group Policy, and add a monitoring check that pings every server by FQDN every five minutes. Half the NERR_NoSuchServer tickets I've closed over the years would never have been opened if someone had noticed a dead A record before a user did.