Fix RPLUSER 0X00000A46: Local Group Missing on Windows

You're staring at this error because something on your Windows box — usually a legacy service, a replication job, or an old login script — is trying to reference the RPLUSER local group and it's just not there. The full message reads: "The local group could not be found. The exact error code is: 0X00000A46" (which maps to NERR_RplNeedsAcct). I've seen this most often after a domain migration, or when someone "cleaned up" local groups and got a bit too aggressive. It's also common on servers that were promoted from workgroup to domain without a fresh install.

Here's the deal. RPLUSER is a hidden local group that Windows creates by default. It's tied to the Remote Program Load (RPL) service — legacy stuff from the Windows NT days, but it still exists in modern Server versions. When that group gets deleted (or never created properly), any service that expects it will throw this exact error. It's not a hardware issue. It's not a permissions issue. It's just a missing object in the SAM database.

Root Cause

The group is normally created during OS installation. In my experience, the culprit is almost always one of three things:

1. Someone manually deleted RPLUSER using net localgroup or the GUI, thinking it was unused.
2. A domain migration tool (like ADMT) skipped it when copying local groups over.
3. The server was sysprepped or cloned, and the group didn't survive the process.

Once it's gone, you can't just "re-add" it through the GUI — the group is hidden, so you won't see it in the Local Users and Groups snap-in. That catches a lot of people off guard.

The Fix: Recreate RPLUSER

Don't bother reinstalling or running SFC — that won't help here. The fix is straightforward. You're going to recreate the group with the built-in command line tool. Here's the exact sequence:

1. Open an elevated Command Prompt (right-click > Run as Administrator).
2. Run this command to create the group:

net localgroup RPLUSER /add

That's it. Literally one command. But wait — you might need to set the right SID or add the default members. In most cases, the group just needs to exist. The service that was failing will now find it and move on.

If you're paranoid (like me), verify it worked:

net localgroup RPLUSER

You should see the group listed, even if it's empty.

If It Still Fails

Sometimes recreating the group isn't enough. Here's what to check next:

1. Check if RPL Service is Actually Needed

If you're not running legacy RPL clients (like old diskless workstations), you can disable the service altogether. That sidesteps the error entirely.

sc config RplService start= disabled
sc stop RplService

2. Look for Hard-Coded SIDs

Some apps store the group's SID, not the name. If you recreated the group, it'll get a new SID. The default SID for RPLUSER is S-1-5-32-43 (well-known for the built-in group). If your app is checking for that specific SID, you're stuck — you'll need to find wherever it's hard-coded and update it. That's rare, but I've seen it with some homegrown scripts.

3. Check the Event Log

Look at the System and Application logs. Search for Event ID 5805 or 5807 — those often tie directly to Netlogon and group resolution failures. That'll point you to which service is actually choking.

4. Domain Controller Specifics

If this is a DC, you might need to ensure the group is replicated. Use repadmin /replsum to check replication health. In one case, I had to run adprep /rodcprep on a 2016 DC after a bad migration — that regenerated the missing groups.

Bottom line: 90% of the time, net localgroup RPLUSER /add fixes it instantly. The other 10% is digging into what's referencing the group and why. Don't overthink it — start with the command and move up from there.

One last thing: after you recreate the group, reboot the server if you're running anything older than Server 2012. Some services cache group lookups, and a reboot clears that cache. Took me a while to learn that one.