Go to content Go to menu

Проводя осмотр серверов по договору подряда у одной организации, которые были без присмотра около года, я наткнулся на одну любобытную проблему: ошибку применения групповой политики на резервном контроллере домена. Но интересна ни сколько сама ошибка, а сколько ее решение. Не иначе как "танец с бубном" ее не назвать.

Теперь сама история. Умер в домене резервный контроллер домена. Средствами ntdsutil.exe на основном контроллере под управлением Windows 2003 была вычищена информация из ActiveDirectory о нем (об этом можно прочесть здесь: http://it-korolkov.ru/blog/index.php?id=21). Контроллер был проверен утилитами dcdiag, netdiaggpresult - прекрасное состояниие. 

Собрали второй сервер, накатили на него Windows 2008, апдейтили средствами adprep.exe существующий ActiveDirectory и ввели сервер в домен. И вот тут началось...

Все тесты проходили, кроме теста групповой политики. В лог падала ошибка GroupPolicy 1006. При попытке "силой" применить политики через команду gpupdate /force в лог падала ошибка GroupPolicy 1055. А в консоль выводилось сообщение, что политика для "Пользователь" применена успешно, а для "Компьютер" - увы. анализ через gpresult /H показал, что где-то недостает прав на ее применение.

Вообщем, перепробовал все, что можно. Удалял sysvol, создавал чистый каталог с дефолтными правами (какие должны быть - написано на сайте Microsoft), пересоздавал симлинки, сбрасывал на дефолтные групповые политики для домена и контроллеров через dcgpofix. Эффекта было нуль. Проверил каждый файлик, каждую папку на соотвествие прав доступа Ntfs. 

И каково было мое удивление, когда проблема решилась передачей ролей мастера на этот самый злополучный резервный контроллер и обратно. Проблема ушла, в логах чисто, а я в недоумении. Если мне кто-то сможет объяснить почему это было, буду весьма признателен.

Leave A Reply

Помощь по Textile