Comment forcer les postes de travail à s'authentifier auprès du nouveau contrôleur de domaine 2019

Question

Bonjour,

En vous remerciant d'avances pour votre support,

Pour l'une de nos filiales, nous avions besoin dans le cadre du projet de migration vers M365 (EOL) de mettre à niveau nos 3 contrôleurs de domaine en Windows 2019 R2 vers Windows 2019,

Nous avions procéder par la manière suivante:

• Approvisionnement de nouveaux serveurs Windows 2019,
• Promouvoir en contrôleur de domaine et catalogues globaux
• Nettoyer les Metadata AD et DNS
• Transférer, les rôles FSMO,
• Rétrograder les anciens
• Laisser un seul DC en 2012 R2 pendant quelques jours pour laisser le temps à la réplication

Après avoir rerograder le dernier controleur de domaine en 2012 R2 et supprimer les roles AD et DNS, les postes de travail clients n'arrivent pas à reconnaitre les nouveaux DC comme logon server et persiste à contacter l'ancien (2012 R2)

Après plusieurs tentatives qui nous amenés à 2 reprises de tous restaurer, nous n'arrivons pas à retirer le dernier DC en 2012 R2 et permettre aux utilisateurs de s'authentifier

Cordialement,

Answer 1

Bonjour,
Les deux noms du domaine sont identiques sur 2012 et 2019.
Voir la page support Afficher et transférer des rôles FSMO - Windows Server | Microsoft Learn

Answer 2

Cette réponse a été automatiquement traduite. Par conséquent, il peut y avoir des erreurs grammaticales ou des formulations étranges.

Bonjour TAZI ABDESSAMAD (Externe),

Merci d’avoir posté sur le forum de la communauté Microsoft.

Avez-vous transféré les rôles FSMO vers un nouveau contrôleur de domaine 2019 ? Vous pouvez vérifier le détenteur des rôles FSMO en exécutant netdom query fsmo sur un seul contrôleur de domaine.

Si tous les rôles fsmo sont maintenant sur le nouveau contrôleur de domaine 2019, vous pouvez rétrograder tous les anciens contrôleurs de domaine 2012 R2 du domaine.

Avant de rétrograder les anciens contrôleurs de domaine R2 2012, tenez compte des points suivants :

• Si l’ancien contrôleur de domaine 2012 R2 était un serveur de catalogue global, évaluez si les serveurs d’applications qui pointaient vers le serveur de catalogue global hors connexion doivent être pointés vers un serveur de catalogue global actif.
• Si l’ancien contrôleur de domaine 2012 R2 était un serveur de catalogue global, évaluez si un catalogue global supplémentaire doit être promu vers le site d’adresse, le domaine ou la charge du catalogue global de forêt.
• Si l’ancien contrôleur de domaine 2012 R2 était titulaire d’un rôle FSMO (Flexible Single Master Operation), déplacez ces rôles vers un contrôleur de domaine actif.
• Si l’ancien contrôleur de domaine 2012 R2 était un serveur DNS, mettez à jour la configuration du client DNS sur tous les postes de travail membres, les serveurs membres et les autres contrôleurs de domaine susceptibles d’avoir utilisé ce serveur DNS pour la résolution de noms. Si nécessaire, modifiez l’étendue DHCP pour refléter la suppression du serveur DNS.
• Si l’ancien contrôleur de domaine 2012 R2 était un serveur DNS, mettez à jour les paramètres de redirection et de délégation sur tous les autres serveurs DNS susceptibles d’avoir pointé vers le contrôleur de domaine supprimé pour la résolution de noms. Avant d’ajouter un nouveau contrôleur de domaine 2019 et de rétrograder les anciens contrôleurs de domaine 2012 R2, vous feriez mieux de sauvegarder tous les contrôleurs de domaine à l’aide du rôle de sauvegarde Windows intégré.

Avant et après l’ajout d’un nouveau contrôleur de domaine 2019 et avant et après la rétrogradation des anciens contrôleurs de domaine 2012 R2, vous feriez mieux de vérifier l’atatus de réplication AD et l’intégrité de chaque contrôleur de domaine.

Vérifier l’état de la réplication AD :

**repadmin /showrepl >C :\rep1.txtrepadmin /replsum >C :\rep2.txt**

**repadmin /showrepl \* /csv >c :\repsum.csv**  

Vérifiez l’état du contrôleur de domaine sur chaque contrôleur de domaine.

Dcdiag /v

Vous avez mentionné que vous ne pouvez pas supprimer les anciens contrôleurs de domaine, nettoyez-vous les métadonnées des anciens contrôleurs de domaine ? Lien de référence : Nettoyer les métadonnées du serveur AD DS | Microsoft Learn.

Selon votre description. L’authentification du client recherche toujours l’ancien contrôleur de domaine, qui peut être un serveur DNS et un SRV, et l’enregistrement HOST(A) pointe vers le contrôleur de domaine d’origine, ce qui oblige le client à essayer de se connecter à un contrôleur de domaine dégradé lors du déverrouillage ou de l’ajout d’un domaine.

Vérifiez également que l’ancien contrôleur de domaine a été dégradé avec succès, et si l’ancien contrôleur de domaine n’est pas dégradé avec succès, il peut toujours être considéré comme un contrôleur de domaine actif et l’authentification sera également effectuée. Lien de référence : Rétrogradation des contrôleurs de domaine et des domaines (niveau 200) | Microsoft Learn.

J’espère que les informations ci-dessus vous seront utiles.

Si vous avez des questions ou des préoccupations, n’hésitez pas à nous en faire part.

Sinceres salutations

Daisy Zhou