Автоматическое развертывание рабочих мест начинается с эталона

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

Эти слои нельзя смешивать без причины. Если положить в образ все драйверы, сертификаты, агент управления с уже созданной идентичностью и настройки конкретного подразделения, первый тираж может пройти быстро. Следующее обновление превратится в разбор зависимостей, а две машины начнут спорить за одну запись в консоли управления. Я видел такие тиражи: время, сэкономленное на подготовке, потом тратится у стола каждого пользователя.

Ниже речь идет о Windows 11 и классическом развертывании из WIM-образа. Тот же принцип работает с Microsoft Configuration Manager и другими системами управления: эталон хранит только общее, задача развертывания выбирает переменное, а проверка доказывает результат.

Одинаковое рабочее место состоит из трех разных вещей

Эталонный образ должен содержать только то, что действительно одинаково для всей партии. Обычно это редакция и сборка Windows, языковые компоненты, системные обновления, приложения для всех компьютеров и базовые настройки операционной системы. Имя компьютера, членство в домене, сертификат устройства, инвентарный номер и профиль конкретного пользователя появляются позже.

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

Не стремитесь получить буквально одинаковые диски. Рабочие места должны иметь одинаковое управляемое состояние, но разные идентификаторы. У каждой машины нужны собственные SID, имя, ключи защиты, запись в каталоге и идентичность агента управления. Microsoft прямо требует запускать Sysprep с параметром /generalize перед переносом полного образа Windows на другой компьютер, даже если аппаратная конфигурация совпадает.

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

Инвентаризация до сборки экономит повторный тираж

Сначала разделите сто компьютеров на аппаратные семейства, даже если поставщик называет их одной серией. Одинаковая надпись на корпусе не гарантирует одинаковый контроллер накопителя, сетевой адаптер или ревизию системной платы. Снимите точную модель, версию BIOS или UEFI, аппаратные идентификаторы устройств и режим контроллера диска хотя бы с одного экземпляра каждой партии поставки.

Для работающего образца базовую информацию можно собрать штатными командами PowerShell:

Get-CimInstance Win32_ComputerSystem | Select-Object Manufacturer,Model
Get-CimInstance Win32_BIOS | Select-Object SMBIOSBIOSVersion,ReleaseDate
Get-PnpDevice -PresentOnly | Select-Object Class,FriendlyName,InstanceId,Status

Результат сохраните рядом с пакетом драйверов и датой его проверки. Название папки Model-A мало что сообщает через полгода; имя вроде L200_rev2_W11_24H2_2026-07 связывает модель, ревизию, выпуск ОС и момент испытания. Дату в примере нужно заменить фактической датой вашей проверки.

Одновременно проверьте условия, которые образ не исправит: совместимость процессора с выбранным выпуском Windows, UEFI, возможность Secure Boot, TPM 2.0, объем памяти и диска. Microsoft перечисляет UEFI с поддержкой Secure Boot и TPM 2.0 среди требований Windows 11. Обход этих проверок ради быстрого запуска создает неподдерживаемый парк, который неожиданно упирается в обновление или политику безопасности.

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

На этом же этапе определите канал доставки. Для стабильной локальной сети подойдет PXE с собственным WinPE и репозиторием образов. Для филиала с узким каналом разумнее подготовить проверенный USB-носитель или локальную точку распространения. Скорость копирования одного WIM не должна определять архитектуру, но она определяет размер параллельной партии и время окна работ.

Эталон собирают в чистой и воспроизводимой среде

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

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

Режим аудита существует именно для настройки Windows до показа OOBE конечному пользователю. В него можно перейти сочетанием Ctrl+Shift+F3 на первом экране OOBE или через файл ответов. Не создавайте обычного рабочего пользователя ради украшения профиля. Для переноса настроек профиля Microsoft поддерживает параметр Microsoft-Windows-Shell-Setup\CopyProfile в Unattend.xml, переданном Sysprep; ручное копирование каталога профиля переносит лишние ссылки, кэш и разрешения.

Я не советую запекать в образ антивирусный или управляющий агент после его регистрации на сервере. У многих агентов есть собственный GUID, сертификат или токен. Клонированная идентичность приводит к тому, что консоль показывает одну прыгающую машину вместо ста. Если производитель агента документирует подготовку к клонированию, выполните именно ее. Если такой процедуры нет, устанавливайте или регистрируйте агент после specialize, когда компьютер уже получил уникальное имя.

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

В конце повторите сборку с нуля по записанному сценарию. Если второй эталон отличается от первого и вы не можете объяснить почему, автоматизировать тираж рано. Храните сценарии установки приложений и контрольные суммы исходных пакетов рядом с описанием версии образа. WIM можно переснять, а историю решений восстановить значительно труднее.

Unattend.xml заменяет ручные ответы, а не архитектуру

Файл ответов автоматизирует решения Windows Setup: разметку диска, выбор выпуска, язык, проход OOBE и команды на определенных этапах. Microsoft описывает семь проходов конфигурации, среди них windowsPE, offlineServicing, generalize, specialize и oobeSystem. Параметр с правильным значением, но в неправильном проходе, либо будет проигнорирован, либо сработает не тогда, когда вы рассчитывали.

Создавайте Unattend.xml в Windows System Image Manager для той версии образа, которую развертываете, и проверяйте его там же. Ручное редактирование допустимо при ревью, но валидатор ловит отсутствующий компонент и неподходящий проход раньше, чем сотый компьютер остановится на OOBE. Не храните в XML пароль доменного администратора. Присоединение к каталогу лучше выполнять учетной записью с узкими правами, одноразовым механизмом или системой управления после установки.

Минимальный фрагмент для русской локали и часового пояса Казахстана может выглядеть так; архитектуру компонента и значения локали сверяйте с вашим выпуском:

<settings pass="specialize">
  <component name="Microsoft-Windows-Shell-Setup"
             processorArchitecture="amd64"
             publicKeyToken="31bf3856ad364e35"
             language="neutral" versionScope="nonSxS">
    <TimeZone>Central Asia Standard Time</TimeZone>
  </component>
</settings>
<settings pass="oobeSystem">
  <component name="Microsoft-Windows-International-Core"
             processorArchitecture="amd64"
             publicKeyToken="31bf3856ad364e35"
             language="neutral" versionScope="nonSxS">
    <InputLocale>ru-RU</InputLocale>
    <SystemLocale>ru-RU</SystemLocale>
    <UILanguage>ru-RU</UILanguage>
    <UserLocale>ru-RU</UserLocale>
  </component>
</settings>

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

Команды первого запуска делите по контексту. То, что меняет компьютер, должно выполняться от системы и писать отдельный журнал. Пользовательские настройки применяйте политикой при входе пользователя. Длинная цепочка FirstLogonCommands ненадежна: интерактивный вход, сеть и перезагрузки начинают зависеть друг от друга. Для каждого шага задайте код возврата, допустимую повторную попытку и понятный признак завершения.

Sysprep и DISM дают переносимый WIM

Обобщать нужно финальную, выключаемую копию эталона. Запустите проверку обновлений, убедитесь, что установщики не ожидают перезагрузку, остановите собственный сборочный сценарий и выполните:

%WINDIR%\System32\Sysprep\Sysprep.exe /generalize /oobe /shutdown /unattend:C:\Windows\Panther\Unattend.xml

Параметр /generalize удаляет уникальные для установки сведения и готовит следующий запуск к проходу specialize. /oobe задает состояние следующей загрузки, /shutdown не дает эталону случайно загрузиться снова перед захватом. Если Sysprep завершился ошибкой, не клонируйте машину «как есть». Смотрите %WINDIR%\System32\Sysprep\Panther\setupact.log и setuperr.log, исправляйте пакет или незавершенное обслуживание и повторяйте на чистом состоянии.

После выключения загрузите эталон в WinPE. Не запускайте установленную Windows еще раз: следующий старт уже расходует подготовленное состояние и меняет систему. В WinPE буквы разделов могут отличаться, поэтому сначала найдите том Windows через diskpart, dir или сценарий, который проверяет наличие каталога Windows\System32.

Один воспроизводимый цикл захвата и применения выглядит так:

1. Подключите сетевой ресурс или внешний диск, на котором достаточно места для WIM и журнала.
2. Захватите системный раздел командой dism /Capture-Image /ImageFile:D:\Images\Office-2026-07.wim /CaptureDir:C:\ /Name:"Office base" /Compress:Max /CheckIntegrity /Verify.
3. На тестовой машине очистите диск, создайте GPT-разделы EFI, MSR и Windows, затем отформатируйте их сценарием DiskPart, который хранится в системе контроля версий.
4. Примените образ: dism /Apply-Image /ImageFile:D:\Images\Office-2026-07.wim /Index:1 /ApplyDir:W:\ /CheckIntegrity /Verify.
5. Создайте загрузочные файлы: W:\Windows\System32\bcdboot W:\Windows /s S: /f UEFI, отключите носитель и перезагрузите компьютер.

DISM в документации Microsoft определяет /Capture-Image как захват каталога со всеми подкаталогами в WIM, а /Apply-Image как применение выбранного индекса. Параметры /CheckIntegrity и /Verify стоят времени, но для эталона это разумная плата: поврежденный файл лучше обнаружить до начала партии. После захвата вычислите SHA-256 WIM командой Get-FileHash, сохраните хэш в паспорте релиза и проверяйте его после копирования на точки распространения.

Не называйте файл просто gold.wim. В имени и паспорте укажите выпуск Windows, назначение, ревизию и дату утверждения. Сам файл сделайте неизменяемым артефактом: исправление означает новую версию, а не тихую замену содержимого под старым именем. Это оставляет возможность закончить начатую партию прежним образом и отдельно испытать новый.

Драйверы выбирают по модели, а не складывают в общий мешок

В базовый образ не нужно добавлять все найденные драйверы. Windows уже содержит большой набор встроенных пакетов, а лишние OEM-пакеты увеличивают WIM, время обслуживания и число вариантов при выборе Plug and Play. Особенно опасны несколько версий драйверов накопителя, сетевых фильтров и графики без понятной причины их присутствия.

Создайте отдельный подписанный пакет для каждого аппаратного семейства. В WinPE нужны только драйверы, без которых среда не видит накопитель или сеть. Остальные пакеты можно добавить в примененный офлайн-образ до первой загрузки:

dism /Image:W:\ /Add-Driver /Driver:D:\Drivers\L200_rev2 /Recurse
dism /Image:W:\ /Get-Drivers /Format:Table

Microsoft предупреждает, что /Recurse легко раздувает образ: каждый INF разворачивается как отдельный пакет, иногда с повторяющимися файлами. Поэтому рекурсия допустима внутри проверенной папки одной модели, но не в корне общего архива драйверов. Параметр /ForceUnsigned не должен быть штатным решением. Неподписанный драйвер требует отдельного обоснования и теста совместимости с политиками Secure Boot.

Если на эталонной машине уже стоит подтвержденный пакет производителя, выгрузите сторонние драйверы командой pnputil /export-driver * D:\DriverExport, затем разберите результат по INF и аппаратным ID. Не считайте экспорт готовым пакетом автоматически: там могут оказаться старые версии и драйверы подключавшейся периферии. Для реестра пакета сохраните поставщика, версию, дату, поддерживаемые ID и источник установщика.

Модель можно определить в полном Windows через Get-CimInstance Win32_ComputerSystem. В системе развертывания сопоставьте нормализованную строку модели с одной папкой. Не используйте условие «если название содержит 200», когда существуют L200 и M200 с разными устройствами. Неизвестная модель должна останавливать автоматизацию с ясной ошибкой, а не получать ближайший похожий набор.

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

Канал доставки не должен возвращать ручной труд

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

Для сети используйте собственный WinPE, который загружается по PXE, получает сценарий, находит модель, очищает только выбранный системный диск, применяет WIM и пакет драйверов, затем пишет статус на сервер. Важно не путать PXE и старый сквозной сценарий WDS. Документация Microsoft указывает, что для Windows 11 развертывание через WDS с boot.wim из установочного носителя и запуском Setup в режиме WDS не поддерживается. Сам PXE в WDS остается пригоден для загрузки собственного boot image, в том числе для Configuration Manager или другого решения.

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

Рассчитайте параллелизм на пилоте. Сто машин, одновременно читающих многогигабайтный WIM с одной сетевой папки, могут превратить десятиминутное применение в длинную очередь. Ограничьте число одновременных сессий, распределите содержимое по локальным точкам или используйте многоадресную передачу, если выбранная система ее поддерживает. Не обещайте время тиража по скорости одной машины на пустой сети.

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

Пилот проверяет модель, партия проверяет процесс

Одна успешно загруженная машина доказывает только то, что WIM применился на одном экземпляре. Сначала разверните по одному компьютеру каждой аппаратной ревизии, затем небольшую партию одновременно и только после этого запускайте основной тираж. Так вы отдельно видите дефект совместимости и ограничение сети или сервера.

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

$result = [ordered]@{
  ComputerName  = $env:COMPUTERNAME
  Model         = (Get-CimInstance Win32_ComputerSystem).Model
  WindowsBuild  = [Environment]::OSVersion.Version.Build
  PendingReboot = Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'
  ProblemDevices = @(
    Get-PnpDevice -PresentOnly |
      Where-Object Status -ne 'OK' |
      Select-Object Class,FriendlyName,InstanceId,Status
  )
}
$result | ConvertTo-Json -Depth 4

У исправного компьютера ProblemDevices обычно возвращается как пустой массив, а PendingReboot должен быть false перед выдачей. Номер сборки и модель сравнивайте с разрешенными значениями в паспорте, а не просто записывайте. Добавьте отдельные тесты, которые важны вашей роли: наличие агента управления с уникальным ID, состояние шифрования, получение политик, запуск делового приложения, доступ к нужной сети и печать на тестовое устройство.

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

При ошибке собирайте доказательства до повторной установки. Для Windows Setup основные действия лежат в %WINDIR%\Panther\setupact.log, ошибки в setuperr.log, установка Plug and Play в %WINDIR%\INF\setupapi.dev.log, а журналы Sysprep находятся в %WINDIR%\System32\Sysprep\Panther. Если сразу стереть диск и попробовать еще раз, вы получите работающую машину, но не узнаете, повторится ли сбой на следующих двадцати.

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

Выдача пользователю завершает развертывание, но не жизнь образа

Перед передачей устройству нужны уникальное имя, запись в инвентаре, корректная активация, примененные политики, нужные приложения роли и подтвержденное шифрование. Не считайте экран входа доказательством готовности. Сформируйте для каждого серийного номера запись о версии WIM, пакете драйверов, результате тестов и сотруднике, который принял машину.

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

Откат тоже проектируют до массового запуска. Храните предыдущий утвержденный WIM, его Unattend.xml, пакеты драйверов и паспорт. Возможность вернуть старую версию не означает, что можно смешивать ее с новыми драйверами без теста. Релизная единица включает весь согласованный набор, а не только файл образа.

Если парк закупается и внедряется как единый проект, согласуйте аппаратные ревизии и способ развертывания еще в спецификации. GSE выпускает в Казахстане настольные ПК L200, моноблоки M200 и серверы S200, а также выполняет системную интеграцию и поддержку, поэтому модельные пакеты драйверов и приемочные критерии можно связать с поставкой, а не восстанавливать после разгрузки оборудования.

Сотая машина должна устанавливаться тем же путем, что первая пилотная, с теми же хэшами и тем же протоколом проверки. Если к середине партии администратор уже держит список исключений в блокноте, остановите тираж и верните исключения в сценарий. Иначе вы выдадите сто похожих компьютеров, но не получите один управляемый парк.