Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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:

  1. In the very beginning, I get 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.
  2. After Backup-GPO has read Registry.pol under MACHINE and USER, I get a NAME NOT FOUND result from a CreateFile operation on ...\Adm
  3. Finally, I also get an 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.

share|improve this question
1  
Note that the other GPOs can be backed up successfully, so the issue only affects the Default Domain Policy GPO. –  Tomi Junnila Feb 14 '13 at 21:08

2 Answers 2

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 :

  • "manually" backup the GPO (copy the content of \servername\sysvol\domainname\Policies{31B2F340-016D-11D2-945F-00C04FB984F9}
  • compare hashs between different DC (might look stupid, but already happened to me and drove me crazy : Replication corruption)

Did you try to backup from a different DC to see if you reproduce the error on your whole domain ?

share|improve this answer
    
When I wrote that question, the "primary" and "secondary" DCs were very much out of sync, so I probably didn't try backing up the other server which was much behind in the GPO version numbers. I have since fixed the replication issue, so the servers are now in sync so I'll try to backup the GPO from the other DC later (and double check the hashes). –  Tomi Junnila Aug 26 '13 at 9:52
    
Ok, now I managed to take a look at the DCs, and backup-gpo fails for both DCs. However, the GPO folders can be manually copied off both DCs without problems, and are identical in content. –  Tomi Junnila Aug 26 '13 at 18:22
    
If you' re interested in digging this out, I'd suggest you to ProcMon the Backup-GPO powershell command to see where this is failing. For comparing purposes, I uploaded a correct Default Domain Policy backup ProcMon via powershell here Let me know if you want some help ! –  Douda Aug 27 '13 at 13:06
    
Thanks. I looked at ProcMon dumps, and will update the question accordingly. –  Tomi Junnila Aug 27 '13 at 19:03
up vote 1 down vote accepted

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).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.