Групповая политика (GPO) на практике: как применяется, как проверить и когда брать Intune

«Эта настройка уже применяется через GPO», «на ПК заказчика всё жёстко ограничено групповой политикой» — любой, кто работает с бизнес-системами на Windows, постоянно слышит слово «GPO». Но когда нужно самому принять сопровождение AD или внедрить приложение на доменный ПК заказчика, на удивление мало кто может точно объяснить, когда, откуда и с каким приоритетом применяется групповая политика.

«Настройку изменил, а она не применилась», «сказали выполнить gpupdate, но непонятно, что он делает», «на машине разработки приложение работает, у заказчика — нет, и оказалось, что это GPO» — статья для разработчиков бизнес-приложений, которые с этим сталкиваются, и для ИТ-сотрудников малого и среднего бизнеса, унаследовавших среду AD. Разбираем устройство групповой политики (порядок применения LSDOU), когда настройка вступает в силу, диагностику через gpresult и журнал событий, ADMX и центральное хранилище, а также выбор между GPO и Intune (MDM) — по первичным источникам на август 2026 года.

1. Сначала выводы

• Групповая политика работает по принципу «побеждает обработанный позже». Обработка идёт в порядке локальный объект → сайт → домен → OU (LSDOU); при конфликте приоритет у GPO, который система обработала позже. Локальный GPO (gpedit.msc) — самый слабый слой.¹
• Применение — это обработка на переднем плане плюс фоновое обновление. Конфигурация компьютера всегда применяется при запуске, конфигурация пользователя — всегда при входе. Сверху по умолчанию идёт фоновое обновление примерно каждые 90 минут плюс случайное смещение 0–30 минут (на контроллерах домена — 5 минут).²
• gpupdate /force — это «повторно применить все настройки», а не универсальное средство. Некоторые расширения, например установка ПО и перенаправление папок, обрабатываются только при входе или перезагрузке. Именно поэтому существуют параметры /logoff и /boot.³
• Отправная точка диагностики — отчёт RSoP из gpresult /h. Видны и применённые GPO, и отклонённые — с причинами. Для углубления смотрите операционный журнал GroupPolicy (Microsoft-Windows-GroupPolicy/Operational).⁴⁵
• Политики административных шаблонов по правилу пишутся в специальные ключи реестра (Software\Policies и подобные). Значение политики имеет приоритет над собственной настройкой приложения, а «Не задано» ничего не пишет. Часть политик при этом пишет вне этих ключей (глава 5).⁶
• Центральное хранилище ADMX — папка PolicyDefinitions в SYSVOL. После её создания GPMC берёт общедоменные определения шаблонов оттуда.⁷
• GPO или Intune выбирают по тому, к какому каталогу присоединено устройство. Одну и ту же настройку в обоих задавать нельзя: результат не гарантирован. Когда думаете о миграции, помогает Group Policy analytics.⁸⁹
• Для разработчика GPO — классическая причина «не работает только у заказчика». Политика выполнения, отключённое слияние локальных правил брандмауэра, конфигурация прокси и дисков — всё это меняет условия, на которые рассчитано приложение, и приходит централизованно.¹⁰¹¹

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 29, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что такое групповая политика — локальный GPO и доменный GPO

Групповая политика — механизм, которым администратор централизованно задаёт настройки Windows и принудительно применяет их к целевым компьютерам и пользователям. Набор настроек называется GPO (Group Policy Object, объект групповой политики). У GPO два места хранения.

ПК в рабочей группе (не присоединённый к домену) обрабатывает только локальный GPO.¹ Поэтому на практике фраза «управляется через GPO» почти всегда относится к доменному GPO.

flowchart TB
    accTitle: Какие GPO обрабатывает ПК в рабочей группе и ПК в домене
    accDescr: ПК в рабочей группе обрабатывает только локальный GPO, а ПК в домене — ещё и доменный GPO, который приходит из Active Directory
    pc{"Как ПК присоединен?"}
    pc -->|Рабочая группа| wg["Только локальный GPO"]
    pc -->|В домене| dom["Локальный + доменный GPO"]
    dom -.-> note["На практике почти всегда доменный GPO"]

Рис. 1: ПК в рабочей группе обрабатывает только локальный GPO, ПК в домене — ещё и доменный.

Содержимое любого GPO делится на две ветви.

• Конфигурация компьютера: настройки, которые действуют на любого, кто входит на этот ПК. Применяются при запуске.
• Конфигурация пользователя: настройки, которые действуют на этого пользователя на любом ПК, на который он входит. Применяются при входе.

Эта ось — «настройка привязана к ПК или к человеку» — дальше проходит через весь порядок применения и через проверку, что политика действительно вступила в силу. Некоторые пункты есть в обеих ветвях, поэтому, ища настройку, привыкайте смотреть обе.

flowchart TB
    accTitle: Две ветви содержимого GPO
    accDescr: В любом GPO есть конфигурация компьютера и конфигурация пользователя; первая применяется при запуске и действует на любого, кто входит на этот ПК, вторая — при входе и действует на этого пользователя на любом ПК
    gpo["Содержимое GPO"] --> comp["Конфигурация компьютера"]
    gpo --> user["Конфигурация пользователя"]
    comp --> boot["Применяется при запуске"]
    user --> logon["Применяется при входе"]
    boot -.-> anyone["Действует на любого, кто входит"]
    logon -.-> anypc["Действует на любом ПК"]

Рис. 2: В GPO две ветви: конфигурация компьютера, привязанная к ПК, и конфигурация пользователя, привязанная к человеку.

3. Как применяется политика — LSDOU: побеждает обработанный позже, и как управлять наследованием

3.1. LSDOU: локальный объект → сайт → домен → OU

На ПК в домене GPO обрабатываются в таком порядке.¹

1. Локальный GPO
2. GPO, связанные с сайтом
3. GPO, связанные с доменом
4. GPO, связанные с OU (организационным подразделением) — сверху вниз; последним идёт GPO того OU, которому целевой компьютер или пользователь принадлежит напрямую

По первым буквам этот порядок называют LSDOU. Главное: это не «сначала самый приоритетный», а порядок обработки. Когда несколько GPO задают одну и ту же настройку, побеждает обработанный позже (неконфликтующие настройки просто складываются).¹ Иначе говоря, GPO ближайшего к объекту OU — самый сильный, локальный GPO — самый слабый. «Поправил в gpedit.msc, а оно вернулось» — не сбой, а эта спецификация, работающая как задумано.

flowchart TB
    accTitle: Порядок обработки LSDOU и победа обработанного позже
    accDescr: GPO обрабатываются в порядке локальный, сайт, домен, OU; при конфликте побеждает обработанный позже, поэтому GPO ближайшего OU самый сильный, а локальный GPO самый слабый
    l["1. Локальный GPO"] --> s["2. Сайт"]
    s --> d["3. Домен"]
    d --> ou["4. OU (сверху вниз)"]
    ou --> win["При конфликте побеждает последний"]
    win -.-> strongest["GPO ближайшего OU самый сильный"]
    win -.-> weakest["Локальный GPO самый слабый"]

Рис. 3: LSDOU — это порядок обработки; при конфликте одной и той же настройки побеждает GPO, обработанный позже.

Когда к одному сайту, домену или OU привязано несколько GPO, приоритет задаёт порядок связей на вкладке GPMC «Связанные объекты групповой политики». GPO с наименьшим номером порядка связей обрабатывается последним и получает наивысший приоритет.¹

flowchart TB
    accTitle: Порядок связей, когда в одном месте несколько GPO
    accDescr: Если к одному сайту, домену или OU привязано несколько GPO, порядок обработки задаёт порядок связей в GPMC; GPO с наименьшим номером обрабатывается последним и получает наивысший приоритет
    multi["Несколько GPO в одном месте"] --> tab["Решает порядок связей GPMC"]
    tab --> last["GPO с мин. номером обрабатывается последним"]
    last --> win["Побеждает последний — высший приоритет"]

Рис. 4: На одном контейнере связи GPO с наименьшим номером порядка связей обрабатывается последним и побеждает.

3.2. Блокировка наследования и принудительная связь (Enforced)

От порядка по умолчанию можно сделать исключения.¹

• Блокировка наследования (Block Inheritance): задаётся на домене или OU и останавливает наследование GPO сверху. Инструмент для случая «это одно OU не должно получать общефирменный стандарт».
• Принудительная связь (Enforced, раньше — No Override): задаётся на связи GPO. Такой GPO применяется всегда, даже если ниже стоит блокировка наследования, и его уже не перезапишет нижестоящий GPO. Когда блокировка наследования и Enforced сталкиваются, побеждает Enforced.¹

flowchart TB
    accTitle: Связь блокировки наследования и принудительного применения
    accDescr: Блокировка наследования останавливает наследование GPO сверху, но принудительно связанный GPO применяется даже при блокировке ниже и не перезаписывается нижестоящими GPO
    upper["GPO сверху"] --> blocked{"Блокировка наследования ниже?"}
    blocked -->|Нет| inherit["Наследуется как есть"]
    blocked -->|Да| enforced{"У GPO стоит Enforced?"}
    enforced -->|Нет| stop["Наследование останавливается"]
    enforced -->|Да| apply["Применяется всегда"]
    apply -.-> noover["Нижестоящие GPO не перезаписывают"]

Рис. 5: Блокировка наследования останавливает наследование сверху, но принудительно связанный GPO проходит через блок и применяется всегда.

Enforced ломает принцип «побеждает обработанный позже», поэтому при злоупотреблении в отчёте RSoP всё чаще появляются результаты, которые противоречат интуиции. Принятая практика — оставлять его для настроек безопасности, которые вся компания обязана соблюдать.

3.3. Фильтрация безопасности

Помимо контейнера связи, кому применяется GPO, можно сузить на уровне самого объекта. Чтобы GPO применился, целевой пользователь или компьютер должен иметь на этот GPO оба разрешения — «Чтение» и «Применение групповой политики». По умолчанию оба выданы Authenticated Users (туда входят и пользователи, и компьютеры), поэтому GPO применяется ко всем ниже контейнера связи. Фильтрация безопасности как раз сужает это до конкретных групп безопасности. Фильтр действует на GPO целиком; варьировать его по отдельным настройкам внутри GPO нельзя.¹³

Есть одна важная оговорка. Сужая область, не снимайте «Чтение» с Authenticated Users по умолчанию. После обновления безопасности MS16-072 (2016) пользовательская политика запрашивается в контексте безопасности компьютера. Если учётная запись компьютера не может прочитать GPO, пользовательский GPO не применится, даже если у целевого пользователя есть оба разрешения.¹⁴ Правильный способ сузить область — выдать целевой группе «Чтение + Применение групповой политики», а Authenticated Users (или Domain Computers) оставить только «Чтение».¹⁴

flowchart TB
    accTitle: Как фильтрация безопасности решает, применять GPO или нет
    accDescr: Чтобы GPO применился, целевой пользователь или компьютер должен иметь оба разрешения — чтение и применение групповой политики; для пользовательских GPO дополнительно нужно, чтобы учётная запись компьютера могла прочитать объект
    target["Объекты ниже контейнера связи GPO"] --> perm{"Оба разрешения: чтение и применение?"}
    perm -->|Нет| deny["Отклонено фильтром"]
    perm -->|Да| usergpo{"Пользовательский GPO?"}
    usergpo -->|Нет| apply["Применяется"]
    usergpo -->|Да| comp{"Компьютер может читать?"}
    comp -->|Да| apply
    comp -->|Нет| deny2["Не применяется (MS16-072)"]

Рис. 6: Для применения нужны и «Чтение», и «Применение групповой политики»; для пользовательского GPO нужно ещё и чтение учётной записью компьютера.

На практике две классические ловушки: «добавил в группу, а не применяется» (настройка компьютерная, а в группу положили только пользователя) и «убрал из группы, а продолжает применяться». Второе не рассосётся, даже если дождаться фонового обновления. Членство в группах оценивается по маркеру доступа, созданному при входе. Изменение группы пользователя доходит до фильтра только после выхода и повторного входа, изменение группы компьютера — только после перезагрузки, когда выдан новый маркер.

flowchart TB
    accTitle: Когда изменение группы доходит до фильтра
    accDescr: Членство в группах оценивается по маркеру доступа, созданному при входе; изменение пользователя учитывается фильтром только после повторного входа, изменение компьютера — после перезагрузки, когда выдан новый маркер
    change["Изменение члена группы"] --> old["Со старым маркером ещё не учитывается"]
    old --> u["Пользователь: повторный вход"]
    old --> c["Компьютер: перезагрузка"]
    u --> token["Оценка по новому маркеру"]
    c --> token
    token --> ok["Фильтр учитывает изменение"]
    old -.-> bg["Фоновое обновление не помогает"]

Рис. 7: Изменение группы доходит до фильтра только когда при выходе и входе либо при перезагрузке создаётся новый маркер доступа.

Есть ещё особый режим обработки замыкания на себя (loopback processing) — для ситуаций вроде общих ПК или серверов удалённых рабочих столов, когда нужно, чтобы у всех, кто входит на этот ПК, конфигурация пользователя подменялась. Механизм применяет пользовательские настройки исходя из расположения компьютера; есть режимы Replace и Merge.¹⁵ Это прикладная функция для киосков и учебных ПК, поэтому в статье ограничимся тем, что она существует.

flowchart TB
    accTitle: Идея обработки замыкания на себя
    accDescr: Обработка замыкания на себя — особый режим, который применяет конфигурацию пользователя исходя из расположения компьютера; есть режимы замены и слияния, и он используется на общих ПК и киосках, когда нужно одинаково настроить всех, кто входит
    shared["Общий ПК, киоск и т.п."] --> lb["Обработка замыкания на себя"]
    lb --> base["Решает расположение компьютера"]
    base --> rep["Режим замены"]
    base --> mrg["Режим слияния"]
    lb -.-> aim["Действует на всех, кто вошёл"]

Рис. 8: Обработка замыкания на себя — особый режим, который применяет конфигурацию пользователя исходя из расположения компьютера; есть режимы замены и слияния.

4. Когда политика вступает в силу — обработка на переднем плане и фоновое обновление

Половина случаев «настроил, а не применилось» — просто ещё не наступил момент применения. Применений два вида.²

Иначе говоря, на работающем устройстве, которое может достичь контроллера домена, настройки с поддержкой фонового обновления после изменения GPO разойдутся примерно за два часа без каких-либо действий. Автономные устройства или ноутбуки вне офиса без VPN не получат её, пока в следующий раз не подключатся к DC. Настройки, которые применяются только обработкой на переднем плане, дополнительно ждут запуска или входа. Если срочно — выполните gpupdate на целевом ПК. По умолчанию применяются только изменившиеся настройки; с /force повторно применяются все, независимо от того, менялись они или нет.³

rem Обновить только изменившиеся настройки (обычно достаточно)
gpupdate

rem Повторно применить все настройки (когда подозреваете кэшированное состояние)
gpupdate /force

flowchart TB
    accTitle: Достижимость DC и то, как доходит применение
    accDescr: На работающие устройства, которые могут достичь контроллера домена, настройки с поддержкой фонового обновления доходят примерно за два часа; на автономные ПК и ноутбуки вне офиса без VPN — не раньше следующего подключения к DC
    pc{"DC достижим?"}
    pc -->|Да| ok["Дойдёт примерно за 2 часа"]
    pc -->|Нет| ng["Не дойдёт, пока не подключится"]
    ng -.-> ex["Автономный ПК или ноутбук вне офиса без VPN"]

Рис. 9: На работающие устройства с доступом к DC настройка доходит примерно за два часа, на автономные — только при следующем подключении к DC.

На что смотреть: есть настройки, которые через gpupdate просто не применяются. Установка ПО в конфигурации пользователя и перенаправление папок обрабатываются только при входе, установка ПО в конфигурации компьютера — только при запуске. Именно для этого у gpupdate есть параметры /logoff (выйти после обновления) и /boot (перезагрузить после обновления).³ Прежде чем возмущаться «выполнил gpupdate /force, а всё равно не вошло», проверьте, не относится ли настройка к тем, которым нужны перезагрузка или вход.

flowchart TB
    accTitle: Пути, по которым настройка применяется
    accDescr: Изменение GPO для настроек с фоновым обновлением доходит по умолчанию примерно за 90 минут плюс смещение 0-30 минут; настройки только переднего плана ждут запуска или входа, а срочный gpupdate для настроек переднего плана всё равно требует /logoff или /boot
    change["Изменение GPO"] --> kind{"Поддерживает фоновое обновление?"}
    kind -->|Да| bg["Обновление примерно 90 мин + 0-30 мин"]
    kind -->|Нет| fg["Применяется при запуске или входе"]
    bg --> done["Применено"]
    fg --> done
    rush["Если срочно"] -.-> upd["Выполнить gpupdate"]
    upd -.-> force["/force — полное повторное применение"]
    upd -.-> reboot["Передний план: /logoff или /boot"]

Рис. 10: Фоновое обновление доносит только совместимые настройки; то, что применяется только на переднем плане, после gpupdate всё равно требует выхода или перезагрузки.

5. Если не применилось — gpresult, журнал событий и реестр

5.1. Проверка RSoP через gpresult /h

gpresult — стандартное средство посмотреть итоговый результат (RSoP: Resultant Set of Policy, результирующий набор политик), когда несколько GPO наложились друг на друга. Самый читаемый способ — вывести HTML-отчёт из командной строки с правами администратора.⁴⁵

rem Вывести HTML-отчёт RSoP и для пользователя, и для компьютера
gpresult /h C:\temp\gp-report.html /f

rem Чтобы посмотреть только сводку в консоли
gpresult /r
gpresult /scope computer /r

Первые три вещи, которые смотреть в отчёте:

1. Список применённых GPO — есть ли тот GPO, который вы ищете
2. Список отклонённых GPO с причинами — почему не применился: фильтрация безопасности, фильтр WMI, пустой GPO и так далее⁵
3. Побеждающий GPO по каждой настройке — значение какого GPO решило нужную настройку. Если побеждает другой GPO, вернитесь к правилам приоритета главы 3

flowchart TB
    accTitle: Три вещи, которые сначала смотреть в отчёте RSoP
    accDescr: В отчёте gpresult сначала смотрят, есть ли нужный GPO в списке применённых, затем список отклонённых GPO и причины, и наконец по побеждающему GPO для каждой настройки определяют, чьё значение победило
    rep["Открыть отчёт RSoP"] --> one["1. Список применённых GPO"]
    one --> two["2. Отклонённые GPO и причины"]
    two --> three["3. Побеждающий GPO по настройкам"]
    three -.-> review["Если победил другой GPO — пересмотреть"]

Рис. 11: Отчёт RSoP читают в порядке применённых GPO, отклонённых GPO с причинами и побеждающего GPO по каждой настройке.

5.2. Операционный журнал GroupPolicy

Когда gpresult недостаточно — обработка вовсе срывается или занимает слишком много времени — смотрите операционный журнал GroupPolicy в Просмотре событий. Путь: «Журналы приложений и служб > Microsoft > Windows > GroupPolicy > Operational» (имя журнала Microsoft-Windows-GroupPolicy/Operational). Туда записывается весь проход обработки политики от начала до конца вместе со списком применённых GPO и списком отклонённых (с причинами). Каждому проходу назначается уникальный ActivityID, поэтому рекомендованная Microsoft процедура — взять ActivityID из предупреждения или ошибки в журнале системы и через настраиваемое представление оставить события только этого одного прохода.⁵

flowchart TB
    accTitle: Как сузить операционный журнал GroupPolicy
    accDescr: В операционном журнале GroupPolicy каждому проходу обработки политики назначается уникальный ActivityID, поэтому ActivityID берут из предупреждения или ошибки журнала системы и через настраиваемое представление оставляют события только этого одного прохода
    sys["Предупреждения и ошибки журнала системы"] --> aid["Взять ActivityID"]
    aid --> cv["Сузить настраиваемым представлением"]
    cv --> one["Читать события одного прохода"]
    one -.-> rec["Списки применённых и отклонённых GPO с причинами"]

Рис. 12: Операционный журнал читают, взяв ActivityID из журнала системы и сузив настраиваемым представлением до одного прохода обработки политики.

5.3. Связь с ключом Policies в реестре

Политики административных шаблонов (следующая глава) в итоге пишутся как значения реестра. По правилу они попадают в следующие специальные ключи политик.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (конфигурация компьютера; рекомендуемое место)
• HKEY_CURRENT_USER\Software\Policies (конфигурация пользователя; рекомендуемое место)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Здесь работает важная идея проекта. Приложение, которое понимает политики, ведёт себя так: сначала читает ключ Policies; если значение есть, оно имеет приоритет; если нет — приложение берёт собственную настройку (preference) или значение по умолчанию. Политика «Не задано» ничего не пишет в реестр.⁶ Иначе говоря, политики административных шаблонов не переписывают собственную настройку приложения и не оставляют «tattooing» — вместо этого принудительное значение, лежащее в другом месте, читается с приоритетом. Перестаёте задавать политику — приложение снова подчиняется своему значению.

flowchart TB
    accTitle: Приоритет значения политики и настройки приложения
    accDescr: Приложение, поддерживающее политики, сначала читает ключ Policies и при наличии значения отдаёт ему приоритет, иначе использует свою настройку или значение по умолчанию; политика Не задано ничего не пишет в реестр
    app["Приложение читает настройку"] --> haspol{"В ключе Policies есть значение?"}
    haspol -->|Да| pol["Приоритет у значения политики"]
    haspol -->|Нет| pref["Своя настройка или значение по умолчанию"]
    notconf["Политика Не задано"] -.-> nowrite["В реестр ничего не пишется"]

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

При этом не каждая политика пишет в специальный ключ. Часть встроенных настроек ОС (например, «включить длинные пути Win32» пишет в LongPathsEnabled под HKLM\SYSTEM\CurrentControlSet\Control\FileSystem) и шаблоны старого поколения или сторонние пишут по произвольным путям вне этих ключей. Для таких настроек значение остаётся даже после того, как вы перестали задавать политику. В какой ключ данная настройка на самом деле пишет, смотрите в определении ADMX, в тексте описания настройки или в отчёте gpresult.

Иначе говоря, описанная выше «хорошая» схема держится только внутри границы административных шаблонов (специальных ключей политик). Значения, которые скрипты или предпочтения групповой политики (Preferences) пишут вне ключа Policies, ведут себя как обычные значения реестра, и эта рамка не даёт механизма автоматически вернуть их, когда вы перестали их распространять. На практике при диагностике самый быстрый и надёжный ход — напрямую посмотреть, записана ли нужная настройка под ключом Policies.

# Пример прямой проверки значения, записанного политикой (большинство политик пишутся под Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: Порядок диагностики, когда настройка не применяется
    accDescr: Сначала по отчёту RSoP из gpresult проверяют применённые и отклонённые GPO; если этого мало, сужают операционный журнал GroupPolicy по ActivityID, а фактическое значение смотрят напрямую в ключе Policies реестра
    start["Настройка не применяется"] --> rsop["Проверить RSoP через gpresult /h"]
    rsop --> found{"Причины применения и отклонения ясны?"}
    found -->|Да| fix["Пересмотреть приоритет и фильтры"]
    found -->|Нет| oplog["Смотреть операционный журнал GroupPolicy"]
    oplog -.-> aid["Сузить один проход по ActivityID"]
    rsop -.-> reg["Проверить фактическое значение в Policies"]

Рис. 14: Диагностику ведут по шагам, начиная с gpresult /h; если этого мало — операционный журнал GroupPolicy, фактическое значение — прямой просмотр ключа Policies.

6. Административные шаблоны (ADMX) и центральное хранилище

Определения пунктов, которые стоят в GPMC под «Административные шаблоны», записаны как файлы ADMX (тело определения) плюс файлы ADML (строки отображения по языкам). На каждом ПК под C:\Windows\PolicyDefinitions лежат определения, поставляемые с ОС, и средства управления загружают их, чтобы собрать экран настроек.⁷

Если вы работаете в домене, базовый ход — создать центральное хранилище. Создайте папку PolicyDefinitions в SYSVOL контроллера домена (например, \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions) — содержимое реплицируется на все контроллеры домена, и средства групповой политики по умолчанию обращаются к центральному хранилищу.⁷ Так исчезает проблема «на каждой управляющей станции своя версия шаблона, и видимые настройки не совпадают». Файлы ADML кладут в языковые подпапки (для японского — ja-JP).⁷

flowchart TB
    accTitle: Как устроено центральное хранилище
    accDescr: Если создать папку PolicyDefinitions в SYSVOL контроллера домена, содержимое реплицируется на все контроллеры домена, и средства групповой политики по умолчанию обращаются к центральному хранилищу, поэтому расхождения определений между управляющими компьютерами исчезают
    create["Создать в SYSVOL"] --> cs["PolicyDefinitions"]
    cs --> repl["Реплицируется на все DC"]
    cs --> ref["Средства GP обращаются по умолчанию"]
    ref -.-> benefit["Расхождения определений между ПК исчезают"]
    cs -.-> adml["ADML — в языковые папки"]

Рис. 15: PolicyDefinitions в SYSVOL реплицируется на все контроллеры домена, и средства групповой политики обращаются к нему по умолчанию.

Два эксплуатационных предостережения. Первое: Microsoft выпускает новые ADMX под каждую версию Windows, и при обновлении меняют сторону центрального хранилища. Заменять C:\Windows\PolicyDefinitions на каждом отдельном ПК скачанной версией не поддерживается.⁷ Второе: при обновлении существующего центрального хранилища производственную PolicyDefinitions не перезаписывают напрямую. Полный набор ADMX — и для ОС, и для приложений вроде Office и Edge — собирают в рабочей папке с именем версии вроде PolicyDefinitions-24H2, текущую папку откладывают переименованием, например в PolicyDefinitions-23H2, и затем переименовывают рабочую папку в PolicyDefinitions, выводя её в производство.⁷ Средства групповой политики обращаются только к папке с буквальным именем PolicyDefinitions, поэтому просто положить файлы в папку с именем версии эффекта не даёт. Плюс этого подхода — при проблеме можно откатиться к отложенной папке.⁷

flowchart TB
    accTitle: Порядок обновления центрального хранилища
    accDescr: Обновление собирает полный набор ADMX ОС и приложений в рабочей папке с именем версии, переименовывает текущую папку в сторону, затем переименовывает рабочую папку в производственное имя PolicyDefinitions; при проблеме возвращаются к отложенной старой папке
    work["Рабочая папка с именем версии"] --> gather["Собрать набор ОС и приложений"]
    gather --> evac["Переименовать текущую в сторону"]
    evac --> rename["Рабочую папку — в производственное имя"]
    rename --> live["К ней обращаются как к рабочей"]
    live -.-> back["При проблеме вернуться к старой папке"]

Рис. 16: Обновление собирает полный набор в рабочей папке, откладывает текущую и выводит в производство переименованием.

7. GPO vs Intune (MDM/CSP) vs вручную и скриптами — таблица решений

GPO больше не единственный вариант управления конфигурацией устройств Windows. MDM, воплощённый Intune, задаёт настройки ОС через механизм CSP (Configuration Service Provider, поставщик служб конфигурации). Таблица, вокруг чего строить подход.

Ось решения проста: к какому каталогу присоединено устройство (AD или Microsoft Entra) и где оно находится. Для парка офисных ПК, полностью присоединённых к локальному AD, GPO самый надёжный; до мобильных ПК с присоединением к Entra GPO просто не доходит.

В реальности большинство малых и средних компаний сидит посередине, в гибриде (присоединение к домену плюс регистрация в Intune), и худшее, что можно сделать, — «задать одну и ту же настройку и через GPO, и через MDM». У Policy CSP есть политика MDMWinsOverGP, которая даёт победу MDM при конфликте GPO и MDM, но её область ограничена соответствующими политиками внутри Policy CSP. Сама Microsoft прямо пишет, что задавать настройку вне этого контроля и через GPO, и через MDM даёт конфликт без гарантии, кто победит, и двойной конфигурации следует избегать.⁸ Первый принцип гибридной эксплуатации — по областям настроек решить «это GPO, это Intune» и свести управление к одной стороне.

flowchart TB
    accTitle: Как выбирать между GPO и Intune
    accDescr: Если устройство присоединено к локальному AD и постоянно в офисе, надёжнее GPO; для присоединения к Entra и внеофисных устройств подходит Intune; в гибриде одну и ту же настройку не задают дважды и сводят управление каждой областью к одной стороне
    q{"Каталог и расположение устройства?"}
    q -->|AD, постоянно в офисе| gpo["GPO надёжнее и детальнее"]
    q -->|Entra или вне офиса| intune["Intune доходит и вне офиса"]
    q -->|Гибрид| split["Каждую область — к одной стороне"]
    split -.-> warn["Двойная конфигурация не гарантирует результат"]
    split -.-> ana["Для разбора — Group Policy analytics"]

Рис. 17: Выбор задают каталог, к которому присоединено устройство, и его расположение; в гибриде одну и ту же настройку не задают одновременно в GPO и MDM.

Когда вы уже думаете о миграции с GPO на Intune, входная точка — Group Policy analytics в Intune. Импортируйте GPO, экспортированные из GPMC (XML), и инструмент разберёт, поддерживается ли каждая настройка MDM, или она неподдерживаемая/устаревшая; поддерживаемые настройки можно перенести в политику каталога параметров Intune.⁹ Точнее думать об этом как об инструменте «разделить, что можно перенести, что нельзя и что выбросить», а не «перенести всё». Управление Windows Update перестраивается в том же ключе — см. также «Управление Windows Update после перевода WSUS в deprecated».

flowchart TB
    accTitle: Разбор в Group Policy analytics
    accDescr: Если импортировать в Group Policy analytics GPO, экспортированные из GPMC в XML, по каждой настройке видно, поддерживается ли она MDM, устарела или недоступна, а поддерживаемые настройки можно перенести в политику каталога параметров
    exp["Экспорт XML из GPMC"] --> imp["Импорт в analytics"]
    imp --> ana["Анализ поддержки по настройкам"]
    ana --> ok["Поддерживается MDM"]
    ana --> dep["Устарело или недоступно"]
    ok --> mig["Перенос в политику каталога параметров"]

Рис. 18: Group Policy analytics импортирует экспортированный GPO и разделяет настройки, которые можно перенести в MDM, и те, которые нельзя.

8. Ловушка с точки зрения разработчика — GPO заказчика меняет поведение приложения

Напоследок — то, что стоит знать, если вы занимаетесь заказной разработкой. GPO заказчика незаметно переписывает условия, на которые рассчитано ваше приложение. Рядом с брандмауэрами и антивирусами GPO — типичная причина «на машине разработки работает, у заказчика — нет». Конкретные примеры.

• Политика выполнения PowerShell: политику выполнения можно задать централизованно через GPO, и области MachinePolicy/UserPolicy, пришедшие из GPO, всегда имеют приоритет над значением, заданным локально или на процессе.¹⁰ Если установщик или эксплуатационный скрипт построен на допущении «добавлю -ExecutionPolicy Bypass — заработает», под управлением GPO он даже не запустится. Подробности — в «Политика выполнения PowerShell и подпись скриптов».
• Отключённое слияние локальных правил брандмауэра: в средах, где брандмауэр централизованно управляется через GPO/Intune, по профилям можно отключить «слияние локальных правил» (AllowLocalPolicyMerge). Где оно отключено, входящее правило, которое установщик зарегистрировал локально, существует, но не применяется.¹¹ Это пункт, который нужно подтвердить до внедрения серверного приложения; подробно — в «Брандмауэр Windows и бизнес-приложения».
• Конфигурация среды вроде подключенных дисков и прокси: подключения сетевых дисков, принтеры и подобное обычно распространяют через предпочтения групповой политики (Preferences).¹⁶ Допущения о среде — «должен быть диск Z», «прокси быть не должно, прямой выход в интернет» — могут развалиться в зависимости от вошедшего пользователя или членства ПК в OU. Для постоянно работающего приложения легко пропустить и то, что настройки из конфигурации пользователя естественно не применяются к учётной записи, под которой работает служба или назначенное задание.
• Настройку просто «нельзя вернуть»: настройки из административных шаблонов обычно нельзя изменить через интерфейс (пункт серый). То, что «пусть заказчик сам поменяет настройку» не работает, напрямую влияет на то, как вы проектируете поддержку.

flowchart TB
    accTitle: Какие условия приложения меняет GPO заказчика
    accDescr: GPO заказчика меняет условия приложения принудительной политикой выполнения, отключением слияния локальных правил брандмауэра, распространением дисков и прокси и состоянием, когда пользователь не может вернуть настройку, и становится одной из причин, почему не работает только у заказчика
    gpo["GPO заказчика"] --> ep["Принудительная политика выполнения"]
    gpo --> fw["Слияние локальных правил отключено"]
    gpo --> env["Распространение дисков и прокси"]
    gpo --> lock["Настройку нельзя вернуть"]
    ep --> sym["Одна из причин: только у заказчика"]
    fw --> sym
    env --> sym
    lock --> sym

Рис. 19: GPO заказчика незаметно переписывает условия приложения: политику выполнения, брандмауэр, конфигурацию среды.

Со стороны разработки реалистичных мер три. Первая: задокументировать как требования к внедрению средовые условия, на которые рассчитано приложение — политику выполнения, порты прослушивания, куда пишет, путь прокси и так далее — и попросить ИТ заказчика подтвердить их до внедрения. Вторая: при сбое смотреть фактический отчёт gpresult /h и реальные значения под HKLM\Software\Policies, а не гадать (глава 5). Третья: на этапе проектирования отделить операции, которым нужны права администратора, от тех, которым не нужны (эта граница разобрана в «Когда в Windows нужны права администратора»). GPO — не враг, это спецификация среды. Отнеситесь к нему как к спецификации, и диагностика станет механической.

flowchart TB
    accTitle: Три меры со стороны разработки
    accDescr: Меры со стороны разработки — задокументировать средовые условия приложения как требования к внедрению и попросить ИТ заказчика подтвердить их до внедрения, при сбое проверять отчёт gpresult и фактические значения ключа Policies, и на этапе проектирования отделить операции, которым нужны права администратора
    dev["Меры разработки"] --> doc["1. Задокументировать условия среды"]
    dev --> chk["2. Проверить gpresult и фактические значения"]
    dev --> priv["3. Разделить нужность прав в проекте"]
    doc -.-> ask["До внедрения — запрос в ИТ заказчика"]

Рис. 20: Меры разработки — документирование условий среды, проверка через gpresult и фактические значения и проектное отделение необходимости прав администратора.

9. Итог

• Групповая политика обрабатывает настройки на уровне GPO в порядке локальный объект → сайт → домен → OU (LSDOU), а конфликты разрешает по принципу «побеждает обработанный позже». GPO ближайшего к объекту OU — самый сильный слой, локальный GPO — самый слабый.
• Блокировка наследования, Enforced и фильтрация безопасности позволяют управлять потоком по умолчанию. Enforced побеждает и блокировку наследования, поэтому злоупотреблять им не стоит.
• Применение идёт двумя каналами: обработка на переднем плане при запуске и входе и фоновое обновление по умолчанию примерно каждые 90 минут плюс случайное смещение. gpupdate /force повторно применяет все настройки, но не действует на те, что обрабатываются только при входе или перезагрузке.
• Когда настройка не применяется, диагностируйте по шагам: gpresult /h → операционный журнал GroupPolicy → ключ Policies в реестре. Отклонённые GPO показаны с причиной.
• Определения административных шаблонов — ADMX/ADML, и доменная эксплуатация должна сводить их в центральное хранилище SYSVOL. При обновлении меняйте сторону центрального хранилища, а не локальную папку PolicyDefinitions.
• GPO или Intune решают каталог, к которому присоединено устройство, и его расположение; в гибриде избегайте задавать одну и ту же настройку дважды и держите управление на одной стороне. Group Policy analytics помогает разобрать миграцию.
• Для разработчика GPO заказчика — часть спецификации среды. Задокументируйте условия вокруг политики выполнения, брандмауэра, подключенных дисков и прокси и привыкните проверять их через gpresult — и большинство случаев «не работает только у заказчика» перестанут пугать.

Похожие статьи

• Брандмауэр Windows и бизнес-приложения — входящие правила регистрирует установщик
• Управление Windows Update после перевода WSUS в deprecated — как выбрать WUfB, Autopatch и Intune
• Политика выполнения PowerShell и подпись скриптов — как отказаться от Bypass в роли постоянной заглушки
• Автоматизация подготовки ПК через winget и PowerShell — сделать инструкцию исполняемой
• Как избавиться от зависимости внутренних веб-систем от режима IE
• Когда в Windows нужны права администратора — UAC, защищённые области и как это отличить на этапе проектирования

Смежные области консультирования

KomuraSoft занимается расследованием, почему бизнес-приложение не запускается в среде заказчика под управлением GPO, упорядочиванием требований к внедрению (политика выполнения, брандмауэр, сетевые условия) и техническими консультациями по инвентаризации политик и плану совместного управления с Intune для ИТ-сотрудников, унаследовавших среду AD. Начать можно уже с этапа «давайте вместе прочитаем отчёт gpresult».

• Технические консультации и ревью дизайна
• Расследование ошибок и причин
• Разработка приложений для Windows
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Выполнил gpupdate /force, а настройка всё равно не применилась. Почему?

Сначала проверьте, не относится ли эта настройка к тем, которые фоновое обновление не обрабатывает. Установка ПО в конфигурации пользователя и перенаправление папок обрабатываются только при входе, установка ПО в конфигурации компьютера — только при запуске. Поэтому после gpupdate нужны выход из системы (/logoff) или перезагрузка (/boot). Затем выполните gpresult /h, получите отчёт RSoP и посмотрите: этот GPO есть среди применённых или стоит среди отклонённых — с причиной. Если GPO применился, а поведение не изменилось, подозревайте, что другой GPO с более высоким приоритетом перезаписывает ту же настройку (побеждает обработанный позже). В отчёте для каждой настройки показан побеждающий GPO, так что можно точно сказать, какой объект выиграл.

Что в gpresult значит «отклонено фильтром»?

GPO связан с нужным контейнером и формально входит в область действия, но фильтрация исключила его из фактического применения. Самая частая причина — фильтрация безопасности: чтобы GPO применился, пользователь или компьютер должен иметь на этот объект оба разрешения — «Чтение» и «Применение групповой политики». По умолчанию оба выданы Authenticated Users. Если область сузили до конкретных групп, отклонение даёт пропущенное членство: забыли добавить группу или учётную запись компьютера. Для пользовательских GPO выдать оба разрешения только целевому пользователю недостаточно. Начиная с MS16-072 пользовательская политика запрашивается в контексте безопасности компьютера, поэтому «Чтение» (не «Применение») нужно оставить Authenticated Users или Domain Computers. Другие причины — несовпадение фильтра WMI или отключённая на самом GPO конфигурация пользователя либо компьютера. Причина отклонения записывается и в отчёте gpresult, и в операционном журнале GroupPolicy.

Чем управлять устройством — GPO или Intune?

Исходите из того, к какому каталогу присоединено устройство. Если парк в основном в локальном AD и постоянно во внутренней сети, GPO — самый надёжный и самый детальный вариант. Если растёт доля устройств, присоединённых к Microsoft Entra, или домашних машин, которые не подключаются к контроллеру домена, лучше подходит Intune (MDM/CSP): конфигурация доходит и вне офиса. В гибридной среде, где есть и то и другое, одну и ту же настройку нельзя задавать и через GPO, и через MDM: получится конфликт без гарантированного победителя. Принцип — по областям настроек решить, кто ими управляет, и держаться одной стороны. Когда уже думаете о миграции, импорт существующих GPO в Group Policy analytics в Intune позволяет разделить настройки на уже поддерживаемые MDM и неподдерживаемые либо устаревшие.

Настройку из редактора локальной групповой политики (gpedit.msc) постоянно перезаписывает доменная. Так и должно быть?

Да, так и задумано. Групповая политика обрабатывается в порядке локальный объект → сайт → домен → OU (LSDOU), и при конфликте побеждает GPO, обработанный позже. Локальный GPO — самый слабый слой. Если доменный GPO задаёт ту же настройку, локальное изменение всегда будет перезаписано. Наоборот, если на стороне домена стоит «Не задано», значение локального GPO остаётся. Даже если для проверки хочется отдать приоритет локальной настройке, на ПК в домене этот порядок обратить нельзя. Реалистичные пути — завести тестовое OU и поправить доменный GPO либо пользоваться тестовой машиной вне домена.

Бизнес-приложение у заказчика не запускается, хотя у нас всё работает. Можно ли проверить, виноват ли GPO?

Первый шаг — попросить администратора заказчика выполнить gpresult /h report.html из командной строки с правами администратора на проблемном ПК и просмотреть отчёт RSoP. Ищите настройки, которые меняют поведение приложения: скрипты, остановленные политикой выполнения, отключённое слияние локальных правил брандмауэра, заданные прокси и подключенные диски. Полезно также проверить, нет ли под HKLM\Software\Policies и HKCU\Software\Policies значений политик связанного продукта — так механически находятся принудительные настройки из административных шаблонов. Со стороны разработки практическая подготовка — задокументировать условия, на которые рассчитано приложение (политика выполнения, порты прослушивания, папка для записи и так далее), как требования к внедрению и попросить ИТ заказчика подтвердить их до установки.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.