“Access is denied” error running Group Policy Results Wizard

The permission on the Group Policy Container (the GPC, an Active Directory object) has been set to deny your read-level permission. The permissions on the filesystem object you've found (the "Group Policy Template", or GPT) can "come out of sync" with the permissions on the Active Directory object. (For some background, have a look at http://msdn.microsoft.com/en-us/library/aa374180(VS.85).aspx).

Fortunately, you can use a tool like ADSIEDIT to restore the permission on the GPC. Using ADSIEDIT you'll find a "groupPolicyContainer" corresponding to the GUID of the problematic GPO under the "CN=Policies" object of the "CN=System" object in the Domain NC of the domain the GPO resides in. (Install ADSIEDIT from the Support Tools on the Windows Server media, open it, drill into "Domain", then "CN=System" and "CN=Policies" and you'll find the GPC).

Using the "Security" tab of the "Properties" sheet for the GPC corresponding to the problematic GPO and use the "Default" button in the "Advanced" dialog to restore the default permissions.

If ADSIEDIT won't allow you to modify the permissions (probably displaying an oddball error message like "An invalid directory pathname was passed"), then likely someone placed a "Deny / Full Control" permission onto the object. The dsacls command with the arguments CN=GUID-OF-THE-PROBLEMATIC-GPO,CN=Policies,CN=System,DC=your,DC=domain,DC=com will report the permissions. Search for the errant "Deny" and "FULL CONTROL" entry and use the /R user-or-group-namme parameter on dsacls to remove the permissions associated with that user or group. If it's really messed up then you'll probably have to use the Windows Server 2008 ADAM / AD LDS version of dscals with the /takeownership argument to take ownership of the object).

This seems more like a management issue than a technical one. Taking ownership with a script or trying to block the few people that would ever play with permissions is more trouble than I think it would be worth.

In the past, we've made personal folders completely inaccessible to domain admins, but there are inevitably times when people call up and ask "can you check something in my personal directory?"

So we follow a policy that admins have to be able to read everything (with a few exceptions). If we ever come across a folder where someone has blocked admin access, we find out why, explain why we think it's better that we have access, and we change the permissions back to our default. If it happened while we were tracking down a problem, that's why we have the policy: so we could simply take control at the time and sort it out later.