Melhores práticas da USMT
Este artigo aborda as melhores práticas gerais e relacionadas com a segurança ao utilizar a User State Migration Tool (USMT).
Práticas recomendadas gerais
Instale aplicações antes de executar a ferramenta LoadState.
Embora nem sempre seja essencial, é melhor prática instalar todas as aplicações no computador de destino antes de restaurar o estado do utilizador. Instalar aplicações antes de restaurar o estado do utilizador ajuda a garantir que as definições migradas são preservadas.
Não utilize MigUser.xml e MigDocs.xml em conjunto.
Se ambos
MigUser.xml
eMigDocs.xml
forem utilizados em conjunto, alguns ficheiros migrados podem ser duplicados se forem dadas instruções em conflito sobre localizações de destino. A/genmigxml
opção da linha de comandos pode ser utilizada para determinar que ficheiros estão incluídos na migração e para determinar se são necessárias modificações. Para obter mais informações, veja Identificar tipos de ficheiro, ficheiros e pastas.Utilize MigDocs.xml para uma melhor experiência de migração.
Se o conjunto de dados for desconhecido ou se muitos ficheiros estiverem armazenados fora das pastas de perfil de utilizador padrão, o
MigDocs.xml
ficheiro é uma escolha melhor do que oMigUser.xml
ficheiro, uma vez que oMigDocs.xml
ficheiro recolhe um âmbito de dados mais amplo. OMigDocs.xml
ficheiro migra pastas de dados com base na localização e no tipo de ficheiro registado ao consultar o registo para obter extensões de aplicação registadas. OMigUser.xml
ficheiro migra apenas os ficheiros com as extensões de ficheiro especificadas.Feche todas as aplicações antes de executar as ferramentas ScanState ou LoadState.
Embora a utilização do
/vsc
comutador possa permitir a migração de muitos ficheiros que estão abertos com outra aplicação, é melhor prática fechar todas as aplicações para garantir que todos os ficheiros e definições são migrados. Sem o/vsc
parâmetro ou/c
, o USMT falha quando não consegue migrar um ficheiro ou definição. Quando a opção é utilizada, a/c
USMT ignora todos os ficheiros ou definições que não pode migrar e regista sempre um erro.Termine sessão depois de executar o LoadState.
Algumas definições, como tipos de letra, padrões de fundo e definições de deteção de ecrã, só entrarão em vigor na próxima vez que o utilizador iniciar sessão. Por este motivo, termine sessão depois de executar a ferramenta LoadState .
Ambiente gerido.
Para criar um ambiente gerido, todos os documentos do utilizador final podem ser movidos para a pasta Documentos (%CSIDL_PERSONAL%). A Microsoft recomenda a migração de ficheiros para o menor número possível de pastas no computador de destino. Minimizar as pastas ajuda a limpar ficheiros no computador de destino se o comando falhar antes da
LoadState.exe
conclusão.Chkdsk.exe.
A Microsoft recomenda executar Chkdsk.exe antes de executar as ferramentas ScanState e LoadState . Chkdsk.exe cria um relatório de estado para uma unidade de disco rígido e lista e corrige erros comuns. Para obter mais informações sobre a ferramenta Chkdsk.exe , consulte Chkdsk.
Migrar em grupos.
Se a migração for efetuada enquanto os utilizadores utilizam a rede, é melhor migrar contas de utilizador em grupos. Para minimizar o efeito no desempenho da rede, determine o tamanho dos grupos com base no tamanho de cada conta de utilizador. Migrar por fases também permite garantir que cada fase é bem-sucedida antes de iniciar a fase seguinte. Quando este método for, podem ser efetuadas quaisquer modificações necessárias ao plano entre grupos.
Práticas recomendadas de segurança
Enquanto administrador autorizado, é da responsabilidade proteger a privacidade dos utilizadores e manter a segurança durante e após a migração. Em particular, os seguintes problemas têm de ser considerados:
Encriptar o Sistema de Ficheiros (EFS).
Tenha muito cuidado ao migrar ficheiros encriptados, porque o utilizador final não precisa de ter sessão iniciada para capturar o estado do utilizador. Por predefinição, o USMT falha se for encontrado um ficheiro encriptado. Para obter instruções específicas sobre as melhores práticas do EFS, veja Migrar Ficheiros e Certificados EFS.
Observação
Se um ficheiro encriptado for migrado sem também migrar o certificado, os utilizadores finais não poderão aceder ao ficheiro após a migração.
Encripte o arquivo.
Considere utilizar a opção
/encrypt
com oScanState.exe
comando e a opção/decrypt
com oLoadState.exe
comando . No entanto, tenha muito cuidado com este conjunto de opções, uma vez que qualquer pessoa que tenha acesso ao script daScanState.exe
linha de comandos também tem acesso à chave de encriptação.Análise de Vírus.
A Microsoft recomenda analisar vírus nos computadores de origem e de destino antes de executar o USMT. Além disso, a imagem do computador de destino deve ser analisada. Para ajudar a proteger os dados contra vírus, a Microsoft recomenda vivamente a execução de um utilitário antivírus antes da migração.
Mantenha a segurança do servidor de ficheiros e do servidor de implementação.
A Microsoft recomenda a gestão da segurança dos servidores de ficheiros e implementação. É importante certificar-se de que o servidor de ficheiros onde o arquivo está guardado é seguro. O servidor de implementação também tem de ser protegido para garantir que os dados do utilizador que estão nos ficheiros de registo não são expostos. A Microsoft também recomenda que transmita apenas dados através de uma ligação de rede segura, como uma rede privada virtual. Para obter mais informações sobre a segurança de rede, consulte Gestor de Conformidade de Segurança da Microsoft.
Migração de Palavras-passe.
Para garantir a privacidade dos utilizadores finais, a USMT não migra palavras-passe, incluindo palavras-passe para aplicações ou unidades de rede mapeadas. É importante certificar-se de que os utilizadores finais sabem as respetivas palavras-passe.
Criação de Conta Local.
Antes de as contas locais serem migradas, veja a secção Migrar Contas Locais no artigo Identificar Utilizadores .
Melhores práticas do ficheiro XML
Especifique o mesmo conjunto de ficheiros mig*.xml nas ferramentas ScanState e LoadState.
Se um determinado conjunto de ficheiros mig*.xml for utilizado com a ferramenta ScanState , chamada através da opção
/auto
ou individualmente através da opção/i
, a mesma opção deve ser utilizada para chamar exatamente os mesmos ficheiros mig*.xml na ferramenta LoadState .O <CustomFileName> no urlid de migração deve corresponder ao nome do ficheiro.
Embora não seja um requisito, é uma boa prática que <CustomFileName> corresponda ao nome do ficheiro. Por exemplo, o exemplo seguinte é do
MigApp.xml
ficheiro :<?xml version="1.0" encoding="UTF-8"?> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migapp">
Utilize o Esquema XML (MigXML.xsd) ao criar .xml ficheiros para validar a sintaxe.
O
MigXML.xsd
ficheiro de esquema não deve ser incluído na linha de comandos ou em nenhum dos ficheiros .xml .Utilize os ficheiros XML de migração predefinidos como modelos.
Para criar um ficheiro de.xml personalizado, os ficheiros .xml de migração podem ser utilizados como modelos para criar versões personalizadas. Se os ficheiros de dados do utilizador precisarem de ser migrados, modele o ficheiro de.xml personalizado no
MigUser.xml
. Para migrar as definições da aplicação, modele o ficheiro de.xml personalizado noMigApp.xml
ficheiro.Considere o impacto no desempenho ao utilizar o <parâmetro de contexto> .
O desempenho da migração pode ser afetado quando o <elemento de contexto> é utilizado com o elemento do< componente>. Por exemplo, ao encapsular unidades lógicas de regras baseadas em <ficheiros ou caminhos, inclua> e <exclua> regras.
No contexto utilizador , uma regra é processada uma vez para cada utilizador no sistema.
No contexto do Sistema , uma regra é processada uma vez para o sistema.
No contexto UserAndSystem , uma regra é processada uma vez para cada utilizador no sistema e uma vez para o sistema.
Observação
O número de vezes que uma regra é processada não afeta o número de vezes que um ficheiro é migrado. O motor de migração USMT garante que cada ficheiro migra apenas uma vez.
A Microsoft recomenda criar um ficheiro de .xml separado em vez de adicionar .xml código a um dos ficheiros de migração .xml existentes.
Por exemplo, para o código que migra as definições de uma aplicação, o código não deve ser adicionado apenas ao
MigApp.xml
ficheiro.Os ficheiros .xml personalizados não devem ser criados para alterar as definições do sistema operativo que são migradas.
Os ficheiros de manifesto determinam que definições são migradas. Os ficheiros de manifesto não podem ser modificados. Uma vez que os ficheiros de manifesto não podem ser modificados, para excluir determinadas definições do sistema operativo da migração, crie e modifique um
Config.xml
ficheiro.O caráter universal asterisco (*) pode ser utilizado em qualquer ficheiro XML de migração criado.
Observação
O ponto de interrogação não é válido como caráter universal nos ficheiros .xml USMT.