SCCM 2012 R2: OSD Task Sequence и как мы перестали тратить три часа на новое рабочее место

После того как мы отработали поточную миграцию с XP на Windows 7 через WDS и MDT, один из клиентов поставил вопрос прямо: а можно сделать так, чтобы новое рабочее место вводилось в строй вообще без инженера? Не «меньше телодвижений», а «нажал кнопку и ушёл». Мы взялись за SCCM 2012 R2.

До этого использовали WDS с MDT - схема рабочая, но всё равно требующая присутствия: выбрать task sequence вручную, потом подтвердить ввод в домен, потом руками поставить несколько приложений под конкретную роль. В итоге вся процедура занимала около трёх часов, из которых инженер реально что-то делал суммарно минут сорок - остальное ждал. Это раздражает.

SCCM 2012 R2 вышел в октябре прошлого года. На клиентской инфраструктуре у нас уже был SCCM 2012 SP1 для патч-менеджмента - апгрейд до R2 дал нормальный OSD без костылей.

Что такое OSD Task Sequence в SCCM

OSD (Operating System Deployment) - это конвейер шагов, которые SCCM выполняет последовательно при развёртывании машины. Внешне напоминает MDT Task Sequence, но интеграция с SCCM даёт куда больше: приложения тянутся из одного каталога, политики применяются через AD, отчётность видна в той же консоли что и Software Updates.

Наш Task Sequence в итоге выглядит примерно так:

1. Форматирование и разбивка диска. UEFI-машины идут с GPT, старые BIOS - с MBR. Условие через WMI-запрос к прошивке, добавляется в одно условие на шаге.
2. Применение образа Windows 7 x64. WIM-файл лежит на Distribution Point - SCCM сам разберётся с ближайшей точкой.
3. Windows Setup and Configuration. Sysprep-ответный файл с настройками языка, часового пояса, имени компьютера. Имя - из переменной, которую задаём при запуске через PXE-меню или штрихкодом с наклейки.
4. Применение драйверов через Driver Package. Отдельные пакеты под HP EliteBook, HP ProDesk и Dell OptiPlex - SCCM подтягивает нужный по моделям из WMI.
5. Ввод в домен. Автоматически, через встроенный шаг Join Domain or Workgroup.
6. Установка обязательных приложений. Отдельный шаг Install Application - сюда идут антивирус, офисный пакет, корпоративный браузер, агент мониторинга. Всё из SCCM Application Catalog.
7. Установка роль-специфичного ПО. Здесь - коллекции. Если машина по имени попадает в коллекцию «Бухгалтерия», SCCM доставит нужный набор. Логика через переменную, которую ставим при старте деплоя.
8. Windows Update через SCCM Software Updates. Машина получает обязательные обновления прямо в Task Sequence, до первого входа пользователя. Это важно: не хочется вводить машину в продакшн с незакрытыми дырками.
9. Финальная перезагрузка и уведомление.

Весь конвейер на новой машине занимает от сорока до пятидесяти минут. Инженер запускает деплой через PXE, задаёт имя машины и роль в меню - и всё. Дальше SCCM работает сам.

Про патч-менеджмент в SCCM vs WSUS

Раньше Software Updates в SCCM мы не трогали - справлялись с отдельным WSUS, процесс был отлаженный. Но раз уж SCCM стоит - грех не перенести. Плюс один: всё в одной консоли, отчётность по патчам в том же месте, где отчётность по инвентарю и деплою.

Минус один: настройка Software Update Point в SCCM - это несколько часов в первый раз. Нужно синхронизировать SUP с Microsoft Update, настроить Deployment Packages, разобраться с Automatic Deployment Rules (ADR). ADR - это то, что позволяет не одобрять каждый патч руками: правило само находит новые Critical и Security патчи, добавляет в Deployment Package и рассылает по коллекциям по расписанию. По факту - тот же Patch Tuesday автоматом, без ручного Approve в WSUS.

Тестовую коллекцию мы оставили: ADR сначала катит на Test Computers, через три дня - на Pilot, ещё через пять - на All Workstations. Логика та же что с WSUS, просто всё в одном инструменте.

Где споткнулись

Первое - распределение контента. SCCM копирует WIM-образы и пакеты приложений на Distribution Points. Когда добавляешь новый DP или меняешь пакет - нужно не забыть обновить Distribution. Несколько раз Task Sequence падал с ошибкой «content not found», потому что приложение обновилось, а DP не получил новую версию. Теперь проверяем Monitoring - Content Status перед каждым массовым деплоем.

Второе - UEFI и Secure Boot. Несколько новых машин от HP шли с включённым Secure Boot. Windows 7 с этим конфликтует, пришлось добавить шаг в начало Task Sequence, который проверяет наличие Secure Boot через WMI и, если включён - выводит сообщение с инструкцией для инженера. Автоматически выключить не стали - трогать настройки BIOS/UEFI скриптом без явного согласования не хочется.

Третье - имена машин при массовом вводе. Если деплоим пять машин подряд, каждый раз вводить имя в PXE-меню неудобно. Нашли решение через Computer Association: заранее импортируем таблицу MAC-адрес - имя машины в SCCM, и Task Sequence сам берёт нужное имя. Это делается через импорт CSV в консоли, несложно, но нужно знать MAC заранее.

Что по факту получается

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

Три часа против сорока минут - это не только время. Это значит, что инженер может параллельно делать что-то другое, пока машина деплоится. Или что замену вышедшего из строя рабочего места можно организовать без планирования на день вперёд.

Патч-менеджмент через SCCM пока обкатываем: первый полный Patch Tuesday прогнали на прошлой неделе, без происшествий. Managed-сопровождение в данном случае означает что мы и за деплоем, и за патчами следим из одной консоли - что удобно, когда инфраструктура клиента растёт.

Следующий шаг - автоматическое ребро в нулевое состояние для машин после увольнения сотрудника. Task Sequence для «чистого листа» уже набросан, но в продакшн пока не пустили: нужен дополнительный уровень подтверждения, чтобы случайно не снести рабочую машину.