Групповые политики не применяются к конкретному серверу
У меня есть один сервер - 2008 R2 Enterprise, на котором работает WSUS и наш сервер KMS - который не может применить какие-либо групповые политики из домена. У меня нет идей, как заставить это обработать. Есть идеи?
Мои шаги до сих пор включали следующее.
- проверил, что безопасный канал хорош через
netdom verify myhost
- пытался
gpupdate /force
- Пересмотр вывода gpresult / v, который не показывает никаких политик компьютера.
- Тыкнул через реестр.
HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\GPOLink-List
показывает только запись для локальной политики. - Переименуйте папку C:\ProgramData\Microsoft\ Групповая политика
- Удалить ключ
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
- Примените шаги, описанные в KB310741
- Тройная проверка журнала событий (приложения, системы, работающей групповой политики), которые не показывают проблем.
- трижды проверьте расположение в компьютере AD и настройках членства в группах - должно быть около 30 примененных политик.
Что-нибудь более очевидное, что я пропустил?
РЕДАКТИРОВАТЬ:
Я заметил еще один интересный элемент - значение Distinguished-Name в ключе State\Machine, описанном выше, возвращается пустым. Не уверен, как или почему. Я попытался вставить правильное значение, но это не сработало.
2 ответа
После всех головных болей и проблем, которые это вызывало в течение последних нескольких недель, похоже, проблема заключалась в том, как был активирован наш Windows-сервер. Похоже, кто-то случайно вставил ключ KMS через графический интерфейс.
Это привело к тому, что ОС не активировалась правильно и не была полностью (?) Присоединена к домену. Это отфильтровывалось из-за невозможности должного взаимодействия с контроллерами домена - поле присоединения к домену было серым - и запись DN, необходимая для работы групповой политики, не заполнялась. В конце концов, серое поле присоединения к домену было подсказкой, которая мне была нужна, указывая на проблему с лицензией Windows.
Когда я набрал ключ MAK и вставил информацию о нашей KMS через cscript cscript slmgr.vbs /ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
как и должно было быть, все начало работать именно так, как вы ожидаете.
Надеюсь, это поможет другой бедной душе из лишнего месяца дополнительной работы.
Вы не упоминаете, запускали ли вы RSoP, но это был бы мой первый шаг. Кроме того, сервер показывает какие-либо признаки "применения политики компьютера" во время запуска?
Получив результаты RSoP, вы можете по крайней мере увидеть, считает ли сервер, что он должен применять политики (если не более того, политики домена / пользователя по умолчанию).
- Начать редактирование - просто перечитайте и заметили, что вы запустили GPRESULT. Поэтому я бы продолжил с монитором процесса (ниже).- Конец редактирования--
Следующим моим шагом будет использование Microsoft SysInternals Process Monitor в режиме регистрации загрузки, чтобы увидеть, что происходит.
Кроме того, еще одна вещь, которую я пробовал в прошлом, это использовать PsExec для запуска командной строки, работающей в качестве локальной учетной записи SYSTEM. Затем вы можете выполнить простой список каталогов области политик в SYSVOL. Принимая во внимание, что применение политики / фильтрация контролируются старыми добрыми списками ACL NTFS. Если вы видите политики * (и это будут политики компьютера), у вас есть другая проблема.
* Политики перечислены в SYSVOL с использованием их идентификаторов GUID, но их можно разрешить, запросив AD (или просмотрев с помощью ADSIEDIT, или аналогичный). Если вам нужен путь LDAP, кричите.