Freeze de GPMC sur un Domain Controller
Dans cet article nous allons décrire un problème rencontré sur notre infrastructure de production et détailler sa résolution. L’incident est le suivant: A partir de nos postes d’administration la GPMC freezait dès que l’on clickait sur une OU afin d’afficher les GPOs liées à celle ci, le problème ne se produisait que en étant connecté à un DC en particulier: Dans notre cas il s’agissait du PDC Emulator, si nous indiquions à la console de pointer sur un DC différent, la GPMC fonctionnait normalement.
L’application et la réplication des GPOs dans notre domaine fonctionnait normalement, par contre l’édition des stratégies de groupe sur le DC impacté devenait impossible, en même temps que la GPMC freezait une surcharge CPU du process lsass.exe survenait sur le contrôleur de domaine et ceci tant que la GPMC n’était pas killée sur la console. Nous avons donc continué à éditer nos GPOs à partir d’autres DCs et le fonctionnement de la production était quasi-normal le temps de la résolution de l’incident.
Afin de mieux comprendre le problème, la première chose à faire est de lancer lors du freeze de GPMC une analyse avec Server Performance Advisor sur le DC dont voici le résultat:
On voit que le DC a du mal à effectuer une recherche LDAP initiée par la GPMC et cela entraine une consommation anormale du process lsass.exe, afin d’en savoir plus nous réalisons deux analyses de trames avec WireShark sur nos consoles d’administration: La première en reproduisant le problème en lançant la GPMC connecté au DC impacté, la seconde en connectant la GPMC à un autre DC et sur lequel l’édition de GPOs est possible:
On voit que sur le DC posant problème la requête LDAP n’aboutit pas, au bout de plus de 2 minutes toujours pas de résultat. Lors d’un fonctionnement normal de la GPMC, les GPOs liées à notre OU sont trouvées en quelques secondes.
Il nous faut maintenant identifier quelle requête LDAP n’arrive pas à traiter notre DC, pour cela nous allons activer le diagnostique Active Directory Field Engineering, l’événement d’ID 1644 sera alors généré lorsque le problème survient, celui ci est caractéristique d’une requête LDAP consommant trop de ressources. Une fois l’audit activé, nous avons alors l’événement suivant qui apparaît lors du freeze de GPMC:
Les valeurs retournées par la requête sont GPLink et GPOptions (on peut d’ailleurs observer le résultat sur la capture de trames réseau). Le filtre de recherche se fait sur ObjectCategory qui est un attribut indexé par défaut de la base AD. La requête LDAP devrait donc être réalisée rapidement, ce qui n’est pas du tout le cas, nous en avons malheureusement la confirmation en lançant la même requête avec ldp.exe, le résultat est le suivant:
———–
***Searching…
ldap_search_ext_s(ld, “DC=ldap389,DC=info”
, 2, “( | (objectCategory=CN=Domain-DNS,CN=Schema,CN=Configuration,DC=ldap389,DC=info) (objectCategory=CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=ldap389,DC=info) )”, attrList, 0, svrCtrls, ClntCtrls, 10, 0 ,&msg)
Error: Search: Timeout. <85>
Server error:
Error<94>: ldap_parse_result failed: No result present in message
Getting 0 entries:
———–
La requête tombe en Timeout, alors que sur les autres DCs aucun problème avec celle ci. Nous avons donc décidé dans un premier temps d’augmenter la valeur du paramètre MaxQueryDuration des stratégies LDAP de notre DC, ainsi que de configurer ldp.exe afin d’augmenter la période de TimeOut. Ces manipulations n’ont servi à rien.
Après quelques recherches nous sommes tombés sur cet article très instructif de Tim Springston. Il affirme que:
“if the attribute(s) which are showing as taking an extended amount of time to search for are already indexed then the lack of an index is clearly not your problem. Sometimes indices, perhaps through frequent changes or other reasons, need to be re-indexed to remove “whitespace” or other problems. So checking the integrity of the database or doing an offline defrag may be the way to go.”
Procédons donc d’abord à une analyse sémantique du ntds.dit de notre DC:
Le résultat est immédiat: des inconsistances dans la base ont été trouvées. Nous relançons cette fois la même analyse sur la base, mais en mode “fixer les problèmes” (voir point 11 de la KB). Pour terminer nous réalisons une défragmentation offline du ndts.dit et nous quittons le mode DSRM pour rebooter notre DC normalement.
Une fois le DC redémarré nous essayons d’utiliser la GPMC en étant connecté sur le DC qui posait problème: L’utilisation de l’éditeur de stratégies de groupe se fait normalement et nous pouvons à nouveau éditer des GPOs sur ce contrôleur de domaine.
This post is also available in: Anglais
