KomuraSoft LLC
Связаться с нами
Меню

Практическое руководство по Group Policy (GPO) — как это работает, подтверждение применения и выбор между GPO и Intune

· · Windows, Group Policy, Active Directory, Intune, Управление ПК, PowerShell, Информационные системы

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

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

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

  • Group Policy работает по принципу «побеждает последний». Обработка идёт в порядке локальный → сайт → домен → OU (LSDOU), и при конфликте приоритет у GPO, обработанного позже. Локальный GPO (gpedit.msc) — самый слабый слой.1
  • Момент применения — «передний план плюс фон». Конфигурация компьютера всегда применяется при запуске, конфигурация пользователя — всегда при входе; сверху по умолчанию идёт фоновое обновление примерно каждые 90 минут плюс случайное смещение 0–30 минут (на контроллерах домена — 5 минут).2
  • gpupdate /force — это «повторно применить все настройки», а не универсальное лекарство. Некоторые настройки, например установка ПО и перенаправление папок, обрабатываются только при входе или перезагрузке (именно поэтому существуют параметры /logoff и /boot).3
  • Точка входа в диагностику — отчёт RSoP из gpresult /h. Видны и применённые GPO, и отклонённые — с причинами. Для углубления — операционный журнал GroupPolicy (Microsoft-Windows-GroupPolicy/Operational).45
  • Политики административных шаблонов по правилу пишутся в выделенные ключи реестра (Software\Policies и подобные). Значение политики имеет приоритет над собственной настройкой приложения, а «Не задано» ничего не пишет. При этом часть политик пишет вне выделенных ключей (глава 5).6
  • Центральное хранилище ADMX — папка PolicyDefinitions в SYSVOL. После её создания GPMC начинает брать общедоменные определения шаблонов оттуда.7
  • GPO или Intune выбирают по основе идентичности устройства. Задавать одну и ту же настройку в обоих не даёт гарантированного результата. Когда думаете о миграции, помогает Group Policy analytics.89
  • Для разработчика GPO — классическая причина «не работает только у заказчика». Настройки, которые меняют предпосылки приложения — политика выполнения, отключённое слияние локальных правил брандмауэра, конфигурация прокси и дисков и прочее — раздаются централизованным управлением.1011

2. Что такое Group Policy — локальный GPO и доменный GPO

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

  Локальный GPO Доменный GPO
Средство правки gpedit.msc (редактор локальной групповой политики) GPMC (консоль управления групповой политикой) + редактор управления групповой политикой
Место хранения Сам ПК. Для компьютера он один, но для пользователей можно создать несколько локальных GPO (MLGPO), разделённых на «администраторы / не администраторы / конкретные пользователи»12 Active Directory (раздаётся связями с сайтами, доменами и OU)
Область Только этот ПК Все компьютеры/пользователи под целью связи
Приоритет Самый слабый (перезаписывается доменными GPO)1 Сильнее локального. Среди доменных GPO приоритет решают цель связи и порядок связей
Типичное применение Автономные настройки ПК в рабочей группе и тестовых машин Раздача и принуждение стандартных настроек организации

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

GPO, которые обрабатывают ПК в рабочей группе и ПК, присоединённый к доменуПК в рабочей группе обрабатывает только локальный GPO, а ПК, присоединённый к домену, обрабатывает помимо локального GPO ещё и доменный GPO, распространяемый из Active DirectoryРабочая группаПрисоединение к доменуФорма участия ПК?Обрабатывается только локальный GPOЛокальный + доменный GPOНа практике GPO почти всегда доменный

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

Каким бы ни был GPO, его содержимое делится на две ветви.

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

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

Две ветви содержимого GPOВ любом GPO есть две ветви — конфигурация компьютера и конфигурация пользователя; конфигурация компьютера применяется при запуске и действует на любого, кто входит на этот ПК, а конфигурация пользователя применяется при входе и действует на этого пользователя на любом ПКСодержимое GPOКонфигурация компьютераКонфигурация пользователяПрименяется при запускеПрименяется при входеДействует на любого, кто входитДействует на любом ПК

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

3. Как работает применение — «побеждает последний» LSDOU и управление наследованием

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

На ПК, присоединённом к домену, GPO обрабатываются в следующем порядке.1

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

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

Порядок обработки LSDOU и победа последнегоGPO обрабатываются в порядке локальный, сайт, домен, OU, и при конфликте побеждает GPO, обработанный позже, поэтому GPO ближайшего к объекту OU самый сильный, а локальный GPO самый слабый1. Локальный GPO2. Сайт3. Домен4. OU (сверху вниз)При конфликте побеждает последнийGPO ближайшего OU самый сильныйЛокальный GPO самый слабый

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

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

Порядок связей, когда в одном месте несколько GPOЕсли к одному сайту, домену или OU привязано несколько GPO, порядок обработки задаётся порядком связей в GPMC, и GPO с наименьшим номером обрабатывается последним и получает наивысший приоритетНесколько GPO в одном местеРешает порядок связей GPMCGPO с мин. номером обрабатывается последнимПобеждает последний — высший приоритет

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

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

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

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

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

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

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

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

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

Решение о применении фильтра безопасностиЧтобы GPO применился, целевой пользователь или компьютер должен иметь оба разрешения — чтение и применение групповой политики, а для пользовательских GPO дополнительно нужно, чтобы учётная запись компьютера могла прочитать GPOНетДаНетДаДаНетОбъекты под целью связи GPOОба разрешения: чтение и применение?Отклонено фильтромПользовательский GPO?ПрименяетсяКомпьютер может читать?Не применяется (MS16-072)

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

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

Пока изменение группы не отразится в фильтреЧленство в группах оценивается по маркеру безопасности, созданному при входе, поэтому изменение пользователя отражается в фильтре только после повторного входа, а изменение компьютера — после перезагрузки, когда выдан новый маркерИзменение члена группыСо старым маркером ещё не отраженоПользователь: повторный входКомпьютер: перезагрузкаОценка по новому маркеруОтражается в фильтреФоновое обновление не помогает

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

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

Идея обработки замыканияОбработка замыкания — особый режим, который применяет конфигурацию пользователя исходя из расположения компьютера; есть режимы замены и слияния, и он используется на общих ПК и киосках, когда нужно одинаково настроить всех, кто входитОбщий ПК, киоск и т.п.Обработка замыканияРешает расположение компьютераРежим заменыРежим слиянияДействует на всех, кто вошёл

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

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

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

Вид Момент Область
Обработка на переднем плане (foreground) Конфигурация компьютера: при запуске / конфигурация пользователя: при входе Все настройки
Фоновое обновление По умолчанию примерно каждые 90 минут плюс случайное смещение 0–30 минут (сдвигается, чтобы не все устройства забрали сразу) Только настройки, поддерживающие фоновую обработку
Фоновое обновление (контроллеры домена) По умолчанию каждые 5 минут То же

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

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

rem Повторно применить все настройки (когда подозреваете кэшированное состояние)
gpupdate /force
Достижимость DC и то, как доходит применениеНа работающие устройства, которые могут достичь контроллера домена, настройки с поддержкой фонового обновления доходят примерно за два часа, а на автономные и выносные ПК без VPN — не раньше следующего подключения к DCДаНетDC достижим?Дойдёт примерно за 2 часаНе дойдёт, пока не подключитсяАвтономный или выносной ПК без VPN

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

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

Пути, по которым настройка применяетсяИзменение GPO для настроек с фоновым обновлением доходит по умолчанию примерно за 90 минут плюс смещение 0-30 минут; настройки только переднего плана ждут запуска или входа, а срочный gpupdate для настроек переднего плана всё равно требует /logoff или /bootДаНетИзменение GPOПоддерживает фоновое обновление?Обновление примерно 90 мин + 0-30 минПрименяется при запуске или входеПримененоЕсли срочноВыполнить gpupdate/force — полное повторное применениеПередний план: /logoff или /boot

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

5. Диагностика, когда не применяется — gpresult, журнал событий и реестр

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

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

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 и так далее5
  3. «Побеждающий GPO» по каждой настройке — значение какой GPO решило нужную настройку. Если побеждает другой GPO, вернитесь к правилам приоритета главы 3
Три вещи, которые сначала смотреть в отчёте RSoPВ отчёте gpresult сначала смотрят, есть ли нужный GPO в списке применённых, затем список отклонённых GPO и причины, и наконец по побеждающему GPO для каждой настройки определяют, чьё значение победилоОткрыть отчёт RSoP1. Список применённых GPO2. Отклонённые GPO и причины3. Побеждающий GPO по настройкамЕсли победил другой GPO — пересмотреть

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

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

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

Как сузить операционный журнал GroupPolicyВ операционном журнале GroupPolicy каждому проходу обработки политики назначается уникальный ActivityID, поэтому ActivityID берут из предупреждения или ошибки журнала системы и через настраиваемое представление оставляют события только этого одного проходаПредупреждения и ошибки журнала системыВзять ActivityIDСузить настраиваемым представлениемЧитать события одного проходаСписки применённых и отклонённых GPO с причинами

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

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

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

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

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

Приоритет значения политики и настройки приложенияПриложение, поддерживающее политики, сначала читает ключ Policies и при наличии значения отдаёт ему приоритет, иначе использует свою настройку или значение по умолчанию; политика Не задано ничего не пишет в реестрДаНетПриложение читает настройкуВ ключе Policies есть значение?Приоритет у значения политикиСвоя настройка или значение по умолчаниюПолитика Не заданоВ реестр ничего не пишется

Рис. 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
Порядок диагностики, когда настройка не применяетсяСначала по отчёту RSoP из gpresult проверяют применённые и отклонённые GPO; если этого мало, сужают операционный журнал GroupPolicy по ActivityID, а фактическое значение смотрят напрямую в ключе Policies реестраДаНетНастройка не применяетсяПроверить RSoP через gpresult /hПричины применения и отклонения ясны?Пересмотреть приоритет и фильтрыСмотреть операционный журнал GroupPolicyСузить один проход по ActivityIDПроверить фактическое значение в Policies

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

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

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

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

Как устроено центральное хранилищеЕсли создать папку PolicyDefinitions в SYSVOL контроллера домена, содержимое реплицируется на все контроллеры домена, и средства групповой политики по умолчанию обращаются к центральному хранилищу, поэтому расхождения определений между управляющими компьютерами исчезаютСоздать в SYSVOLPolicyDefinitionsРеплицируется на все DCСредства GP обращаются по умолчаниюРасхождения определений между ПК исчезаютADML — в языковые папки

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

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

Порядок обновления центрального хранилищаОбновление собирает полный набор ADMX ОС и приложений в рабочей папке с именем версии, переименовывает текущую папку в сторону, затем переименовывает рабочую папку в производственное имя PolicyDefinitions; при проблеме возвращаются к отложенной старой папкеРабочая папка с именем версииСобрать набор ОС и приложенийПереименовать текущую в сторонуРабочую папку — в производственное имяК ней обращаются как к рабочейПри проблеме вернуться к старой папке

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

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

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

Аспект Доменный GPO Intune (MDM/CSP) Вручную / скриптами
Предпосылки Присоединение к домену AD + связность с контроллером домена Лицензия Intune + устройство, зарегистрированное в Intune (Entra join / hybrid join, плюс Entra-registered устройства вроде BYOD в зависимости от способа регистрации) Нет (именно поэтому нет и управления)
Достижимость внеофисных и домашних устройств Не обновится, пока не достигнет DC по VPN или подобному Доходит через интернет Зависит от ручной работы
Детальность / покрытие настроек Самое широкое (административные шаблоны + настройки безопасности + скрипты и так далее) Растёт, но ещё не эквивалентно полному набору настроек GPO9 Ровно столько, сколько вы написали
Принуждение Принуждается как политика (приоритет у ключа Policies)6 Принуждается как политика (CSP) Не возвращается, если пользователь изменил
Как подтверждать применение gpresult / операционный журнал GroupPolicy45 Отчёты центра администрирования Intune Строить свой механизм
Хорошо подходит для Устройства вокруг локального AD, постоянно во внутренней LAN Облако, выносные устройства, распределённые площадки Горстка машин или как дополнение к другим методам

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

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

Как выбирать между GPO и IntuneЕсли основа идентичности устройства — локальный AD и устройство постоянно в офисе, надёжнее GPO; для Entra join и внеофисных устройств подходит Intune; в гибриде одну и ту же настройку не задают дважды и сводят управление каждой областью к одной сторонеAD join, постоянно в офисеEntra join или вне офисаГибридОснова и расположение устройства?GPO надёжнее и детальнееIntune доходит и вне офисаКаждую область — к одной сторонеДвойная конфигурация не гарантирует результатДля разбора — Group Policy analytics

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

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

Разбор в Group Policy analyticsЕсли импортировать в Group Policy analytics GPO, экспортированные из GPMC в XML, по каждой настройке видно, поддерживается ли она MDM, устарела или недоступна, а поддерживаемые настройки можно перенести в политику каталога настроекЭкспорт XML из GPMCИмпорт в analyticsАнализ поддержки по настройкамПоддерживается MDMУстарело или недоступноПеренос в политику каталога настроек

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

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

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

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

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

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

Три меры со стороны разработкиМеры со стороны разработки — задокументировать средовые предпосылки приложения как требования внедрения и попросить ИТ заказчика подтвердить их до внедрения, при сбое проверять отчёт gpresult и фактические значения ключа Policies, и на этапе проектирования отделить операции, которым нужны права администратораМеры разработки1. Задокументировать предпосылки среды2. Проверить gpresult и фактические значения3. Разделить нужность прав в проектеДо внедрения — запрос в ИТ заказчика

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

9. Итог

  • Group Policy — механизм, который обрабатывает настройки на уровне 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 — и большинство случаев «не работает только у заказчика» перестанут пугать.

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

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

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

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

  1. Microsoft Learn, Group Policy processing and precedence. О том, что Group Policy обрабатывается в порядке локальный GPO → сайт → домен → OU, и GPO, обработанный позже, при конфликте перезаписывает более ранний (неконфликтующие настройки агрегируются); о том, что несколько GPO в одном контейнере обрабатываются в порядке связей, и GPO с наименьшим номером обрабатывается последним и получает наивысший приоритет; об исключениях Enforced, отключения связи, отключения конфигурации пользователя/компьютера и блокировки наследования; о том, что принудительно применённый GPO продолжает применяться даже при блокировке наследования ниже; о том, что компьютер в рабочей группе обрабатывает только локальный GPO; и о том, что политика компьютера применяется при запуске, а политика пользователя — при входе. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, ADMX_GroupPolicy Policy CSP. О том, что компьютерная Group Policy всегда применяется при запуске системы и по умолчанию обновляется в фоне каждые 90 минут плюс случайное смещение 0–30 минут; о том, что пользовательская Group Policy всегда применяется при входе и обновляется с тем же интервалом по умолчанию 90 минут плюс смещение 0–30 минут; о том, что интервал обновления на контроллерах домена по умолчанию 5 минут; и о том, что интервал обновления можно задать в диапазоне 0–64 800 минут. ↩ ↩2

  3. Microsoft Learn, gpupdate. О том, что gpupdate по умолчанию применяет только изменившиеся настройки политики, а с /force повторно применяет все; о /logoff, нужном для расширений вроде установки ПО, нацеленной на пользователя, или перенаправления папок, которые фоновое обновление не обрабатывает, а обрабатывает только при входе; о /boot, нужном для расширений вроде установки ПО, нацеленной на компьютер, которые обрабатываются только при запуске; и о параметрах /target:{computer user} и /wait.

    ↩ ↩2 ↩3

  4. Microsoft Learn, gpresult. О том, что gpresult — команда, которая показывает Resultant Set of Policy (RSoP); о том, что /h даёт HTML-отчёт, /x — XML, а /f разрешает перезапись; о том, что /r даёт краткий вывод, а /v и /z — подробный; о том, что /scope {user computer} сужает цель; и о том, что итоговый набор наложившихся политик строится исходя из членства в сайте, домене и OU.

    ↩ ↩2 ↩3

  5. Microsoft Learn, Applying Group Policy troubleshooting guidance. О процедуре запуска gpresult /h из командной строки с повышенными правами, чтобы выяснить, почему GPO не применяется, как о точке входа в диагностику Group Policy; о том, что операционный журнал GroupPolicy (Microsoft-Windows-GroupPolicy/Operational) записывает список применённых GPO и список отклонённых вместе с причинами отклонения; о том, что каждому проходу обработки политики назначается уникальный ActivityID, и о процедуре сузить события только этого прохода через настраиваемое представление; и о включении отладочного журнала GPSvc. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, Implementing Registry-based Policy. О том, что хранение политик на основе реестра ограничено HKCU\Software\Policies и HKLM\Software\Policies (рекомендуемые места) плюс Software\Microsoft\Windows\CurrentVersion\Policies под HKCU/HKLM; о том, что состояние «Не задано» ничего не пишет в реестр; о том, что приложениям следует сначала читать ключ политики и при его отсутствии откатываться к значению preference, причём ключ политики всегда имеет приоритет над ключом preference; о допустимых типах данных REG_DWORD, REG_SZ и REG_EXPAND_SZ; и о том, что приложениям следует заново проверять ключ политики при обновлении политики. ↩ ↩2 ↩3 ↩4

  7. Microsoft Learn, How to create and manage the Central Store for Group Policy Administrative Templates in Windows. О том, что административные шаблоны делятся на тело определения ADMX и языковые строки отображения ADML; о создании центрального хранилища как папки PolicyDefinitions в SYSVOL контроллера домена (например, \contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions); о том, что содержимое реплицируется на все контроллеры домена, и средства групповой политики по умолчанию обращаются к центральному хранилищу; о том, что файлы ADML кладут в языковые папки вроде en-US или ko-KR; о том, что замена C:\Windows\PolicyDefinitions скачанным набором ADMX не поддерживается; о рекомендации при обновлении существующего центрального хранилища собрать полный набор ADMX/ADML ОС и расширений приложений в новой папке с именем версии вроде PolicyDefinitions-24H2, отложить текущую папку переименованием, например в PolicyDefinitions-23H2, и затем переименовать новую папку в производственное имя PolicyDefinitions; и о том, что плюс этого подхода — возможность откатиться к отложенной папке при серьёзной проблеме. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  8. Microsoft Learn, ControlPolicyConflict Policy CSP. О том, что установка политики MDMWinsOverGP (значение по умолчанию 0) в 1 даёт настройке MDM приоритет над Group Policy для соответствующих политик внутри Policy CSP; о том, что область ограничена политиками внутри Policy CSP и не применяется к другим CSP вроде Defender CSP; и о том, что задавать настройку вне этого контроля и через GPO, и через MDM даёт гонку без гарантии, кто победит, поэтому двойной конфигурации следует избегать. ↩ ↩2

  9. Microsoft Learn, Analyze your on-premises GPOs using Group Policy analytics in Microsoft Intune. О том, что Group Policy analytics импортирует и анализирует локальные GPO, показывая, какие настройки поддерживаются поставщиками MDM, включая Intune, а какие устарели или недоступны; о импорте GPO, экспортированных из GPMC в формате XML; и о том, что импортированные GPO можно перенести в политику каталога настроек для развёртывания на устройства. ↩ ↩2 ↩3

  10. Microsoft Learn, about_Execution_Policies. О том, что области политики выполнения оцениваются в порядке приоритета MachinePolicy, UserPolicy, Process, CurrentUser, LocalMachine; о том, что MachinePolicy и UserPolicy — области, задаваемые Group Policy, так что даже более мягкая (или более строгая) политика на нижней области перекрывается политикой с более высоким приоритетом; и о том, что Get-ExecutionPolicy -List показывает настройку каждой области. ↩ ↩2

  11. Microsoft Learn, Windows Firewall rules. О том, что среды, централизованно управляющие брандмауэром через GPO или CSP, могут отключить «слияние локальных правил» (AllowLocalPolicyMerge) по профилям; о том, что при отключении локально созданные правила не применяются; и о том, что для правил приложений, которым нужны входящие подключения, становится обязательной централизованная раздача. ↩ ↩2

  12. Microsoft Learn, Step-by-Step Guide to Managing Multiple Local Group Policy Objects. О том, что локальный GPO начиная с Windows Vista имеет несколько слоёв — «Local Computer Policy», «Administrators/Non-Administrators» и политики по пользователям — известных как MLGPO; о том, что они обрабатываются в порядке локальный компьютер → администраторы/не администраторы → по пользователю, и слой по пользователю читается последним и имеет наивысший приоритет; и о том, что это функция, рассчитанная на управление ПК вне домена. ↩

  13. Microsoft Learn, Security filtering using GPMC. О том, что фильтрация безопасности — механизм, который сужает, какие пользователи и компьютеры получают настройки GPO; о том, что GPO применяется, только если целевой пользователь или компьютер имеет оба разрешения «Чтение» и «Применение групповой политики»; о том, что по умолчанию оба разрешения выданы Authenticated Users (куда входят и пользователи, и компьютеры) на каждом GPO; и о том, что фильтр действует на GPO целиком, а не по отдельным настройкам. ↩

  14. Microsoft Learn, Deploying Group Policy Security Update MS16-072 (KB3163622). Об изменении проекта после MS16-072, по которому Group Policy пользователя забирается в контексте безопасности компьютера; о вытекающем требовании, чтобы учётная запись компьютера имела доступ на чтение к GPO; и о необходимости, если разрешение Authenticated Users снято фильтрацией безопасности или подобным, добавить «Чтение» (не «Применение групповой политики») для Authenticated Users или Domain Computers. ↩ ↩2

  15. Microsoft Learn, Loopback processing of Group Policy. О том, что обработка замыкания — функция, которая применяет набор GPO пользовательских настроек исходя из расположения объекта компьютера; о том, что она рассчитана на компьютеры особого назначения в общественных зонах, лабораториях или классах; и о том, что она поддерживается только в среде Active Directory, с режимами Merge и Replace. ↩

  16. Microsoft Learn, Group Policy Preferences Getting Started Guide. О том, что предпочтения групповой политики (Preferences) — семейство расширений GPMC, которые задают сопоставления дисков, принтеры, назначенные задания, службы, параметры папок и прочее; о том, что адресация на уровне элемента позволяет сужать дальше; и о том, что Preferences раздают настройки, не ограничивая изменения пользователем, с выбором, принуждать данную настройку или нет — характер, отличный от собственно Policies. ↩

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

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

Политика аудита безопасности Windows и расследование журнала событий на практике — как стать ИТ-службой, которая умеет читать 4625

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

Читать статью

Теневое копирование тома (VSS): устройство и практика — почему резервное копирование может скопировать файл, который ещё используется

Занятый файл обычно нельзя скопировать из-за нарушения совместного доступа — как тогда это делает ПО резервного копирования? Статья разби...

Читать статью

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

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

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

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

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

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

Я выполнил gpupdate /force, но настройка всё равно не применяется. Почему?
Сначала проверьте, не относится ли настройка к тем, которые фоновое обновление никогда не применяет. Установка ПО, нацеленная на пользователя, и перенаправление папок обрабатываются только при входе, а установка ПО, нацеленная на компьютер, — только при запуске, поэтому после завершения gpupdate нужны выход (/logoff) или перезагрузка (/boot). Затем выполните gpresult /h, получите отчёт RSoP и посмотрите, есть ли этот GPO среди «применённых GPO» или он стоит среди «отклонённых GPO» с причиной. Если GPO применён, а поведение не изменилось, подозревайте, что другой GPO с более высоким приоритетом перезаписывает ту же настройку (побеждает последний). В отчёте для каждой настройки показан «побеждающий GPO», поэтому можно точно указать, какой GPO побеждает.
Что в отчёте gpresult значит «Denied - Filtering»?
Это значит, что по месту связи GPO входит в область действия, но фильтрация исключила его из фактического применения. Самая частая причина — фильтрация безопасности: чтобы 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), постоянно перезаписывается доменной. Так и должно быть?
Да, это по проекту. Group Policy обрабатывается в порядке локальный → сайт → домен → OU (LSDOU), и при конфликте побеждает GPO, обработанный позже, поэтому локальный GPO — самый слабый слой. Если доменный GPO задаёт ту же настройку, локальное изменение всегда будет перезаписано. Наоборот, если сторона домена оставляет эту настройку «Не задано», значение локального GPO остаётся. Даже если для проверки хочется, чтобы локальная настройка имела приоритет, на ПК, присоединённом к домену, этот порядок приоритета обратить нельзя, поэтому реалистичные пути — завести отдельное тестовое OU и подправить доменный GPO либо пользоваться тестовой машиной вне домена.
Разработанное нами бизнес-приложение в среде заказчика просто не запускается. Можно ли проверить, виноват ли GPO?
Первый шаг — попросить администратора заказчика выполнить gpresult /h report.html из командной строки с повышенными правами на проблемном ПК и просмотреть отчёт RSoP. Ищите настройки, которые меняют поведение приложения: скрипты, заблокированные политикой выполнения, отключённое слияние локальных правил брандмауэра, заданные прокси и сопоставления дисков. Полезно также проверить, не записаны ли под HKLM\Software\Policies и HKCU\Software\Policies в реестре политические значения связанного продукта — так механически выявляются принудительные настройки из административных шаблонов. Со стороны разработки практическая подготовка — задокументировать предпосылки, от которых зависит приложение (политика выполнения, порты прослушивания, папка записи и так далее), как требование внедрения и попросить ИТ заказчика подтвердить их до внедрения.

Об авторе

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

Го Комура

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

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

Связаться с нами

Публичные ссылки

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal
Вернуться в блог