Переезд с SCCM на Intune: план 6-недельного пилота

Что меняется при уходе от SCCM и зачем нужен пилот

SCCM (ConfigMgr) обычно решает сразу несколько задач: развертывание приложений и обновлений, управление образами Windows, инвентарь железа и софта, отчеты, удаленные действия и частично безопасность. При переходе к современному управлению устройствами (Intune) цели остаются теми же, но меняются подход и точки контроля. Больше логики уходит в облачные политики, а привычные сценарии приходится собирать заново.

Чаще всего по-другому начинают работать такие области:

• Развертывание приложений. Вместо коллекций и task sequence вы опираетесь на группы, назначения и требования к установке.
• Обновления Windows. Вместо централизованных циклов SCCM ключевую роль играют Windows Update for Business и политики обновлений.
• Подготовка новых ПК. Вместо эталонных образов и PXE многие переходят к Windows Autopilot и настройке после выдачи.
• Инвентарь и отчетность. Данные собираются иначе, отчеты выглядят непривычно, и важно заранее понять, каких ответов вам не хватает.
• Удаленная помощь и поддержка. Меняются инструменты и процессы: права, аудит, ожидания по времени реакции.

Пилот обязателен, потому что риск здесь не только технический. Ошибка в назначении или политике бьет по людям: пропадет доступ к VPN, не установится рабочее приложение, включится лишнее шифрование, а служба поддержки получит всплеск обращений.

Хороший пилот проверяет не только «работает ли Intune», а поддерживаемость новой модели в повседневной жизни. В смешанной организации (офис, удаленка, филиалы) особенно важно убедиться, что устройство разворачивается и чинится без визита в центральный офис.

Успех пилота стоит измерять конкретно:

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

Границы пилота: устройства, пользователи, сценарии

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

По устройствам лучше выбрать 2-3 типовых класса, которые действительно живут в компании каждый день: офисные ПК, ноутбуки для разъездной работы и несколько сенсорных AIO. Если есть специализированные рабочие места (терминалы в регистратуре, учебные классы, нестандартная периферия), возьмите один понятный подтип, чтобы не утонуть в драйверах и исключениях.

По пользователям полезно включить разные условия работы: офис, один-два филиала, несколько удаленных сотрудников. Отдельно решите вопрос с привилегированными учетными записями. Чаще всего их либо исключают из первой волны, либо подключают ограниченно, с отдельными правилами.

Чтобы пилот оставался управляемым, зафиксируйте границы письменно:

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

Простой пример: 30 устройств (20 офисных ПК, 8 ноутбуков, 2 AIO) и 3 группы пользователей (офис, филиал, удаленные). Все, что не укладывается в этот набор, переносится в следующий этап, даже если очень хочется «добавить еще один кейс».

Целевая модель: co-management или полный переход

Выбор модели определяет, как пройдет переезд с SCCM на Intune и сколько рисков вы берете на пилоте. Есть два базовых пути: co-management (часть нагрузок в SCCM, часть в Intune) или полный переход, когда Intune становится главным инструментом, а SCCM выводится из эксплуатации.

Co-management обычно безопаснее для старта: нагрузки переносятся по очереди, а критичные процессы временно остаются там, где они уже отлажены. Полный переход быстрее по итогам, но в пилоте требует жестче держать стандарты: меньше исключений, четче требования к устройствам и приложениям.

Часто первыми имеет смысл переносить то, что дает быстрый эффект и редко конфликтует с текущими настройками:

• базовые политики конфигурации (Wi-Fi, VPN, параметры Windows);
• compliance и условный доступ (проверки состояния устройства);
• обновления Windows через политики обновлений;
• базовую защиту (например, настройки Defender).

Главный риск в пилоте - двойное управление. Если одинаковые параметры задаются и из SCCM, и из Intune, поведение станет непредсказуемым: настройки «прыгают», отчеты расходятся, пользователи жалуются. Практическое правило простое: у каждой нагрузки один владелец и одна «точка истины». Все, что не переносите, явно оставляйте за SCCM.

Оставить SCCM на время разумно, если у вас есть сложный OSD и task sequences, локальные точки распространения для больших пакетов, офлайн-сегменты или площадки с нестабильным интернетом, а также приложения, которые пока нельзя надежно упаковать под Intune.

Хороший итог пилота - понятная «матрица нагрузок»: что уже в Intune, что еще в SCCM, и почему.

Команда и роли: кто за что отвечает

Пилот чаще ломается не из-за Intune, а из-за размытых обязанностей. Перед переездом заранее договоритесь, кто принимает решения, кто вносит изменения и кто отвечает перед пользователями.

Минимальный состав команды обычно такой:

• владелец пилота (ИТ-руководитель или менеджер) - определяет границы, календарь, бюджет времени и финальное решение;
• инженер MDM/Intune - настраивает enrollment, профили, политики, соответствие и следит за дрейфом настроек;
• инженер приложений - ведет каталог, упаковку, зависимости, требования и план обновлений;
• специалист по безопасности - утверждает базовые меры (шифрование, пароли, Defender, условный доступ), согласует исключения;
• helpdesk - принимает обращения, фиксирует симптомы, эскалирует и проверяет, что исправление реально помогло.

Чтобы изменения не ломали пилот, задайте простой процесс. Например: инженер MDM правит профили только через заявку; инженер приложений публикует приложения только после теста на 2-3 устройствах; исключения (например, временно отключить требование соответствия) подтверждают безопасность и владелец пилота.

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

Канал обратной связи сделайте единым (почта, форма или чат), а SLA зафиксируйте письменно: критические инциденты пилота - реакция за 2 часа, некритичные - в течение рабочего дня. Так меньше шума и проще честно мерить результат.

Базовая подготовка среды до старта пилота

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

Сначала проверьте идентичности и доступ. Убедитесь, что учетные записи пилотных пользователей активны, а группы (по пользователям и по устройствам) отражают ваш замысел: кому назначаются приложения, кому выдаются политики, кто получает админ-доступ. Путаница «устройство vs пользователь» часто ломает назначения в первые дни.

Дальше - сеть. Устройства должны стабильно выходить к облачным сервисам управления, а прокси и TLS-инспекция не должны подменять сертификаты на критичных точках. При строгой фильтрации заранее согласуйте исключения для автоподготовки Windows, магазина приложений и проверки соответствия. Иначе получите «случайные» сбои: на одной площадке работает, на другой - нет.

Отдельный блок - сертификаты и профили Wi-Fi/VPN. Если планируете автоматическую настройку сети, заранее решите, как подтверждается доступ: сертификатами, учетными данными или гибридно. Подготовьте цепочки доверия и проверьте, что устройство подключается к Wi-Fi до входа пользователя (если это важно).

Модель безопасности задайте сразу, минимально необходимую. Удобно зафиксировать короткие правила: кто администратор Intune и кто может менять политики; как выдаются временные права на время пилота; как разделяются тестовые и «боевые» назначения; где хранится журнал изменений (кто и что поменял).

Пример из практики: в филиальной сети часть сотрудников работает через прокси с TLS-инспекцией. Если не согласовать исключения, Autopilot может зависнуть на регистрации, а приложения - не установиться. Это лучше выявить на подготовке, чем на третьей неделе пилота.

Инвентарь: устройства, приложения, зависимости и отчеты

Инвентарь в пилоте нужен не ради «красивых таблиц». Он помогает заранее увидеть, что сломается при переезде: какие устройства не готовы, какие приложения держатся на редких установщиках, а какие настройки безопасности завязаны на локальные исключения.

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

Дальше разберите приложения не только списком, но и по смыслу. Для каждого приложения полезно знать владельца в бизнесе, критичность, частоту использования, источник установщика и понятный способ обновления. Типичный риск - «ручные» компоненты, о которых помнит один человек (например, редкий плагин к браузеру).

Отдельно выпишите зависимости. Обычно всплывают плагины, драйверы принтеров и сканеров, правила брандмауэра, исключения антивируса, сертификаты и локальные компоненты (например, библиотеки VC++). Эти вещи часто не видны в «простом списке», но именно они ломают запуск.

Заранее договоритесь, какие отчеты вам нужны в пилоте, чтобы бизнес и ИБ приняли результат:

• покрытие устройств пилота и процент успешно управляемых;
• соответствие требованиям (шифрование, пароль, обновления);
• статус установки ключевых приложений и ошибки;
• перечень исключений (антивирус, брандмауэр) и кто их согласовал;
• инциденты: что не установилось и сколько времени заняло исправление.

Если этот набор собрать сразу, пилот становится измеримым, а не «ощущением, что вроде работает».

Приложения: упаковка, развертывание, обновления

Пилот часто ломается не на политиках, а на приложениях. Для миграции приложений из SCCM в Intune сначала разложите портфель по типам: MSI, «тихие» EXE, приложения из Microsoft Store, PowerShell-скрипты. Браузерные расширения обычно удобнее вести политиками, а не установщиками.

Дальше нужен единый стандарт упаковки и детекта. Без него вы получите повторные установки, «вечные» попытки развертывания и путаницу в отчетах. Договоритесь о правилах: единые имена и версии, владелец приложения, и главное - понятный detection rule (по файлу, реестру или коду продукта MSI). Если у приложения есть зависимости, фиксируйте их сразу. Иначе в пилоте вы будете чинить «не запускается», а не проверять управление.

Набор приложений для пилота лучше ограничить тем, что нужно каждый день: офисный пакет, 1-2 браузера, VPN-клиент, средство ВКС, агент безопасности (EDR/антивирус/шифрование - что у вас принято).

Обновления продумайте до первого развертывания. Определите, кто отвечает за версию, как проходит тест (например, на 10-20 пилотных устройствах) и как выглядит откат, если обновление ломает работу. В SCCM откат часто решали «переустановкой по коллекции», а в Intune важно заранее иметь предыдущий пакет и понятный триггер отката.

Практичный сценарий: VPN обновили, и после перезагрузки часть пользователей не входит в сеть. Если детект версий настроен нормально, вы быстро отделите «не обновилось» от «обновилось, но не работает» и откатите только проблемную группу. Такие ситуации и показывают, готов ли переезд к реальной нагрузке.

Образы и подготовка устройств: от task sequences к Autopilot

В SCCM часто держатся за кастомный образ: так проще «зашить» драйверы, базовые настройки и набор софта. При переходе на Intune в большинстве случаев выигрывает другой подход: стандартная Windows, а все остальное задают политики и приложения. Кастомный образ стоит оставлять только при жестких ограничениях, например офлайн-развертывание в закрытой сети или редкие драйверы, которые сложно поставить после установки.

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

Для действующих устройств важно не ломать рабочий день. Обычно начинают с мягкого подключения к управлению, проверяют совместимость и переносят настройки по частям: сначала базовые политики безопасности и Wi-Fi/VPN, затем приложения, и только потом расширенные ограничения.

Task sequences лучше заменять по шагам. Сначала разберите их на этапы (настройки, приложения, обновления, постконфигурация), перенесите настройки в политики Intune, софт - в пакеты Win32, а условные шаги закройте группами и динамическими назначениями. Отдельно решите, чем закрывать драйверы и обновления (Windows Update for Business, OEM-инструменты). И важно сразу принять ограничение: в Autopilot нельзя повторить один в один все pre-OS сценарии SCCM.

Политики, соответствие и безопасность в пилоте

В пилоте не стоит переносить все политики из SCCM «один к одному». Цель другая: убедиться, что базовая безопасность и управляемость работают стабильно, а правила соответствия действительно влияют на доступ к корпоративным ресурсам.

Начните с минимального набора, который дает ясный эффект и легко проверяется:

• BitLocker: шифрование включено, ключ восстановления сохраняется, есть правило для съемных носителей (если нужно).
• Windows Update: обновления включены, окна перезагрузки понятны пользователям, критические патчи приходят вовремя.
• Брандмауэр: включен на всех профилях, без лишних исключений.
• Локальные администраторы: прозрачный список, личные учетные записи исключены.
• Базовая защита: включены встроенные механизмы безопасности Windows без «тонкой настройки» на первом шаге.

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

Отдельно проверьте профили Wi-Fi/VPN и сертификаты. Это частый источник сбоев: один неверный сертификат или профиль, и пользователь «как будто в управлении», но подключиться не может.

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

Пример пилота: смешанная организация и реальная нагрузка

Представим пилот в компании на 200 устройств: в офисе 150 ноутбуков, в филиалах 30, у удаленных сотрудников 20. Это хороший срез: разные сети, разные каналы поддержки и типичные бытовые задачи, которые часто ломают «идеальную» схему переезда.

По приложениям картина обычно такая: 10 обязательных для всех (браузер, офисный пакет, мессенджер, EDR, VPN-клиент), 15 по запросу (CAD, бухгалтерия, отдельные плагины), и несколько устаревших и проблемных. Эти проблемные лучше сразу пометить как риск: старые MSI, самописные установщики без тихого режима, приложения с зависимостью от локальных прав.

Больнее всего почти всегда оказываются мелочи, которые видны только в живой эксплуатации. В таком пилоте заранее заложите время на проверку VPN (автоподключение, сертификаты, работа вне офиса и после смены пароля), печати в филиалах, драйверов (док-станции, Wi-Fi, камеры, сканеры), поведения старых MSI и реальной необходимости админских прав.

Поддержку лучше организовать так, чтобы пилот не превратился в хаос. Дайте участникам один путь обращения и фиксируйте каждый инцидент одинаково: шаблон тикета (устройство, сеть - офис/филиал/дом, что изменилось, время), обязательный сбор логов (Intune Management Extension, события установки, скрин ошибки), правило «30 минут на диагностику» и быстрый откат на SCCM для критичных ролей, если простой недопустим.

Если часть парка - локально произведенные рабочие станции и ноутбуки (например, поставки от GSE.kz), имеет смысл включить их в пилот отдельной группой. Так вы заранее увидите нюансы по драйверам и подготовке на «своем» железе, а не после масштабирования.

План пилота на 6 недель: неделя за неделей

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

Неделя 1. Закройте инвентарь: модели ПК в пилоте, критичные приложения, зависимости (VPN, сертификаты, драйверы, плагины). Выберите группы пользователей (например, 2 отдела и 1 ИТ-группа), назначьте роли (владелец пилота, упаковка приложений, безопасность, поддержка), подготовьте базовые политики и правила исключений.

Неделя 2. Подключите первые 10-20 устройств. Включите минимум: регистрацию, базовые профили, доступ к почте и Wi-Fi/VPN. Собирайте проблемы в одном месте и каждый день закрывайте хотя бы 1-2 причины, а не симптомы.

Неделя 3. Упакуйте и разверните топ-10 приложений (то, без чего люди не работают: офисные инструменты, браузер, VPN, ЭДО). Настройте обновления и проверку установки. Расширьте до 30-50 устройств и проверьте, как ведет себя поддержка при потоке обращений.

Неделя 4. Добавьте Autopilot: сценарий нового устройства и сценарий переустановки. Расширьте пилот на 1-2 филиала, чтобы проверить сеть, часовые пояса, локальные принтеры и работу вне офиса.

Неделя 5. Перенесите дополнительные нагрузки: сложные приложения, политики безопасности, базовый hardening. Закройте критичные баги (например, конфликт VPN с обновлениями или сбой установки драйвера).

Неделя 6. Сведите метрики и примите решение о масштабировании. Зафиксируйте план волн: кого переводите первым, какие ограничения, какой план отката. Пример: если у бухгалтерии 2 ключевых приложения, включите их в обязательный набор и требуйте 95% успешных установок до старта следующей волны.

Критерии успешности и метрики: как понять, что пилот удался

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

Устройства и политики

Смотрите не только факт регистрации, но и скорость выхода на состояние «готово к работе». Полезные метрики:

• успешная регистрация и применение базовых политик (процент устройств);
• время от первого входа пользователя до состояния «все обязательное установлено»;
• доля устройств с ошибками политик или профилей (и какие именно ошибки повторяются);
• количество ручных вмешательств ИТ на 10 устройств.

Если из 30 пилотных ноутбуков 6 требуют ручной починки из-за одной и той же политики, это не мелочь, а причина менять дизайн или исключения.

Приложения, поддержка и безопасность

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

Набор must-have для безопасности в пилоте:

• шифрование включено и не ломает рабочие сценарии;
• соответствие (compliance) проходит у большинства без исключений;
• обновления ОС и защитных компонентов применяются в срок;
• все отклонения оформлены как осознанные исключения, а не «так получилось».

Финальное go/no-go решение удобнее делать по таблице: что прошло, что не прошло, что исправляем до масштабирования (с датой и ответственным).

Частые ошибки при переходе и как их избежать

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

Первая ловушка - двойное управление без четких границ. Когда одни и те же настройки задаются в SCCM (или GPO) и в новом управлении, устройства получают разные команды. В итоге часть параметров «мигает», отчеты расходятся, а поддержка не понимает, где искать источник.

Перед стартом пилота зафиксируйте простые правила:

• разделите зоны ответственности: какие политики и приложения остаются за SCCM, а что уходит в Intune;
• для пилота используйте отдельные коллекции и группы, чтобы случайно не задеть остальных;
• выберите 1-2 критичных сценария и доведите их до стабильности, прежде чем расширяться.

Вторая ошибка - миграция без владельцев приложений. Если у приложения нет ответственного, быстро выясняется, что нет «чистого» установщика, неизвестны ключи, зависимости, правила обновления и срок реакции на уязвимости. Назначьте владельца на каждое пилотное приложение и договоритесь о понятном SLA: кто и как быстро выпускает новую версию и кто подтверждает совместимость.

Третья проблема - слишком широкий пилот. Желание сразу покрыть все типы устройств и весь софт почти гарантирует затяжку сроков. Репрезентативный набор обычно лучше: 2-3 модели ПК, 2 отдела, 10-15 приложений, включая одно сложное (например, с драйверами или плагинами).

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

Минимум, который должен быть готов: сценарий отката (что делаем за 30-60 минут), короткая памятка пользователям и проверка сети до пилота (доступ к облачным службам, прокси, SSL-инспекция, пропускная способность в часы пик).

Короткий чек-лист и следующие шаги после пилота

Перед тем как считать пилот успешным, пройдитесь по короткому чек-листу. Он помогает увидеть риски в ежедневной работе: установки, обновления, шифрование, обращения в поддержку.

Что должно быть зафиксировано и подтверждено до старта и по ходу пилота:

• назначены роли (владелец пилота, упаковка приложений, безопасность, поддержка), утверждены пилотные группы, список приложений и правила отката;
• работает регистрация устройств, применяются базовые политики, включены шифрование и обновления, есть контроль соответствия;
• для приложений готовы правила детекта, понятное логирование установок и процедура обновлений (кто тестирует, где фиксируется результат, что делаем при сбое);
• у поддержки есть короткая инструкция: как собрать диагностику, как проверить статус устройства, и 2-3 сценария восстановления (например, переустановка корпоративного VPN или повторная регистрация);
• согласован план масштабирования и заложено время на упаковку оставшихся приложений (обычно это больше половины усилий).

После пилота не делайте «большой взрыв». Переходите волнами: например, 50 устройств, затем 200, затем офис целиком. Если в пилоте выяснилось, что два критичных приложения нестабильно ставятся, сначала доведите упаковку и тестирование до предсказуемого результата, и только потом расширяйте охват.

Если нужна помощь с пилотом и последующим масштабированием, можно привлечь GSE.kz (gse.kz) как системного интегратора: от планирования и политики безопасности до подготовки рабочих станций и серверов и организации поддержки 24/7.