0X00000982: NERR_AcctLimitExceeded Fix

Quick answer: 0X00000982 is NERR_AcctLimitExceeded — Windows terminated the session because the user's logon-hours window expired, not because of a crash or a network drop.

What's actually happening here is that every AD account carries a logonHours attribute — a 21-byte bitmap covering Sunday through Saturday in one-hour blocks, in UTC. When a user is connected (RDP, SMB, mapped drive, whatever) and current time crosses out of an allowed block, the Local Security Authority kicks the session and writes event 0X00000982 into the System log. The reason most admins get blindsided by this is that logon-hours restrictions are often set once during onboarding and then forgotten for years, until a shift change or a DST jump lands someone outside the window. The reason the error looks like a mystery disconnect is that the client side usually just says "session ended" — no hint that the server did it on purpose.

Confirm the account and its allowed hours

Find the account in Active Directory. Pull its logon hours with PowerShell so you see the raw bitmap, not a friendly summary:
```
Get-ADUser -Identity 'jdoe' -Properties logonHours, logonWorkstations |
  Select-Object Name, logonHours, logonWorkstations
```
An empty logonHours means the account is unrestricted and the error came from something else — go to the alternatives section below.
Decode the bitmap into readable days and hours. The AD Users and Computers GUI shows this under Account > Logon Hours, and it's easier for a quick check. From PowerShell you can use the account operators module or just open dsa.msc and look at the grid. Compare it against the actual time the session died, converted to UTC.
Check the server's System event log for the matching entry. Filter for source LsaSrv or the security log for 4634/4647:
```
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1} |
  Where-Object { $_.Message -match '0X00000982' }
```
The event timestamp is authoritative. If the disconnect happened two hours earlier than you expected, that's your DST clue.
If the hours genuinely need to change, extend them. GUI: dsa.msc > user properties > Account tab > Logon Hours > select block > Allow. Command line for a quick fix:
```
net user jdoe /time:M-F,08:00-18:00
```
That sets Monday through Friday, 8am to 6pm, in local time as the tool interprets it. Verify with net user jdoe afterward — the /time string is easy to mistype and it fails silently on bad ranges.
Force the change to replicate. If you've got multiple DCs, the session might reconnect to a DC that still has the old bitmap cached for up to the replication interval. Nudge it:
```
repadmin /syncall /AeD
```
Have the user log back in. If the error is gone, you fixed it. If the session drops again at the exact same wall-clock time, the bitmap is still wrong somewhere — check every DC, not just the one you edited.

If changing hours doesn't help

Look at the whole picture per user, not just hours. NERR_AcctLimitExceeded shares the 0x982 code with a couple of adjacent conditions on older Server 2003-era tooling, including workstation restrictions. If logonWorkstations is set to a specific list and the user's machine isn't on it, you can see a similar disconnect pattern. Clear it or add the machine.
Check for a forced logoff GPO. Group Policy > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Session Time Limits. Set a maximum session time and Windows disconnects users on a schedule that looks identical to the hours error in the event log.
Set the account to never expire and verify it isn't locked. A locked or expired account won't typically produce 0X00000982, but admins frequently conflate the two when they only see 'session deleted' in a third-party monitoring tool.
Audit the DC that issued the ticket. Run klist purge on the client and have them reconnect. If the DC handling the logon is a different one than where you changed hours, the Kerberos ticket may be carrying stale restrictions.

Prevention

The real fix is to stop treating logon hours as a set-and-forget field. Export them quarterly:

Get-ADUser -Filter * -Properties logonHours |
  Where-Object { $_.logonHours } |
  Select-Object Name, logonHours | Export-Csv logon-hours-audit.csv

Any account with a non-null logonHours shows up in that CSV. Review it every quarter, especially before a shift rotation or a DST transition. Also, if your org genuinely needs 24/7 access for some users, clear the restriction entirely rather than setting a wide window — a wide window still cuts people off at the boundary, and nobody ever remembers the boundary.

One more thing: document which accounts have hours restrictions and why, right next to the ticket that created them. Six months from now, the person googling 0X00000982 will be you or a colleague, and that note saves an hour of DC digging.