Active Directory : redéfinir correctement TOUS les rôles

FSMO y compris le Forest et Domain Dns Zone

Pour info 1 an après et pour répondre: Il faut effectuer la manip depuis le nouveau serveur détenant
les rôles et non depuis le serveur que l’on souhaite rétrograder
petite précision, il faut faire la modification dans forest avant domain car sinon message d’erreur
d’écriture 5003

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”.

Merci bien j’ai pu régler mon souci grâce à toi. En revanche pour la partie ForestDnsZones c’est
DC=ForestDNSZones et non CN

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