Tester la migration

Testez toujours le plan de migration dans un paramètre de laboratoire contrôlé avant de le déployer dans l’ensemble de l’organisation. Dans l’environnement de test, au moins un ordinateur est nécessaire pour chaque type de système d’exploitation à partir duquel les données sont migrées.

Une fois que l’ensemble du processus de migration a été testé sur un seul ordinateur exécutant chacun des systèmes d’exploitation sources de l’organisation, effectuez une migration pilote avec un petit groupe d’utilisateurs. Après avoir migré quelques états utilisateur classiques vers le magasin intermédiaire, notez l’espace nécessaire et ajustez les calculs initiaux en conséquence. Pour plus d’informations sur l’estimation de l’espace nécessaire à la migration, consultez Estimer la taille du magasin de migration. Les informations relatives aux paramètres du Registre et à l’emplacement des fichiers doivent peut-être être ajustées dans les fichiers de règle de migration. Si des modifications sont apportées, testez à nouveau la migration et vérifiez que toutes les données et paramètres ont migré comme prévu. Une migration pilote permet également de tester les estimations d’espace pour le magasin intermédiaire.

Si le test de migration rencontre des erreurs, examinez les journaux ScanState et LoadState pour obtenir le code de retour exact de l’outil de migration de l’état utilisateur (USMT) et les messages d’erreur associés ou le message d’erreur de l’interface de programmation d’application (API) Windows. Pour plus d’informations sur les codes de retour et les messages d’erreur USMT, consultez Codes de retour. Vous pouvez obtenir plus d’informations sur les codes d’erreur système Windows répertoriés en tapant ce qui suit dans une fenêtre d’invite de commandes :

net.exe helpmsg <error_number>

où <error_number> est le numéro de code d’erreur généré par le message d’erreur. Pour plus d’informations sur les codes d’erreur système, consultez Codes d’erreur système (0-499).

Dans la plupart des cas, les journaux ScanState et LoadState indiquent la raison de l’échec d’une migration USMT. Microsoft recommande d’utiliser l’option /v:5 lors du test de la migration. Ce niveau de détail peut être ajusté lors d’une migration de production. La réduction du niveau de détail peut rendre plus difficile le diagnostic des échecs rencontrés pendant les migrations de production. Des niveaux de détail plus élevés peuvent être utilisés si les fichiers journaux doivent être générés pour accéder à un débogueur.

Remarque

L’exécution des outils ScanState et LoadState avec l’option /v:5 crée un fichier journal détaillé. Bien que cette option rend le fichier journal volumineux, elle est utile pour déterminer où les erreurs de migration se sont produites.

Une fois la migration pilote vérifiée qu’elle a correctement migré les fichiers et paramètres spécifiés, l’outil USMT est prêt à être utilisé dans l’environnement pour migrer des données. Par exemple, l’utilisation de l’outil USMT avec Microsoft Configuration Manager. Pour plus d’informations, consultez [Gérer l’état utilisateur dans Configuration Manager]/(mem/configmgr/osd/get-started/manage-user-state).

Remarque

À des fins de test, un magasin non compressé à l’aide de l’option /hardlink /nocompress peut être créé. Lorsque la compression est désactivée, l’outil ScanState enregistre les fichiers et les paramètres dans un dossier masqué nommé File sur <StorePath>\USMT. Le magasin non compressé peut être utilisé pour afficher ce que l’outil USMT a stocké ou pour résoudre un problème. Un utilitaire antivirus peut également être exécuté sur les fichiers. En outre, les éléments suivants peuvent être utilisés pour résoudre les problèmes liés à la migration :

  • Option /listfiles de ligne de commande.
  • Journal de diagnostic qui répertorie les fichiers qui ont été collectés.