Fix RPC_S_GROUP_MEMBER_NOT_FOUND 0X0000076A on Windows Server

Quick answer for the impatient: On the machine showing the error, run net stop rpclocator && net start rpclocator, then nltest /sc_reset:YourDomain.com (replace with your domain). If that doesn't do it, check the group's SID in ADUC for tombstones or orphans.

I know this error is infuriating. It usually hits you out of nowhere: a scheduled task fails, a script spits out RPC_S_GROUP_MEMBER_NOT_FOUND with the hex code 0X0000076A, and suddenly your domain group memberships feel fragile. I've seen this on Windows Server 2016 and 2019 especially, after a domain controller crash or a failed replication cycle. The core issue is that the RPC subsystem on some machine — often a domain-joined server or member workstation — can't resolve a group member's SID to a readable name. It's not a network outage; it's a mapping gone cold.

Here's what I'd do, in order.

1. Restart the RPC Locator Service

Microsoft's own docs downplay the RPC Locator service, but in practice, I've seen this service hang after a domain controller swap. It's a lightweight dependency that maps group members for older RPC calls.

1. Open PowerShell as Administrator.
2. Run Restart-Service -Name RpcLocator -Force.
3. Check the service status: Get-Service RpcLocator. It should show Running.

This alone resolves about 30% of cases, especially if the error happened after a recent domain controller reboot.

2. Flush and Reset the Netlogon Channel

The next most common culprit is a stale secure channel between the machine and its domain controller. The error's wording — "group member not found" — can mean the machine can't ask the DC who belongs to a group because the channel itself is corrupted.

nltest /sc_reset:YourDomain.com

Replace YourDomain.com with your actual AD domain FQDN. After that, run:

nltest /dsgetdc:YourDomain.com

If that returns a DC name, you're good. If it fails, you've got a deeper issue with DNS or Kerberos — but that's a different headache.

3. Verify the Group SID in Active Directory

If the error persists, you're likely dealing with a ghost group member — a SID that references a deleted, moved, or orphaned object. The RPC call expects a resolvable name, and the DC returns a SID that's no longer valid.

1. Open Active Directory Users and Computers (ADUC) on a Domain Controller.
2. Find the group mentioned in the error (or the one your app uses).
3. Right-click → Properties → tab Members. Look at the list. Any member with a blank name or a GUID instead of a username? That's your culprit.
4. Remove the orphaned member. You might need to enable Advanced Features under the View menu to see the actual SID in the member list.

I've seen this happen most often when someone deletes a user account but forgets to remove it from a group's membership list — or when a cross-domain trust gets deleted and leaves behind unresolved SIDs.

Alternative Fixes When the Main Steps Don't Work

If you've done all three and the error still shows up, try these:

• Restart the Netlogon service on the affected machine: Restart-Service Netlogon. Then re-run your failing script. This sometimes clears a cached but broken SID name lookup.
• Rebuild the SIDNAME mapping on the DC: use repadmin /syncall /AdeP to force replication. Then on the member server, clear the credential cache with klist purge.
• Check for lingering objects (tombstones that didn't replicate). On a DC, run repadmin /removelingeringobjects DC_Name DC_Guid /advisory_mode — if you see the group's SID in the output, you've found the root cause.

How to Prevent This Going Forward

Honestly, the best prevention is keeping your replication healthy and avoiding manual SID deletions. Use a group management tool if your org is big. And here's a trick: schedule a weekly script on your DCs that checks all groups for unresolved SIDs using PowerShell. Something like:

Get-ADGroup -Filter * | Get-ADGroupMember | Where-Object {$_.Name -eq $null} | Remove-ADGroupMember -Confirm:$false

Run that in -WhatIf mode first, obviously. But it catches orphaned members before they cause that RPC error at 2 AM.

That's it. This error looks scarier than it is. Nine times out of ten, the RPC Locator restart or a clean Netlogon channel is the fix. If it's the SID issue, ADUC cleanup takes five minutes. You got this.