Репликация 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:
NAME NOT FOUND
результаты из CreateFile
операции с четырьмя каталогами непосредственно под каталогом GPO \\servername\sysvol\domainname\Policies\{31b2f340-016d-11d2-945f-00c04fb984f9}
: UserStaging, MachineStaging, UserOld и MachineOld.Registry.pol
под MACHINE
и USER
, Я получаю NAME NOT FOUND
результат операции CreateFile на ...\Adm
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, я могу предложить вам покопаться вручную:
Вы пытались выполнить резервное копирование с другого контроллера домена, чтобы проверить, воспроизводится ли ошибка во всем домене?