Fix RPC_NT_GROUP_MEMBER_NOT_FOUND (0XC002004B) in AD

Quick answer for pros

Use ADUC's Active Directory Users and Computers console or PowerShell's Remove-ADGroupMember to delete the orphaned SID referencing a deleted object. Run repadmin /syncall after to force replication.

Why this error shows up

This error—RPC_NT_GROUP_MEMBER_NOT_FOUND (0XC002004B)—tripped me up the first time too. It usually appears when you try to modify a group's membership in Active Directory and one of the members is a SID for a user, computer, or another group that's been deleted from the directory but the group member reference still exists. I've seen it most often after bulk user deletions or when a domain controller gets restored from a backup without proper tombstone handling. The group object still holds that SID, but AD can't resolve it to an actual object, so it throws this error. The problem is especially common in Windows Server 2012 R2 and later versions when you're managing groups with nested members across multiple domains.

Fix steps

1. Identify the broken group—Open ADUC on a domain controller (preferably Windows Server 2019 or 2022). Right-click the domain and select Find. Search for groups that might have been modified when the error occurred. If you know the group name, navigate to it directly under an OU like CN=Users,DC=domain,DC=com.
2. Check the membership—Double-click the group, go to the Members tab. Look for any member entry that shows as a SID (starts with S-1-5-21-) instead of a friendly name. If you see one, that's your orphaned SID.
3. Remove the orphaned SID—Select the SID entry and click Remove. You'll get a confirmation prompt—click Yes. If ADUC gives you another error about not finding the object, try removing it via PowerShell instead. Open PowerShell as an administrator and run:

   $group = Get-ADGroup -Identity "YourGroupName" -Properties Members
   $group.Members | ForEach-Object {
       try { Get-ADObject $_ | Out-Null }
       catch { Remove-ADGroupMember -Identity $group.DistinguishedName -Members $_ -Confirm:$false }
   }

   Replace YourGroupName with the actual group name.
4. Force replication—Run the following on a domain controller to sync all changes:

   repadmin /syncall /AdeP

   This ensures the fix propagates to all domain controllers quickly.
5. Test the error—Try adding or removing a legitimate member to the group. The error should be gone.

Alternative fixes

If the main fix doesn't work (say ADUC crashes or PowerShell throws access denied), try these:

• Use ADSI Edit—Connect to the default naming context, find the group object, right-click it, choose Properties, locate the member attribute, and manually delete the orphaned SID value. This is riskier—back up the attribute value first by copying it to Notepad.
• Check if the object is in the recycle bin—If you're on Windows Server 2008 R2 or later with AD Recycle Bin enabled, restore the deleted object. Use:

  Get-ADObject -Filter {Name -eq "OldUserName"} -IncludeDeletedObjects | Restore-ADObject

  After restoration, the SID becomes valid again, and the error stops.
• Use ntdsutil—If replication issues persist, run ntdsutil and clean up lingering objects. I've only needed this in extreme cases when multiple DCs had replication conflicts.

Prevention tip

Always delete user or computer objects through proper procedures—never directly delete from the domain's LostAndFound container or restore DCs from backups without a tombstone reanimation process. Enable the AD Recycle Bin feature in your forest (it's a one-time toggle). This lets you restore deleted objects within 180 days and avoids these orphaned SIDs entirely. Also, run a quick script weekly to check for unresolved SIDs in group memberships:

$groups = Get-ADGroup -Filter *
foreach ($g in $groups) {
    try { Get-ADGroupMember $g | Out-Null }
    catch { Write-Warning "Issue with group $($g.Name): $_" }
}