Моя проблема в том, что групповая политика не применяется, когда клиент только что загружен. Сразу после загрузки клиент помещает сообщение об ошибке в журнал событий с источником «GroupPolicy (Microsoft-Windows-GroupPolicy)» и идентификатором события 1058: «Ошибка обработки групповой политики. [...]». На вкладке «Подробности» код ошибки равен 50, что означает ERROR_NOT_SUPPORTED. Это не просто косметическая проблема: политики действительно не применяются должным образом: например, подключенных сетевых дисков нет. Через некоторое время запускается «gpupdate», и политики применяются нормально: отображаются подключенные сетевые диски.
Самый простой сценарий, в котором мне удалось воспроизвести проблему: недавно созданный домен на недавно установленном Windows Server 2012R2, клиент - это недавно установленный 64-разрядный компьютер с Windows 10. Домен состоит только из одного контроллера домена и не имеет никаких отношений с другими доменами.
Поскольку в сообщении об ошибке указано, что Windows не может прочитать файл .GPT из общего ресурса Sysvol домена, я попытался получить доступ к тому же файлу из командной строки. И действительно, когда я открываю командную строку сразу после загрузки, я получаю следующее:
C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.
Подождав минуту или две, выполнение той же команды выдаст список каталогов. На этом этапе gpupdate будет работать нормально.
Я установил для параметра групповой политики «Всегда ждать сети при запуске компьютера и входе в систему» значение «Включено», и я знаю, что эта политика применяется: в том же объекте политики указан параметр реестра, и когда я проверяю реестр на клиенте указанная настройка есть.
Другие факторы, которые могут иметь значение:
powercfg /h off), поэтому каждая загрузка - это полная загрузка, а не быстрая загрузкаЭто скорее проблема SMB, чем проблема групповой политики. Обнюхивание соединения на стороне сервера показывает кое-что интересное: когда я впервые выполняю команду dir \\domain.example.com\sysvol, в анализаторе сообщений Microsoft на контроллере домена отображается следующее:
Каждый раз, когда я запускаю команду и получаю сообщение об ошибке, выполняются шаги 2 и 3.
Когда команда начинает работать, выполняются шаги 1 и 2, но вместо того, чтобы клиент отправлял TCP RST, выполняется SessionSetup, затем TreeConnect, а затем происходит много (на вид нормальное) болтовня SMB.
Таким образом, похоже, что каким-то образом клиент не будет должным образом взаимодействовать с SMB с контроллером домена в течение минуты или двух после загрузки, и это приводит к сбою обработки групповой политики.
Кто-нибудь знает, как я могу отладить и решить эту проблему?
Начиная с Windows 8, Microsoft ввела понятие «быстрой загрузки», при котором, когда вы выключаете ОС, они переводят объем памяти ОС в спящий режим так же, как Hibernate работает в обычных сценариях гибернации. Это приводит к тому, что ОС запускается быстрее, но также имеет побочный эффект отключения обработки GP на компьютере при запуске. Вероятно, это то, что вы видите, и это можно отключить, отключив политику в разделе Конфигурация компьютера \ Политики \ Административные шаблоны \ Система \ Shutdown \ Требовать использования быстрого запуска
Если это не решит проблему, то, скорее всего, это проблема синхронизации сетевого стека, когда обработка GP для компьютера начинается до полной инициализации сетевого стека. Это было примерно с XP, и начиная с Windows 7, Microsoft добавила политику в разделе Computer Configuration \ Policies \ Administrative Templates \ System \ Group Policy \ Startup Policy Processing Wait Time, где вы можете увеличить время ожидания GP перед запуском. Попробуйте установить его на 60 секунд и посмотрите, поможет ли это.
Даррен
Мне удалось решить эту проблему самостоятельно. Для ссылка вот что решило мою проблему:
Во-первых, я ошибался в том, что отключение всех блокировок NTLM приводило к тем же симптомам. Это привело к разные симптом, оказавший такое же действие. Если не действуют какие-либо политики блокировки NTLM, dir команда теперь привела к ошибке отказа в доступе. Групповая политика по-прежнему не применяется, что имеет смысл: SYSVOL по-прежнему недоступен.
Небольшой поиск в Интернете сказал мне, что я знаю, что у меня более распространенная проблема. хотя. По-видимому, у клиентов Windows 10 могут возникнуть проблемы с доступом к общей папке SYSVOL контроллеров домена (а также, возможно, к общей папке NETLOGON). Предположительно Windows 10 что-то изменила в способе доступа к этим общим ресурсам, что может привести к проблемам. Обходной путь - отключить защиту UNC-пути на клиенте для этих общих ресурсов, установив групповую политику «Hardened UNC Paths» для клиентов Windows 10 следующим образом:
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1
(Если у вас возникли проблемы с доступом к общему ресурсу Netlogon из клиентов Windows 10, это также может помочь установить все три параметра равными нулю для этого общего ресурса.)
Увидеть статья от Microsoft о MS15-011 Чтобы получить больше информации. Он содержит хорошее описание последствий изменения этого параметра для безопасности, а также подробные инструкции по изменению политики.
Предупреждение: Обратите внимание, что настройки выше отключить некоторые или все средства защиты от проблемы безопасности были созданы для MS15-011! Не просто слепо скопируйте / вставьте их, но примите осознанное решение, основанное на имеющихся рисках. Кроме того, эта проблема, вероятно, будет решена когда-нибудь в будущем. В таком случае не забудьте установить для этой политики рекомендуемые значения, как описано в MS15-011.
Я попробовал несколько предложений, включая изменения реестра и изменения локальной групповой политики, ни одно из которых не решило проблему - подключенные диски все еще были отключены при загрузке. Gpupdate исправлял это каждый раз, но для пользователя это был дополнительный шаг.
Что в конечном итоге исправило это, так это было вручную сопоставить сетевые диски, заменив записи GPO на каждом из них. Нет необходимости отключать и заменять, я сопоставил их так же, как они были сопоставлены, только вручную.
Просто к сведению всех, кто найдет этот поток, отключение защиты UNC путем установки для взаимной аутентификации значения 0 частично отключает вашу безопасность. У нас та же проблема с клиентами Win7, и я пытался работать с Microsoft над этим. Они сказали мне, что это ошибка, но пока не дали мне способа отследить, когда ошибка будет устранена.
Смотрите эту другую ветку для получения дополнительной информации https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise-x64