Принудительное обновление групповых политик Windows и Active Directory: команды и диагностика | AdminWiki

Принудительное обновление групповых политик Windows и Active Directory: команды и диагностика

09 сентября 2026 17 мин. чтения
Содержание статьи

Как обновить групповые политики Windows без перезагрузки

Для немедленного повторного применения локальной и доменной групповой политики на текущем компьютере выполните в CMD или PowerShell команду gpupdate /force. Она обновляет компьютерную и пользовательскую части политики без перезапуска всей инфраструктуры. Если групповая политика не применяется, одной команды недостаточно: нужно проверить применение GPO на конкретном клиенте и найти причину отказа.

gpupdate /force

Если gpupdate /force не помог, не запускайте команду повторно вслепую — начните с трёх проверок:

  1. посмотрите, что реально применилось, а что отклонено на клиенте, — раздел «Как проверить применение политики через gpresult и RSoP»;
  2. сверьте область действия GPO: OU объекта, наследование, Security Filtering и WMI-фильтр — раздел «Почему не применяется групповая политика: проверка от OU до фильтра»;
  3. убедитесь, что клиент видит контроллер домена и актуальную копию SYSVOL, — раздел «Диагностика репликации Active Directory и SYSVOL».

Успешное завершение gpupdate подтверждает запуск обработки, но не доказывает применение нужного параметра. Фактический результат проверяют через gpresult, rsop.msc и журналы Group Policy. Если настройка относится к конкретному расширению клиентской политики, пользователю может потребоваться выйти из системы или перезагрузить компьютер.

Для доменных GPO клиенту нужны корректный DNS домена, доступ к контроллеру домена и чтение SYSVOL. Компьютерную часть лучше обновлять из консоли с повышенными правами. Команда применяется к текущему устройству и не перезапускает рабочие станции, серверы или контроллеры домена массово.

Команда gpupdate /force: базовый вариант

Ключ /force заставляет Windows повторно обработать все доступные параметры групповой политики. Без этого ключа система может пропустить часть настроек, которые считает уже применёнными. Это особенно заметно после изменения существующей GPO, когда имя политики и область ссылки остались прежними.

gpupdate /force

В консоли появятся отдельные сообщения о компьютерной и пользовательской политике. Возможные результаты:

  • обе части обработаны без ошибок;
  • обновилась только компьютерная или пользовательская часть;
  • Windows сообщила о необходимости выхода пользователя или перезагрузки;
  • обработка завершилась ошибкой из-за DNS, контроллера домена, SYSVOL или доступа к политике.

Повторяйте команду после исправления причины, но фиксируйте время запуска и текст ошибки. Это помогает сопоставить попытку обновления с событиями в журнале Group Policy.

Обновление только компьютерной или пользовательской политики

Компьютерные настройки находятся в разделе Computer Configuration. Они относятся к устройству и обычно обрабатываются от имени учетной записи компьютера. Пользовательские настройки находятся в User Configuration и обрабатываются для текущего пользователя.

gpupdate /target:computer /force
gpupdate /target:user /force

Команда с /target:computer полезна после изменения параметров безопасности, служб, брандмауэра, Windows Update или запуска компьютера. Команда с /target:user подходит для настроек рабочего стола, реестра пользователя, перенаправления папок и пользовательских предпочтений.

У одного сотрудника и его компьютера могут быть разные ветки OU. Учетная запись пользователя может находиться в OU=Users, а учетная запись компьютера в OU=Workstations. Поэтому проверка пользовательской политики не подтверждает применение компьютерной GPO, и наоборот.

Пользовательскую часть запускают в сеансе нужного пользователя. Для компьютерной части нужна консоль с административными правами, особенно если отчет или обработчик должен прочитать системные параметры.

Параметры /wait, /logoff, /boot и /sync

Дополнительные ключи управляют ожиданием команды и поведением после обработки политики. Ниже — сводка по четырём основным параметрам и их практическому смыслу.

ПараметрНазначениеПрактический смысл
/wait:60Ждать завершения обработки 60 секундУдобно для скриптов и диагностики, где нужно получить полный результат в одной консоли
/wait:0Не ждать завершенияКоманда быстро возвращает управление, но отчет нужно собирать позже
/logoffВыйти из текущего сеанса после обработкиПрименяется, когда клиентское расширение требует нового входа пользователя
/bootПерезагрузить компьютер после обработкиИспользуется для параметров, которые читаются при запуске системы
/syncЗапросить синхронную обработку при следующем запуске или входеПолезно для последовательной обработки зависимых политик, но не заменяет проверку результата

Пример с ожиданием:

gpupdate /force /wait:60

Команды с /logoff и /boot прерывают текущую работу. На сервере, терминальном хосте или рабочей станции с активным пользователем сначала соберите gpresult, согласуйте окно обслуживания и предупредите пользователей.

Как обновить групповые политики на компьютере удалённо

Удаленное обновление сокращает число ручных подключений к рабочим станциям. Администратор отправляет компьютеру задание, после чего клиент запускает обработку локально. Отправка задания и применение политики представляют собой разные этапы: запрос может доставиться успешно, а GPO все равно будет отклонена из-за OU, Security Filtering или WMI-фильтра.

Group Policy Update из консоли GPMC

Group Policy Management Console позволяет отправить обновление выбранным компьютерам в OU.

  1. Откройте GPMC на сервере управления или административной рабочей станции.
  2. Раскройте домен и выберите OU, где находятся целевые компьютеры.
  3. Откройте контекстное меню OU и выберите команду Group Policy Update.
  4. Проверьте список найденных компьютеров и подтвердите отправку запроса.
  5. Сохраните сообщение об успешной отправке и проверьте результат на целевых системах.

GPMC создает удаленное задание для компьютеров, которые включены и доступны по сети. Выключенная рабочая станция не получит команду до следующего подходящего момента. Отчет о доставке запроса не показывает, применился ли конкретный параметр, поэтому после операции используйте Group Policy Results или gpresult.

Способ удобен для разового обновления OU. Перед массовым запуском проверьте, что в OU нет серверов с активными службами или терминальных хостов, для которых обновление может привести к выходу пользователей либо перезапуску.

Invoke-GPUpdate для отдельного компьютера

PowerShell-командлет Invoke-GPUpdate отправляет удаленному компьютеру запрос на обновление политики. Параметр -RandomDelayInMinutes 0 убирает случайную задержку, а -Force добавляет принудительную обработку.

Invoke-GPUpdate -Computer PC-01 -RandomDelayInMinutes 0 -Force

Для группы компьютеров сначала получите список устройств, проверьте их доступность, затем запускайте команды по очереди или небольшими партиями.

$computers = Get-ADComputer -SearchBase 'OU=Workstations,DC=ad,DC=example,DC=local' -Filter *
$computers | ForEach-Object {
    Invoke-GPUpdate -Computer $_.Name -RandomDelayInMinutes 0 -Force
}

Массовый запуск создает много сетевых запросов и заданий Task Scheduler. В большой среде задайте группы компьютеров, исключите выключенные устройства и сохраняйте ошибки по каждому имени. Для удаленного запуска нужны административные права, разрешение имени компьютера, доступ по RPC и работающие службы Task Scheduler.

Почему удалённое обновление не запускается

Если локальный gpupdate /force работает, а удаленный вызов завершается ошибкой, разделите проблему на доставку запроса и применение GPO.

  • Имя не разрешается. Проверьте DNS-запись компьютера и его доступность по имени. Подключение по адресу может скрыть ошибку DNS, поэтому тестируйте именно имя хоста.
  • Компьютер выключен или отключен от сети. Удаленное задание не появится на недоступной системе.
  • RPC или правила Firewall блокируют запрос. Проверьте правила удаленного управления, Remote Scheduled Tasks Management и доступ к службе Task Scheduler.
  • Недостаточно прав. Учетная запись администратора должна иметь право создавать удаленные задания и обращаться к компьютеру.
  • Компьютер не использует доменную учетную запись. Проверьте членство в домене, доверительные отношения и актуальный security token.
  • Запрос доставлен, но GPO отклонена. Соберите отчет на целевом компьютере и проверьте Applied Group Policy Objects, Denied Group Policy Objects, фильтры и порядок обработки.

Ошибку сети ищут через RPC, DNS, Firewall и Task Scheduler. Ошибку применения политики ищут через gpresult, Group Policy Operational log и RSoP. Смешивание этих двух уровней часто приводит к повторной отправке команды без исправления причины.

Как проверить применение политики через gpresult и RSoP

Команда gpupdate сообщает о попытке обработки. Команда gpresult показывает фактический набор примененных и отклоненных GPO для пользователя и компьютера. RSoP помогает увидеть итоговое значение параметра после конфликтов и фильтрации.

Быстрая проверка через gpresult /r

Для компьютерной и пользовательской областей выполняйте отдельные проверки.

gpresult /r /scope computer
gpresult /r /scope user

В результате ищите разделы Applied Group Policy Objects и Denied Group Policy Objects. В отчете указываются имя пользователя, имя компьютера, контроллер домена, время обработки, примененные политики и причины отказа.

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

Если нужная GPO отсутствует в списке примененных и отклоненных политик, проверьте ссылку на OU, доступность домена и состояние обработки. Если политика есть в списке Denied, причина обычно указана рядом: Security Filtering, WMI Filter, блокировка наследования или отключенная часть GPO.

Типовые ошибки gpupdate и gpresult и что они значат

Большинство сообщений об отказе сводится к нескольким типовым ситуациям. Ниже — что именно проверять в каждой из них.

  • Access denied. Недостаточно прав: команда запущена без повышенных прав, у учетной записи нет разрешений Read и Apply Group Policy на объект GPO или закрыт доступ к файлам политики в SYSVOL.
  • The user has not been granted logon rights. Учетной записи отказано в локальном входе на этот компьютер — например, через настройку User Rights Assignment в другой GPO или через группу с явным запретом. Проверьте членство в группах и параметры прав входа, а также актуальность security token.
  • The processing of Group Policy failed. Windows could not determine the user or computer name. Ошибка разрешения имен: проверьте DNS-суффиксы, DNS-записи клиента и доступность контроллера домена.
  • The processing of Group Policy failed because of lack of network connectivity to a domain controller. Клиент не видит DC: проверьте DNS, маршрутизацию, правила Firewall и обнаружение контроллера домена.
  • The network path was not found или отказ доступа к SYSVOL. Проблема с общим ресурсом SYSVOL, репликацией или правами на чтение каталога политики.

Текст ошибки фиксируйте вместе со временем запуска: те же события с подробностями обычно есть в журнале Group Policy Operational.

HTML- и XML-отчёт gpresult

HTML-отчет удобен для чтения и передачи коллегам, XML подходит для автоматизированного разбора и архивирования.

gpresult /h C:\Temp\gpo.html /f
gpresult /x C:\Temp\gpo.xml /f

Перед запуском убедитесь, что каталог C:\Temp существует, или укажите другой доступный путь. Ключ /f разрешает перезапись предыдущего файла.

В HTML-отчете проверьте:

  • время последней обработки компьютерной и пользовательской политики;
  • имя контроллера домена, от которого получены сведения;
  • список примененных GPO и их порядок;
  • отклоненные GPO и текст причины;
  • Security Filtering и WMI-фильтр;
  • значения в разделах Computer Configuration и User Configuration;
  • признаки необходимости выхода пользователя или перезагрузки.

Для регулярного контроля рабочих станций отчеты можно собирать по расписанию и сравнивать с эталонными требованиями. Практический набор проверок безопасности рабочих станций и GPO собран в чек-листе аудита Active Directory.

RSoP через rsop.msc и Group Policy Results

Запустите rsop.msc на проблемном компьютере или в нужном пользовательском сеансе. Оснастка соберет Resultant Set of Policy, то есть итоговый набор параметров после обработки всех доступных GPO.

rsop.msc

RSoP показывает, какой параметр получил итоговое значение, из какой политики он пришел и какая GPO победила при конфликте. Это полезно, когда несколько политик задают один параметр с разными значениями.

В GPMC используйте Group Policy Results для удаленного формирования отчета по конкретному пользователю и компьютеру. Целевой компьютер должен быть доступен, а учетная запись администратора должна иметь право читать результаты. Group Policy Results обычно дает более предметную картину для удаленной диагностики, тогда как rsop.msc удобен при работе непосредственно на клиенте.

Для сложных случаев сравнивайте RSoP с HTML-отчетом gpresult и журналом Group Policy Operational. Оснастка показывает итоговые параметры, а журнал помогает установить момент и причину ошибки обработки.

Как читать Applied и Denied Group Policy Objects

Сначала найдите имя или GUID проблемной GPO. Затем определите, в каком списке она находится и какая причина указана рядом.

РезультатЧто проверить
GPO в AppliedИтоговое значение параметра, порядок применения, конфликт с более приоритетной политикой и включение нужной части GPO
GPO в DeniedSecurity Filtering, права Read и Apply Group Policy, WMI-фильтр, Block Inheritance, доступ к SYSVOL
GPO отсутствует в обоих спискахСсылку на домен, сайт или OU, расположение объекта, состояние связи с доменом и источник политики

Список примененных GPO сам по себе не подтверждает нужное значение. Найдите конкретный параметр в отчете и сопоставьте его с политикой-источником. Если в GPO задана настройка, но итоговое значение другое, ищите конфликтующую политику с более высоким приоритетом или локальную настройку приложения.

Почему не применяется групповая политика: проверка от OU до фильтра

Одна GPO может корректно существовать в домене и не применяться к конкретному компьютеру. Причина обычно связана с областью действия, наследованием, разрешениями, WMI-фильтром, DNS или тем, что клиент получил старую копию политики. Проверяйте каждое условие через GPMC, Active Directory Users and Computers, gpresult и журналы.

Проверить объект компьютера или пользователя и структуру OU

Откройте Active Directory Users and Computers и найдите фактический объект компьютера или пользователя. Учетная запись должна находиться в OU, где есть ссылка на нужную GPO или где политика наследуется от родительского контейнера.

Компьютерная и пользовательская части могут идти по разным веткам:

  • компьютер входит в OU=Servers, а пользователь находится в OU=Employees;
  • компьютер переместили из общего OU в отдельное серверное подразделение;
  • пользователь вошел на другой терминальный сервер, где работает loopback;
  • GPO связана с OU, но объект фактически остался в стандартном контейнере Computers или Users.

Проверьте ссылку GPO на уровне сайта, домена или OU. Убедитесь, что ссылка включена, нужная часть GPO не отключена, а объект не перемещался после изменения политики. Название OU в документации не подтверждает фактическое расположение объекта, его нужно проверить в каталоге.

Проверить наследование, Block Inheritance и Enforced

Политики обрабатываются в порядке Local, Site, Domain, родительские OU и дочернее OU. При конфликте параметров обычно выигрывает настройка, обработанная позже. Поэтому GPO на дочернем OU способна заменить значение из политики домена.

Проверьте два механизма, которые меняют обычный порядок:

  • Block Inheritance. Блокирует наследование обычных GPO с более высокого уровня. Политика со свойством Enforced продолжает действовать.
  • Enforced. Принудительная ссылка не позволяет нижестоящему OU заменить ее параметры обычной политикой и преодолевает Block Inheritance.

В GPMC откройте Group Policy Inheritance для проблемного OU. Там видны ссылки, приоритет, источник и признаки блокировки. Итоговое значение проверяйте в Group Policy Results, потому что список ссылок не показывает, какая политика установила конкретный параметр.

Проверить Security Filtering и права Apply Group Policy

Для применения GPO субъекту нужны права Read и Apply Group Policy. Security Filtering ограничивает круг пользователей и компьютеров, к которым относится политика.

Проверяйте учетную запись компьютера для Computer Configuration и учетную запись пользователя для User Configuration. Членство пользователя в нужной группе не заменяет проверку компьютерного объекта. Если фильтр содержит группу рабочих станций, компьютер должен входить в нее, а его security token должен уже отражать это членство.

После добавления объекта в группу новый token может появиться только после нового входа пользователя или перезапуска компьютера. Повторный gpupdate /force не всегда создает новый token. Проверьте разрешения на вкладке Delegation или через Advanced Security в GPMC:

  • Read разрешает прочитать объект и параметры GPO;
  • Apply Group Policy разрешает обработать политику;
  • явный Deny имеет приоритет над разрешающим доступом;
  • вложенные группы нужно учитывать при расчете фактического членства.

Изменение разрешений фиксируйте отдельно от изменения параметров GPO. Для управляемого жизненного цикла политик пригодится руководство по управлению политиками безопасности.

Проверить WMI-фильтр на целевом компьютере

WMI-фильтр добавляет условие, зависящее от свойств компьютера. GPO может быть связана с правильным OU и доступна учетной записи, но исключаться после проверки операционной системы, редакции, версии или другого свойства.

В GPMC откройте раздел WMI Filters и проверьте:

  • namespace, в котором выполняется запрос;
  • текст WMI-запроса и имя используемого класса;
  • условия для редакции Windows, версии и номера сборки;
  • связь фильтра с нужной GPO;
  • ошибки доступа или выполнения запроса.

Сопоставьте условия фильтра с фактическими сведениями на компьютере.

Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber

Если запрос рассчитан на Windows 11, а клиент работает под Windows 10, политика корректно окажется в списке отклоненных. Не меняйте WMI-фильтр по названию компьютера, пока не проверили его запрос и фактические свойства устройства.

Учитывать Loopback Processing на терминальных серверах

Loopback Processing меняет способ обработки пользовательских настроек на RDS и общих рабочих местах. В этом режиме итоговая User Configuration зависит от компьютера, на который вошел пользователь.

  • Merge. Сначала обрабатываются обычные пользовательские GPO, затем добавляются политики из OU компьютера.
  • Replace. Пользовательские политики обычного OU заменяются набором, связанным с компьютером.

Проверьте настройку Configure user Group Policy loopback processing mode в Computer Configuration. Убедитесь, что терминальный сервер находится в ожидаемом OU, а ссылка с loopback включена для нужной ветки.

Group Policy Results для конкретной пары пользователь-компьютер покажет, какие пользовательские GPO пришли через компьютер. Проверка только OU пользователя в этом сценарии дает неполную картину.

Проверить DNS, доступ к SYSVOL и журналы Group Policy

Клиент домена должен использовать DNS-серверы Active Directory. Публичный DNS может разрешать обычные имена, но не возвращать SRV-записи, через которые Windows ищет контроллер домена.

nltest /dsgetdc:ad.example.local
nslookup -type=SRV _ldap._tcp.dc._msdcs.ad.example.local
echo %LOGONSERVER%

Проверьте, что клиент определяет контроллер домена и может открыть общие ресурсы:

\\DC01\SYSVOL
\\DC01\NETLOGON

Для конкретной GPO проверьте каталог с ее GUID в SYSVOL. Ошибки доступа к файлам, отсутствие каталога или старая версия gpt.ini указывают на проблему SYSVOL или репликации.

В Event Viewer откройте Applications and Services Logs, Microsoft, Windows, GroupPolicy, Operational. Сопоставьте время событий с запуском gpupdate. В System ищите сообщения DNS Client, Netlogon, DFS Replication и ошибки связи с контроллером домена.

Диагностика репликации Active Directory и SYSVOL

Доменная GPO состоит из двух связанных частей. Group Policy Container хранит объект политики, ссылки, разрешения и метаданные в Active Directory Domain Services. Group Policy Template хранит файлы настроек в SYSVOL. Клиенту нужны обе части.

Если объект GPO в Active Directory уже изменился, а файл в SYSVOL еще не реплицировался, разные контроллеры домена могут отдавать клиентам разные результаты. Повторное редактирование GPO до окончания репликации усложняет поиск причины и создает несколько конкурирующих версий.

Определить контроллер домена, который использует клиент

Сначала зафиксируйте источник, от которого рабочая станция получила сведения. Проверка другого контроллера домена не показывает состояние клиента, если он обращался к соседнему DC.

nltest /dsgetdc:ad.example.local
echo %LOGONSERVER%

Команда nltest выводит найденный контроллер домена и параметры обнаружения. Переменная LOGONSERVER обычно показывает DC, который обслужил вход пользователя. Для компьютерной политики дополнительно учитывайте DC Locator и текущую сетевую топологию.

Сохраните имя DC, время проверки и состояние SYSVOL. Затем проверьте тот же GUID GPO на этом контроллере и на DC, где выполнялось изменение.

Проверить репликацию AD через repadmin

Команда repadmin /replsummary дает сводку по ошибкам входящей и исходящей репликации. Команда repadmin /showrepl показывает состояние репликации по каждому партнеру, а repadmin /syncall запускает принудительную синхронизацию разделов каталога между контроллерами домена.

repadmin /replsummary
repadmin /showrepl DC01
repadmin /syncall

Ошибки в выводе читайте по времени последней успешной репликации: если расхождение измеряется часами или сутками, клиент вполне может получать устаревшую версию GPO. Дополнительно проверьте события репликации в журналах Directory Service и DFS Replication.

Проверить состояние контроллера домена через dcdiag

dcdiag выполняет комплексную проверку контроллера домена, включая DNS, регистрацию сетевых записей, доступ к общим ресурсам и репликацию. Запускайте его на самом DC или с административной рабочей станции.

dcdiag /test:dns /v
dcdiag /test:netlogons
dcdiag /test:replications

Тест netlogons проверяет доступ к SYSVOL и NETLOGON, от которых напрямую зависит чтение Group Policy Template. Тест dns показывает проблемы с SRV-записями, по которым клиенты находят контроллеры домена. Ошибки в этих проверках объясняют, почему групповая политика не применяется сразу на нескольких компьютерах.

Сравнить версии GPO в SYSVOL на разных контроллерах

Версию политики можно сверить по номеру в объекте Group Policy Container и по содержимому gpt.ini в файловом шаблоне. Откройте на двух контроллерах домена общий ресурс SYSVOL, найдите каталог с GUID проблемной GPO и сравните номер версии.

  • версии совпадают — репликация завершена, причину ищите в области действия, фильтрах и правах;
  • версии расходятся — дождитесь репликации и не вносите новые правки в эту GPO;
  • каталог отсутствует или недоступен — проверьте репликацию DFSR и права на чтение SYSVOL.

Пока репликация не завершилась, результат gpupdate будет зависеть от того, к какому контроллеру домена обратился клиент.

Порядок диагностики, если GPO не применяется: чек-лист

Держите этот порядок под рукой, чтобы не перескакивать между уровнями диагностики.

  1. Проверьте фактическое расположение объекта пользователя или компьютера в OU со ссылкой на GPO — раздел «Почему не применяется групповая политика: проверка от OU до фильтра».
  2. Сверьте наследование, Block Inheritance, Enforced, Security Filtering, права Read и Apply Group Policy, WMI-фильтр.
  3. Запустите gpupdate /force из консоли с повышенными правами и сохраните текст сообщений.
  4. Соберите gpresult /r /scope computer и gpresult /r /scope user, изучите списки Applied и Denied — раздел «Как проверить применение политики через gpresult и RSoP».
  5. Проверьте DNS, SRV-записи, доступ к SYSVOL и журнал Group Policy Operational — раздел «Проверить DNS, доступ к SYSVOL и журналы Group Policy».
  6. Уточните, от какого контроллера домена работает клиент, и проверьте репликацию через repadmin и dcdiag — раздел «Диагностика репликации Active Directory и SYSVOL».
  7. Учтите требования клиентских расширений: если gpupdate сообщает о необходимости нового входа или загрузки, используйте /logoff или /boot в согласованное окно.

Частые вопросы: gpupdate не работает и GPO не применяется

Почему gpupdate /force не применяет политику?

Команда запускает обработку, но не меняет область действия GPO. Если объект не попадает в OU со ссылкой, политика отфильтрована через Security Filtering или WMI-фильтр, заблокирована наследованием либо недоступна в SYSVOL, параметр не появится. Проверяйте результат через gpresult и RSoP, а не по выводу gpupdate.

Сколько ждать применения групповой политики без gpupdate?

Клиент обновляет политику фоновым циклом: ориентировочно каждые 90 минут со случайным смещением до 30 минут, у контроллеров домена интервал короче — около 5 минут. Это ориентиры, а не гарантия: фактический момент зависит от смещения, сети и загрузки. Если результат нужен сейчас, используйте gpupdate /force.

Нужно ли выходить из системы или перезагружать компьютер после gpupdate?

Не всегда. Часть клиентских расширений применяет параметры только при новом входе или загрузке — gpupdate сообщает об этом отдельной строкой. В таких случаях используйте /logoff или /boot, заранее согласовав перерыв с пользователями.

Что делать, если GPO применяется не на всех компьютерах?

Сравните проблемные устройства по OU, группам Security Filtering, условиям WMI-фильтра и контроллеру домена, от которого они получают политику. Разное состояние SYSVOL на контроллерах дает разные результаты до завершения репликации.

Поделиться: