Stratégie de support et problèmes connus liés à l’outil de migration Active Directory

Cet article décrit les informations sur le niveau actuel de prise en charge de l’outil de migration Active Directory (ADMT) sur les systèmes d’exploitation Windows Client et Windows Server actuels. Cet article répertorie également les problèmes connus rencontrés par les administrateurs lorsqu’ils tentent de migrer des profils utilisateur, des principaux de sécurité, des mots de passe ou des données d’historique des identificateurs de sécurité (sIDHistory) entre les domaines Et forêts Active Directory.

Numéro de base de connaissances d’origine : 4089459

Support Microsoft par système d’exploitation

ADMT a été publié gratuitement pour prendre en charge la migration vers les systèmes d’exploitation Windows Server 2000/Windows Server 2003.

ADMT n’a pas été mis à jour pour prendre en charge les systèmes d’exploitation suivants :

• Windows 11
• Windows 10
• Windows 8.1
• Windows Server 2022
• Windows Server 2019
• Windows Server 2016
• Windows Server 2012 R2

Lorsque vous exécutez ADMT sur des systèmes d’exploitation qui ne sont pas pris en charge, vous pouvez rencontrer les problèmes connus suivants :

• ADMT ne peut pas migrer les profils utilisateur des systèmes d’exploitation ultérieurs à Windows 7 ou Windows Server 2008 R2 vers d’autres systèmes d’exploitation. ADMT ne peut pas également migrer des profils utilisateur vers des systèmes d’exploitation ultérieurs à Windows 7 ou Windows Server 2008 R2 à partir de systèmes d’exploitation plus anciens.
• ADMT n’est pas compatible avec les valeurs par défaut sécurisées utilisées par les systèmes d’exploitation modernes.
• ADMT n’a pas été testé avec les versions ultérieures de Microsoft SQL Server. Si vous utilisez ADMT dans de telles circonstances, vous pouvez rencontrer des incompatibilités ou d’autres problèmes.

Important

Votre expérience dans l’utilisation d’ADMT dépend de nombreux facteurs, notamment la version de Windows à partir de laquelle vous migrez et la version de Windows vers laquelle vous effectuez la migration. Utilisez l’outil à votre propre risque.

Stratégie de cas de support Windows commercial

Microsoft gère les cas de support pour les problèmes ADMT complètement sur une base « best effort ». Les cas de support peuvent ne pas être transmis aux équipes produit. Microsoft ne peut pas garantir que les problèmes seront résolus.

Stratégie de prise en charge au niveau du code

La base de code ADMT 3.2 a été déconseillée. Microsoft a officiellement arrêté tout développement sur la base de code ADMT. ADMT n’est pas éligible pour les correctifs de sécurité, les correctifs de bogues ou les modifications de conception.

Scénarios de support courants et problèmes connus

Cette section répertorie les problèmes les plus courants que vous pouvez rencontrer lorsque vous utilisez ADMT.

Important

La plupart de ces problèmes se produisent en raison de modifications qui ont amélioré les fonctionnalités ou la sécurité de Windows. Certaines solutions à ces problèmes impliquent d’apporter des modifications temporaires à Windows qui nullifient ces améliorations. Utilisez ces solutions à votre propre risque.

ADMT ne s’exécutera pas sur les appareils sur veillant à ce que Windows Defender Credential Guard soit activé

Problème : Vous voyez des erreurs similaires à ce qui suit :

Échec du déplacement de l’objet source CN=User1. Vérifiez que le compte de l’appelant n’est pas marqué comme sensible et ne peut donc pas être délégué. hr=0x8009030e. Aucune information d’identification n’est disponible dans le package de sécurité.

Solution : désactivez temporairement Credential Guard sur le serveur ADMT.

Important

Consultez votre équipe de sécurité avant de modifier la configuration Credential Guard. Sauvegardez le serveur ADMT avant d’apporter des modifications.

La rubrique Gérer Credential Guard de Windows Defender fournit un script qui désactive Credential Guard . Outre l’exécution du script, désactivez l’objet de stratégie de groupe de configuration de lancement sécurisé (GPO) configuration de l’ordinateur\System\Device Guard\System\Device Guard\Secure Launch. Sinon, l’ordinateur réactive Credential Guard la prochaine fois qu’il démarre.

Note

Sur les appareils qui exécutent Windows Server 2022, Credential Guard est activé si l’objet de stratégie de groupe décrit ici est défini sur Non configuré.

Les contrôleurs de domaine ne peuvent pas utiliser la délégation non contrainte

Problème : pendant le processus de migration, ADMT exige que les contrôleurs de domaine utilisent la délégation non contrainte. Cette pratique n’est plus autorisée ou recommandée.

Solution : installez et exécutez des applications ADMT sur le contrôleur de domaine cible. Cette configuration supprime la nécessité de la délégation.

Les applications modernes ne démarrent pas pour un utilisateur qui utilise un profil utilisateur migré

Problème : lorsque vous utilisez ADMT 3.2 pour migrer un profil utilisateur vers un ordinateur client Windows, puis que vous exécutez l’Assistant Traduction de sécurité pour mettre à jour le profil, les applications modernes ne s’exécutent pas. Ces applications incluent les applications intégrées (telles que windows menu Démarrer et recherche) et les applications installées à partir du Windows Store.

Les migrations intra-forêts sont les plus à risque pour ce comportement. Cela est dû au fait que les comptes d’utilisateur migrés intra-forêt ne peuvent pas être restaurés dans le domaine source d’origine.

Solution : une fois la migration terminée, désinstallez les applications modernes, puis réinstallez-les à partir du Windows Store.

Pour plus d’informations sur ce problème, consultez l’application Windows ne peut pas démarrer après l’exécution de la traduction de sécurité ADMT 3.2 dans Windows 8, Windows 8.1 et Windows 10.

La traduction de sécurité réinitialise les associations de fichiers

Problème : vous migrez un profil utilisateur, puis vous exécutez l’Assistant Traduction de sécurité en mode Ajouter. Lorsque vous vous connectez à l’ordinateur pour la première fois après la migration, vous utilisez les informations d’identification utilisateur d’origine (source) au lieu des informations d’identification de l’utilisateur migré (cible). Les associations de fichiers sont réinitialisées à leurs valeurs par défaut et toutes les associations personnalisées sont perdues.

Dans Windows 10, une association de fichiers personnalisée est protégée contre les modifications indésirables à l’aide d’un hachage basé en partie sur l’identificateur de sécurité de l’utilisateur (SID). L’association de fichiers personnalisée et le hachage sont stockés dans le Registre. Lorsque l’utilisateur est migré vers un nouveau domaine, le nouveau compte d’utilisateur reçoit un nouveau SID. Tous les hachages d’association de fichiers doivent être mis à jour en conséquence.

Solution : dès que la migration se termine, désactivez le compte d’utilisateur source. Cette action empêche le problème de se produire.

Les objets qui ont des objets enfants ne sont pas migrés

Problème : lorsque ADMT tente de migrer un objet qui a un objet enfant, la migration échoue et ADMT enregistre l’entrée suivante dans le journal des erreurs de migration :

Erreur 7422 : Échec du déplacement du nom> de l’objet source CN=<object. hr=0x8007208c L’opération ne peut pas être effectuée, car les objets enfants existent. Cette opération ne peut être effectuée que sur un objet enfant.

Voici quelques exemples d’objets enfants qui bloquent la migration, mais qui ne sont pas limités à :

• Exchange Active Sync
• Stratégie de groupe dynamique Microsoft
• TermSrvLicensing
• Citrix SSOSecret et SSOConfig

Solution : vous devez supprimer l’objet enfant (également appelé objet feuille) pour migrer l’objet parent. Par exemple, vous devrez supprimer l’objet Exchange ActiveSync. Sinon, il n’existe aucune solution de contournement connue.

La migration de l’ordinateur échoue sur les appareils qui ont des suffixes DNS personnalisés

Problème : lors d’une migration inter-forêts, vous migrez des ordinateurs configurés pour conserver leur suffixe DNS principal lorsque leur appartenance au domaine change. La vérification post-migration ADMT échoue lorsque ADMT tente de vérifier l’appartenance au domaine de l’ordinateur migré. Les messages d’erreur ressemblent aux exemples suivants :

Erreur 7711 : Impossible de récupérer le nom d’hôte DNS de l’ordinateur migré « workstation1.contoso.com ». La propriété ADSI est introuvable dans le cache de propriétés. (hr=0x8000500d) La vérification post-vérification sera retentée sur l’ordinateur « station de travail1 »

Erreur 7709 : Échec de la vérification post-vérification sur l’ordinateur « workstation1.contoso.com »

Erreur 7675 : Impossible de vérifier que l’ordinateur migré « station de travail1 » appartient au domaine « tailspintoys.com ». L’accès est refusé. (hr=0x80070005)

Pour vérifier cette configuration, ouvrez les propriétés système sur l’ordinateur. Pour ce faire, sélectionnez Paramètres de démarrage>à propos des>paramètres>système avancés>Nom>de l’ordinateur Modifier>plus. Si modifier le suffixe DNS principal lorsque les modifications d’appartenance au domaine ne sont pas sélectionnées, l’ordinateur est affecté par ce problème.

Solution : essayez l’une des méthodes suivantes :

• Configuration manuelle. Après avoir joint l’ordinateur au domaine cible, supprimez les SPN du compte dans le domaine source. Vous pouvez également supprimer le compte d’ordinateur dans le domaine source.

• Configuration du fichier de réponses. Utilisez SyncDomainWithMembership. Vous pouvez définir SyncDomainWithMembership sur 1. Il s’agit de l’équivalent de l’activation du suffixe DNS principal lorsque l’appartenance au domaine change. Ensuite, au cours de la migration, l’ordinateur inscrit des noms de principal de service qui correspondent au nouveau domaine et n’est plus en conflit.

ADMT 3.2 ne démarre pas si TLS 1.0 est désactivé sur l’hôte de base de données SQL Server

Problème : sur un appareil qui héberge une base de données SQL Server, ADMT 3.2 ne démarre pas et affiche les erreurs de sécurité SSL si TLS 1.0 a été désactivé. Cela se produit même si ADMT est installé sur le même ordinateur que l’instance SQL Server. Le message d’erreur est semblable au suivant :

Le système ne peut pas trouver le fichier spécifié.

Solution : sur l’ordinateur sur lequel ADMT est installé, activez temporairement TLS 1.0. ADMT fonctionne même si TLS 1.0 est désactivé sur le contrôleur de domaine.

Important

Consultez votre équipe de sécurité avant d’activer TLS 1.0.

Échec du serveur d’exportation de mot de passe (PES) si la protection LSA est activée

Problème : la migration de mot de passe échoue et génère un message d’erreur semblable à ce qui suit :

Impossible d’établir une session avec le serveur d’exportation de mot de passe. Le serveur RPC est indisponible.

Solution : la migration de mot de passe ADMT fonctionne uniquement si la protection LSA est désactivée.

Important

Consultez votre équipe de sécurité avant de modifier la configuration de la protection LSA. Sauvegardez l’ordinateur avant d’apporter des modifications.

Les profils locaux ne sont pas migrés

Problème : lorsque vous exécutez ADMT 3.2 et l’Assistant Traduction de sécurité, ADMT migre les comptes d’utilisateur locaux, mais pas les profils locaux.

Solution : Ce comportement est normal.

Plus d’informations

ADMT est disponible en téléchargement sur Active Directory Migration Tool version 3.2.