Partager via

Bonnes pratiques usMT

Cet article décrit les meilleures pratiques générales et liées à la sécurité lors de l’utilisation de l’outil de migration de l’état utilisateur (USMT).

Meilleures pratiques générales

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

    Bien que ce ne soit pas toujours essentiel, il est recommandé d’installer toutes les applications sur l’ordinateur de destination avant de restaurer l’état utilisateur. L’installation des applications avant la restauration de l’état utilisateur permet de s’assurer que les paramètres migrés sont conservés.

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

    Si et MigUser.xmlMigDocs.xml sont utilisés ensemble, certains fichiers migrés peuvent être dupliqués si des instructions en conflit sont fournies sur les emplacements cibles. L’option /genmigxml de ligne de commande peut être utilisée pour déterminer quels fichiers sont inclus dans la migration et pour déterminer si des modifications sont nécessaires. Pour plus d’informations, consultez Identifier les types de fichiers, les fichiers et les dossiers.

  • Utilisez MigDocs.xml pour une meilleure expérience de migration.

    Si le jeu de données est inconnu ou si de nombreux fichiers sont stockés en dehors des dossiers de profil utilisateur standard, le MigDocs.xml fichier est un meilleur choix que le MigUser.xml fichier, car le MigDocs.xml fichier collecte une étendue plus large de données. Le MigDocs.xml fichier migre les dossiers de données en fonction de l’emplacement et du type de fichier inscrit en interrogeant le registre pour les extensions d’application inscrites. Le MigUser.xml fichier migre uniquement les fichiers avec les extensions de fichier spécifiées.

  • Fermez toutes les applications avant d’exécuter les outils ScanState ou LoadState.

    Bien que l’utilisation du /vsc commutateur puisse permettre la migration de nombreux fichiers ouverts avec une autre application, il est recommandé de fermer toutes les applications afin de garantir la migration de tous les fichiers et paramètres. Sans commutateur ou /c , l’outil /vsc USMT échoue lorsqu’il ne peut pas migrer un fichier ou un paramètre. Lorsque l’option /c est utilisée, USMT ignore tous les fichiers ou paramètres qu’il ne peut pas migrer et enregistre une erreur à chaque fois.

  • Déconnectez-vous après avoir exécuté LoadState.

    Certains paramètres, tels que les polices, le papier peint et les paramètres d’écran de veille, ne prendront effet qu’à la prochaine connexion de l’utilisateur. Pour cette raison, déconnectez-vous après avoir exécuté l’outil LoadState .

  • Environnement managé.

    Pour créer un environnement managé, tous les documents de l’utilisateur final peuvent être déplacés dans le dossier Documents (%CSIDL_PERSONAL%). Microsoft recommande de migrer les fichiers vers le plus petit nombre possible de dossiers sur l’ordinateur de destination. La réduction des dossiers permet d’propre fichiers sur l’ordinateur de destination si la LoadState.exe commande échoue avant la fin.

  • Chkdsk.exe.

    Microsoft recommande d’exécuter Chkdsk.exe avant d’exécuter les outils ScanState et LoadState . Chkdsk.exe crée un rapport status pour un disque dur et répertorie et corrige les erreurs courantes. Pour plus d’informations sur l’outil Chkdsk.exe , consultez Chkdsk.

  • Migrer en groupes.

    Si la migration est effectuée pendant que les utilisateurs utilisent le réseau, il est préférable de migrer des comptes d’utilisateur dans des groupes. Pour réduire l’impact sur les performances réseau, déterminez la taille des groupes en fonction de la taille de chaque compte d’utilisateur. La migration en phases permet également de s’assurer que chaque phase est réussie avant de commencer la phase suivante. Lorsque cette méthode est utilisée, toutes les modifications nécessaires peuvent être apportées au plan entre les groupes.

Meilleures pratiques de sécurité

En tant qu’administrateur autorisé, il est de la responsabilité de protéger la confidentialité des utilisateurs et de maintenir la sécurité pendant et après la migration. En particulier, les questions suivantes doivent être prises en compte :

  • Système de fichiers EFS (Encrypting File System).

    Soyez extrêmement prudent lors de la migration de fichiers chiffrés, car l’utilisateur final n’a pas besoin d’être connecté pour capturer l’état de l’utilisateur. Par défaut, l’outil USMT échoue si un fichier chiffré est trouvé. Pour obtenir des instructions spécifiques sur les meilleures pratiques EFS, consultez Migrer des fichiers et des certificats EFS.

    Remarque

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

  • Chiffrez le magasin.

    Envisagez d’utiliser l’option /encrypt avec la ScanState.exe commande et l’option /decrypt avec la LoadState.exe commande . Toutefois, faites preuve d’une extrême prudence avec cet ensemble d’options, car toute personne ayant accès au ScanState.exe script de ligne de commande a également accès à la clé de chiffrement.

  • Analyse antivirus.

    Microsoft recommande d’analyser les ordinateurs source et de destination à la recherche de virus avant d’exécuter USMT. En outre, l’image de l’ordinateur de destination doit être analysée. Pour protéger les données contre les virus, Microsoft recommande vivement d’exécuter un utilitaire antivirus avant la migration.

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

    Microsoft recommande de gérer la sécurité des serveurs de fichiers et de déploiement. Il est important de s’assurer que le serveur de fichiers dans lequel le magasin est enregistré est sécurisé. Le serveur de déploiement doit également être sécurisé pour s’assurer que les données utilisateur qui se trouvent dans les fichiers journaux ne sont pas exposées. Microsoft recommande également de transmettre uniquement des données via une connexion réseau sécurisée, telle qu’un réseau privé virtuel. Pour plus d’informations sur la sécurité réseau, consultez Microsoft Security Compliance Manager.

  • Migration de mot de passe.

    Pour garantir la confidentialité des utilisateurs finaux, l’outil USMT ne migre pas les mots de passe, y compris les mots de passe pour les applications ou les lecteurs réseau mappés. Il est important de s’assurer que les utilisateurs finaux connaissent leurs mots de passe.

  • Création d’un compte local.

    Avant la migration des comptes locaux, consultez la section Migration des comptes locaux dans l’article Identifier les utilisateurs .

Meilleures pratiques relatives aux fichiers XML

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

    Si un ensemble particulier de fichiers mig*.xml est utilisé avec l’outil ScanState , appelé via l’option /auto ou individuellement via l’option /i , la même option doit être utilisée pour appeler exactement les mêmes fichiers mig*.xml dans l’outil LoadState .

  • Le <CustomFileName> dans l’URLID de migration doit correspondre au nom du fichier.

    Bien que ce ne soit pas obligatoire, il est recommandé que <CustomFileName> corresponde au nom du fichier. Par exemple, l’exemple suivant provient du MigApp.xml fichier :

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

  • Utilisez le schéma XML (MigXML.xsd) lors de la création de fichiers .xml pour valider la syntaxe.

    Le MigXML.xsd fichier de schéma ne doit pas être inclus dans la ligne de commande ou dans les fichiers .xml .

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

    Pour créer un fichier .xml personnalisé, les fichiers de migration.xml peuvent être utilisés comme modèles pour créer des versions personnalisées. Si les fichiers de données utilisateur doivent être migrés, modélisez le fichier .xml personnalisé sur MigUser.xml. Pour migrer les paramètres d’application, modélisez le fichier de.xml personnalisé sur le MigApp.xml fichier.

  • Tenez compte de l’impact sur les performances lors de l’utilisation du paramètre de <contexte> .

    Les performances de migration peuvent être affectées lorsque l’élément <de contexte> est utilisé avec l’élément <component> . Par exemple, lors de l’encapsulation d’unités logiques de règles d’inclusion> et d’exclusion basées sur un fichier ou un< chemin d’accès>.<

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

    Dans le contexte Système , 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 sur le système et une fois pour le système.

    Remarque

    Le nombre de fois où une règle est traitée n’affecte pas le nombre de fois où un fichier est migré. Le moteur de migration USMT garantit que chaque fichier ne migre qu’une seule fois.

  • Microsoft recommande de créer un fichier .xml distinct au lieu d’ajouter .xml code à l’un des fichiers .xml de migration existants.

    Par exemple, pour le code qui migre les paramètres d’une application, le code ne doit pas simplement être ajouté au MigApp.xml fichier.

  • Les fichiers .xml personnalisés ne doivent pas être créés pour modifier les paramètres du système d’exploitation migrés.

    Les fichiers manifeste déterminent les paramètres qui sont migrés. Les fichiers manifeste ne peuvent pas être modifiés. Étant donné que les fichiers manifeste ne peuvent pas être modifiés, pour exclure certains paramètres du système d’exploitation de la migration, créez et modifiez un Config.xml fichier à la place.

  • L’astérisque (*) caractère générique peut être utilisé dans n’importe quel fichier XML de migration créé.

    Remarque

    Le point d’interrogation n’est pas valide en tant que caractère générique dans les fichiers .xml USMT.