Тестирование миграции
Всегда тестируйте план миграции в управляемой лабораторной среде перед его развертыванием во всей организации. В тестовой среде для каждого типа операционной системы, из которой переносятся данные, требуется по крайней мере один компьютер.
После тестирования всего процесса миграции на одном компьютере под управлением каждой из исходных операционных систем организации выполните пилотную миграцию с небольшой группой пользователей. После переноса нескольких типичных пользовательских состояний в промежуточное хранилище обратите внимание на требуемое пространство и соответствующим образом настройте начальные вычисления. Дополнительные сведения об оценке пространства, необходимого для миграции, см. в разделе Оценка размера хранилища миграции. Сведения о параметрах реестра и расположении файлов может потребоваться изменить в файлах правил миграции. Если изменения внесены, протестируйте миграцию еще раз и убедитесь, что все данные и параметры перенесены должным образом. Пилотная миграция также дает возможность протестировать оценки пространства для промежуточного хранилища.
Если при тестовой миграции возникают какие-либо ошибки, просмотрите журналы ScanState и LoadState , чтобы получить точный код возврата средства миграции пользовательской среды (USMT) и связанные с ними сообщения об ошибках или сообщение об ошибке интерфейса прикладного программирования (API) Windows. Дополнительные сведения о кодах возврата USMT и сообщениях об ошибках см. в разделе Коды возврата. Дополнительные сведения о любых перечисленных кодах системных ошибок Windows можно получить, введя в окне командной строки следующую команду:
net.exe helpmsg <error_number>
где <error_number> — номер кода ошибки, сформированный сообщением об ошибке. Дополнительные сведения о системных кодах ошибок см. в разделе Коды системных ошибок (0–499).
В большинстве случаев журналы ScanState и LoadState указывают, почему миграция USMT завершается сбоем. Корпорация Майкрософт рекомендует использовать параметр /v:5
при тестировании миграции. Этот уровень детализации можно изменить в рабочей миграции. Снижение уровня детализации может затруднить диагностику сбоев, возникающих во время миграции рабочей среды. Более высокий уровень детализации можно использовать, если файлы журнала должны выводить данные для перехода в отладчик.
Примечание.
При запуске средств ScanState и LoadState с параметром /v:5
создается подробный файл журнала. Хотя этот параметр делает файл журнала большим, он полезен при определении места возникновения ошибок миграции.
После проверки пилотной миграции, успешной миграции указанных файлов и параметров, USMT готов к использованию в среде для переноса данных. Например, использование USMT с Microsoft Configuration Manager. Дополнительные сведения см. в разделе [Управление состоянием пользователя в Configuration Manager]/(mem/configmgr/osd/get-started/manage-user-state).
Примечание.
В целях тестирования можно создать несжатое хранилище с помощью /hardlink /nocompress
параметра . Если сжатие отключено, средство ScanState сохраняет файлы и параметры в скрытой папке с именем File по адресу <StorePath>\USMT
. Несжатое хранилище можно использовать для просмотра хранимых USMT или устранения проблемы. Для файлов также можно запустить антивирусную программу. Кроме того, для устранения проблем с миграцией можно использовать следующие элементы:
- Параметр
/listfiles
командной строки. - Журнал диагностики, в который перечислены собранные файлы.