Partilhar via

Testar a migração

Teste sempre o plano de migração numa definição de laboratório controlada antes de implementá-lo em toda a organização. No ambiente de teste, é necessário pelo menos um computador para cada tipo de sistema operativo a partir do qual os dados estão a ser migrados.

Depois de todo o processo de migração ser testado num único computador a executar cada um dos sistemas operativos de origem da organização, realize uma migração piloto com um pequeno grupo de utilizadores. Depois de migrar alguns estados de utilizador típicos para o arquivo intermédio, tenha em atenção o espaço necessário e ajuste os cálculos iniciais em conformidade. Para obter detalhes sobre como estimar o espaço necessário para a migração, veja Estimar o tamanho do arquivo de migração. As informações de definição de registo e localização de ficheiros podem ter de ser ajustadas nos ficheiros de regras de migração. Se forem feitas alterações, teste novamente a migração e verifique se todos os dados e definições migraram conforme esperado. Uma migração piloto também dá a oportunidade de testar as estimativas de espaço para o arquivo intermédio.

Se a migração de teste encontrar erros, examine os registos ScanState e LoadState para obter o código de retorno exato da Ferramenta de Migração de Estado do Utilizador (USMT) e as mensagens de erro associadas ou a mensagem de erro da interface de programação de aplicações (API) do Windows. Para obter mais informações sobre códigos de retorno USMT e mensagens de erro, veja Códigos de retorno. Pode obter mais informações sobre quaisquer códigos de erro do sistema Windows listados ao escrever o seguinte numa janela da linha de comandos:

net.exe helpmsg <error_number>

em <que error_number> é o número de código de erro gerado pela mensagem de erro. Para obter mais informações sobre os Códigos de Erro do Sistema, veja Códigos de Erro do Sistema (0-499).

Na maioria dos casos, os registos ScanState e LoadState indicam o motivo pelo qual uma migração USMT está a falhar. A Microsoft recomenda a utilização da opção /v:5 ao testar a migração. Este nível de verbosidade pode ser ajustado numa migração de produção. Reduzir o nível de verbosidade pode dificultar o diagnóstico de falhas encontradas durante as migrações de produção. Podem ser utilizados níveis de verbosidade mais elevados se os ficheiros de registo precisarem de ser exportados para aceder a um depurador.

Observação

Executar as ferramentas ScanState e LoadState com a opção /v:5 cria um ficheiro de registo detalhado. Embora esta opção faça com que o ficheiro de registo seja grande, é útil para determinar onde ocorreram erros de migração.

Após a migração piloto ser verificada que migrou com êxito os ficheiros e definições especificados, o USMT está pronto para ser utilizado no ambiente para migrar dados. Por exemplo, utilizar o USMT com Microsoft Configuration Manager. Para obter mais informações, consulte [Gerir o estado do utilizador no Configuration Manager]/(mem/configmgr/osd/get-started/manage-user-state).

Observação

Para fins de teste, pode ser criado um arquivo descomprimido com a opção /hardlink /nocompress . Quando a compressão está desativada, a ferramenta ScanState guarda os ficheiros e definições numa pasta oculta chamada Ficheiro em <StorePath>\USMT. O arquivo descomprimido pode ser utilizado para ver que USMT armazenou ou para resolver um problema. Um utilitário antivírus também pode ser executado nos ficheiros. Além disso, os seguintes itens podem ser utilizados para resolver problemas com a migração:

  • A /listfiles opção da linha de comandos.
  • O registo de diagnósticos que lista os ficheiros que foram recolhidos.