Les rôles listés par netdom query fsmo sont-ils les mêmes que ceux que j'ai vus mentionnés ailleurs ? Par exemple, Domain role owner est-il identique à Domain Naming Master ? RID Pool Manager est-il identique au rôle RID ?
Oui, exactement. Je ne sais pas pourquoi les noms sont légèrement différents dans cet affichage particulier.
Quels sont les problèmes qui pourraient survenir si je prends le contrôle de l'un de ces rôles ?
La prise de contrôle en elle-même ? Pas grand-chose. La plupart des problèmes potentiels signalés concernent la remise en marche de l'ancien DC après la saisie de son rôle - et même dans ce cas, il y a beaucoup d'alarmisme pour pas grand-chose ; il faut des scénarios assez étranges pour casser quoi que ce soit avec une saisie au lieu d'un transfert de rôle. Pour faire une parenthèse, passons en revue les rôles et les risques potentiels :
-
Maître de schéma : Celui-ci rend tout le monde nerveux, mais le casser n'est pas un scénario très probable. La documentation dit que vous ne devez jamais, au grand jamais, rallumer l'ancien maître de schéma après avoir saisi le rôle, ce que je considère comme alarmiste. L'ancien serveur sera informé du changement de rôle, et dès qu'il le sera, il abandonnera le rôle. Le risque potentiel ici est si des modifications sont apportées au nouveau maître de schéma, puis l'ancien maître de schéma est remis en ligne, puis avant qu'il ne réplique depuis les autres DC, des modifications de schéma différentes et conflictuelles sont effectuées sur l'ancien serveur. Cette situation est improbable, mais détruirait votre domaine.
-
Maître de nommage : Même principe que pour le maître de schéma, il faudrait effectuer des modifications (dans ce cas, créer un nouveau domaine dans la forêt) sur l'ancien DC, après avoir saisi son rôle mais avant qu'il ne prenne connaissance de la saisie.
-
Émulateur PDC : Aucun risque, il n'est responsable de rien qui risque de provoquer une divergence.
-
Maître RID : Il faudrait une structure de réplication défaillante pour casser celui-ci - imaginez que vous avez 2 DC ; un ancien maître RID qui ne sait pas que son rôle a été saisi, et un nouveau maître RID. Dans cette situation, il faudrait créer suffisamment d'objets pour épuiser le pool RID sur les deux (ils sont distribués par lots de 500), et leur faire attribuer des pools qui se chevauchent. Créez des objets avec des RID identiques, reconnectez les contrôleurs de domaine, et regardez l'apocalypse se dérouler.
-
Maître d'infrastructure : Honnêtement, probablement 50% des domaines dans le monde n'ont même pas un maître d'infrastructure fonctionnel, puisqu'il ne fonctionne pas lorsqu'il est sur un GC. Dans tous les cas, vous ne pouvez pas le casser avec une saisie.
Les utilisateurs le remarqueront-ils ?
Ils ne devraient pas.
Cette configuration fonctionne depuis longtemps et les gens travaillent plus ou moins normalement ; la prise de contrôle du rôle PDC va-t-elle changer quelque chose ?
Non. Avec un seul DC, aucune des fonctions du PDC ne manque, sauf peut-être le fait que votre DC non-PDC ne puisse pas synchroniser l'heure avec la source souhaitée (le PDC manquant).
De plus :
Vous ne remarquerez l'absence du maître de schéma que lorsque vous essaierez de mettre à jour le schéma
Vous ne remarquerez l'absence du maître de nommage que lorsque vous essaierez de créer un nouveau domaine dans la forêt
Vous ne remarquerez l'absence du maître RID que lorsque vous créerez trop d'objets et épuiserez le pool RID de votre DC (c'est probablement le cas le plus probable pour vous si vous continuez tel quel)
Vous ne remarquerez l'absence du maître d'infrastructure que pour les mises à jour de groupes du catalogue global dans une forêt multi-domaines
Certains de ces documents prédisent de graves conséquences si tous les rôles sont sur un seul DC. Avec une base de clients de maximum 20 - et peut-être moins de 10 la plupart des jours - est-ce que concentrer tous les rôles sur un seul DC est un vrai problème ?
Non - mais ajoutez un second DC. Vous ne voulez pas que votre unique DC tombe en panne.
Y a-t-il des mises en garde concernant le processus de nettoyage recommandé par Microsoft pour supprimer l'ancien DC d'Active Directory ?
Oui - soyez prudent. Mais affûtez vos outils ntdsutil et supprimez les anciennes données - des données superflues n'aident pas à la maintenabilité du domaine.
