Методичка по Windows 7 Unattended Setup

[Иван Левшин aka Ivan L.]

Здравствуйте, коллеги

Предлагаю для ознакомления документ, описывающий методику практически полностью автоматической процедуры разворачивания Windows 7 с помощью ZCM Native Imaging. Автоматизация доведена почти до предела: в процессе разворачивания необходимо 1 раз ввести имя машины (это можно авторизовать) и 2 раза нажать на Enter при активации копии ОС на локальном сервере KMS. Кроме этого, подробно описана методика созда1ния эталонного базового образа, создания и использования Add-On Image, особенности формирования локального репозитория драйверов и т.д.

Методика опробована на тестовом стенде: среднее время разворачивания машины составляет 35-40 минут.

Установка bundle и прочее - не описано, т.е. речь исключительно о получении рабочей машины с ОС Windows 7, ее активации и установке ZENworks Adaptive Agent (ну и плюс добавление в домен - я работал с Domain Services for Windows, для Active Directory должно быть то же самое).

За любые замечания и комментарии буду благодарен.

P.S. Как прикрепить файл-то?

[Иван Левшин aka Ivan L.]

Коллеги,

Никому не интересно или нет вопросов? Я бы хотел получить замечания и комментарии, это сильно поможет сделать документ лучше. На авторские права не претендую, можете использовать по своему разумению.

[Ковалев Артем]

Иван, если честно, разливка образов у зена - не самая удачная его часть и (я так подозреваю) не самая востребованная. Поэтому, вряд ли кто пользуется.
А так, написано хорошо, понятно.

[Иван Левшин aka Ivan L.]

Артем, данная позиция ошибочна. Это классический довод, используемый в спорах о том, что лучше - обычно мне его приводят в качестве иллюстрации того, почему WIM лучше. На самом деле это реальная возможность разделить статическую и динамическую части образа. Экономия на размере, удобство администрирования (в процессе создания документа убедился лично - скрипты заработали совсем не сразу, вместо пересоздания всего образа целиком размером в 6 Гб надо было просто поменять ZMG размером в 150 Кб. Отличный пример, как мне кажется). Именно из-за этого считаю эту технологию в высшей степени удачной и удобной. У одного из заказчиков на ZEN7 так было построено вообще все управление тиражированием и админы были очень довольны (в крупной сети - это ТНК на несколько континентов). Сейчас они на SCCM и воют от тоски и досады.

Основное же, что меня интересует - именно восприятие идеи в документе, все ли мне удалось передать и сделал ли я это верно. Если все понятно - хорошо.

[Ковалев Артем]

По существу спорить не буду, хотя по мне по сравнению с usb-диском или ghost-server зеновский разлив имаджей тормозной.

Документ понятен, но я его только читал, не пробовал. Возможно, при использовании что-то непонятное и вылезет.

[Иван Левшин aka Ivan L.]

Решение не претендует на то, чтобы быть некой абсолютной панацеей на все случаи жизни. Понятно, что существуют ситуации, когда собирать образ из кучи аддонов невыгодно - например, при массовой заливке образов в заводских условиях и наличии большого числа объемных аддонов. Я рассматривал типовую задачу тиражирования при следующих вводных: минимизация места под хранение образа на сервере (традиционная проблема любой корпоративной инфраструктуры: "много места на файловом сервере не бывает"), максимальное удобство внесения изменений при минимальном воздействии на готовый образ. В таких условиях ZCM с аддонами выигрывает с огромной форой. Никакой особой "тормознутости" я не заметил, аддон размером в 150 Кб требует для "доразлития" максимум 40-50 секунд, основная часть этого времени тратится на повторный запуск оболочки img.

К слову сказать, Вы не сможете поставить тот же зен-агент в образ Ghost или WIM - и ZAA не является "несчастливым исключением", таких приложений масса (когда их нельзя ставить в образе и неудобно/невозможно "накатить" потом с помощью бандла). Приведенное решение демонстрирует, как можно решить и эту задачу в т.ч. Ну т.е. основная логика: есть статичный образ Win7 c обновами (не знаю, как у Вас - у меня Windows Update накатывает обновления больше суток, что нереально бесит) и есть куча динамического контента, которой можно и хотелось бы сразу "накатывать" на машину. Результат: минимальными усилиями достигается максимальный эффект. Решение можно еще и развить: если наделать аддонов "на все случаи жизни" (что реально совсем несложно, не сложнее работы с архиватором) и грамотно прописать правила применения того или иного Preboot Bundle, можно гибко компоновать один и тот же статический образ с разными аддонами автоматически. Классическое тиражирование в таких случаях требует нескольких разных образов, что означает:
- перерасход места под хранение образов;
- повышенные трудозатраты на тиражирование;
- повышенную трудность управления всем этим хозяйством.

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

Так что "на вкус и цвет все фломастеры - разные" (с) Все зависит от того, какие задачи решаются. Если мы говорим о Small Business с сервисами в облаке и 5-10 машинами в офисе с типовым набором софта - приведенный подход явно избыточен. Он оправдан для средних и реально крупных структур - от 50 машин и далее. В случае, если парк при этом представляет из себя реальный "зоопарк архитектур" (а я пока не видел ни одного крупного предприятия, все рабочие места которого были бы унифицированы по железу на 100%) - это реальное избавление от головной боли. Прикиньте сами, что проще: при условии, что у нас, допустим, 5-6 поколений машин (что реально довольно мало, чаще всего разброс куда сильнее), при этом есть и 32-бита, и 64 - сколько нам потребуется "Ghost-образов на USB"? В случае с ZCM достаточно ДВУХ базовых образов (32 и 64) и набора аддонов, из которых можно буквально за полчаса налепить на коленке до 10 Preboot Bundle. И по месту на серверах, и по трудозатратам выигрыш очевиден. Удобство управления инфраструктурой Imaging я даже сравнивать не берусь - классика проигрывает со свистом.

[Ковалев Артем]

Иван, ну от вас никак не ожидал.
Вполне себе стоит зен агент в образе. После заливки - zac reg, zag cc, zag ref. И всё.

[Иван Левшин aka Ivan L.]

Артем, не ожидали чего именно? "Зен в образе" означает zac unr|zac fsg -d перед снятием образа. Об этом, вроде бы, "все знают". Однако - чаще всего не помнят В моей практике полно случаев такого тиражирования и расхлебывания того, что начинается потом.

И потом - ZAA далеко не единственное ПО, которое не получится (ну хорошо - просто так не получится) установить в образ. И потом - с ZAA ладно, его централизованно довольно просто обновить. Однако что делать, если вышла новая версия ПО, установленного в образ, и именно его надо разворачивать? Предлагаемый Вами вариант предписывает либо пересобирать образ (ничего сложного, но сжирает время), либо изобретать иные пути (бандлы или что-то еще). В случае с аддоном Вы просто меняете инсталлятор в аддоне и все. Даже правила менять не надо

Забыл еще об одном, на мой взгляд весьма важном, аспекте - чем больше степень автоматизации, тем меньше влияние "человеческого фактора". Это машина может миллион раз выполнить запрограммированную операцию и не допустить ни одной ошибки (давайте просто забудем о естественном износе и прочем - предположим, что машина идеальна, не изнашивается и не ломается). Любой человек при повторении одной и той же операции рано или поздно допускает ошибки. Именно потому, что психологически устает, да и просто перестает контролировать действия ("ну а что тут думать-то, все давно и хорошо известно").

[Сергей Дубовский]

Замечена опечатка:
путь к базе драйверов
HKLM\Software\Microsoft\CurrentVersion\DevicePath

между Microsoft и CurrentVersion забыто Windows

[Иван Левшин aka Ivan L.]

Точно. Спасибо, поправлю.