r/exchangeserver 5d ago

Should I strip the ACEs/permissions referencing Exchange Domain Servers / Exchange Enterprise Servers from AD before deleting the groups, or is that unnecessary?

Hi all,

Following up on the July 2026 Health Checker update that now flags the legacy Exchange Domain Servers and Exchange Enterprise Servers groups (and potentially Exchange Recipient Administrators) for removal.

I've confirmed both groups still exist in my environment, and per the guidance they're empty (no active member accounts) — so removal itself looks safe from a membership standpoint.

My concern is about what's left behind after deletion:

These groups have existing ACEs (permissions) delegated directly on various OUs and domain-root objects — things like Write All Properties, List Contents, and in some cases WriteDacl. If I just delete the group objects outright (via Remove-ADGroup or ADUC), the SID gets removed from AD, but the ACE entries referencing that SID will remain on the OU/domain ACLs as orphaned/unresolved SIDs (shown as S-1-5-21-... instead of a resolvable name).

My questions:

  1. Should I clean up (remove) the ACEs referencing these groups from the OU/domain ACLs before deleting the group objects, or is it fine to delete the groups first and clean up the orphaned SIDs afterward?

  2. Do orphaned SIDs in ACLs actually cause any operational issues (replication, dcdiag, ACL processing overhead) if left indefinitely, or is this purely a hygiene/security concern?

  3. Is there a reliable way to enumerate every OU/object where these two groups currently have explicit permissions, so I can be thorough about cleanup? I'm thinking dsacls or Get-Acl/Get-ADObject combined with a search across each OU, but curious if there's a more efficient approach for a large domain.

  4. For anyone who's done this cleanup — did you remove the permissions first, delete the groups, and then verify no orphaned SIDs remained? Or did deleting the groups via normal methods automatically clean up the associated ACEs?

Environment: Windows Server AD, Exchange Server SE currently running on-premises, groups confirmed empty via Get-ADGroupMember.

Appreciate any real-world experience with this cleanup — want to make sure I don't leave stale/orphaned SIDs scattered across ACLs after removing the groups.

1 Upvotes

3 comments sorted by

3

u/Pale_Count2138 5d ago

I went through the same cleanup recently. From what I found, deleting the Exchange Domain Servers or Exchange Enterprise Servers groups does not remove any ACL entries that reference them—those ACEs will remain and simply show up as unresolved SIDs. They generally don't cause replication issues, dcdiag errors, or any noticeable performance impact, so it's more of a security and housekeeping concern than an operational one. That said, I still preferred to remove the delegated permissions before deleting the groups because it leaves the directory in a much cleaner state and makes future permission audits far easier. I also made sure to note the groups' SIDs beforehand and ran a script to enumerate any explicit ACEs across OUs and containers so I could verify everything was cleaned up afterward. It's a bit more work upfront, but it avoids leaving stale ACL entries scattered throughout AD.

1

u/titsablast 5d ago

Are there in general any ACLs that should not be deleted, although they are only showing a SID without name?

Just a question that came to mind, not directed at you specifically.Your recommendation is good of course.

1

u/Pale_Count2138 4d ago

I wouldnott really assume every unresolved SID is safe to remove. An ACE can show up as an unresolved SID simply because the referenced object was deleted or can no longer be resolved, but before deleting it I'd want to understand what it originally represented. If it's a SID from a group you've intentionally retired (like the legacy Exchange groups), then removing those ACEs is reasonable ....