Tester votre migration
Veillez à toujours tester votre plan de migration dans un laboratoire contrôlé avant de le déployer à l’échelle de votre organisation. Dans votre environnement de test, vous devez avoir au moins un ordinateur pour chaque type de système d’exploitation à partir duquel vous migrez des données. Par exemple, si vous migrez des données à partir d’ordinateurs sources exécutant Windows® XP ou Windows Vista®, vous devez tester au moins un ordinateur exécutant chacun de ces systèmes d’exploitation.
Après avoir soigneusement testé l’intégralité du processus de migration sur un ordinateur exécutant chacun de vos systèmes d’exploitation sources, effectuez une migration pilote avec un petit groupe d’utilisateurs. Après avoir migré quelques états utilisateur par défaut vers le magasin intermédiaire, notez l’espace requis et ajustez vos calculs initiaux en conséquence. Pour plus de détails sur l’estimation de l’espace nécessaire pour votre migration, voir Estimer la taille des magasins de migration. Vous devrez peut-être également ajuster les informations relatives aux paramètres de Registre et aux emplacements de fichiers dans vos fichiers de règles de migration. Si vous apportez des modifications, testez de nouveau la migration. Ensuite, vérifiez que toutes les données et tous les paramètres ont été migrés comme prévu. Une migration pilote vous offre également l’opportunité de tester vos estimations en matière d’espace pour le magasin intermédiaire.
Si vous rencontrez des erreurs durant votre migration test, examinez les journaux ScanState et LoadState afin d’obtenir le code de retour Outil de migration utilisateur (USMT) 5.0 exact et le message d’erreur de l’API (Application Programming Interface) Windows ou les messages d’erreurs associés. Pour plus d’informations sur les codes de retour et les messages d’erreur de l’USMT, voir Codes de retour. Vous pouvez également obtenir davantage d’informations sur un message d’erreur de l’API Windows en tapant net helpmsg et le numéro du message d’erreur sur la ligne de commande.
Dans la plupart des cas, les journaux ScanState et LoadState indiquent les raisons de l’échec d’une migration de l’USMT. Nous vous conseillons d’utiliser l’option /v*:5* durant le test de votre migration. Ce niveau de commentaires peut être ajusté dans une migration de production. La réduction du niveau de commentaires peut rendre plus difficile le diagnostic des échecs rencontrés durant les migrations de production. Vous pouvez utiliser un niveau de commentaires supérieur si vous voulez que la sortie des fichiers journaux soit envoyée à un débogueur.
Notes
L’exécution des outils ScanState et LoadState avec l’option /v:5 donne lieu à la création d’un fichier journal détaillé. Bien que cette option accroisse la taille du fichier journal, elle aide à déterminer l’emplacement où les erreurs de migration se sont produites.
Une fois que vous avez déterminé que la migration pilote a migré avec succès les fichiers et paramètres spécifiés, vous êtes prêt à ajouter USMT au serveur qui exécute Microsoft® System Center Configuration Manager (SCCM) ou une technologie de gestion non-Microsoft. Pour plus d’informations, voir Configuration Manager.
Notes
À des fins de test, vous pouvez créer un magasin non compressé à l’aide de l’option /hardlink /nocompress. Lorsque la compression est désactivée, l’outil ScanState enregistre les fichiers et paramètres dans un dossier masqué nommé « File » dans chemin_magasin\USMT. Vous pouvez utiliser le magasin non compressé pour afficher ce que USMT a stocké ou pour résoudre un problème, ou vous pouvez exécuter un utilitaire antivirus sur les fichiers. En outre, vous pouvez utiliser l’option de ligne de commande /listfiles et le journal de diagnostic pour répertorier les fichiers qui ont été recueillis et pour résoudre les problèmes liés à votre migration.