Usmt ppkg что это

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

USMT включает два средства, которые переносят параметры и данные: ScanState и LoadState. ScanState собирает сведения с исходных компьютеров, и LoadState применяет эти сведения к компьютеру назначения.

Примечание.
Дополнительные сведения о том, как USMT обрабатывает правила и XML-файлы, см. в материалах Conflicts and Precedence.

Процесс ScanState

При запуске средства ScanState на исходных компьютерах он проходит следующий процесс:

Он проверяет и проверяет параметры командной строки, создает файл ScanState.log, а затем начинает ведение журнала.

Он собирает сведения обо всех компонентах миграции, которые необходимо перенести. Компонент миграции — это логическая группа файлов, ключей реестра и значений. Например, набор файлов, ключей реестра и значений, которые хранят параметры Adobe Acrobat, сгруппировали в один компонент миграции.

Существует три типа компонентов:

В Windows 7 и Windows 8 файлы манифеста контролируют миграцию параметров операционной системы. Вы не можете изменить эти файлы. Чтобы исключить определенные параметры операционной системы, необходимо создать и изменить Config.xml файл.

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

На этапе «Сканирование» ScanState делает следующее для каждого профиля пользователя, выбранного для миграции:

Для каждого компонента ScanState проверяет тип компонента. Если текущий профиль пользователя — это профиль системы, а тип компонента — «System» или «UserAndSystem», компонент выбирается для этого пользователя. В противном случае компонент игнорируется. Кроме того, если текущий профиль пользователя не является системным профилем, а тип компонента — «Пользователь» или «UserAndSystem», компонент выбирается для этого пользователя. В противном случае этот компонент игнорируется.

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

Каждый компонент, выбранный на предыдущем шаге, обрабатывается далее. В контексте текущего профиля оцениваются все переменные, определенные для профиля (например, CSIDL_PERSONAL). Например, если обрабатываемая анкета относится к «User1», то CSIDL_PERSONAL будет расширяться до C:\Users\User1\Documents, если предположить, что профили пользователей хранятся в каталоге C:\Users.

Для каждого выбранного компонента ScanState оценивает раздел обнаружения. Если условие в разделе обнаружения оценивается как ложное, компонент больше не обрабатывается. В противном случае обработка этого компонента продолжается.

Для каждого выбранного компонента ScanState оценивает правил. Для каждого раздела правил, если текущий профиль пользователя — это профиль системы, а контекст раздела правил — «Система» или «UserAndSystem», это правило обрабатывается далее. В противном случае это правило игнорируется. Кроме того, если текущий профиль пользователя не является системным профилем, а контекст раздела правил «Пользователь» или «UserAndSystem», правило обрабатывается дополнительно. В противном случае это правило игнорируется.

Кроме того, не перенесено любое подразделение миграции (например, файл, ключ реестра или набор значений реестра), которое находится в разделе

Примечание.
ScanState игнорирует некоторые подсекции, такие как и Эти разделы оцениваются только на компьютере назначения.

На этапе «Сбор» ScanState создает мастер-список подразделений миграции, объединяя списки, созданные для каждого выбранного профиля пользователя.

На этапе «Сохранение» ScanState записывает единицы миграции, собранные в расположение магазина.

Примечание.
ScanState не изменит исходный компьютер в любом случае.

Процесс LoadState

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

ScanState проверяет и проверяет параметры командной строки, создает файл ScanState.log и начинает ведение журнала.

LoadState собирает сведения о компонентах миграции, которые необходимо перенести.

В Windows 7 и Windows 8 файлы манифеста контролируют миграцию параметров операционной системы. Вы не можете изменить эти файлы. Чтобы исключить определенные параметры операционной системы, необходимо создать и изменить Config.xml файл.

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

Если вы переносят локальные учетные записи пользователей и если учетные записи еще не существуют на компьютере назначения, необходимо использовать параметр командной строки /lac. Если вы не указываете параметр /lac, все локальные учетные записи пользователей, которые еще не присутствуют на компьютере назначения, не переносят.

Параметры /md и /mu обрабатываются для переименования профиля пользователя на компьютере назначения, если они были включены при указании команды LoadState.

Для каждого профиля пользователя, выбранного из магазина, LoadState создает соответствующий профиль пользователя на компьютере назначения. Для создания профилей пользователей домена не требуется подключать компьютер назначения к домену. Если USMT не может определить домен, он пытается применить параметры к локальной учетной записи. Дополнительные сведения см. в twitter Identify Users.

На этапе «Сканирование» LoadState делает следующее для каждого профиля пользователя:

Для каждого компонента LoadState проверяет тип компонента. Если текущий профиль пользователя — это профиль системы, а тип компонента — «System» или «UserAndSystem», компонент выбирается для этого пользователя. В противном случае компонент игнорируется. Кроме того, если текущий профиль пользователя не является системным профилем, а тип компонента — «Пользователь» или «UserAndSystem», компонент выбирается для этого пользователя. В противном случае этот компонент игнорируется.

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

Каждый выбранный компонент обрабатывается дополнительно. В контексте текущего профиля оцениваются все переменные, определенные для профиля (например, CSIDL_PERSONAL). Например, если обрабатываемая анкета относится к «User1», CSIDL_PERSONAL будет расширяться до C:\Users\User1\Documents (если предположить, что профили пользователей хранятся в каталоге C:\Users).

Примечание.
LoadState игнорирует раздел указанный в компоненте. На этом этапе все указанные компоненты считаются обнаруженными и выбираются для переноса.

Для каждого выбранного компонента LoadState оценивает правил. Для каждого раздела правил, если текущий профиль пользователя — это профиль системы, а контекст раздела правил — «Система» или «UserAndSystem», это правило обрабатывается далее. В противном случае это правило игнорируется. Кроме того, если текущий профиль пользователя не является системным профилем, а контекст раздела правил «Пользователь» или «UserAndSystem», правило обрабатывается дополнительно. В противном случае это правило игнорируется.

LoadState создает мастер-список единиц миграции, обрабатывая различные подсекции в разделе правила. Каждая единица миграции, которая находится в подгруппе, передается до тех пор, пока в исключенной подгруппе в том же разделе правил нет более конкретного правила. Дополнительные сведения о приоритете см. в дополнительных сведениях о конфликтах и приоритетах.

LoadState оценивает подсекции, определенные для конкретного компьютера; например, и subsections.

Если на компьютере назначения Windows 7 или Windows 8, то migunits, собранные ScanState с помощью файлов манифеста downlevel, обрабатываются LoadState с помощью соответствующего манифеста компонентов для Windows 7. Файлы манифеста downlevel не используются во время LoadState.

На этапе «Применить» LoadState записывает блоки миграции, собранные в различные расположения на компьютере назначения. Если существуют конфликты и для объекта не существует правила слияния, по умолчанию для реестра необходимо переписать пункт назначения. По умолчанию для файлов необходимо постепенное переименование источника, например OriginalFileName(1). OriginalExtension. Некоторые параметры, такие как шрифты, обои и параметры сохранения экрана, не вступает в силу до следующего входа пользователя. По этой причине после завершения командных действий LoadState необходимо выйти из журнала.

Источник

Что нового в развертывании Windows 10

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

Требования к оборудованию, совместимость приложений

Формальные требования к оборудованию перечислены здесь. По сути же можно сказать, что если на вашем «железе» работает Windows 7, Windows 8 или Windows 8.1, то будет работать и Windows 10. Есть, пожалуй, одна тонкость, касающаяся 64-битной версии. Начиная с версии 8.1, Windows использует некоторые инструкции процессора, не поддерживаемые Pentium D. На этих процессорах 64-битная версия Windows 10 работать не будет. Впрочем, я надеюсь, таких процессоров у вас давно нет.

С точки зрения совместимости приложений все выглядит весьма неплохо. В Windows 10 довольно много изменений и усовершенствований, но они в массе своей не затрагивают подсистему Win32, в которой запускаются приложения. Мы предполагаем, что не менее 90% имеющихся десктоп-приложений будут без проблем работать и под Windows 10. Но жизнь – штука сложная, а разработчики – люди креативные, поэтому нет, не 100%. К тому же в некоторых случаях, даже если приложение работает нормально, необходимо чтобы компания-разработчик (ISV) официально подтвердила поддержку / сертифицировала свое ПО под новую ОС. Или же выпустила новую версию.

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

Internet Explorer

А вот здесь есть несколько важных моментов, на которые стоит обратить внимание.

Во-первых, как вы наверняка знаете, в Windows 10 будет встроено два браузера – Microsoft Edge (ранее Project Spartan) и Internet Explorer 11. Первый – для просмотра современных сайтов с поддержкой HTML5 и новейших стандартов, второй – главным образом для совместимости с имеющимися веб-приложениями. Применение IE11 особенно актуально в корпоративной среде, где применяются собственные кастомизированные порталы и веб-сайты или веб-приложения, использующие Silverlight. Напомню, Microsoft Edge не поддерживает Silverlight.

Во-вторых, c 12 января 2016 года заканчивается поддержка старых версий IE в ОС Microsoft. В таблице ниже приведены комбинации версий ОС и IE, которые будут поддерживаться после 12.01.2016.

Это означает, что если вы спокойно используете Windows 7 скажем с IE9 и даже не планируете переход на «десятку» в ближайшие месяцы, вам необходимо начать тестирование ваших веб-приложений на предмет совместимости с IE11. Потому что с нового года IE11 будет единственной версией Internet Explorer, поддерживаемой на Windows 7.

Варианты развертывания

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

Третий вариант – provisioning – ноу-хау Windows 10. Предназначен он для «превращения» нового устройства с Windows 10 в устройство корпоративное, с соответствующими настройками, приложениями и редакцией ОС.

Далее чуть более подробно о каждом из вариантов.

Wipe-and-Load

In-Place

In-Place Upgrade доступен на протяжении многих релизов. Не секрет, что ИТ-департаменты предпочитают использовать чистую установку (Wipe-and-Load), особенно после опыта миграции с XP на Vista. Понимая это, команда Windows провела серьезную работу по совершенствованию процесса обновления. Результаты перехода пользователей с Windows 8 на Windows 8.1 показали, что усилия не прошли даром. Кроме того, были проведены пилоты с рядом заказчиков по обновлению «на месте» с Windows 7 до Windows 8.1, выявившие дополнительные векторы приложения усилий разработчиков.

В итоге, «десятка» поддерживает In-Place Upgrade для Windows 7 SP1, Windows 8, Windows 8.1, то есть для большинства поддерживаемых на текущий момент версий клиентской Windows.

Процесс обновления до Windows 10 состоит из 4 фаз.

1. Down-level. Во время первой фазы Setup проверяет соответствие обновляемого компьютера требованиям Windows 10, собирает информацию о драйверах, настройках пользователя, установленных приложениях. Обнаруженные приложения сверяются с Compatibility Database на предмет совместимости. На последнем шаге формируется образ WinRE (winrm.wim), в который при необходимости добавляются boot critical драйверы, специфичные для данного компьютера. По окончанию этой фазы осуществляется первая перезагрузка.

2. WinRE. Машина загружается с помощью образа WinRE (Recovery Environment), некоей минималистской среды, задача которой скопировать файлы исходной (down-level) версии Windows в папку Windows.old, развернуть образ «десятки» из файла install.wim дистрибутива, создать требуемую структуру каталогов, добавить необходимые для первой загрузки новой ОС драйверы и перезагрузить машину. Во время этой фазы компьютер находится в некотором промежуточном состоянии, когда старая версия Windows уже не используется, новая только готовится к использованию.

3. 1st boot to New OS. По своему наполнению фаза очень близка к этапу Specialize в варианте развертывания Wipe-and-Load. В этой фазе происходит первая загрузка уже новой ОС, устанавливаются драйверы, применяются все необходимые настройки, восстанавливаются приложения (копируются соответствующие ветки реестра, бинарные файлы, если в базе совместимости были обнаружены какие-либо инструкции для тех или иных приложений, они применяются и пр.). По окончании происходит еще одна перезагрузка.

4. 2nd boot to New OS. В заключительной фазе завершаются все миграционные процессы, и перед пользователем появляется экран приветствия, известный как OOBE (Out-Of-Box Experience), где как минимум следует принять условия лицензионного соглашения. На этом процесс обновления ОС завершен.

Хотел бы отметить несколько важных моментов, связанных с In-Place Upgrade.

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

Как следствие, в первой фазе во время анализа параметров компьютера Setup вычисляет требуемое дисковое пространство с учетом необходимости хранения папки Windows.old для возможного отката. Если пространства на диске не хватает, пользователь может предоставить внешний носитель (и это еще одно новшество), где будет создана Windows.old. И все же на диске C: должно быть достаточно места, чтобы разместить %SystemRoot% самой «десятки».

Для того чтобы выполнять обновление «на месте» в корпоративной среде с помощью традиционных инструментов, в SCCM vNext и MDT 2013 Update 1 добавлена новая последовательность задач (upgrade task sequence). Детали того, как реализовать такую последовательность задач в SCCM 2012 R2 SP1, можно посмотреть здесь.

При использовании MDT или SCCM компании как правило готовят свой преднастроенный образ ОС. Для успешного же обновления «на месте» необходимо применять стандартный install.wim. Основная причина – сохранение установленных приложений при апгрейде. Если ИТ-отдел добавил в образ Windows 10 какое-либо приложение, а на обновляемой машине это приложение (той же или иной версии) уже установлено, то установщик ОС не сможет выполнить корректное слияние файлов и настроек этого приложения. Он прост не умеет этого делать. В результате может быть нарушена ассоциация расширений файлов приложения, приложение может работать не стабильно или не работать вообще.

Provisioning

Суть варианта развертывания provisioning (подготовка) проще всего пояснить на примере. Предположим, для мобильных сотрудников компания закупает несколько новых планшетов с Windows 10 Professional. Чтобы сотрудники могли начать работу на этих планшетах, ИТ-отдел должен применить к новым устройствам ряд настроек: выполнить апгрейд до Enterprise-версии, включить в домен и/или подключить к Microsoft Intune (или другому MDM-решению), применить политики, загрузить необходимые сертификаты, создать профили Wi-Fi и VPN, установить корпоративные приложения и пр.

Практически все это можно реализовать групповыми политиками. Но последние требуют включения машин в домен, а для ряда мобильных сценариев, возможно, удобнее такие устройства оставлять вне домена. Кроме того, включение в домен либо выполняет сотрудник ИТ-отдела, либо сам пользователь, который должен обладать соответствующими полномочиями и знаниями. Скрипт? Вполне возможно. А если задача схожая, но речь идет о смартфонах?

Provisioning позволяет ИТ-администратору подготовить файл, содержащий все необходимые настройки, а если нужно, то и приложения. Такой файл в зависимости от размера можно прислать по электронной почте, расположить на веб-портале, на сетевой папке, на флэшке. Все что требуется от пользователя – запустить такой файл на нужном устройстве двойным щелчком. Настройки, заданные в файле, применяются к системе, и через несколько минут или даже секунд устройство полностью готово к работе.

Этот же подход применим и к смартфонам с Windows 10. Вместо двойного щелчка мышки могут применяться метки NFC, либо смартфон подключается через USB к компьютеру, отображается в виде иконки в проводнике, и требуемый фал просто переносится на иконку с помощью drag-and-drop.

Конфигурационных или provisioning-файлов можно создать столько, сколько нужно, для разных сценариев, разных типов устройств и пр. Для создания таких файлов используется Windows Imaging and Configuration Designer (Windows ICD) – новый инструмент пакета ADK. Принцип использования Windows ICD довольно прост – в левой части экрана отображаются все доступные настройки и параметры, в средней части экране для нужных вам параметров вы задаете значения, в правой части отображаются выбранные и сформированные настройки.

По окончанию редактирования формируется provisioning-файл с расширением ppkg, который остается доставить на устройство любым доступным способом.

Теме Provisioning будет посвящен отдельный пост (возможно, не один), пока же я хотел бы отметить несколько важных моментов.

Самый важный. Provisioning предназначен для устройств, на которых уже установлена Windows 10, но хотелось бы быстро и без особых административных усилий настроить эти устройства для работы в определенных сценариях.

Windows 10 предусматривает возможность апгрейда редакции Professional до Enterprise путем ввода соответствующего ключа, без переустановки системы. Потребуется лишь одна перезагрузка. А ключ можно как раз указать в ppkg-файле.

После того как ppkg-файл применен к устройству, его можно с устройства удалить (если только вы явным образом не запретили пользователю такую операцию). При удалении файла удаляются все политики, которые были к устройству применены в ходе provisioning.

Ppkg-файл может быть применен как в процессе работы устройства (runtime), так и при первом включении нового устройства на этапе OOBE, например, на съемном носителе.

Можно настроить систему так, чтобы ppkg-файл оставался в системе и применялся автоматически после factory reset. Тогда необходимые настройки применятся к устройству даже после сброса к заводским установкам.

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

Я надеюсь, у вас сложилось первое представление о том, какие варианты и инструменты развертывания Windows 10 скоро будут или уже в вашем распоряжении. Ну а мы еще не раз вернемся к этой теме в нашем блоге на Хабре, а также в online- и offline-мероприятиях.

Источник

Начало работы со средством миграции пользовательской среды

В этом разделе описывается общий процесс переноса файлов и параметров.

В этом разделе

Шаг 1. Планирование миграции

Планирование миграции. В зависимости от того, является ли ваш сценарий миграции обновлением или заменой компьютеров, вы можете выбрать миграцию в интернете или перенос в автономном режиме с помощью Windows среды предварительной реализации (WinPE) или файлов в каталоге Windows.old. Дополнительные сведения см. в общих сценариях миграции.

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

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

Используйте параметр командной строки /GenMigXML, чтобы определить, какие файлы будут включены в миграцию, и определить, необходимы ли какие-либо изменения. Дополнительные сведения см. в обзоре ScanState Syntax

scanstate /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scanstate.log

Просмотрите состояние миграции компонентов, перечисленных в файле Config.xml, и укажите для всех компонентов, которые не нужно migrate=no перенести.

Шаг 2. Сбор файлов и параметров с исходных компьютеров

Back up the source computer.

Закрой все приложения. Если некоторые приложения работают при запуске команды ScanState, USMT может не перенести все указанные данные. Например, если microsoft ® Office Outlook ® открыта, USMT может не перенести PST-файлы.

Примечание.
USMT не удастся, если он не сможет перенести файл или параметр, если не указать параметр /C. При указании параметра /C USMT игнорирует ошибки и регистрирует ошибку каждый раз, когда он сталкивается с файлом, который используется, который usMT не переносит. Вы можете использовать раздел ** ** в файле Config.xml, чтобы указать, какие ошибки следует игнорировать, а какие должны привести к сбой миграции.

scanstate \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scan.log

Примечание.
Если исходный компьютер работает Windows 7 или Windows 8, необходимо выполнить команду ScanState в режиме администратора. Чтобы запустить в режиме администратора, щелкните правой кнопкой мыши командноеподсказок, а затем нажмите кнопку Выполнить как администратор. Если исходный компьютер Windows XP, необходимо выполнить команду ScanState из учетной записи с административными учетными данными. Дополнительные сведения о том, как команда ScanState обрабатывает и хранит данные, см. в пункте How USMT Works.

Запустите команду USMTUtils с помощью параметра /Verify, чтобы убедиться, что созданный вами магазин не поврежден.

Шаг 3. Подготовка компьютера назначения и восстановление файлов и параметров

Установите операционную систему на компьютер назначения.

Установите все приложения, которые находились на исходных компьютерах. Хотя это не всегда требуется, мы рекомендуем установить все приложения на компьютере назначения перед восстановлением состояния пользователя. Это позволяет сохранить перенесенные параметры.

Примечание.
Версия приложения, установленная на компьютере назначения, должна быть той же версией, что и версия на исходный компьютер. USMT не поддерживает перенос параметров для более старой версии приложения в более новую версию. Исключением является microsoft Office, которую USMT может перенести из более старой версии ® в более новую.

Закрой все приложения. Если некоторые приложения работают при запуске команды LoadState, USMT может не перенести все указанные данные. Например, если Microsoft Office Outlook открыт, USMT может не перенести PST-файлы.

Примечание.
Используйте /C, чтобы продолжить миграцию в случае возникновения ошибок, и используйте раздел ** ** в файле Config.xml, чтобы указать, какие ошибки следует игнорировать и какие ошибки должны привести к сбой миграции.

Например, следующая команда переносит файлы и параметры:

loadstate \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log

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

Вход после запуска команды LoadState. Некоторые параметры (например, шрифты, обои и параметры сохранения экрана) не вступает в силу до следующего входа пользователя.

Источник