One of the annoying things about Group Policy, is that delegations to GPOs are not cleaned up when the underlying security principal (e.g. user, computer or group) is deleted in Active Directory. For example, if you create a security filter on a GPO for a particular user, computer or group, and delete that object, the GPO retains the (invalid) reference to that principle. In the best case, it causes confusion when looking in GPMC (see below). In the worst case, it can increase GPO processing time by having to search for non-existent security principals during the core phase of GP processing.
The first challenge here is discovering these orphaned delegations against potentially 10s, 100s or even 1000s of GPOs. The good news here for discovering these orphans, is that the SDM Software Reporting Pak comes with nearly 50 in-the-box reports related to Group Policy health, optimization, best practices and security, and one of these is an orphaned delegation report that you can run against a given AD domain on an interactive, or scheduled basis, to find that these problematic GPOs, as shown here.
Once you’ve found these problematic GPOs, the next step is removing the orphaned access control entries. The good news here is that this does not need to be a manual process. Our free PowerShell GPMC module contains two cmdlets that can help with this. First, the Get-SDMGPOSecurity cmdlet allows you to enumerate the delegation on a given GPO, as shown here:
As you can see above, the SID that is referenced in the list of delegations on this GPO called “OrphanedACL”, is the one that we need to clean up, as the underlying security principal has been removed. Once I have this information, I can use the Remove-SDMGPOSecurity cmdlet to clean this orphaned ACE from the GPOs delegation, as shown here:
You’ll notice in the cmdlet above, that I passed the SID of the orphaned ACE as the -Trustee parameter and the permission that I wanted to remove from that Trustee as -permapply. This will remove the errant permission from the GPO.