Мигрируем с SCCM 2007 на SCCM 2012: новая ролевая модель и суровая реальность миграции баз

SCCM 2007 у нескольких наших клиентов живёт с 2008-2009 года. Живёт - громко сказано: работает, конечно, но с каждым новым пакетом обновлений и каждой новой версией Windows всё более скрипит. Когда вышел SCCM 2012 GA, мы сразу взяли его в лабораторию, а сейчас начали первую боевую миграцию. Записываем, что видим.

Зачем вообще мигрировать

Честный ответ: не обязательно прямо сейчас, если SCCM 2007 справляется. Но в двух конкретных случаях у нас не было выбора.

Первый - Windows 8 и Server 2012. SCCM 2007 не умеет нормально управлять этими системами. Клиент начинает разворачивать ноутбуки с Windows 8, и тут выясняется, что software inventory работает криво, OSD-последовательности падают, а WinPE 4.0 не поддерживается вовсе. Патч-менеджмент через WSUS ещё как-то живёт, но deployment - нет.

Второй - ролевая модель. В SCCM 2007 разграничение прав реализовано через Security Rights, и это боль. Дать оператору helpdesk права на запуск advertisment'ов только на его площадке, не давая ничего лишнего, - это упражнение в мазохизме. Мы в итоге выдавали либо слишком много, либо ходили по кругу с настройками.

Что изменилось в 2012

SCCM 2012 ввёл Role-Based Administration - RBAC, построенный на трёх сущностях: роли (Role), области безопасности (Security Scope) и коллекции (Collection). Звучит как очередная бюрократия, но на практике это сильно чище.

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

Консоль тоже переработали - появился Application Catalog, деплоймент теперь называется Deployment, а не Advertisement (ура). Application Model вместо Package/Program - принципиально другой подход к распространению ПО: приложение описывается с Deployment Type'ами, правилами обнаружения и зависимостями. Это сложнее для понимания с нуля, но масштабируется лучше.

Миграция: где всё становится нетривиальным

Вот тут начинается суровая реальность. Microsoft предоставляет Migration Job Wizard - инструмент, который переносит объекты из SCCM 2007 в SCCM 2012 через специальный Source Hierarchy. Работает примерно так: разворачиваешь новый SCCM 2012 site, настраиваешь соединение с существующим 2007-сайтом, и мастер переносит Collections, Packages, Advertisments (они конвертируются в Deployments), Software Update Groups.

На бумаге - просто. На практике:

• Пакеты без source files. Если за пять лет кто-то переименовал или перенёс папки дистрибутивов, пакет переносится, но ссылается в никуда. Перед миграцией пришлось час провести в SCCM 2007, выясняя, что ещё живёт, а что - артефакт давно умершего проекта.
• Коллекции с ручными memberships. Часть коллекций в 2007 была с прямыми включениями без WQL-запросов. При переносе они переносятся как есть, но логика «почему именно эти машины» теряется. Потратили время на документирование до начала миграции.
• Database side-by-side. Обе системы работают параллельно в период перехода - клиент на 2007, новый сайт растёт на 2012. Клиенты (SCCM Client) нужно перенастроить на новый Management Point. Делать это одновременно на всём парке - плохая идея: нужна пошаговая миграция по площадкам или по коллекциям.
• Software Updates - отдельная история. SUG'и переносятся, но Deployment Packages - нет автоматически. Точнее, переносятся метаданные, а сами файлы обновлений нужно либо скачать заново, либо перенести вручную в новый Distribution Point. У клиента с узким каналом на удалённых точках это критично планировать заранее.

Как мы строим план

Грубая последовательность, которую используем:

1. Инвентаризация того, что реально используется в SCCM 2007 - пакеты, коллекции, отчёты. Мёртвые артефакты не переносить.
2. Проектирование новой ролевой модели в 2012 до начала переноса - кто какую роль получает, какие Security Scope нужны.
3. Установка SCCM 2012 site, настройка Source Hierarchy, пробный прогон Migration Wizard на тестовых объектах.
4. Перенос Distribution Point'ов площадка за площадкой - сначала лаборатория, потом менее критичные площадки, потом центральный офис.
5. Постепенная миграция SCCM Client'ов через Group Policy - меняем параметры site assignment.
6. Период двойного управления - месяц-полтора обе системы работают параллельно.
7. Деактивация 2007.

Где мы сейчас

Первый клиент - в середине шага 4. Три площадки перенесены, клиенты там уже отчитываются в SCCM 2012. Software Update Groups синхронизировались нормально. Проблема вылезла на одном Distribution Point с нестандартным расположением контента - решали через переиндексацию.

Ролевая модель уже настроена, и первая же проверка с операторами helpdesk показала: то, что в 2007 занимало полдня согласований прав, в 2012 решается за двадцать минут. Это реальный эффект, не рекламный.

В рамках управляемой поддержки ведём эту миграцию как отдельный проект с недельными checkpoint'ами. Следующий пост напишем, когда закончим - или раньше, если что-то сломается интересным образом.

Кстати, MDM через SCCM 2012 мы уже смотрели раньше: в посте про выбор MDM-платформы объясняли, почему для полноценного управления iOS и Android он не дотягивает. Но для Windows Phone и корпоративных ноутбуков в связке с ConfigMgr это уже другой разговор.