От групповой политики к Intune — руководство по миграции для малого и среднего бизнеса

«Срок поддержки сервера истекает, поэтому планируем замену. Но мы уже не уверены, что стоит снова покупать сервер AD и ещё один цикл (пять лет) держать домен и групповую политику.» «Корпоративная групповая политика так и не доходит до ноутбуков, с которых работают из дома. Если она применяется только после подключения к VPN, можно ли вообще сказать, что этими ПК управляют?» — За последние годы такие обращения от заказчиков малого и среднего бизнеса заметно участились.

Причина — в том, как изменилась работа. Локальные Active Directory (AD) и групповая политика (GPO) рассчитаны на то, что ПК стоит в корпоративной LAN и в любой момент может достучаться до контроллера домена. Когда ноутбуки уносят из офиса и удалёнка стала нормой, сломалось именно это допущение. Плюс WSUS — привычный способ управлять обновлениями — в сентябре 2024 объявлен устаревшим,¹ и центр управления устройствами Microsoft сместился на Entra ID и Intune (MDM).

flowchart TB
    accTitle: Как сломалось допущение и куда сместилось управление
    accDescr: AD и GPO рассчитаны на то, что ПК в корпоративной LAN и всегда может достучаться до контроллера домена, но ноутбуки вне офиса и удалёнка как норма это допущение сломали, а вместе с объявлением WSUS устаревшим центр управления сместился на Entra ID и Intune
    adgpo["Локальные AD и GPO"] -.-> premise["Допущение: DC всегда доступен"]
    work["Ноутбуки вне офиса и удалёнка как норма"] --> broken["Допущение уже не держится"]
    premise --> broken
    wsus["WSUS объявлен устаревшим"] --> shift["Центр смещается на Entra ID+Intune"]
    broken --> shift

Рис. 1: Допущение AD+GPO «ПК стоит в корпоративной LAN» сломалось вместе со сменой работы, и центр управления сместился на Entra ID и Intune.

При этом миграция — не «всё или ничего». ПК под Entra join и Intune и ПК, присоединённые к домену AD и управляемые GPO, могут работать в одной компании,² и поэтапный переход реален: AD оставляют ради файлового сервера, а новые ПК переводят на Intune. Статья рассчитана на ИТ-специалистов и руководителей малого и среднего бизнеса. По первоисточникам Microsoft Learn на август 2026 здесь собраны различия в том, как применяются GPO и MDM, исходные конфигурации, лицензии, как инвентаризировать текущие GPO, сценарий поэтапной миграции и типичные сложности.

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

• GPO применяется, когда устройство подключено к сети домена; Intune (MDM) синхронизируется через интернет. Проблема «настройки не доходят до домашнего ПК» в MDM структурно не возникает. Штатная синхронизация — примерно раз в 8 часов; при смене политики дополнительно срабатывает синхронизация по уведомлению.³
• Миграция — не «всё или ничего». Реалистичный путь — поэтапный переход с сосуществованием. Сама Microsoft рекомендует новые ПК присоединять через Entra join, а уже присоединённые к домену оставлять как hybrid join и менять по циклу обновления оборудования.²
• Intune можно купить отдельно, но для малого и среднего бизнеса реалистичнее брать Intune Plan 1 в составе Microsoft 365 Business Premium (по состоянию на август 2026). Состав планов продолжает меняться — перед договором сверяйтесь с первоисточниками.⁴⁵
• Текущие GPO инвентаризируют встроенным Group Policy analytics. Импортируйте XML-экспорт GPO — и каждая настройка помечается по возможности переноса; те, у которых есть соответствие, можно преобразовать в политику каталога параметров.⁶
• У основных задач эпохи GPO почти всегда есть соответствие в Intune. Административные шаблоны — каталог параметров,⁷ WSUS — Windows Update for Business, ключи восстановления BitLocker — хранение в Entra ID,⁸ пароли локального администратора — Windows LAPS,⁹ раздача приложений — Win32-приложения (.intunewin)¹⁰ и приложения Microsoft Store (на базе winget).¹¹
• Как есть не переезжают прежде всего сценарии входа, подключение дисков и раздача принтеров. Их заменяют развёртыванием сценариев PowerShell,¹² Remediations (ранее Proactive remediations),¹³ упаковкой в приложение или отказом от этой практики.
• Не раздавайте одну и ту же настройку и из GPO, и из MDM. По умолчанию при конфликте побеждает GPO. MDMWinsOverGP=1 отдаёт приоритет MDM, но только для настроек Policy CSP.¹⁴
• Машины, присоединённые к домену, и машины Entra join могут работать вместе; с машины Entra join можно обратиться к локальному файловому серверу. Немедленный вывод AD не является условием миграции.²

Одной фразой: вопрос «менять ли сервер AD ещё на один цикл» стоит переформулировать в «чем в ближайшие пять лет управлять ПК, которые стоят вне офиса» — и решать уже его.

flowchart LR
    accTitle: Какой вопрос на самом деле нужно решать
    accDescr: Вопрос, менять ли сервер AD ещё на один цикл, следует переформулировать в вопрос, чем в ближайшие пять лет управлять ПК вне офиса
    q1["Менять сервер AD ещё на цикл?"] -->|переформулировать| q2["Чем 5 лет управлять ПК вне офиса?"]

Рис. 2: Вопрос замены сервера стоит переформулировать в «чем в ближайшие пять лет управлять ПК вне офиса» — и решать уже его.

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

2. Чем GPO отличается от MDM — сравниваем, как применяется политика

Сначала сравним оба механизма напрямую. Сам GPO (порядок LSDOU, проверка через gpupdate/gpresult) подробно разобран в «Практическом руководстве по групповой политике (GPO)», поэтому здесь остаются только различия, которые влияют на решение о миграции.

Для решения о миграции важнее всего первая и третья строки. То, что GPO не доходит до домашнего ПК, — не сбой: проектное допущение «ПК стоит там, откуда доступен контроллер домена» больше не совпадает с тем, как люди работают. Можно продлить GPO, обязав всех держать always-on VPN, но это одновременно выбор взять на себя ещё одну инфраструктуру — платформу VPN.

flowchart TB
    accTitle: Продлить GPO или перейти на MDM
    accDescr: GPO не доходит до домашнего ПК, потому что проектное допущение больше не совпадает с тем, как люди работают; путь продлить GPO через always-on VPN означает взять на себя ещё одну инфраструктуру — платформу VPN
    gap["Допущение не совпадает с тем, как работают"] --> sel{"Как ответить?"}
    sel -->|Продлить через always-on VPN| vpn["Оставить GPO"]
    sel -->|Перейти на MDM| mdm["Управлять через интернет"]
    vpn --> cost["Берёте на себя другую инфраструктуру"]

Рис. 3: Продлить GPO через always-on VPN — это также выбор взять на себя ещё одну инфраструктуру: платформу VPN.

С другой стороны, интервал синхронизации MDM (около 8 часов) грубее периодического обновления GPO (около 90 минут), и ощущение «раздал — сразу применилось» сюда не переносится. При назначении или смене политики устройству уходит уведомление, и синхронизация обычно идёт относительно быстро,³ но контроль, которому нужна немедленная доставка (аварийная блокировка и подобное), нужно проектировать с учётом интервала синхронизации.

flowchart TB
    accTitle: Как GPO и MDM применяют политику
    accDescr: GPO применяется только когда устройство может подключиться к внутреннему контроллеру домена, поэтому домашний ПК зависит от VPN; Intune синхронизируется через интернет примерно раз в 8 часов и дополнительно по уведомлению при смене политики, поэтому доходит независимо от места
    officepc["ПК в офисе"] -->|Запуск, вход и периодическое обновление| dc["Контроллер домена"]
    homepc["Домашний ПК"] --> vpn{"DC доступен по VPN?"}
    vpn -->|Да| dc
    vpn -->|Нет| miss["Последняя политика не приходит"]
    anypc["ПК где угодно"] -->|Синхронизация примерно раз в 8 ч| intune["Служба Intune"]
    intune -.-> notify["При смене политики — синхронизация по уведомлению"]

Рис. 4: GPO применяется только когда устройство может достучаться до контроллера домена; Intune синхронизируется через интернет независимо от места.

3. Исходные условия — три формы: присоединение к домену, hybrid join и Entra join

У Windows-ПК есть три способа «войти в компанию», и от выбора зависит, какими средствами управления можно пользоваться.²

Hybrid join — форма «дать уже присоединённому к домену ПК облачную идентичность»: можно начать пользоваться Intune и условным доступом, не бросая существующие активы. Microsoft, однако, рекомендует не делать hybrid join конечной целью и присоединять новые и заменяемые ПК через Entra join.²

Здесь одно жёсткое ограничение. Поддерживаемого Microsoft способа превратить уже присоединённый к домену ПК (включая hybrid join) в Entra join нет: нужен сброс Windows (wipe). Поэтому Microsoft и советует переходить на Entra join в момент обновления оборудования или переустановки ОС.²

flowchart TB
    accTitle: Три формы присоединения и пути миграции
    accDescr: ПК только с присоединением к домену AD можно зарегистрировать ещё и в Entra ID и получить hybrid join, но прямого преобразования в Entra join нет и нужен wipe, поэтому рекомендуется присоединять новые и заменяемые ПК через Entra join
    adonly["Только присоединение к домену AD (GPO)"] -->|Также зарегистрировать в Entra ID| hybrid["hybrid join (GPO и Intune)"]
    hybrid -.->|Прямого преобразования нет| wipe["Нужен wipe (сброс)"]
    wipe --> entra["Entra join (Intune)"]
    newpc["Новые и заменяемые ПК"] -->|Рекомендуется| entra

Рис. 5: Поддерживаемого способа превратить уже присоединённую к домену машину в Entra join нет; привычный путь — переключать с новых и заменяемых ПК.

Отсюда реалистичная цель для малого и среднего бизнеса выглядит так.

1. Новые и заменяемые ПК вести через Entra join и Intune
2. Уже присоединённые к домену ПК не трогать специально и дать им смениться по циклу обновления оборудования
3. AD пока оставить ради оставшихся ролей вроде аутентификации файлового сервера и поэтапно опустошать содержимое GPO

flowchart TB
    accTitle: Сосуществование во время поэтапной миграции
    accDescr: Машины Entra join и машины, присоединённые к домену, могут работать в одной корпоративной среде; первые ведёт Intune, вторые — GPO, а AD пока оставляют ради оставшихся ролей и поэтапно опустошают только содержимое GPO
    env["Та же корпоративная среда"] --> ejoin["Машины Entra join"]
    env --> djoin["Машины, присоединённые к домену"]
    ejoin --> intune["Управляются Intune"]
    djoin --> gpo["Управляются GPO"]
    gpo -.-> shrink["Поэтапно опустошать содержимое"]
    env -.-> ad["AD оставить ради оставшихся ролей"]

Рис. 6: Машины Entra join и машины, присоединённые к домену, могут работать в одной корпоративной среде; AD пока оставляют ради оставшихся ролей.

Машины Entra join и машины, присоединённые к домену, могут работать в одной среде, и с машины Entra join можно обратиться к внутренним ресурсам вроде локального файлового сервера.² Но у этого единого входа два условия. (1) Пользователь — гибридная идентичность, синхронизированная из локального AD через Entra Connect (или Cloud Sync) (пользователь, который есть только в облаке, не получит учётные данные Kerberos/NTLM AD) и (2) с ПК есть сетевая доступность контроллера домена (извне офиса нужен VPN или аналог).¹⁵ В плане миграции сначала проверьте, нет ли пользователей или сценариев, которые эти два пункта не выполняют.

flowchart TB
    accTitle: Условия SSO с машины Entra join к локальным ресурсам
    accDescr: Чтобы с машины Entra join обратиться к локальному файловому серверу, нужны два условия: гибридная идентичность, синхронизированная через Entra Connect или аналог, и доступность контроллера домена
    pc["Машина Entra join"] --> cond1{"Гибридная идентичность?"}
    cond1 -->|Да| cond2{"DC доступен?"}
    cond1 -->|Нет| ng1["Учётные данные AD не получить"]
    cond2 -->|Да| ok["SSO к файловому серверу"]
    cond2 -->|Нет| ng2["Извне офиса нужен VPN или аналог"]

Рис. 7: SSO с машины Entra join к локальным ресурсам держится на двух условиях: гибридная идентичность и доступность контроллера домена.

4. Лицензии и стоимость — в каких планах есть Intune (по состоянию на август 2026)

Базовая лицензия Intune — Microsoft Intune Plan 1. Её продают и как отдельную подписку, и в составе разных планов Microsoft 365.⁴

Для малого и среднего бизнеса важно, что Microsoft 365 Business Premium до 300 пользователей включает Intune Plan 1.⁵ В Business Premium входят также Microsoft Entra ID P1 и Microsoft Defender for Business, поэтому описанную ниже связку политики соответствия и условного доступа можно закрыть внутри этого плана. Business Standard и Basic, напротив, Intune не включают. Если выходите из договора «только почта и Office» в управление устройствами, стоимость апгрейда до Business Premium — фактическая цена ввода Intune.

flowchart TB
    accTitle: Как планы для малого и среднего бизнеса связаны с Intune
    accDescr: Business Premium до 300 пользователей включает Intune Plan 1, Entra ID P1 и Defender for Business и закрывает условный доступ, а Business Standard и Basic Intune не включают
    bp["Business Premium"] -.-> cap["До 300 пользователей"]
    bp --> intune["Intune Plan 1"]
    bp --> p1["Entra ID P1"]
    bp --> dfb["Defender for Business"]
    p1 --> ca["До условного доступа внутри плана"]
    dfb ~~~ std["Business Standard/Basic"]
    std --> noint["Intune не входит"]

Рис. 8: Business Premium включает Intune Plan 1 и Entra ID P1; Business Standard и Basic Intune не включают.

Две оговорки.

• Состав планов часто меняется. Уже в 2026 функции Intune Suite перераспределяют в старшие планы Microsoft 365 (E3/E5 и подобные), и пересмотр комплектации продолжается.⁴ Этот раздел — снимок на август 2026; перед договором сверяйте актуальные данные на страницах лицензий и цен Microsoft.
• Некоторые функции, которые открываются из интерфейса Intune, требуют отдельную лицензию. Характерный пример — Remediations ниже: нужна лицензия уровня Windows Enterprise E3/E5 (входит в Microsoft 365 E3/E5 и подобные), в рамках Business Premium её нет.¹³

Сравнивать стоимость — не «подписка Intune» против «нуля». На стороне GPO вы уже платите за замену оборудования сервера AD, лицензии Windows Server и CAL, внедрение, пять лет сопровождения, резервное копирование и реакцию на сбои. Правильное сравнение — поставить смету замены сервера рядом с пятью годами Business Premium и уже потом учесть разницу возможностей: доходит ли управление до ПК вне офиса.

flowchart TB
    accTitle: Как правильно сравнивать стоимость
    accDescr: На стороне GPO тоже есть затраты на замену сервера AD, лицензии и пять лет сопровождения, поэтому смету замены сервера ставят рядом с пятью годами Business Premium и решают уже с учётом того, доходит ли управление до ПК вне офиса
    gpocost["Стоимость продолжения GPO"] --> hw["Замена сервера, лицензии, CAL"]
    gpocost --> ops["Внедрение, сопровождение, резерв"]
    bpcost["Стоимость перехода на Intune"] --> sub["Пять лет Business Premium"]
    hw --> diff["Поставить пятилетнюю разницу рядом"]
    ops --> diff
    sub --> diff
    diff --> ability["Учесть, доходит ли управление до ПК вне офиса"]

Рис. 9: Смету замены сервера ставят рядом с пятью годами Business Premium и решают с учётом того, можно ли управлять ПК вне офиса.

5. Как в Intune делать то, что раньше делали через GPO

Для основных работ эксплуатации GPO соответствия в Intune сведены в таблицу.

Несколько уточнений.

• Каталог параметров — экран в духе «облачной версии редактора GPO»; сама Microsoft ставит его как «естественное место миграции, когда нужна такая же детальная настройка, как у локальной GPO». В него входят ADMX-backed политики (MDM-версия настроек, заданных в ADMX), есть и функция (preview) импорта сторонних ADMX.⁷
• Политика соответствия плюс условный доступ — идея, которой у GPO не было. Вы задаёте условия соответствия вроде «BitLocker включён, ОС актуальна, Defender работает» и можете закрыть доступ к Microsoft 365 с устройств, которые им не удовлетворяют. Условный доступ — функция Entra ID P1 и входит в Business Premium.¹⁶
• Remediations переименованы из Proactive remediations. Это механизм, который периодически выполняет пару сценариев обнаружения и исправления; он может заменить практики GPO вида «при каждом входе что-то починить», но, как сказано выше, требует лицензию уровня Windows Enterprise E3/E5.¹³ В рамках Business Premium реалистичная замена — сочетать скрипты платформы (выполняются при смене сценария или назначения и повторяются при сбое)¹² с правилами обнаружения Win32-приложений.
• Подробный выбор управления обновлениями (WUfB, Autopatch или продолжение WSUS) разобран в «Управлении Windows Update после объявления WSUS устаревшим», проектирование BitLocker и LAPS — в «Практическом руководстве по BitLocker» и «Практическом руководстве по Windows LAPS».

flowchart TB
    accTitle: Поток политики соответствия и условного доступа
    accDescr: Политика соответствия только оценивает состояние соответствия устройства условиям; доступ разрешается соответствующим устройствам и блокируется остальным только когда политика условного доступа требует соответствующее устройство
    policy["Задать условия соответствия"] -.-> cond["BitLocker включён, ОС актуальна и подобное"]
    policy --> state["Оценить состояние соответствия устройства"]
    state --> ca["Условный доступ требует соответствие"]
    ca -->|Соответствует| allow["Доступ к Microsoft 365 разрешён"]
    ca -->|Не соответствует| block["Доступ заблокирован"]

Рис. 10: Оценивать соответствие — работа политики соответствия; блокировать — работа условного доступа. Блокировка начинает действовать только вместе.

6. Инвентаризация текущих GPO — разбор через Group Policy analytics

Первая практическая работа плана миграции — инвентаризация текущих GPO. В Intune есть отдельная функция Group Policy analytics: она по каждой настройке отвечает, может ли MDM её заменить, и не заставляет разбирать GPO вручную.⁶

Шаги такие.⁶

1. На контроллере домена или аналоге откройте консоль управления групповой политикой (GPMC.msc), щёлкните правой кнопкой нужный GPO → «Сохранить отчёт» и экспортируйте как XML-файл (не больше 4 МБ на файл)
2. В центре администрирования Intune откройте Devices → Group Policy analytics и импортируйте XML (можно несколько файлов)
3. После автоматического анализа у каждого GPO появляется доля поддержки MDM (какая часть настроек имеет эквивалент в Intune)
4. В отчёте «Group policy migration readiness» по каждой настройке смотрите Ready for migration (можно переносить) / Not supported (соответствия нет) / Deprecated (снято)
5. Настройки Ready for migration можно сразу преобразовать в политику каталога параметров и раздать

flowchart TB
    accTitle: Как идёт инвентаризация через Group Policy analytics
    accDescr: GPO экспортируют как XML из GPMC и импортируют в Intune; появляются доля поддержки MDM и готовность к переносу по каждой настройке, а настройки Ready for migration можно преобразовать в политику каталога параметров
    export["Экспортировать GPO как XML из GPMC"] --> import["Импортировать в Intune"]
    import --> rate["Показать долю поддержки MDM"]
    rate --> report["Отчёт о готовности к миграции"]
    report --> ready["Ready for migration"]
    report --> notsup["Not supported"]
    report --> dep["Deprecated"]
    ready --> convert["Преобразовать в политику каталога параметров"]

Рис. 11: От XML-экспорта через импорт, разбор по настройкам и преобразование в каталог параметров — так работает Group Policy analytics.

В японских средах есть важная оговорка. Разбор настроек не из ADMX в Group Policy analytics есть только для английского; если импортировать GPO с настройками на другом языке, доля поддержки MDM может оказаться неточной.⁶ Долю поддержки берите как грубую справку, а окончательное решение выносите по списку настроек.

flowchart TB
    accTitle: На что смотреть при разборе японского GPO
    accDescr: Разбор настроек не из ADMX в Group Policy analytics есть только для английского, поэтому GPO с японскими настройками может дать неточную долю поддержки MDM; долю берите как грубую справку, окончательное решение — по списку настроек
    jgpo["GPO с японскими настройками"] --> limit["Разбор не-ADMX только на английском"]
    limit --> rate["Доля поддержки может быть неточной"]
    rate --> use1["Долю брать как грубую справку"]
    rate --> use2["Окончательное решение — по списку настроек"]

Рис. 12: В японском GPO доля поддержки MDM может быть неточной, поэтому окончательное решение выносите по списку настроек.

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

1. Настройки, которые выбросить — наследие Internet Explorer, параметры для уже снятых систем, настройки, причину которых никто не может объяснить. Главный выигрыш инвентаризации как раз в том, что эту кучу можно выбросить. У GPO, которому десять лет, такого наследия обычно много.
2. Настройки, которые перенести в Intune — из Ready for migration те, что ещё нужны. Преобразуйте их в каталог параметров и проверьте на пилотной группе.
3. Настройки, для которых проектируют замену — из Not supported те, что ещё нужны. Характерные примеры и направления замены такие.

flowchart TB
    accTitle: Три кучи результатов инвентаризации
    accDescr: Результаты инвентаризации разбирают на три кучи: настройки, которые выбросить, настройки, которые перенести в Intune и проверить, и настройки без соответствия, для которых проектируют замену
    result["Результаты разбора"] --> discard["Настройки, которые выбросить"]
    result --> move["Настройки, которые перенести в Intune"]
    result --> alt["Настройки, для которых проектируют замену"]
    discard -.-> legacy["Утилизировать накопившееся наследие"]
    move --> pilot["Преобразовать в каталог параметров и проверить"]
    alt --> design["Раздача сценарием или упаковка в приложение"]

Рис. 13: Результаты инвентаризации раскладывают на три кучи: «выбросить», «перенести в Intune» и «спроектировать замену».

7. Сценарий поэтапной миграции — пять этапов и критерии готовности

Разбейте целое на пять этапов и на каждый поставьте критерий «когда можно сказать, что этап закрыт». Заранее решить, что считается сделанным, — приём, который не даёт миграции в ИТ из одного человека застрять.

flowchart TB
    accTitle: Пятиэтапный сценарий миграции
    accDescr: Идут поэтапно от пилота через базовую политику, раздачу приложений, замену существующих ПК по циклу обновления оборудования и сжатие роли AD и в конце доводят настройки, которые раздают через GPO, до нуля
    s1["(1) Пилот"] --> s2["(2) Базовая политика"]
    s2 --> s3["(3) Раздача приложений"]
    s3 --> s4["(4) Естественная замена существующих ПК"]
    s4 --> s5["(5) Сжатие роли AD"]
    s5 -.-> goal["Настройки, которые раздают через GPO, равны нулю"]

Рис. 14: Миграцию ведут в пять этапов от пилота до сжатия роли AD и заранее фиксируют критерий готовности каждого этапа.

Главное по этапам.

• (1) Пилот начинают с ПК, который и так собирались купить: следующий компьютер нового сотрудника, замена после поломки и подобное. На новой машине нет дополнительных вложений, а если не получится — можно сделать wipe и начать заново. Когда машин станет больше, имеет смысл рассмотреть Windows Autopilot, чтобы автоматизировать путь от OOBE (первичная настройка) до Entra join и регистрации в Intune.²
• В (2) Базовой политике не пытайтесь воспроизвести все настройки GPO. Сначала сузьте до пяти: обновления, шифрование, Defender, блокировка экрана и LAPS — и покажите состояние соответствия политикой соответствия. «Доступ только с соответствующих устройств» в условном доступе включают после того, как на пилоте убедились, что ложных срабатываний нет.¹⁶
• (3) Раздача приложений продолжает автоматизацию подготовки ПК. Если уже есть процедура на базе winget («Автоматизация подготовки ПК через winget + PowerShell»), этот задел почти без переделки идёт как Store app (new) или обёртка Win32-приложения.¹¹
• (4) Существующие ПК, как сказано в главе 3, нельзя «переконвертировать» в Entra join, поэтому принцип — естественная замена. Организациям, у которых ещё жив план замены Windows 10 («Реалистичные варианты после окончания поддержки Windows 10»), выгоднее вести ту замену одновременно с (4), чтобы не делать работу дважды.
• В (5) Сжатии роли AD пустой GPO не значит, что AD сразу не нужен. Если остаются аутентификация файлового сервера, LDAP-запросы унаследованных приложений и подобное, AD продолжают в сжатом виде как «сервер аутентификации». Разобрать это и поставить сроки — работа этого этапа.

flowchart TB
    accTitle: Что делать с AD после того, как GPO опустел
    accDescr: Даже когда GPO пуст, если остаются аутентификация файлового сервера или LDAP-запросы унаследованных приложений, AD продолжают в сжатом виде как сервер аутентификации, а разбор оставшихся ролей и постановка сроков — работа финального этапа
    gpoempty["GPO опустел"] --> remain{"Какие роли остались?"}
    remain -->|Аутентификация файлового сервера| keep["Продолжить в сжатом виде как сервер аутентификации"]
    remain -->|Унаследованные LDAP-запросы| keep
    remain -->|Ролей нет| retire["Рассмотреть вывод самого AD"]
    keep --> task["Довести разбор и постановку сроков"]

Рис. 15: Даже когда GPO пуст, если роли остались, AD продолжают в сжатом виде как сервер аутентификации.

8. Где спотыкаются

8.1. Двойное применение GPO и MDM — по умолчанию побеждает GPO

На время миграции и GPO, и Intune будут раздавать настройки на один и тот же ПК (машину hybrid join). Здесь если одна и та же настройка конфликтует, по умолчанию побеждает групповая политика. Если выставить MDMWinsOverGP в Policy CSP в 1, приоритет переходит к настройке MDM, а соответствующая настройка GPO блокируется. Но механизм действует только для настроек под Policy CSP и не распространяется на параметры из других CSP, например Defender CSP. Сама Microsoft прямо пишет: если настройку, которая не под MDMWinsOverGP, задать и из GPO, и из MDM, вы попадаете в конфликт, и победитель не гарантирован.¹⁴

flowchart TB
    accTitle: Кто побеждает при конфликте GPO и MDM
    accDescr: Если одну и ту же настройку раздать и из GPO, и из MDM, по умолчанию побеждает GPO; MDMWinsOverGP=1 отдаёт приоритет MDM только для настроек под Policy CSP, а для настроек в других CSP победитель не гарантирован
    both["Одну настройку раздать и из GPO, и из MDM"] --> flag{"MDMWinsOverGP=1?"}
    flag -->|Нет| gpowin["Побеждает GPO (умолчание)"]
    flag -->|Да| csp{"Настройка под Policy CSP?"}
    csp -->|Да| mdmwin["Побеждает MDM"]
    csp -->|Нет| unknown["Победитель не гарантирован"]
    both -.-> avoid["Правило — не раздавать из обоих"]

Рис. 16: По умолчанию побеждает GPO, а MDMWinsOverGP действует только под Policy CSP. Правило — не раздавать одно и то же из двух каналов.

Практическое правило простое. Не опирайтесь на переключение приоритета; не раздавайте одну настройку из обоих каналов. Для настройки, которую уже перенесли в Intune, верните соответствующую конфигурацию GPO в «Не задано» или снимите привязку GPO целиком. Список перенесённых из главы 6 — ещё и реестр для этой уборки.

8.2. Зависимость от локальных ресурсов — сетевые диски и принтеры

Миграция чаще застревает не на функциях Intune, а на связке с локальными ресурсами. Сам доступ с машины Entra join к локальному файловому серверу возможен,² но если подключение дисков и раздача принтеров держались на сценарии входа GPO, это средство раздачи пропадает первым. Во время пилота решите, вшить ли в этап (3) перенос общих папок в OneDrive/SharePoint или замену на Universal Print — или пока закрыть разрывы развёртыванием сценарием.¹²

flowchart TB
    accTitle: Чем заменить раздачу, которая зависит от локальных ресурсов
    accDescr: Если подключение дисков и раздача принтеров зависят от сценария входа GPO, это средство раздачи пропадает первым при миграции, поэтому во время пилота решают, закрывать ли это переносом общих папок в OneDrive или SharePoint, заменой на Universal Print или пока развёртыванием сценарием
    dep["Зависимость от сценария входа"] --> lost["Средство раздачи пропадает при миграции"]
    lost --> share["Перенести в OneDrive/SharePoint"]
    lost --> print["Заменить Universal Print или аналогом"]
    lost --> script["Пока закрыть развёртыванием сценарием"]
    share --> decide["Решить подход во время пилота"]
    print --> decide
    script --> decide

Рис. 17: Раздача, которая зависит от сценария входа, теряет средство первой при миграции, поэтому замену решают во время пилота.

8.3. Пересборка подготовки ПК — Autopilot не обязателен

Вместе с переходом на Intune часто предлагают сразу вводить Windows Autopilot, но при закупке от нескольких до десятка с небольшим машин в год вход рабочей учётной записью на OOBE и ручной Entra join реального вреда не делают. Autopilot начинает окупаться, когда закупок больше и есть смысл в безлюдной настройке из коробки, или когда можно задействовать регистрацию устройств на стороне реселлера. Добавить его после того, как закрыты (2) и (3), нормально: это не условие старта миграции.

flowchart TB
    accTitle: Стоит ли вводить Autopilot
    accDescr: При закупке от нескольких до десятка с небольшим машин в год ручной Entra join на OOBE реального вреда не делает; Autopilot добавляют позже, когда закупок больше и безлюдная настройка имеет смысл
    scale{"Каков годовой объём закупок?"} -->|Несколько — десяток с небольшим| manual["Ручной Entra join на OOBE"]
    scale -->|Когда машин станет больше| ap["Безлюдный Autopilot"]
    ap -.-> later["Добавить после того, как закрыты (2) и (3)"]

Рис. 18: Пока закупок мало, хватает ручного Entra join; Autopilot можно добавить позже.

8.4. Заблуждение «пока всё не в Intune — миграция не считается»

Последнее — не техника, а установка. Сосуществование машин Entra join и машин, присоединённых к домену, — официально поддерживаемая конфигурация,² и «AD ещё есть = миграция провалилась» — неверно. Компании, которые годы живут с несколькими настройками, всё ещё лежащими в GPO, не редкость, и даже тогда велика ценность состояния «каждый новый ПК ведётся из облака, и контроль работает и вне офиса». Лучше маленькие шаги, которые можно откатить, чем красивая полная миграция.

flowchart TB
    accTitle: Ценность параллельной работы без требования полной миграции
    accDescr: То, что AD остаётся, не значит, что миграция провалилась; даже если годы работать параллельно с настройками, ещё лежащими в GPO, велика ценность состояния, в котором каждый новый ПК ведётся из облака и контроль работает вне офиса
    miscon["AD остаётся — значит миграция провалилась?"] -->|Нет| run["Годы параллельной работы с оставшимся GPO"]
    run --> value["Новые ПК под контролем даже вне офиса"]
    value -.-> forward["Предпочитать маленькие шаги"]

Рис. 19: Даже при параллельной работе с оставшимся AD состояние, в котором каждый новый ПК ведётся из облака, имеет большую ценность.

9. Реалистичный путь, когда ИТ — один человек

Наконец, как проектировать эксплуатацию в компании, где за это отвечает один человек (или роль совмещённая).

• С самого начала сузьте, чем управляете. Если тащить все настройки эпохи GPO, вы выдохнетесь уже на инвентаризации. Начните с пяти пунктов главы 7 (2) (обновления, шифрование, Defender, блокировка экрана, LAPS) и проектируйте «вычитанием»: добавляйте настройку только когда она реально понадобилась. Каталог параметров предлагает тысячи настроек,⁷ но пользоваться ими всеми вы не обязаны.
• Зафиксируйте один стандартный образ ПК. Держите один стандарт: «ПК в этой компании — вот этот набор политик и вот этот набор приложений». Исключения отделов можно выразить группами и фильтрами, но чем их больше, тем меньше один человек успевает.
• Внешнего партнёра просите о проекте и шаблонах; повседневную эксплуатацию оставляйте себе. Аутсорсинг миграции Intune чаще всего ломается так: внедрение отдают целиком и оказывается, что смысл экранов администрирования не понимает никто. Снаружи берите начальное проектирование, шаблоны политик и обсуждение решений по миграции и целью ставьте состояние, в котором добавить ПК и чуть поправить политику вы можете сами. Иначе говоря, выбирайте партнёра, который передаст вам работу до этого уровня.
• Меняйте по одному. Политику меняйте по одной и к следующей переходите только после проверки результата в отчётах Intune (состояние применения и сбои назначения). Синхронизация MDM идёт циклом около 8 часов,³ и большинство «не применилось» — вопрос времени, а не поломка.

flowchart TB
    accTitle: Цикл смены политики
    accDescr: Политику меняют по одной и к следующей переходят только после проверки состояния применения в отчётах Intune. Большинство случаев «не применилось» закрывается ожиданием цикла синхронизации примерно 8 часов
    change["Сделать только одну смену политики"] --> report["Проверить состояние применения в отчётах"]
    report --> next["Если проблем нет — к следующей смене"]
    next --> change
    report -.-> wait["Большинство «не применилось» — ожидание синхронизации"]

Рис. 20: Политику меняют по одной и к следующей переходят только после проверки результата в отчётах.

10. Итог

• GPO рассчитан на доступность контроллера домена и структурно не доходит до ПК вне офиса. Intune (MDM) синхронизируется через интернет и закрывает эту задачу в корне.
• Миграция — не «всё или ничего». Машины Entra join и машины, присоединённые к домену, могут работать вместе; поэтапный переход, при котором новые ПК идут в Entra join и Intune, — реалистичный путь для малого и среднего бизнеса. Пути преобразования существующих машин нет, поэтому привычный шаблон — замена по циклу обновления оборудования.
• Для малого и среднего бизнеса начинать Intune с Microsoft 365 Business Premium (Intune Plan 1 плюс Entra ID P1) реалистично. Состав планов, однако, продолжает меняться, а часть функций вроде Remediations требует старшую лицензию, поэтому не принимайте статью августа 2026 за истину в последней инстанции — сверяйтесь с первоисточниками.
• Инвентаризацию текущих GPO можно автоматизировать через Group Policy analytics. Настройки Ready for migration преобразуйте в каталог параметров; сценарии входа и раздачу принтеров без соответствия заменяйте развёртыванием сценарием, упаковкой в приложение или отказом от практики. В японском GPO доля поддержки может быть неточной.
• Миграцию ведите в пять этапов «пилот → базовая политика → раздача приложений → естественная замена существующих ПК → сжатие роли AD» и сначала зафиксируйте критерий готовности каждого этапа.
• При конфликте двойного применения по умолчанию побеждает GPO. MDMWinsOverGP — механизм только Policy CSP, поэтому правило — «не раздавать одну настройку из обоих каналов».
• Когда приходит смета замены сервера — лучший момент рассмотреть эту миграцию. Прежде чем «ещё один цикл AD», подумайте, где в ближайшие пять лет будут работать ПК.

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

• Практическое руководство по групповой политике (GPO) — как это работает, как проверить применение и как разделить роли с Intune
• Управление Windows Update после объявления WSUS устаревшим — как выбрать между WUfB, Autopatch и Intune
• Реалистичные варианты после окончания поддержки Windows 10 — таблица решений для ESU, LTSC и замены
• Автоматизация подготовки ПК через winget + PowerShell — сделать инструкцию исполняемой
• Практическое руководство по BitLocker — шифрование дисков, начиная с управления ключами восстановления
• Практическое руководство по Windows LAPS — отказаться от одного пароля локального администратора на все ПК

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

KomuraSoft LLC проектирует поэтапный переход с AD+GPO на Entra ID+Intune (инвентаризация текущих GPO, как воспроизводить политики, пилотный план), сравнивает замену сервера и переход в облако и помогает опереться на существующие бизнес-приложения и наработки по подготовке ПК. Можно начать с совместного разбора вопроса: «стоит ли снова покупать сервер AD».

• Техническая консультация и ревью проекта
• Использование и миграция существующих активов
• Связаться с нами

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

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

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

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

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

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

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

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

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

Если перейти с GPO на Intune, удастся ли воспроизвести все текущие настройки групповой политики?

Все — нет. Каталог параметров Intune содержит тысячи настроек Windows, в том числе унаследованных из ADMX, и большинство ограничений и параметров безопасности переносится. Но у части сценариев — подключение дисков из сценария входа, массовая раздача принтеров — в MDM нет соответствующего параметра. Если импортировать XML-экспорт текущих GPO в Group Policy analytics, каждая настройка помечается как Ready for migration, Not supported или Deprecated. Там, где соответствия нет, задачу закрывают развёртыванием сценария PowerShell, упаковкой в приложение или отказом от самой настройки.

Какая лицензия нужна, чтобы пользоваться Intune?

Базовая — Microsoft Intune Plan 1. Её можно купить отдельно, но в малом и среднем бизнесе обычно берут как часть Microsoft 365 Business Premium (до 300 пользователей). В Business Premium входит и Entra ID P1, поэтому можно дойти до связки политик соответствия с условным доступом. Отдельные функции, например Remediations, требуют лицензию уровня Windows Enterprise E3/E5. Состав планов часто меняется: перед договором сверяйтесь с официальными страницами лицензирования Microsoft (статья — по состоянию на август 2026).

Нужно ли сразу выводить сервер AD из эксплуатации?

Нет. ПК под Entra join и Intune и ПК, присоединённые к домену AD и управляемые GPO, могут работать в одной корпоративной сети. Реалистичный путь — оставить AD ради аутентификации файлового сервера и существующих бизнес-систем, а на Entra join переводить только новые ПК. Обратного «преобразования» уже присоединённого к домену ПК в Entra join нет: нужен wipe (сброс), поэтому существующие машины обычно меняют по циклу обновления оборудования. Вывод AD имеет смысл рассматривать после того, как GPO опустеют и вы разберёте оставшиеся роли.

Почему групповая политика не применяется к домашним ПК?

Потому что GPO забирается и применяется, только когда устройство может достучаться до контроллера домена. Вне офиса последняя политика приходит лишь после доступа к контроллеру — обычно через VPN. Домашний ПК без VPN её по сути не получает. Intune (MDM) синхронизирует политики через интернет, поэтому устройством можно управлять где угодно: задача управления ПК вне офиса решается устройством MDM. Помимо периодической синхронизации примерно раз в 8 часов, при смене политики срабатывает и синхронизация по уведомлению.

Если одну и ту же настройку раздать и из GPO, и из Intune, какая победит?

По умолчанию при конфликте побеждает групповая политика. Если выставить MDMWinsOverGP в 1, приоритет переходит к MDM (Intune), но только для настроек под Policy CSP; на параметры из других CSP, например Defender CSP, это не распространяется. Если опираться на переключение приоритета, поведение становится плохо предсказуемым. На практике правило такое: не раздавать одну настройку из обоих каналов. Настройку, которую уже перенесли в Intune, удалите из исходной GPO, чтобы не вести её в двух местах.

Об авторе

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

Го Комура

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

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