Fix NERR_ACFNoRoom (0X000008B4) Too Many Names

When This Error Hits

You're running a Windows NT 4.0 domain controller, or maybe an old Samba server still speaking NT4-style RPC. You try to add a user with net user /add or through the User Manager for Domains. Right away you get: System error 0X000008B4 has occurred. There are too many names in the user accounts database.

The machine sits around 2,500 users. You check — yep, you're bumping into the wall. This isn't a disk space or memory issue. It's a hard architectural limit.

What's Actually Happening Here

This error is NERR_ACFNoRoom from the NetApi32 layer. The Security Account Manager (SAM) database on Windows NT 4.0 and older systems has a fixed bucket-based hash structure. The max is 2,515 user accounts — not 2,515 security principals, just users. Groups and computers are tracked separately, but they also have their own limits (around 1,024).

The number 2,515 isn't random. It comes from the SAM's internal allocation of three blocks of 840 entries, plus some overhead for the built-in accounts. Once you fill those buckets, NetUserAdd fails with 0X000008B4.

Microsoft never officially patched this in NT 4.0. It's not a bug — it's a design decision from the early '90s when nobody imagined a domain would have more than a couple thousand users.

The Fix

You have two options. Pick one based on your environment. Don't try both at once.

Option A: Bump the SAM Limit via Registry (NT 4.0 only, risky)

1. Log in as Administrator on the domain controller.
2. Open Regedit (regedit.exe).
3. Navigate to

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

   .
4. Create a DWORD value named SamMaxEntries if it doesn't exist.
5. Set it to a decimal value between 2515 and 65535. Microsoft warns that values above 0x4000 (16384) can cause memory corruption — no joke, the SAM heap isn't designed for huge numbers. I'd stick to 5000 max.
6. Reboot the domain controller.
7. Try adding a user again.

Why this works: The registry entry raises the internal pool size. But the SAM client libraries on older workstations won't know about it — they'll still report the old limit in some API calls. So this is a bandaid, not a clean fix.

Option B: Upgrade to Active Directory (the real fix)

1. Stand up a new Windows Server 2003 or later domain controller (or 2008 R2 if you're still on that).
2. Run adprep /forestprep and adprep /domainprep from the Server installation media if upgrading from NT 4.0.
3. Promote the new server to a domain controller in the same domain using dcpromo.exe.
4. Transfer the FSMO roles to the new server.
5. Demote the old NT 4.0 PDC/BDC.
6. Now the SAM limit is gone. Active Directory's database (NTDS.dit) scales to billions of objects.

Why this works: Active Directory uses the ESE (Extensible Storage Engine) database, not the flat SAM hash. There's no 2,515 cap. You can add users until you run out of disk.

Still Failing?

Check three things:

• Are you hitting the domain's group limit instead? NT 4.0 caps groups at 1,024 global groups and 1,024 local groups. The error code is the same (0X000008B4) but the root cause is different. Check net localgroup counts.
• Is the registry edit actually taking? Reboot after changing SamMaxEntries. No reboot = no effect.
• Is the client also NT 4.0? Older clients cache the SAM size. Run net accounts /sync on the client to force a re-read. Or just reboot the client.

If none of that helps, you're probably dealing with a corrupt SAM database. That's a different beast — run chkdsk /f on the system drive, then restore from backup. But in 99% of cases, the limit is the problem, not corruption.