0X00000789

Fix RPC_S_GRP_ELT_NOT_REMOVED (0X00000789) Error

Server & Cloud Intermediate 👁 7 views 📅 Jul 21, 2026

This RPC error pops up when Windows can't remove a group from Active Directory. I'll show you three ways to fix it.

Quick answer for pros

Run ntdsutil > metadata cleanup > remove selected server to force-remove the orphaned group object. Or use ADSI Edit to delete the group directly from the Configuration partition.

What this error means

RPC_S_GRP_ELT_NOT_REMOVED (0X00000789) is a real pain. You'll see it when you try to delete a group from Active Directory Users and Computers (DSA.msc) and Windows just says "nope." The group element could not be removed.

This usually happens after a domain controller gets demoted wrong or replication breaks. The group still thinks it belongs to a server that's gone. Classic orphan problem. I've seen this on Server 2016 and Server 2019 mostly, but it can hit any version.

The real fix is cutting that group out of the directory metadata. You can't delete it through the normal UI because AD thinks another server still holds a copy. So we go behind the scenes.

Step-by-step fix using ADSI Edit

This is my go-to method. Works 90% of the time.

  1. Open ADSI Edit. You find it in Server Manager under Tools. If it's not there, install it: Add Roles and Features > Remote Server Administration Tools > AD DS and AD LDS Tools.
  2. Right-click ADSI Edit in the left pane and choose Connect to....
  3. In the dialog, set Select a well-known Naming Context to Configuration. Click OK. You should see a new node appear.
  4. Expand Configuration [yourserver.domain.com].
  5. Navigate down: CN=Configuration,DC=domain,DC=com > CN=Services > CN=Windows NT > CN=Directory Service > CN=Deleted Objects. Wait — if the group isn't there, go to CN=Groups under the domain partition instead. That's: CN=Users,DC=domain,DC=com or CN=Groups,DC=domain,DC=com depending on your OU structure.
  6. Find the group that's giving you the error. It'll have the same name you tried to delete.
  7. Right-click the group and choose Delete. You'll get a warning. Click Yes. After you click Yes, you should see a confirmation message: "The object has been deleted."
  8. Close ADSI Edit. Open Active Directory Users and Computers again. Try deleting the group now. If it works, you're done. If it still errors, move to the next fix.

Alternative fix: NTDSUtil metadata cleanup

This one's more advanced but handles stubborn orphans.

  1. Open Command Prompt as Administrator.
  2. Type ntdsutil and press Enter. You'll see the prompt change to ntdsutil:.
  3. Type metadata cleanup and press Enter. Prompt changes to metadata cleanup:.
  4. Type remove selected server and press Enter. It'll ask you for credentials. Use a domain admin account.
  5. A dialog pops up listing servers. Select the server that originally held the group (the one you demoted or that's offline). Click OK. You should see "Removal completed successfully" or similar.
  6. Type quit twice to exit NTDSUtil.
  7. Restart the Active Directory Domain Services service: net stop ntds && net start ntds.
  8. Try deleting the group again in DSA.msc. After restarting the service, the group should disappear like it never existed.

Alternative fix: Replication repair

If neither ADSI Edit nor NTDSUtil worked, replication might be broken.

  1. Open Active Directory Sites and Services.
  2. Expand Sites > your site > Servers > your server > NTDS Settings.
  3. Find the connection object for the domain controller that's missing or dead. Right-click it and choose Delete. Say Yes to the warning.
  4. Right-click NTDS Settings and choose Check Replication Topology. Wait a minute.
  5. Now right-click NTDS Settings again and choose Replicate Now. You should see "Replication request has been queued."
  6. Wait 5 minutes. Then try deleting the group again.

Prevention tip

This error mostly comes from demoting a domain controller without cleaning up metadata first. Always run ntdsutil metadata cleanup before you demote a DC. If you already demoted, run it after. That little step saves hours of headache. I also check replication health once a month with repadmin /replsummary. Catches orphans early.

Note: If you're on a read-only domain controller (RODC), you can't run these fixes locally. You have to log on to a writable DC.

Was this solution helpful?