DFSR replication seems to be broken in my domain, and before starting to fix that, I wanted to take backups of the current Group Policy Objects. However, I am unable to back up the Default Domain Policy, as Group Policy Management -> Default Domain Policy -> Back up GPO simply fails with the error "An invalid directory pathname was passed
", and PowerShell Backup-GPO
fails with "Exception from HRESULT: 0x80005000
".
I did find the earlier question "Diagnosing why a Group Policy Object is inaccessible", which does seem very similar (though the GPO is accessible through Group Policy Management insofar as being able to modify it). However, restoring the default permissions to the GPO as indicated using ADSI Edit didn't help. It didn't fail either; however, switching back to Group Policy Management and re-selecting the Default Domain Policy did note that the filesystem permissions were not in sync with Active Directory and offered to fix them, which I allowed. Even after this, backing up the GPO fails as above. (I subsequently went through all of the sub-folders under the GPO's CN, and reset them to default permissions as well, though I didn't notice any of them not being there already.)
dsacls "CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=my,DC=domain"
does not (and did not) list any Deny rules (exact output), so I'm at a loss - what could be causing the access problems?
Update 2013-08-27:
As suggested by Douda, I looked at ProcMon dumps of powershell.exe trying to run Backup-GPO on the Default Domain Policy, and noticed a few significant differences compared to the dump Douda kindly provided:
NAME NOT FOUND
results from CreateFile
operations on four directories immediately under the GPO directory \\servername\sysvol\domainname\Policies\{31b2f340-016d-11d2-945f-00c04fb984f9}
: UserStaging, MachineStaging, UserOld, and MachineOld.Registry.pol
under MACHINE
and USER
, I get a NAME NOT FOUND
result from a CreateFile operation on ...\Adm
ACCESS DENIED
result from ...\MACHINE\microsoft\windows nt\SecEdit
on a QuerySecurityFile
operation. There is a hex value 0x20 as information in the details, but I don't know the significance of this.I checked the permissions on the SecEdit
folder referred to above (as well as CN=System/CN=Policies/CN={guid}/CN=Machine/CN=Microsoft/CN=Windows under ADSI Edit), and they seem to be permissive enough as far as I can tell. The results are essentially identical from the two DCs.
I will be honest, your issue is pretty unusual. I worked a lot with GPO and never saw this error. I might be wrong, but it seems that you're too focused on the ACLs side in your troubleshoot. As the issue is only related to your root GPO, I could suggest you to do some manual digging :
Did you try to backup from a different DC to see if you reproduce the error on your whole domain ?
I updated to Windows Server 2012 R2, and the same issue still persisted. I did notice, however, that I was getting Event 2004, Group Policy Management events whenever I tried to back up the Default Domain Policy GPO (I'd received the events already earlier, but hadn't noticed them). This, in turn, led me to http://www.eventid.net/display-eventid-2004-source-Group%20Policy%20Management-eventno-6412-phase-1.htm and the suggestion to turn up the trace level in Group Policy Management by creating the two registry keys:
Key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
Value: GPMgmtTraceLevel
Value Type: REG_DWORD
Value Data: 2
Key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics
Value: GPMgmtLogFileOnly
Value Type: REG_DWORD
Value Data: 1
This gave me a warning line in gpmgmt.log
(split to multiple lines for clarity):
[5890.af8] 10/29/2013 19:47:17:955 \
[WARNING] CGPMDSObjectNode::process: \
ADsGetObject failed binding to \
LDAP://(FQDN-of-DC)/CN=(Domain)/(An-ancient-XP-wireless-network-policy),\
CN=Wireless,CN=Windows,CN=Microsoft,cn=Machine,\
cn={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,\
CN=System,DC=(my),DC=(domain) \
0x80005000
I removed this, and after deleting two further ancient network policies (after iterating the above process to find the problematic policies), the Default Domain Policy now backs up just fine (as do all the other policies).
User contributions licensed under CC BY-SA 3.0