Поделиться через


Принцип работы USMT

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

Примечание.

Дополнительные сведения о том, как USMT обрабатывает правила и XML-файлы, см. в разделе Конфликты и приоритет.

Процесс ScanState

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

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

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

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

    • Компоненты, переносимые параметры операционной системы.

    • Компоненты, переносимые параметры приложения.

    • Компоненты, которые переносит файлы пользователей.

    Средство ScanState собирает сведения о параметрах приложения и компонентах пользовательских данных из .xml файлов, указанных в командной строке.

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

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

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

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

      Примечание.

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

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

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

    4. Для каждого выбранного компонента ScanState оценивает <разделы правил> . Для каждого <раздела правил> , если текущий профиль пользователя является системным профилем, а контекст <раздела правил>System или UserAndSystem, правило обрабатывается далее. В противном случае это правило игнорируется. Кроме того, если текущий профиль пользователя не является системным профилем и контекстом <раздела правил> является User или UserAndSystem, правило обрабатывается далее. В противном случае это правило игнорируется.

    5. ScanState создает список единиц миграции, которые необходимо перенести, обработать различные подразделы в этом <разделе правил> . Каждая единица собирается, если единица упоминается в <подразделе include>, если в подразделе exclude> в том же разделе правил нет более конкретного правила<.>< Дополнительные сведения о приоритете в файлах.xml см. в разделе Конфликты и приоритет.

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

      Примечание.

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

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

  6. На этапе сохраненияScanState записывает собранные единицы миграции в расположение хранилища.

    Примечание.

    ScanState не изменяет исходный компьютер каким-либо образом.

Процесс LoadState

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

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

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

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

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

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

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

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

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

  4. На этапе сканированияLoadState выполняет следующие действия для каждого профиля пользователя:

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

      Примечание.

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

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

      Примечание.

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

    3. Для каждого выбранного компонента LoadState оценивает <разделы правил> . Для каждого <раздела правил> , если текущий профиль пользователя является системным профилем, а контекст <раздела правил>System или UserAndSystem, правило обрабатывается далее. В противном случае это правило игнорируется. Кроме того, если текущий профиль пользователя не является системным профилем и контекстом <раздела правил> является User или UserAndSystem, правило обрабатывается далее. В противном случае это правило игнорируется.

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

    5. LoadState вычисляет подразделы целевого компьютера, например <destinationCleanup> и <locationModify> .

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

      Важно.

      Чтобы LoadState использовал файлы.xml , важно указать их с LoadState.exe помощью команды . В противном случае все правила назначения, например <locationModify>, в этих .xml файлах игнорируются, даже если при ScanState.exe выполнении команды были предоставлены те же .xml файлы.

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