Meilleures pratiques concernant USMT

Cette rubrique aborde les meilleures pratiques d’ordre général et de sécurité que vous devez suivre lorsque vous utilisez l’Outil de migration utilisateur (USMT) 5.0.

Meilleures pratiques générales

• Installez les applications avant d’exécuter l’outil LoadState

  Même si cela n’est pas toujours essentiel, il est préférable d’installer toutes les applications sur l’ordinateur de destination avant de restaurer l’état utilisateur. Vous avez ainsi la garantie que les paramètres migrés sont préservés.

• N’utilisez pas les fichiers MigUser.xml et MigDocs.xml ensemble.

  L’utilisation de ces deux fichiers XML peut entraîner la duplication de certains fichiers migrés si les instructions fournies à propos des emplacements cibles sont contradictoires. Vous pouvez utiliser l’option de ligne de commande /genmigxml pour identifier les fichiers à intégrer dans votre migration et pour déterminer si des modifications sont nécessaires. Pour plus d’informations, voir Identifier les types de fichiers, les fichiers et les dossiers.

• Utilisez le fichier MigDocs.xml pour une meilleure migration

  Si votre jeu de données est inconnu ou si un grand nombre de fichiers sont stockés hors des dossiers de profil utilisateur standard, le fichier MigDocs.xml s’avère un meilleur choix que le fichier MigUser.xml car il permet de rassembler un plus large éventail de données. Le fichier MigDocs.xml migre les dossiers de données en fonction de l’emplacement et du type de fichier enregistré. Pour cela, il interroge le Registre et y recherche des extensions d’applications enregistrées. Le fichier MigUser.xml migre seulement les fichiers dotés des extensions spécifiées.

• Fermez toutes les applications avant d’exécuter l’outil ScanState ou LoadState

  Même si l’utilisation du commutateur /vsc peut permettre la migration de nombreux fichiers ouverts avec une autre application, il est recommandé de fermer toutes les applications afin de s’assurer que l’ensemble des fichiers et des paramètres sont migrés. Sans le commutateur /vsc ou /c, l’USMT échoue s’il ne parvient pas à migrer un fichier ou un paramètre. Lorsque vous utilisez l’option /c, l’USMT ignore les fichiers ou les paramètres qu’il ne peut pas migrer et enregistre à chaque fois une erreur dans le journal.

• Fermez votre session après avoir exécuté l’outil LoadState

  Certains paramètres (tels que les polices, le papier peint et l’économiseur d’écran) ne sont effectifs que lors de la prochaine ouverture de session. De ce fait, vous avez tout intérêt à fermer la session après avoir exécuté l’outil LoadState.

• Environnement géré

  Pour créer un environnement géré, vous pouvez déplacer tous les documents de l’utilisateur final dans le dossier Mes documents (%CSIDL_PERSONAL%). Nous vous recommandons de migrer les fichiers dans un minimum de dossiers sur l’ordinateur de destination. Vous pourrez ainsi épurer plus facilement les fichiers sur l’ordinateur de destination si la commande LoadState n’aboutit pas.

• Chkdsk.exe

  Nous vous recommandons d’exécuter Chkdsk.exe avant d’exécuter les outils ScanState et LoadState. Chkdsk.exe crée un rapport d’état pour un lecteur de disque dur et répertorie puis corrige les erreurs courantes. Pour plus d’informations sur l’outil Chkdsk, voir Chkdsk.

• Migrez dans des groupes

  Si vous décidez d’effectuer la migration alors que des utilisateurs travaillent sur le réseau, il est préférable de migrer les comptes d’utilisateurs dans des groupes. Pour limiter autant que possible l’impact sur les performances réseau, déterminez la taille des groupes en fonction de la taille de chaque compte d’utilisateur. Une migration par étapes vous permettra également de vous assurer que chaque étape aboutit avant de passer à la suivante. En optant pour cette méthode, vous pourrez apporter les modifications nécessaires à votre plan entre les groupes.

Meilleures pratiques de sécurité

En qualité d’administrateur agréé, il vous revient de protéger les données personnelles des utilisateurs et de préserver la sécurité pendant et après la migration. Vous devez en particulier tenir compte des points suivants :

• Encrypting File System (EFS)

  Faites preuve d’une extrême prudence lorsque vous migrez des fichiers chiffrés, car l’utilisateur final n’a pas besoin d’être connecté pour capturer l’état utilisateur. Par défaut, l’USMT échoue s’il trouve un fichier chiffré. Pour plus d’informations sur les meilleures pratiques du système de fichiers EFS, voir cet article dans la Base de connaissances Microsoft. Pour obtenir des instructions spécifiques sur les meilleures pratiques inhérentes à ce même système, voir Migrer des fichiers et des certificats EFS.

  Important

  Si vous migrez un dossier chiffré sans migrer également le certificat, les utilisateurs finaux ne pourront pas accéder au fichier après la migration.

• Chiffrez le magasin

  Vous pouvez envisager d’utiliser l’option /encrypt avec la commande ScanState et l’option /decrypt avec la commande LoadState. Toutefois, faites preuve d’une extrême prudence avec ce groupe d’options, car quiconque ayant accès au script de ligne de commande ScanState a aussi accès à la clé de chiffrement.

• Analyse antivirus

  Il est recommandé d’effectuer une analyse antivirus sur les ordinateurs source et de destination avant d’exécuter l’USMT. Par ailleurs, il est préférable d‘analyser l’image de l’ordinateur de destination. Pour protéger les données contre les virus, nous vous recommandons vivement d’exécuter un utilitaire antivirus avant de procéder à la migration.

• Maintenez la sécurité du serveur de fichiers et du serveur de déploiement

  Il est recommandé de maintenir la sécurité des serveurs de fichiers et de déploiement. Il est important de s’assurer que le serveur de fichiers sur lequel vous enregistrez le magasin est sécurisé. Vous devez également sécuriser le serveur de déploiement pour éviter d’exposer les données utilisateur qui figurent dans les fichiers journaux. Nous vous recommandons également de transmettre les données uniquement via une connexion Internet sécurisée, telle qu’un réseau privé virtuel. Pour plus d’informations sur la sécurité réseau, voir Microsoft Security Compliance Manager.

• Migration des mots de passe

  Pour assurer la protection des données personnelles des utilisateurs finaux, l’USMT ne migre pas les mots de passe, y compris ceux employés pour des applications comme Windows Live™ Mail, Microsoft Internet Explorer®, les connexions de type Service d’accès à distance (RAS) et les lecteurs réseau mappés. Il importe de s’assurer que les utilisateurs finaux connaissent leurs mots de passe.

• Création de comptes locaux

  Avant de migrer des comptes locaux, voir la section Migration de comptes locaux dans la rubrique Identifier les utilisateurs.

Meilleures pratiques pour les fichiers XML

• Spécifiez le même jeu de fichiers mig*.xml dans les outils ScanState et LoadState

  Si vous avez utilisé un jeu particulier de fichiers mig*.xml dans l’outil ScanState, appelé soit avec l’option « /auto », soit individuellement avec l’option « /i », vous devez utiliser la même option pour appeler exactement les mêmes fichiers mig*.xml dans l’outil LoadState.

• La valeur <CustomFileName> dans l’ID d’URL de la migration doit correspondre au nom du fichier

  Bien que ce ne soit pas obligatoire, il est préférable que <CustomFileName> soit identique au nom du fichier. Par exemple, ce qui suit provient du fichier MigApp.xml :

  <?xml version="1.0" encoding="UTF-8"?>
  <migration urlid="https://www.microsoft.com/migration/1.0/migxmlext/migapp">
  

• Utilisez le schéma XML (MigXML.xsd) lorsque vous créez des fichiers XML pour valider la syntaxe

  Le fichier de schéma MigXML.xsd ne doit pas apparaître dans la ligne de commande ni dans aucun des fichiers XML..

• Utilisez les fichiers XML de migration par défaut comme modèles

  Pour créer votre propre fichier XML personnalisé, vous pouvez vous servir des fichiers .xml de migration en tant que modèles. Si vous devez migrer des fichiers de données utilisateur, prenez MigUser.xml comme modèle pour créer votre fichier XML personnalisé. Pour migrer des paramètres d’application, basez-vous sur le fichier MigApp.xml.

• Tenez compte de l’impact du paramètre <context> sur les performances

  Si vous l’utilisez conjointement avec l’élément <component>, l’élément <context> peut avoir un impact sur vos performances de migration, par exemple lorsque vous souhaitez encapsuler des unités logiques de règles <include> et <exclude> basées sur des fichiers ou des chemins d’accès.

  Dans le contexte User, une règle est traitée une fois pour chaque utilisateur du système.

  Dans le contexte System, une règle est traitée une fois pour le système.

  Dans le contexte UserAndSystem, une règle est traitée une fois pour chaque utilisateur du système et une fois pour le système.

  Notes

  Le nombre de fois qu’une règle est traitée n’a aucune incidence sur le nombre de fois qu’un fichier est migré. Le moteur de migration de l’USMT s’assure que chaque fichier est migré une seule et unique fois.

• Nous vous recommandons de créer un fichier .xml distinct plutôt que d’ajouter votre code XML à l’un des fichiers .xml de migration existants.

  Par exemple, si vous avez du code qui migre les paramètres d’une application, vous ne devez pas simplement ajouter le code au fichier MigApp.xml.

• Vous ne devez pas créer des fichiers .xml personnalisés dans l’optique de modifier les paramètres de système d’exploitation qui sont migrés.

  Ces paramètres sont modifiés par des manifestes et vous ne pouvez nullement modifier ces fichiers. Si vous souhaitez exclure certains paramètres du système d’exploitation de la migration, vous devez créer et modifier un fichier Config.xml.

• Vous pouvez utiliser un astérisque (*) dans tous les fichiers XML de migration que vous créez.

  Notes

  Le point d’interrogation n’est pas un caractère générique valide dans les fichiers XML de l’USMT.

Voir aussi

Autres ressources

Chiffrement de magasin de migration
Planifier votre migration