NERR_TooManySessions (0X000009A0) fix — server at max sessions

First cause: Stale SMB connections filling the session table

Most of the time, this error hits because clients disconnect uncleanly—power loss, VPN drop, or just shutting down without logging off. Windows Server holds those sessions open until they time out (which can be hours). I had a client last month whose file server locked up at 9 AM every Monday because people left VPN sessions open all weekend.

Check the current session count first. Open PowerShell as admin and run:

net session

That lists every active session. Count them. If you see 50+ and your server's max is 50 (default for some older SKUs), there's your problem.

To clear stale sessions, run:

net session /delete /y

That nukes every session. Clients reconnect automatically when they need to. If you want to target specific ones, use net session \\clientname /delete. This is usually the fastest fix—under 30 seconds, and the error disappears.

To prevent recurrence, reduce the session timeout. Open Registry Editor, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters, create a DWORD called DisableStrictNameChecking (just kidding—that's for a different problem). Instead, look for autodisconnect and set it to 15 (minutes). If it's not there, create a DWORD named autodisconnect with value 15. Reboot the server. Now idle sessions clear out faster.

Second cause: Server SKU limits—reached the max concurrent sessions

Windows Server has hard per-connection limits based on the edition. For example, Windows Server Essentials caps at 50 users or 50 devices. Windows Server Standard on newer versions can handle thousands, but older builds or misconfigured roles might throttle you. The error 0X000009A0 maps to NERR_TooManySessions, which means the server literally won't accept new SMB connections.

First, confirm the limit. Run this in PowerShell:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters" -Name "MaxMpxCt"

If MaxMpxCt is absent, the default on most Windows Server editions is 50 (yes, 50 simultaneous sessions). If you need more—and you're on Standard or Datacenter—you can raise it. Create or set MaxMpxCt as a DWORD and give it a value. For a small office, 200 is fine. For a busy server, I've set it to 1024. Don't go crazy—each session uses memory. 2048 is usually safe on a server with 8GB RAM.

After changing it, reboot the server. Then check the sessions again with net session—you should see room.

One catch: if you're on Windows Server Essentials or Foundation, you can't raise the limit—that's a licensing restriction. Then the fix is to upgrade the edition or split the load across two servers.

Third cause: File shares with sticky sessions from mapped drives

Mapped drives using persistent connections can hang around even after a reboot. Each mapped drive counts as a session. If 20 people each map 3 drives, that's 60 sessions right there. And if those drives disconnect but the server still sees them, you're burning slots.

Check for this by running net use on a client machine to see all connections. On the server, look for multiple sessions from the same IP—that's a red flag.

Fix it by telling clients to use net use * /delete before remapping, or set drives to non-persistent. In the Group Policy under User Configuration > Preferences > Windows Settings > Drive Maps, uncheck "Reconnect". This prevents the drive from staying connected after logoff.

Another trick: disable SMB2 leasing if you're on an older NAS or have flaky clients. PowerShell command:

Set-SmbServerConfiguration -EnableLeasing $false -Force

Leasing can cause sessions to linger. Test this in off-hours—it might break performance on some file operations.

Quick-reference summary table

If you've tried all three and still get the error, check the event logs under Applications and Services Logs > Microsoft > Windows > SMBClient and SMBServer. You might have a runaway service or a misconfigured application hammering the server. In 10 years, I've only seen that twice—once from a backup agent that kept opening new connections without closing old ones.