Partilhar via

Como funciona o USMT

O USMT inclui duas ferramentas que migram definições e dados: ScanState e LoadState. ScanState recolhe informações do computador de origem e LoadState aplica essas informações ao computador de destino.

Observação

Para obter mais informações sobre como o USMT processa as regras e os ficheiros XML, veja Conflitos e precedência.

O processo ScanState

Quando a ferramenta ScanState é executada no computador de origem, passa pelo seguinte processo:

  1. Analisa e valida os parâmetros da linha de comandos, cria o ficheiro e, em seguida, inicia o ScanState.log registo.

  2. Recolhe informações sobre todos os componentes de migração que precisam de ser migrados. Um componente de migração é um grupo lógico de ficheiros, chaves de registo e valores. Por exemplo, o conjunto de ficheiros, chaves de registo e valores que armazenam as definições do Adobe Acrobat é agrupado num único componente de migração.

    Existem três tipos de componentes:

    • Componentes que migram as definições do sistema operativo.

    • Componentes que migram as definições da aplicação.

    • Componentes que migram os ficheiros dos utilizadores.

    A ferramenta ScanState recolhe informações sobre as definições da aplicação e os componentes de dados do utilizador dos ficheiros de.xml especificados na linha de comandos.

    Nas versões atualmente suportadas do Windows, os ficheiros de manifesto controlam a forma como as definições do sistema operativo são migradas. Estes ficheiros não podem ser modificados. Para excluir determinadas definições do sistema operativo, tem de ser criado e modificado um Config.xml ficheiro.

  3. ScanState determina quais os perfis de utilizador que devem ser migrados. Por predefinição, todos os perfis de utilizador no computador de origem são migrados. No entanto, os utilizadores podem ser incluídos e excluídos através das opções de Utilizador. O Perfil de sistema e o Perfil público num computador de origem com versões atualmente suportadas do Windows são sempre migrados e estes perfis não podem ser excluídos da migração.

  4. Na fase de Análise , ScanState faz o seguinte para cada perfil de utilizador selecionado para migração:

    1. Para cada componente, ScanState verifica o tipo do componente. Se o perfil de utilizador atual for o perfil de sistema e o tipo de componente for Sistema ou UserAndSystem, o componente será selecionado para este utilizador. Caso contrário, o componente é ignorado. Em alternativa, se o perfil de utilizador atual não for o perfil do sistema e o tipo de componente for Utilizador ou UserAndSystem, o componente será selecionado para este utilizador. Caso contrário, este componente é ignorado.

      Observação

      A partir de agora, o ScanState não distingue entre componentes que migram definições do sistema operativo, componentes que migram definições de aplicações e componentes que migram ficheiros de utilizadores. ScanState processa todos os componentes da mesma forma.

    2. Cada componente selecionado no passo anterior é processado ainda mais. Todas as variáveis específicas do perfil (como CSIDL_PERSONAL) são avaliadas no contexto do perfil atual. Por exemplo, se o perfil que está a ser processado pertencer ao Utilizador1, CSIDL_PERSONAL expandiria para C:\Users\User1\Documents, partindo do princípio de que os perfis de utilizador estão armazenados no C:\Users diretório.

    3. Para cada componente selecionado, ScanState avalia a <secção deteta> . Se a condição na <secção detetar> for avaliada como falsa, o componente não será processado mais. Caso contrário, o processamento deste componente continua.

    4. Para cada componente selecionado, ScanState avalia as <secções de regras> . Para cada <secção de regras>, se o perfil de utilizador atual for o perfil do sistema e o contexto da secção de< regras> for Sistema ou UserAndSystem, a regra é processada ainda mais. Caso contrário, esta regra é ignorada. Em alternativa, se o perfil de utilizador atual não for o perfil do sistema e o contexto da secção de <regras> for Utilizador ou UserAndSystem, a regra é processada ainda mais. Caso contrário, esta regra é ignorada.

    5. ScanState cria uma lista de unidades de migração que precisam de ser migradas ao processar as várias subsecções nesta <secção de regras> . Cada unidade é recolhida se a unidade for mencionada numa <subsecção de inclusão> , desde que não exista uma regra mais específica para a mesma numa <subsecção de exclusão> na mesma <secção de regras> . Para obter mais informações sobre a precedência nos ficheiros .xml , veja Conflitos e precedência.

      Além disso, qualquer unidade de migração (como um ficheiro, chave de registo ou conjunto de valores de registo) que esteja numa <secção IncondicionalExclude> não é migrada.

      Observação

      ScanState ignora algumas subsecções, como <destinationCleanup> e <locationModify>. Estas secções são avaliadas apenas no computador de destino.

  5. Na fase de Recolha , ScanState cria uma lista central das unidades de migração ao combinar as listas que foram criadas para cada perfil de utilizador selecionado.

  6. Na fase Guardar , ScanState escreve as unidades de migração que foram recolhidas para a localização do arquivo.

    Observação

    ScanState não modifica o computador de origem de forma alguma.

O processo LoadState

O processo LoadState é semelhante ao processo ScanState . A ferramenta ScanState recolhe unidades de migração, como ficheiro, chave de registo ou valores de registo do computador de origem e guarda-as no arquivo. Da mesma forma, a ferramenta LoadState recolhe unidades de migração do arquivo e aplica-as ao computador de destino.

  1. ScanState analisa e valida os parâmetros da linha de comandos, cria o ScanState.log ficheiro e, em seguida, começa a registar.

  2. LoadState recolhe informações sobre os componentes de migração que precisam de ser migrados.

    LoadState obtém informações para os componentes de definições de aplicação e componentes de dados de utilizador a partir da migração .xml ficheiros especificados pelo LoadState.exe comando.

    Nas versões atualmente suportadas do Windows, os ficheiros de manifesto controlam a forma como as definições do sistema operativo são migradas. Estes ficheiros não podem ser modificados. Para excluir determinadas definições do sistema operativo, tem de ser criado e modificado um Config.xml ficheiro.

  3. LoadState determina quais os perfis de utilizador que devem ser migrados. Por predefinição, todos os perfis de utilizador presentes no computador de origem são migrados. No entanto, os utilizadores podem ser incluídos e excluídos através das opções de Utilizador. O Perfil de sistema e o Perfil público num computador de origem com versões atualmente suportadas do Windows são sempre migrados e estes perfis não podem ser excluídos da migração.

    • Se as contas de utilizador local estiverem a ser migradas e se as contas ainda não existirem no computador de destino, a opção da /lac linha de comandos tem de ser utilizada. Se a opção /lac não for especificada, as contas de utilizador locais que ainda não estejam presentes no computador de destino não serão migradas.

    • Quando especificado com o LoadState.exe comando , as /md opções e /mu são processadas para mudar o nome do perfil de utilizador no computador de destino.

    • Para cada perfil de utilizador selecionado a partir do arquivo, LoadState cria um perfil de utilizador correspondente no computador de destino. O computador de destino não precisa de estar ligado ao domínio para que os perfis de utilizador de domínio sejam criados. Se o USMT não conseguir determinar um domínio, tenta aplicar as definições a uma conta local. Para obter mais informações, veja Identificar Utilizadores.

  4. Na fase de Análise , LoadState faz o seguinte para cada perfil de utilizador:

    1. Para cada componente, LoadState verifica o tipo do componente. Se o perfil de utilizador atual for o perfil de sistema e o tipo de componente for Sistema ou UserAndSystem, o componente será selecionado para este utilizador. Caso contrário, o componente é ignorado. Em alternativa, se o perfil de utilizador atual não for o perfil do sistema e o tipo de componente for Utilizador ou UserAndSystem, o componente será selecionado para este utilizador. Caso contrário, este componente é ignorado.

      Observação

      A partir deste ponto, LoadState não distingue entre componentes que migram definições do sistema operativo, componentes que migram definições de aplicações e componentes que migram os ficheiros dos utilizadores. LoadState avalia todos os componentes da mesma forma.

    2. Cada componente selecionado é processado ainda mais. Todas as variáveis específicas do perfil (como CSIDL_PERSONAL) são avaliadas no contexto do perfil atual. Por exemplo, se o perfil que está a ser processado pertencer ao Utilizador1, CSIDL_PERSONAL expandir-se-ia para C:\Users\User1\Documents (partindo do princípio de que os perfis de utilizador estão armazenados no C:\Users diretório).

      Observação

      LoadState ignora a <secção deteta> especificada num componente. Neste momento, todos os componentes especificados são considerados como detetados e estão selecionados para migração.

    3. Para cada componente selecionado, LoadState avalia as <secções de regras> . Para cada <secção de regras>, se o perfil de utilizador atual for o perfil do sistema e o contexto da secção de< regras> for Sistema ou UserAndSystem, a regra é processada ainda mais. Caso contrário, esta regra é ignorada. Em alternativa, se o perfil de utilizador atual não for o perfil do sistema e o contexto da secção de <regras> for Utilizador ou UserAndSystem, a regra é processada ainda mais. Caso contrário, esta regra é ignorada.

    4. LoadState cria uma lista central de unidades de migração ao processar as várias subsecções na <secção de regras> . Cada unidade de migração que está numa <subsecção de inclusão> é migrada durante o tempo, uma vez que não existe uma regra mais específica para a mesma numa <subsecção de exclusão> na mesma <secção de regras> . Para obter mais informações sobre precedência, veja Conflitos e precedência.

    5. LoadState avalia as subsecções específicas do computador de destino, por exemplo, as <subsecções destinationCleanup> e <locationModify> .

    6. Se o computador de destino estiver a executar uma versão suportada atualmente do Windows, os migunits que foram recolhidos pelo ScanState através de ficheiros de manifesto de nível inferior são processados por LoadState através do Manifesto de Componente correspondente da versão inferior do Windows. Os ficheiros de manifesto de nível inferior não são utilizados durante LoadState.

      Importante

      Para o LoadState utilizar os ficheiros .xml , é importante especificá-los com o LoadState.exe comando . Caso contrário, quaisquer regras específicas de destino, como <locationModify>, nestes ficheiros de.xml são ignoradas, mesmo que os mesmos ficheiros.xml tenham sido fornecidos quando o ScanState.exe comando foi executado.

  5. Na fase Aplicar , LoadState escreve as unidades de migração que foram recolhidas para as várias localizações no computador de destino. Se existirem conflitos e não existir uma <regra de intercalação> para o objeto, o comportamento predefinido do registo é que a origem substitua o destino. O comportamento predefinido dos ficheiros é que o nome da origem seja alterado incrementalmente, por exemplo, NomeDoFicheiro Original(1). OriginalExtension. Algumas definições, como tipos de letra, padrões de fundo e definições de poupança de ecrã, só têm efeito na próxima vez que o utilizador iniciar sessão. Por este motivo, termine sessão quando as ações de LoadState.exe comando estiverem concluídas.