System Center Configuration Manager и как с ним бороться

SCCM, Intune, MDT, EMS, MDM, MAM, Azure AD и другие странные слова

Главная
Обо мне
Блоги
Скачать продукты
Блоги на русском языке
Видеоуроки
Видеоуроки на русском языке
Доклады на русском языке
Доклады
Документация
Инструкции по настройке
Книги
Курсы
Лабораторные работы
Платные партнёрские разработки
Утилиты
Утилиты Microsoft
Экзамены

Posts tagged ‘MDT 2013’

Подготовка образа Windows Thin PC и установка при помощи VMware Mirage (часть I)

Одним из способов организации доступа к VDI инфраструктуре является переделывание имеющихся в организации ПК в тонкие клиенты. Среди вариантов присутствуют как коммерческие решения, вроде Dell Wyse PC Extender или Igel Universal Desktop Converter, так и открытые/бесплатные решения, например, Thinstation. Все они строятся на базе ОС Linux с дополнительным ПО, позволяющим создавать и модифицировать образ ОС, а также централизованно управлять, обновлять тонкие клиенты. Но еще одним интересным вариантом является Microsoft Windows Thin PC.

Thin PC строится на базе ОС Microsoft Windows Embedded Standard 7 (Microsoft Windows Thin PC). Данная ОС доступна для загрузки корпоративным пользователям, оформившим подписку Microsoft VDA (что обязательно в тех случаях, когда вы планируете запускать в VDI клиентские ОС Windows).

Thin PC может устанавливаться на любой Intel x86 совместимый компьютер, удовлетворяющий следующим аппаратным требованиям:

1 GHz or faster 32-bit (x86);
1 GB RAM, 16 GB available hard disk space;
DirectX 9 graphics device with WDDM 1.0 or later version driver.

Поскольку в основе Thin PC лежит Windows, то это значит, что тонкие клиенты с данной ОС имеют полный набор функциональных возможностей, которые может предоставить то или иное VDI решение (проброс USB устройств, принтеров, сканеров, Multimedia redirection, Flash redirection, URL redirection, аппаратное декодирование видео, однакратный вход в систему, аутентификация по смарт-картам и т.д.).

Поскольку для распространения Thin PC планируется использовать VMware Mirage, то нам потребуется эталонный компьютер, на которой можно будет установить Thin PC, выполнить ряд настроек, оптимизирующих работу ОС, установить дополнительные компоненты, вроде, клиента VMware Horizon Client и Mirage Client. Ряд настроек я рекомендую выполнить заранее, например, добавить в дистрибутив Thin PC необходимые обновления ОС и драйверы, и только после этого установить его на эталонный компьютер.

Предварительные шаги

Для начала требуется подготовить дистрибутив Thin PC к установке.

Подготовка дистрибутива включает в себя следующие шаги:

Интеграция драйверов устройств в дистрибутив.
Интеграция пакетов обновлений ОС в дистрибутив.
Интеграция установочных пакетов приложений в дистрибутив.
Модификация установочного скрипта ОС.
Модификация файла ответов ОС.
Сборка дистрибутива.

Для подготовки дистрибутива тонкого клиента следует использовать рабочую станцию с установленной ОС Microsoft Windows 7 с установленным пакетом Microsoft Windows Automated Installation Kit 7 (WAIK 7).

Загрузите дистрибутив Windows ThinPC. Также рекомендую загрузить пакет Windows Embedded Standard 7 Service Pack 1 Toolkit с сайта https://www.microsoft.com/en-us/download/details.aspx?id=11887 (по ссылке можно загрузить Evaluation версию Windows Embedded, сам Toolkit находится в архиве, разбитом на 8 частей), содержащего огромное количество драйверов и дополнительных пакетов, которые могут пригодиться при подготовке образа.

При желании, вы также можете загрузить языковой пакет для различных языков по ссылке: https://www.microsoft.com/en-us/download/details.aspx?id=26215

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

C:ThinPC
C:ThinPCDrivers
C:ThinPCImage
C:ThinPCISO
C:ThinPCMount
C:ThinPCUpdates

После получения дистрибутива Thin PC в формате ISO распакуйте его содержимое в каталог “C:ThinPCImage” на рабочей станции.

OSD SCCM: способы задания имени компьютера

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

Пожалуй, самой частой упоминаемой из них является желание в явном виде указать те или иные параметры перед началом установки ОС. Чаще всего таким параметром является имя компьютера. Действительно, пользователям трудно объяснить, почему их компьютер называется MININT-KGKGUBG, а не COMP-V-PUPKIN. Либо на предприятии существует политика, которая предписывает именовать все компьютеры, опираясь на их роль и территориальную принадлежность, например W-MSK-000129.

Вариант I – Computer Association

Одним из способов решения данной проблемы является заведение записи компьютера в базе SCCM. В этом нам поможет механизм Computer Association, смысл которого заключается в ручном добавлении пары Имя компьютера – MAC адрес в базу данных SCCM.

Для того чтобы вручную добавить компьютер в базу данных SCCM необходимо перейти к пункту: Configuration Manager Console – Site Database – Computer Management – Operating System Deployment – Computer Association – Actions: Import Computer Information. В появившемся мастере доступны два способа добавления записей: Import computer using file (добавление группы компьютеров с помощью CSV файла) и Import single computer (добавление одиночного компьютера).

Для примера добавим одиночный компьютер с желаемым именем W-TST-0001 и MAC-адресом 00:E0:4C:62:02:B0. Если мы добавляем новый, ранее не известный SCCM компьютер, то поле SMSBIOS GUID можно не заполнять, оно будет заполнено автоматически.

Параметром Source computer мы можем указать уже существующую запись в базе данных SCCM, с которой будет ассоциирована новые данные (имя и MAC-адрес).

Далее указываем коллекцию в которую будет добавлена запись.

Теперь рассмотрим способ добавление группы компьютеров через файл.

Для начала необходимо сформировать сам файл.

Затем выбираем пункт: Import computer using a file. Указываем место нахождение файла, и соответствие столбцов файла и полей БД.

Но такой способ (Computer Association) приемлем, только если у вас малое количество компьютеров и при этом он требует значительных трудозатрат (предварительно необходимо собрать MAC-адреса компьютеров и внести их в базу). Если есть возможность – переложите эту «ношу» на поставщика вашей техники. Пусть вместе с бухгалтерскими документами, вам передается и заранее сформированный файл. Другим вариантом частичного решения проблемы будет экспорт данных из БД вашего DHCP сервера. Но по многим причинам он далек от оптимального:

необходимо чтобы компьютеры получили адрес от DHCP сервера;
выгрузку из DHCP необходимо вручную обработать и удалить записи известных компьютеров;
выгрузку из DHCP необходимо обработать и привести MAC адрес к виду XX:XX:XX:XX:XX.

Вариант II – Автоматическая генерация имени

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

N-DGDG3546

Для того чтобы воспользоваться данным методом, нам необходим скрипт, который мог бы обрабатывать переменные OSD (OSD variables). Мы можем написать такой скрипт с нуля самостоятельно, либо воспользоваться уже готовой обвязкой из скриптов LTI из набора MDT 2010. Для этого нам необходимо выполнить условия:

установить на сервере MDT 2010
интегрировать MDT 2010 в SCCM 2007
создать и использовать Microsoft Deployment Task Sequence

Думаю что процесс установки MDT не вызовет вопросов, поэтому его описание я опущу. А для того чтобы интегрировать MDT в SCCM необходимо запустить Start – All pograms – Microsoft Deployment Toolkit 2010 – Configure ConfigMgr Intergation и в появившемся мастере выбрать параметр Install the ConfigMgr extensions.

После этого возможно создание MDT Task Sequence в консоли SCCM. Для этого переходим в пункт OSD – Task Sequence – Create Microsoft Deployment Task Sequence.

Внимание! Рассматривается работа MDT 2010 и SCCM 2007 SP2. Настройки для других версий SCCM могут незначительно отличаться.

Выбираем шаблон для рабочих станций: Client Task Sequence.

Вводим название и комментарии.

Задаем настройки присоединения к домену. Необходимо ввести лицензионный ключ, причем установка XP SP3VistaWin7 в принципе его не требует, но в поле его вбить все равно необходимо.

Выбираем, будем ли мы снимать образ с данной установки или нет.

Указываем загрузочный образ. Если его у нас нет, мы можем создать (см. ниже).

Переходим к самому интересному – к созданию различных пакетов MDT. В частности именно этот пакет (MDT Binaries) содержит в себе файлы скриптов LTI.

Вводим служебные данные пакета.

Указываем WIM файл с операционной системой. Кроме того мы можем использовать вариант установки ОС через пакет (OS Install Package), либо тут же создать новый образпакет.

Указываем пакет с клиентом SCCM.

Указываем пакет с USMT, даже если мы не планируем использовать данное средство, как и в случае с лицензионным ключом, нам всеже придется создать пакет.

Данный пакет (MDT Settings) содержит файл unattend.iniunattend.xml и описывает параметры установки ОС.

Использовать или нет sysprep. Отмечать необходимо только если у нас в начале выбран вариант снятия образа (capture image).

Проверяем итоговую сводку настроек.

После создания пакетов, не забудте указать для них Distribution Point!

А теперь собственно, то ради чего мы создавали MDT Task Sequence. Открыв созданный TS, необходимо выкинуть «неинтересные» нам шаги (например USMT) и добавить шаг со скриптом. Добавлять шаг со скриптом необходимо перед шагом TS:

Общий смысл скрипта сводится к изменению значения переменной OSDCOMPUTERNAME на необходимое нам значение. Сделать это можно добавив например такой скрипт в TS перед шагом применения образа ОС.

Сам скрипт можно подожить в исходную папку пакета MDT Binaries (в моем случае это \sccm2007source$osdmdt_binariesscripts).

В итоге мы будем получать уже более-менее осмысленное имя компьютера.

Вариант III – MDT Boot Wizard Hook

Но и этот способ не оптимален. К счастью, в новой версии MDT была внедрена штатная поддержка хуков TS, что позволило нам запускать свой мастер, до старта мастера OSD. Следует сказать, что OSD SCCM предназначен для установки ОС с помощью метода Zero Touch Installation (ZTI) – т.е. полностью в автоматическом режиме. Работа данного метода лучше всего демонстрируется на примере Task Sequence на принудительную перезаливку компьютеров. Когда задание запускается не по сети (PXE) или с диска (CDDVD Boot Media), а из клиентской операционной системы, а затем производит ее переустановку. В MDT же применяется другой метод: Lite Touch Installation (LTI) – т.е. пользователь предварительно отвечает на некоторые вопросы некоего мастера, а затем установка происходит в автоматическом режиме. ZTI метод предназначен в первую очередь для массовой установкипереустановки, и дает меньшую свободу действий по сравнению с LTI (она есть, но основана на автоматическом выборе неких критериев, например: в зависимости от модели и производителя компьютера). LTI, напротив, дает большую свободу, но меньше приспособлен к массовому развертыванию. До выхода MDT 2010 LTI метод был не возможен в OSD SCCM, теперь при интеграции MDT 2010 и SCCM 2007 мы можем использовать и LTI установку. Для поддержки LTI нам необходимо, во-первых, использоваться загрузочный образ MDT, во-вторых, включить хук при создании этого образа.

Читать еще: Разбил жёсткий диск на два тома, на первый том установил Windows 7, а на второй том установил Windows 10, теперь по умолчанию первой загружается Windows 10. Как сделать, чтобы по умолчанию загружалась Windows 7

Чтобы создать MDT Boot Image необходимо в консоли администрирования SCCM перейти к разделу Operating Sustem Deployment – Boot Image – Create Boot Image Using Microsoft Deployment.

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

Вводим название загрузочного образа и другие информационные данные.

Самое интересное начинается на странице Image Options. Во-первых, нам необходимо выбрать архитектуру загрузочного образа (х86 или х64). Во-вторых, указать, что данный образ будет содержать в себе hook файл. Для этого отмечаем параметр Add media hook files to enable the Deployment Wizard for this boot media.

Параметр Custom background bitmap file мы можем указать использование в загрузочном образе собственных обоев. В принципе точно такого же результат можно добиться потом, указав данный параметр в свойствах образа в консоли администрирования SCCM. Параметр Extra directory to add указывает папки, содержимое которой будет скопировано в корень загрузочного диска. В эту папку полезно помещать программу trace32.exe, кроме того сюда же, а точнее в .DeployScripts необходимо добавлять свои скрипты и файлы, если вы планируете их использовать в при работе мастера.

Включение хука, в принципе, регулируется только наличием файла TS.ini в корне загрузочного образа. Загружаясь WinPE проверяет наличие данного файла и если находит его, то запускает указанный в нем скрипт. Это метод работал и при использовании MDT 2008, однако данный файл необходимо было включать в образ вручную.

Однако мало запустить скрип, необходимо создать мастер, который будет выполнятся по указанному нами сценарию. По умолчанию такой мастер уже существует, он называется MDT Boot Wizard и выполняет только одну функцию: запрос имени компьютера у пользователя. Как это происходит можно увидеть на видео в блоге Michael Niehaus. (http://blogs.technet.com/mniehaus/attachment/3284170.ashx).

Мастер представляет из себя xml-файла параметров, который взаимодействуя с готовой формой Wizard.hta и показывает заданные параметры пользователю. По умолчанию файл описания Deploy_SCCM_Definition_ENU.xml находится в папке %programfiles%Microsoft Deployment ToolkitSCCM

Внимание! В текущей версии MDT 2010 есть небольшая ошибка. В загрузочный образ MDT Boot Image включаются только заранее предопределенные файлы из папки %programfiles%Microsoft Deployment ToolkitSCCM. Например файл Deploy_SCCM_Definition_ENU.xml и Deploy_SCCM_Definition_ENU_my_custom.xml будут скопированы в образ. А файл Deploy_SCCM_MyCompany.xml нет. Точно так же будет и с файлами скриптов. Для добавления этих файлов в образ, необходимо воссоздать структуру каталогов Disk:DeploymentScripts и эту папку указывать при создании образа (Extra directory to add).

Алексей Тараненко

Установка Remote Server Administration Tools (RSAT) в Windows 10 v1903 в Offline-режиме

Ранее мы уже писали об особенностях установки пакета Remote Server Administration Tools (RSAT) в Windows 10. Но время идёт и новые релизы Windows 10 вносят новые правила работы с этим пакетом. В этой заметке мы поговорим об особенностях автономной установки RSAT в актуальной версии Windows 10 1903.

Графический интерфейс “Параметры Windows” и UAC

В рассматриваемой нами версии Windows 10 активацию компонент RSAT можно выполнить через графический интерфейс Windows, пройдя последовательно в Параметры Windows > Приложения > Дополнительные возможности > Добавить компонент

Однако, если с помощью этого графического интерфейса мы попытаемся выполнить добавление компонент на системе, подключенной к локальному серверу WSUS/SCCM SUP, то может получиться так, что мы даже не сможем получить перечень доступных к установке компонент.

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

Компоненты RSAT и PowerShell

В качестве альтернативного варианта получения списка опциональных компонент Windows можно использовать оболочку PowerShell, запущенную с правами администратора. Для получения компонент, относящихся к пакету RSAT можно выполнить команду:

Установку той или иной компоненты можно выполнить командой типа:

Feature On Demand и проблема Offline-клиентов

Теперь нам понятно, что графический интерфейс Windows 10 1903 работает с UAC криво, а в PowerShell всё в этом плане хорошо. Однако, безотносительно способа установки, в том случае, если компьютер настроен на использование WSUS/SUP и не имеет прямого доступа в интернет, при попытке установки выбранной компоненты мы можем получить ошибку 0x800f0954 .

И ошибка эта будет воспроизводиться как при использовании PowerShell, так и при использовании графического интерфейса. Правда, в графическом интерфейсе, опять же, это может быть не так очевидно.

Как я понял, связано это с тем, что для установки опциональных компонент требуется наличие доступа к комплекту пакетов установки Feature On Demand (FOD) для нашей “модной” версии Windows 1903. Именно в этот комплект включаются компоненты RSAT, начиная с обновления Windows 10 1809 от Октября 2018 года. Об этом, в частности, гласит примечание на странице загрузки Remote Server Administration Tools for Windows 10

Интересно то, что на этой же веб-странице имеется сноска о том, что пользователям, использующим WSUS/SUP, и получающим выше обозначенную ошибку 0x800f0954 , для возможности установки компонент RSAT придётся настраивать прямой доступ на Windows Update, либо использовать метод с сетевым каталогом.

Known issues affecting various RSAT versions:

Issue: RSAT FOD installation fails with error code 0x800f0954
Impact: RSAT FODs on Windows 10 1809 (October 2018 Update) in WSUS/SCCM environments
Resolution: To install FODs on a domain-joined PC which receives updates through WSUS or SCCM, you will need to change a Group Policy setting to enable downloading FODs directly from Windows Update or a local share.

И в этой ситуации администраторы используют разные пути. Некоторые идут по пути наименьшего сопротивления, не заморачиваясь при этом вопросами удобства и безопасности, и отключают на время установки RSAT нацеливание клиента на WSUS с последующей организацией прямого доступа к Windows Update.

На мой взгляд, этот метод “так себе”, так как далеко не всегда и не во всех ситуациях возможно, или даже временно допустимо, обеспечивать прямой доступ на внешние интернет-узлы. К тому же решение с временной правкой реестра и последующим перезапуском службы клиента Windows Update назвать удобным язык не повернётся. При этом ведь ещё нужно помнить про том, что нигде в групповых политиках не должно быть настроено явных запретов на до-загрузку контента Windows c Windows Update.

Feature On Demand и WSUS

А что же нам в этой ситуации может предложить наш локальный источник обновлений – WSUS? Если заглянуть в свойствах сервера WSUS в перечень продуктов, относящихся к Windows 10 (…интересно, в Microsoft сами ориентируются в этом списке?…), то мы увидим такую интересную позицию, как Windows 10 Feature On Demand.

Не найдя нигде в открытых источниках вменяемого развёрнутого описания этой позиции (…впрочем, как и многих других…) мы решили включить её и проверить, что она нам даст. По итогу могу сказать, что среди метаданных о более, чем тысячи обновлений, прилетевших после синхронизации WSUS с Windows Update, я увидел только некоторые компоненты FOD, большинство из которых применимы только для старых версий Windows 10. Ну и в придачу мы получили целый ворох языковых пакетов на всех мыслимых и немыслимых языках, невзирая на то, что в настройках сервера WSUS у нас включены только английский и русский языки. В общем и целом эта позиция на WSUS для нас оказалась бесполезной и даже вредительской.

Раздача Feature On Demand для Offline-клиентов

В результате проведённых экспериментов стало очевидно, что единственным приемлемым в нашей ситуации вариантом, позволяющим выполнять Offline-установку RSAT, является вариант с развёртыванием специального сетевого каталога с компонентами Feature On Demand с нацеливанием клиентов на этот каталог через групповые политики.

Для начала нам потребуется получить образы дисков с компонентами FOD для нашей версии Windows 10. Загрузить эти образы можно вручную с сайта Volume Licensing Service Center (VLSC)

Создаём на файловом сервере общедоступный сетевой ресурс для клиентских систем 64-bit и распаковываем в него всё содержимое образов SW_DVD9_NTRL_Win_10_1903_64Bit_MultiLang_FOD_.ISO . Рядом создаём аналогичный ресурс для систем 32-bit и распаковываем туда образы SW_DVD9_NTRL_Win_10_1903_W32_MultiLang_FOD_.ISO .

Распакованный контент будет представлять из себя множество *.cab файлов, среди которых есть и интересующие нас опциональные компоненты RSAT.

Теперь на любом Offline-клиенте c Windows 10 1903 мы можем попытаться выполнить установку компонент RSAT c помощью PowerShell, указывая в качестве источника получения подготовленный сетевой каталог:

Имейте в виду, что командлет Add-WindowsCapability работает довольно специфично. То есть он может отработать без ошибки, но если в указанном источнике не будут найдены файлы, подходящие для данной системы, никакой установки на самом деле не произойдёт… Разумеется, “это не баг, а фича”… Поэтому после выполнения командлета установки всех нужных компонент, лучше повторно проверять установленные компоненты:

После этого установленные компоненты RSAT можно будет видеть в уже “горячо полюбившейся” нам графической оболочке Windows 10 1903 в ранее упомянутом перечне дополнительных компонент Windows

И отсюда же их можно будет удалить при необходимости.

Таким образом все администраторы в организации смогут с помощью PowerShell вручную установить нужные им компоненты RSAT на свои системы Windows 10 1903, не имея прямого доступа в интернет. Однако Offline-установку можно сделать ещё удобней, если дополнительно настроить специальный параметр групповой политики, указывающий клиентам расположение сетевого каталога с компонентами FOD. Описан этот параметр GPO, например, в документе: How to make Features on Demand and language packs available when you’re using WSUS/SCCM.

Переходим в консоль управления групповыми политиками и в разделе политик Administrative Templates > System находим параметр “Specify settings for optional component installation and component repair“

Включаем этот параметр и указываем путь к сетевому каталогу с компонентами FOD в поле “Alternate source file path“.

Этот параметр групповой политики фактически принесёт на клиентские системы параметр реестра ” LocalSourcePath ” в ключе HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesServicing

После этого Offline-установка компонент FOD станет доступна и через графический интерфейс Windows без использования танцев с PowerShell

Однако при этом стоит помнить про ранее обозначенный нюанс с пустым списком компонент в случае использования графического интерфейса в связке с UAC. То есть выполнять установку компонент FOD через графический интерфейс окна “Параметры Windows” нужно только при интерактивном входе в систему из под административной учётной записи. Если по какой-то причине заходить в систему администратором интерактивно нет желания/возможности, то можно использовать выше описанный метод с установкой через PowerShell.

Читать еще: Настройка Wi-Fi на D-Link Wireless n150 и Wireless N300

При этом опять же стоит отметить то, что приятным плюсом использования настройки пути к компонентам FOD через групповую политику станет и то, что теперь при использовании PowerShell не потребуется явно указывать путь для установки нужных компонент:

И вроде бы теперь всё здорово, результат достигнут, то есть Offline-установка работает и через графический интерфейс и через PowerShell. Но дивные “фичи” на этом не кончаются.

Обработка “LocalSourcePath” с несколькими путями

Ещё одной странной штукой, которая была обнаружена при работе с выше обозначенным параметром групповой политики, это то, что, судя по описанию в GPO, значение опции “Alternate source file path” может принимать несколько путей с разделителем в виде точки с запятой. Однако практические эксперименты с Windows 10 1903 показали, что при считывании значения ” LocalSourcePath ” из реестра система заглядывает только в первый по счёту каталог (указанный до точки с запятой), а остальные игнорирует. Такое поведение вполне вписывается в рамки обработки значения ключа -Source командлета Add-WindowsCapability, в описании которого есть соответствующее примечание

If you specify multiple Source arguments, the files are gathered from the first location where they are found and the rest of the locations are ignored.

Вариантом выхода из этой ситуации может быть отказ от использования классического параметра из административных шаблонов GPO и настройка пути в реестре средствами Group Policy Preferences (GPP) с использованием таргетинга по версии и разрядности клиентской операционной системы.

По крайней мере именно на таком варианте мы и остановились, как на наиболее гибком и работоспособном.

Финиш

В итоге квест под названием “Выполнить Offline-установку RSAT в Windows 10 и не слететь с катушек” пройден, и теперь все административные пользователи, работающие на новой Windows 10 1903, могут устанавливать компоненты RSAT, как через графический интерфейс Windows, так и через PowerShell фактически в Offline-режиме и без дополнительных сложностей и манипуляций по аналогии с Online-клиентами.

PS: Никогда ещё установка RSAT в Windows у меня не была такой увлекательной и долгой. Чем больше смотрю на новые релизы Windows 10, тем становится интересней, во что же вся эта тенденция в итоге выльется. Коллега предположил, что в итоге получится, что-то вроде ранних выпусков Mandriva Linux – жутко красиво, но пользоваться этим без слёз невозможно

Windows ADK для Windows 10

Microsoft выпустила Windows ADK для Windows 10, который вы можете использовать для MDT 2013 Update 1 Preview, SCCM 2012 R2 SP1 и SCCM Technical Preview 2, если хотите устанавливать Windows 10. Кроме того, в состав Windows ADK входит новая Windows Imaging and Configuration Designer (Windows ICD), с помощью которой вы можете кастомизировать образы Windows 10.

Скачать Windows ADK для Windows 10 можно здесь (пролистайте вниз до раздела Customize, assess, and deploy Windows on your hardware).

Подготовка образа Windows Thin PC и установка при помощи VMware Mirage (часть I)

1 GHz or faster 32-bit (x86);
1 GB RAM, 16 GB available hard disk space;
DirectX 9 graphics device with WDDM 1.0 or later version driver.

Предварительные шаги

Для начала требуется подготовить дистрибутив Thin PC к установке.

Подготовка дистрибутива включает в себя следующие шаги:

Интеграция драйверов устройств в дистрибутив.
Интеграция пакетов обновлений ОС в дистрибутив.
Интеграция установочных пакетов приложений в дистрибутив.
Модификация установочного скрипта ОС.
Модификация файла ответов ОС.
Сборка дистрибутива.

C:ThinPC
C:ThinPCDrivers
C:ThinPCImage
C:ThinPCISO
C:ThinPCMount
C:ThinPCUpdates

Установка Windows 7 – часть 13: Осуществление перехода с Windows XP на Windows 7 вручную

Итак, мы рассмотрели, как использовать MDT 2010 для установки образа Windows 7 на пустые целевые компьютеры. Этот сценарий известен под названием Сценарий установки нового компьютера , в котором новая инсталляция ОС Windows 7 осуществляется на новый компьютер. В этом сценарии нет существующих пользовательских параметров и данных, которые нужно перенести, и используется последовательность задач стандартного клиента (Standard Client Task Sequence) для установки снимка образа вашего эталонного компьютера на целевые машины.

Но что, если наши целевые машины уже используются под управлением Windows XP и содержат пользовательские настройки и данные? И что если нам нужно выполнить миграцию этих машин на Windows 7, сохранив при этом существующие пользовательские параметры и данные на каждом компьютере? В этом случае пользовательские параметры и данные на каждой машине нужно сначала сохранить, затем компьютер нужно почистить, установить новую ОС, и, наконец, сохранить пользовательские параметры и данные. Такой сценарий известен под названием сценарий установки с обновлением компьютера (Refresh Computer deployment scenario) , и он может использоваться не только для миграции пользовательских машин с Windows XP на Windows 7, но и для “восстановления” пользовательских Windows 7 компьютеров путем перезаписи на них образов, когда данные на этих компьютерах повреждаются.

Примечание: почему нельзя использовать сценарий апгрейда Upgrade Computer deployment scenario для миграции компьютеров с Windows XP на Windows 7? Потому что нет поддерживаемого пути апгрейда с Windows XP сразу на Windows 7, смотрите на этой странице список поддерживаемых сценариев апгрейда. Для дополнительной информации о сценариях установки смотрите мои предыдущие статьи Понимание сценариев установки из цикла по установке Vista.

Проверка готовности к миграции

Прежде чем перевести Windows XP компьютер на Windows 7, необходимо убедиться, что компьютер способен работать под управлением новой ОС. Если вы осуществляете перенос небольшого числа машин, вы можете воспользоваться Windows 7 Upgrade Advisor.

Перенос параметров и данных пользователя

MDT 2010 включает инструмент User State Migration Tool (USMT) 4.0 и использует этот инструмент для миграции пользовательских параметров и данных во время сценариев установки Refresh или Replace Computer. Новой функцией в версии 4.0 USMT является поддержка миграции с жесткой связью (hard-link migration), которая позволяет сохранять пользовательские данные и параметры во время сценария установки Refresh Computer. В предыдущих версиях USMT информацию состояния пользовательского профиля (пользовательские настройки и данные) нужно было копировать в сетевой ресурс или на съемный носитель, поскольку все данные компьютера стирались во время сценария установки Refresh Computer, и после установки операционной системы информация состояния пользовательского профиля восстанавливалась обратно на компьютер путем ее копирования из сетевого ресурса или съемного носителя, на котором она сохранялась.

Однако благодаря миграции с жесткой связью пользовательская информация остается в том же месте на пользовательском компьютере, создаются жесткие связи (hard links) для пользовательских параметров и файлов данных. Жесткая связь – это элемент каталога для файла в файловой системе формата NTFS. Обычно для каждого файла есть по одной жесткой связи, а это означает, что файл появляется в одном каталоге в файловой системе. Однако с помощью миграции с жесткой связью USMT создает дополнительные жесткие связи для каждого файла пользовательских параметров и данных, в результате чего файл также храниться во временной C:MININT папке, созданной инструментом MDT во время установки. Затем, вместо стирания файловой системы с компьютера, для того чтобы записать на него новый образ, MDT 2010 просто удаляет все папки и файлы операционной системы с компьютера – загрузочный том не форматируется – а папка MININT сохраняет всю пользовательскую информацию, препятствуя ее удалению с компьютера. По завершении процесса установки, информация пользователя восстанавливается в нужное место путем воссоздания связей с файлами, а папка MININT вместе со своими жесткими связями удаляется.

Преимущество такого подхода миграции включает три аспекта:

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

Миграция Windows XP компьютеров на Windows 7 вручную

Теперь давайте попробуем вручную перенести компьютер Windows XP на Windows 7 с помощью MDT 2010. Начнем с настройки компьютера, например с сохранения файла bitmap рисунка в папку Мои рисунки для пользователя Karen Berg (CONTOSOkberg), как показано на рисунке 1:

Рисунок 1: Компьютер пользователя Karen в настоящее время работает под управлением Windows XP и содержит фото в папке Мои рисунки

1. Установка Microsoft Deployment Toolkit

Это задача не сложная, здесь нам необходимо скачать установочный файл MDT с официального сайта Microsoft.

Установка происходит просто, нажимаете везде ДАЛЕЕ и ГОТОВО. После установки в меню ПУСК>Программы у вас появится утилита DeploymentWorkbench ее то мы и запускаем.

Также необходимо установить набор инструментов Microsoft AIK, который содержит в себе оболочку PowerShell. Без которой будут не возможны следующие действия. Скачиваем с официального сайта Microsoft. И устанавливаем так же нажимая везде ДАЛЕЕ и ГОТОВО.