STATUS_NO_SUCH_MEMBER (0xC000017A) Fix for Local Group Errors

You're on a Windows 10 or Windows Server 2022 machine. You try adding a domain user to the local Administrators group via lusrmgr.msc or the net localgroup command. And you get slapped with STATUS_NO_SUCH_MEMBER (0xC000017A). The exact message: “A member could not be added to or removed from the local group because the member does not exist.” I know this error is infuriating—especially when you know the account exists in Active Directory.

This tripped me up the first time too. The root cause is simple: the Security Accounts Manager (SAM) database on the local machine thinks the user SID is valid, but the actual user object is gone—either deleted from AD, renamed, or the SID history got corrupted. It's especially common after a migration where old accounts were removed but leftover group entries remained.

Fix #1: Use PowerShell to Identify the Orphaned SID

1. Open PowerShell as Administrator.
2. Run Get-LocalGroupMember -Group "Administrators" | Format-Table -AutoSize. Look for any entries where Source says Local but the account doesn't resolve to a name. If you see an SID like S-1-5-21-... with no PrincipalSource value, that's your orphan.
3. Note the SID of the missing account.

Fix #2: Remove the Orphaned Member

1. In the same PowerShell session, run: Remove-LocalGroupMember -Group "Administrators" -Member "S-1-5-21-..." (replace with the actual SID).
2. If that fails with “member not found,” we have to go surgical. Open regedit as Administrator.
3. Navigate to HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Aliases\Members. You'll need to take ownership of the SAM key first—right-click it, go to Permissions, add Administrators group with Full Control. Yes, it's a pain, but it works.
4. Under Members, expand each subkey (one per domain/machine account). Find the subkey matching the domain portion of the orphan SID. Under that, delete the key matching the RID (last part of the SID).
5. Close regedit and reboot.

Fix #3: Use a Third-Party Tool (Easier)

If registry editing makes you nervous (and it should—one mistake and you're rebuilding the SAM), use NTFS Security Command Line (sc.exe) or SetACL. I prefer SetACL for this. Download it, then run in cmd as admin: setacl -on "" -ot grp -actn list. This lists all local groups with their members. Then setacl -on "" -ot grp -actn del -mem "SID" -gid "S-1-5-32-544" to remove the orphan from Administrators.

Fix #4: Recreate the User in Active Directory

If the account was deleted by accident, and you have permissions, recreate the user with the same username and SID. But honestly, that's rarely possible. Better to just remove the orphan and add the correct user fresh.

What If It Still Fails?

Check these:

• Group Policy lockdowns? If the machine is domain-joined, a GPO might be restricting local group modifications. Run gpresult /h gp.html and look for “Restricted Groups” policies. If it's there, you need to add the user via Group Policy Management, not locally.
• Corrupted SAM database? Run sfc /scannow and dism /online /cleanup-image /restorehealth. If that doesn't fix it, consider a repair install of Windows.
• Language mismatch? Rare, but if the machine's language pack doesn't match the original user creation language, the SID might not resolve. Use wmic useraccount where name='username' get sid on a known-good machine to compare.

That's it. No fluff. If you hit a wall, the SAM is probably toast and a backup restore is your only move. But 90% of the time, removing the orphan SID fixes it. You're welcome.