Sébastien Warin

Je me suis retrouvé il y a quelques semaines à refaire l’infrastructure IT chez Wygwam en migrant d’un environnement Virtual Server / VM Ware ESX / Windows 2003 vers un environnement full Microsoft avec Windows 2008 R2 / Hyper-V, SCVMM, SCDPM, & Co…

En supprimant proprement des contrôleurs de domaine (via dcpromo) une erreur m’en empêche  m’indiquant que des rôles FSMO ont été supprimés et n’existent plus :
Ownership of the following FSMO role is set to a server which is deleted or does not exist.
Operations which require contacting a FSMO operation master will fail until this condition is corrected.
FSMO Role: CN=Infrastructure,DC=DomainDnsZones,DC=wygwam,DC=com
FSMO Server DN: CN=NTDS Settings\0ADEL:18a67e84-64fc-4be4-97cc-e28dd0100576,CN=WYGSERVER\0ADEL:6cc8b949-b186-4120-9f6b-085c8c84806b,CN=Servers,CN=Premier-Site-par-defaut,CN=Sites,CN=Configuration,DC=wygwam,DC=com

J’ai donc sur ce pas vérifié dans la console MMC d’Active Directory, les “Operations Master” de notre domaine. Mais rien d’anormal, le ou les serveurs pour les différents rôles sont correctement configurés.

Pour creuser un peu plus loin, vous pouvez aussi vérifier voir redéfinir les bons serveurs avec l’utilitaire “NTDSUtil” (en mode “fsmo maintenance”) en suivant notamment la KB255504. Là aussi, dans mon cas, rien d’anormal, tous les rôles FSMO sont correctement configurés vers les bons serveurs comme me le confirme un “netdom query fsmo” :

En relisant l’erreur, ce qui m’a le plus perturbé, c’est le nom du serveur qui pose problème : “WYGSERVER\0ADEL:6cc8b949-b186-4120-9f6b-085c8c84806b”. WYGSERVER étant chez nous un ancien contrôleur de domaine qui nous a “lâché” il y a déjà plusieurs mois/années. Nous avions pourtant à cette époque correctement migré tous les rôles Active Directory, et supprimé complètement les objets AD et DNS vers ce serveur.

En relisant aussi ce message d’erreur, autre interrogation concernant le rôle FSMO qui pose problème : “CN=Infrastructure,DC=DomainDnsZones,DC=wygwam,DC=com”. Visiblement bien que supprimé ce rôle était toujours sous l’appartenance de l’ancien contrôleur “WYGSERVER” et je ne savais où le vérifier (par rapport aux différentes MMC pour la gestion d’Active Directory).

J’ai donc sorti l’artillerie lourde avec “ADSIEdit” pour fouiller ce qu’il y a vraiment dans notre Active Directory. Je n’ai pas tout de suite trouvé car cet objet ne se trouve pas dans les “Naming Context” connus par défaut. Il faut spécifier le “Distinguished  Name”, dans notre cas “DC=DomainDnsZones,DC=wygwam,DC=com” :

Il devient alors possible d’accéder à notre objet “Infrastruture” qui semble être à la source du problème :

En éditant les propriétés de cet objet, j’ai pu constater que l’attribut “fsmoRoleOwner” défini pointé vers notre ancien contrôleur de domaine d’où la présence du “0ADEL:xxxx” dû fait que ce contrôleur n’existait plus :

J’ai donc pu correctement redéfinir cet attribut en sous la forme : “CN=NTDS Settings,CN=<SERVER_NAME>,CN=Servers,CN=<SITE_NAME>, CN=Sites,CN=Configuration,DC=wygwam,DC=com” (en remplaçant respectivement SERVER_NAME et SITE_NAME par le nom de votre serveur et le nom de votre site AD) :

Il a fallut faire de même avec le rôle “ForestDnsZones” en éditant la valeur de l’attribut “fsmoRoleOwner” sur l’objet “Infrastructure” du schéma “CN=ForestDnsZones,DC=wygwam,DC=com”.

Une fois ces rôles correctement configurés, le retrait de contrôleur de domaine dans notre organisation ne vous posera plus de problème 😉