Назад | Перейти на главную страницу

Неверный путь к каталогу при попытке создать резервную копию GPO

Репликация DFSR в моем домене, похоже, не работает, и прежде чем приступить к ее исправлению, я хотел сделать резервные копии текущих объектов групповой политики. Однако я не могу создать резервную копию политики домена по умолчанию, так как Управление групповой политикой -> Политика домена по умолчанию -> Резервное копирование GPO просто не удается с ошибкой "An invalid directory pathname was passed"и PowerShell Backup-GPO терпит неудачу с "Exception from HRESULT: 0x80005000".

Я нашел предыдущий вопрос "Диагностика недоступности объекта групповой политики", который действительно кажется очень похожим (хотя объект групповой политики доступен через Управление групповой политикой в ​​той мере, в какой его можно изменить). Однако восстановление разрешений по умолчанию для объекта групповой политики, как указано с помощью ADSI Edit, не помогло. Это не помогло либо; однако, переключившись обратно в управление групповой политикой и повторно выбрав политику домена по умолчанию, было отмечено, что разрешения файловой системы не были синхронизированы с Active Directory, и было предложено исправить их, что я разрешил. Даже после этого резервное копирование объекта групповой политики не удается как указано выше (впоследствии я просмотрел все подпапки в CN объекта групповой политики и также сбросил их до разрешений по умолчанию, хотя я не заметил, что ни одна из них уже не существует).

dsacls "CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=my,DC=domain" не содержит (и не содержит) никаких правил запрета (точный вывод), поэтому я в недоумении - что может вызвать проблемы с доступом?

Обновление 2013-08-27:

Как было предложено Douda, я просмотрел дампы ProcMon файла powershell.exe, пытаясь запустить Backup-GPO в политике домена по умолчанию, и заметил несколько существенных отличий от дампа, любезно предоставленного Douda:

  1. В самом начале я получаю NAME NOT FOUND результаты из CreateFile операции с четырьмя каталогами непосредственно под каталогом GPO \\servername\sysvol\domainname\Policies\{31b2f340-016d-11d2-945f-00c04fb984f9}: UserStaging, MachineStaging, UserOld и MachineOld.
  2. После того, как Backup-GPO прочитал Registry.pol под MACHINE и USER, Я получаю NAME NOT FOUND результат операции CreateFile на ...\Adm
  3. Наконец, я также получаю ACCESS DENIED результат от ...\MACHINE\microsoft\windows nt\SecEdit на QuerySecurityFile операция. В качестве информации в деталях есть шестнадцатеричное значение 0x20, но я не знаю значения этого.

Я проверил разрешения на SecEdit папка, упомянутая выше (а также CN = System / CN = Policies / CN = {guid} / CN = Machine / CN = Microsoft / CN = Windows в ADSI Edit), и они кажутся достаточно разрешительными, насколько я могу сказать. Результаты практически идентичны для двух DC.

Я обновился до Windows Server 2012 R2, но проблема не исчезла. Однако я заметил, что получал событие 2004, события управления групповой политикой всякий раз, когда пытался создать резервную копию объекта групповой политики политики домена по умолчанию (я уже получил события ранее, но не заметил их). Это, в свою очередь, привело меня к http://www.eventid.net/display-eventid-2004-source-Group%20Policy%20Management-eventno-6412-phase-1.htm и предложение повысить уровень трассировки в управлении групповой политикой путем создания двух разделов реестра:

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 

Это дало мне предупреждающую строку в gpmgmt.log (разделить на несколько строк для ясности):

[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

Я удалил это, и после удаления еще двух устаревших сетевых политик (после повторения описанного выше процесса для поиска проблемных политик) политика домена по умолчанию теперь отлично копируется (как и все другие политики).

Скажу честно, ваша проблема довольно необычная. Я много работал с GPO и никогда не видел этой ошибки. Возможно, я ошибаюсь, но похоже, что вы слишком сосредоточены на стороне ACL при устранении неполадок. Поскольку проблема связана только с вашим корневым GPO, я могу предложить вам покопаться вручную:

  • "вручную" сделайте резервную копию объекта групповой политики (скопируйте содержимое \ servername \ sysvol \ domainname \ Policies {31B2F340-016D-11D2-945F-00C04FB984F9}
  • сравнивать хеши между разными DC (может показаться глупым, но уже случилось со мной и свело меня с ума: повреждение репликации)

Вы пытались выполнить резервное копирование с другого контроллера домена, чтобы проверить, воспроизводится ли ошибка во всем домене?