Analyser automatiquement les performances de vos contrôleurs de domaine

Sommaire

 


Introduction

Pour analyser les performances de vos contrôleurs de domaine il existe le collecteur de données « Diagnostics Active Directory ». Il est disponible par défaut sur Windows Server 2008 et est  donc particulièrement utile pour identifier des éventuels problèmes de performances.

Je vais donc dans un premier temps vous montrer à quoi cela ressemble et comment l’utiliser. Ensuite, on ira un peu plus loin afin que vous le lanciez automatiquement et au moment le plus opportun.

 

 

Le collecteur de données « Diagnostics Active Directory »

Introduit sous Windows Server 2003 et connu sous le nom de « Server Performance Advisor » (http://www.microsoft.com/en-us/download/details.aspx?id=15506), il est désormais intégré nativement sous Windows Server 2008 sous la forme d’un collecteur de données et est donc appelé « Diagnostics Active Directory ». Il permet de faire une collecte de données exhaustive sur le contrôleur de domaine et de générer un rapport au format HTML.

De plus, le rapport est particulièrement intéressant car Microsoft à créer un ensemble de règles permettant de mettre en relief ce qui ne va pas (exemple : un manque de mémoire, une requête LDAP malformée ou/et consommatrice…). Il n’est donc pas nécessaire de se creuser la tête pendant des heures sur l’analyse de données.

Pour générer donc un rapport de diagnostiques il faut premièrement lancer la console « Analyseur de performances ». Pour cela, vous pouvez lancer depuis « Démarrer | Exécuter » la commande « perfmon.msc ».

 

Depuis la console « Analyseur de performances », développez l’arborescence « Ensemble de collecteurs de données > Système » et à l’aide d’un clic droit sur  « Active Directory Diagnostics (Diagnostics Active Directory) », sélectionnez « Démarrer ».

 

A la fin de la collecte, un rapport de diagnostiques est disponible depuis « Rapports > Système > Active Directory Diagnostics ».

 

Par défaut, la collecte dure 5 minutes et vous ne pouvez pas la modifier. Si vous voulez l’adapter à vos besoins, alors la seule solution va être de créer un modèle de données personnalisé (dit « utilisateur ») s’appuyant sur le modèle existant (dit « système »). Toutefois, je ne vais pas rentrer plus dans le détail car ce n’est pas l’objet de l’article mais si vous voulez plus d’information sur le sujet, je vous propose déjà l’article suivant : Son of SPA: AD Data Collector Sets in Win2008 and beyond (http://blogs.technet.com/b/askds/archive/2010/06/08/son-of-spa-ad-data-collector-sets-in-win2008-and-beyond.aspx).

Maintenant revenons à nos moutons… Il est particulièrement intéressant de disposer d’un outil de la sorte mais faut-il encore que la collecte soit réalisée au bon moment. L’objectif étant de pouvoir identifier clairement l’origine d’une quelconque défaillance. Et pour cela, il faut que le déclenchement se fasse de manière automatique.

 

 

Présentation de la solution

Généralement, les problèmes de performances sur un contrôleur de domaine se traduisent par une utilisation excessive des ressources CPU par le processus LSASS. Nous allons donc définir une alerte de performance sur la consommation processeur de LSASS qui va, après un certain seuil, déclencher le collecteur de données « Diagnostics Active Directory ».

Pour améliorer la pertinence de notre collecte, l’alerte de performance ne va pas déclencher automatiquement le collecteur de données. Le petit plus de l’article est de passer par le biais d’un script qui prendra en charge le déclenchement de la collecte uniquement après plusieurs alertes.

Prenons un exemple. SCOM, L’outil de supervision Microsoft,  génère par défaut une alerte après avoir collecté, 5 fois d’affilé et sur une fréquence de 5 min, une utilisation du processus LSASS excédant 80% du CPU. Du coup si nous voulons reproduire le même comportement, nous devons enregistrer les différentes alertes remontées par notre alerte de performance durant une période précise. Grâce à ce mécanisme, je vais pouvoir démarrer ma collecte après X alertes sur une période de temps T.

 


Configuration du script

Le script est assez simple. Comme nous le disions un peu plus haut, il va contrôler le nombre d’alertes généré durant une certaine période, et si le seuil est atteint, il lancera le collecteur de données « Diagnostics Active Directory ».

Il est disponible depuis le lien Microsoft Technet : Starting Data Collector Set with PowerShell (managing timeline and sampling) (http://gallery.technet.microsoft.com/scriptcenter/Starting-Data-Collect-Set-1efc0013)

Copiez-le dans le répertoire de votre choix et modifiez-le en fonction de vos besoins.

Les paramètres sont :

  • NbSamples : Le nombre d’alertes nécessaire pour le déclenchement de la collecte (valeur par défaut : 5)
  • Duration : La durée de la période en minutes (valeur par défaut : 25)
  • DCSPath : Le nom du collecteur de données (valeur par défaut : « system\Active Directory Diagnostics »)
  • Notify : Activation de la Notification par message électronique. Vous le recevrez si le collecteur est démarré.

 

Si vous activez le paramètre « Notify », il faudra impérativement assigner les bonnes valeurs aux variables suivantes :

  • SmtpServerName : le nom du serveur SMTP
  • SmtpServerPort : le numéro de port du serveur SMTP
  • SmtpEnableSsl : activation du SSL
  • SmtpServerUsername : nom du compte utilisateur pour l’authentification SMTP
  • SmtpServerPassword : mot de passe du compte utilisateur pour l’authentification SMTP
  • SmtpSender : adresse électronique de l’expéditeur
  • SmtpRecipient : adresse électronique de chaque destinataire (si vous comptez ajouter plusieurs expéditeurs alors il faudra ajouter la liste sous forme d’un tableau)

 

Pour votre information, je me suis appuyé sur la configuration de l’alerte SCOM (l’outil de supervision Microsoft) pour définir à quel moment lancer la collecte. En effet, par défaut SCOM est configuré pour déclencher une action après une capture de 5 alertes toutes les 5 minutes.

 

 

Création de la tâche planifiée

La tâche planifiée est nécessaire pour permettre à l’alerte de performance d’interagir avec le script. En tout cas, c’est la seule solution que j’ai trouvée.

Ouvrez le planificateur de tâches et, à l’aide d’un clic droit, sélectionnez « Créer une tâche… ».

 

Entrez un nom pour cette nouvelle tâche (évitez les espaces) et, éventuellement, une description. Au niveau des options de sécurité, vous pouvez utiliser le compte « Système » et spécifier « Exécuter avec les autorisations maximales ».

 

Par contre, nous ne définirons aucun déclencheur. En effet, le déclenchement de la tâche sera réalisé par l’alerte de performance que nous configurons plus tard.

 

Depuis l’onglet « Actions », cliquez sur le bouton « Nouveau… ».

Pour la définition de la nouvelle action :

  • Action : «  Démarrer un programme »
  • Programme/Script : « powershell.exe »
  • Ajouter des arguments (facultatif) : « -ExecutionPolicy Unrestricted –Command ‘CHEMIN_DU_SCRIPT’ –Notify »

{gallery}88_DCSAD_AUTO/01{/gallery}

 

 

 

 

 

 

 

 

 

Au niveau des autres paramètres, je vous conseillerai à minima de définir  le paramètre « Arrêter la tâche si elle s’exécute plus de » à la valeur « 1 heure ».

 

 

Création de l’alerte de performance

Nous allons maintenant utiliser une alerte de performance en guise de déclencheur pour notre tâche. Notre alerte s’appuiera sur la consommation en processeur du processus LSASS.

Pour cela, il faut passer par la console « Analyseur de performances ». Pour cela, vous pouvez lancer depuis « Démarrer | Exécuter » la commande « perfmon.msc ».

 

Pour créer notre alerte, naviguez jusqu’à « Ensembles de collecteurs de données » et à l’aide d’un clic droit sur « Définis par l’utilisateur », sélectionnez « Nouveau >  Ensemble de collecteurs de données ».

 

Spécifiez le nom de votre alerte de performance. En l’occurrence, j’ai choisi « Alerte Processus LSASS ». Sélectionnez l’option « Créer manuellement (avancé) » et cliquez sur le bouton « Suivant ».

 

Le type de de données à inclure sera « Alerte de compteur de performance ».

 

A l’étape suivante, cliquez sur le bouton « Ajouter… ».

 

Sélectionner le compteur « % temps processeur » sur l’ordinateur local et spécifiez l’instance « lsass ». Cliquez le bouton « Ajouter >> » puis validez.

 

Nous définissons le seuil d’alerte « Au-dessus de 80 ».

 

Notre collecteur de données incluant notre alerte de performance est désormais créée. Il nous reste à préciser l’action à réaliser lorsque que l’alerte est déclenchée. Pour cela, nous allons éditer l’alerte « DataCollector01 » située à l’intérieur de notre de collecteur de données « Alerte Processus LSASS » en cliquant sur « Propriétés » à l’aide d’un clic droit.

 

Depuis l’onglet « Alertes », modifiez la valeur de l’intervalle d’échantillonnage à « 5 Minutes ».

 

Depuis l’onglet « Tâche d’alerte », spécifiez le nom de la tâche planifiée dans le champ « Exécuter cette tâche lorsqu’une alerte est déclenchée : ».

 

La dernière et ultime étape cruciale est le démarrage de la collecte de données pour votre alerte de performance. En effet, il faut que le collecteur soit démarré. Pour cela, fait un clic droit sur votre collecteur de données et sélectionnez l’option « Démarrer ».

 

 

Conclusion

Désormais, en cas de charge prolongé du processus LSASS et en fonction du paramétrage que vous aurez spécifié, le collecteur de données « Diagnostics Active Directory » va se déclencher automatiquement et générer un rapport de performance.

Vous serez désormais en mesure de détecter la cause de vos problèmes de performance !

Réplication AD – l’accès à la réplication a été refusé (Erreur 8453)

Dernièrement, j’ai eu un problème de réplication sur une de mes maquettes. L’erreur remontée par l’outil « repadmin » portait le code erreur « 8453 ». Le message indiquait que « L’accès à la réplication a été refusé ».

 

Fait étrange, une seule partition était concernée. En l’occurrence, il s’agissait de la partition de domaine. La partition de configuration et de schéma se répliquait correctement.

Afin de solutionner mon problème, je me suis référé à la KB Microsoft 2022387 (http://support.microsoft.com/kb/2022387). Hormis un problème de droits avec le compte utilisateur (peu probable étant administrateur du domaine), l’accès refusé pouvait provenir soir d’un problème sur l’attribut « userAccountControl » du compte ordinateur d’un des contrôleurs de domaine incriminé, soit d’un problème de droits sur la partition de domaine.

Le problème sur l’attribut « userAccountControl » ne semblait pas être la cause sachant que certaines partitions se répliquaient correctement. Par acquis de conscience, j’ai toutefois vérifié à l’aide de la commande « dcdiag /test:machineaccount ».

 

J’ai ensuite continué le diagnostic en testant les accès sur l’ensemble de mes partitions Active Directory à l’aide de la commande « dcdiag /test:ncssecdesc ».

BINGO !

 

Le test est particulièrement utile car il permet de lister l’ensemble des droits manquants. On pourrait d’ailleurs confirmer le résultat à l’aide de la commande « dsacls <PARTITION DN> » (distinguishedName de la partition concernée).

 

Clairement, les droits d’accès par défaut doivent être mis à jour sur la partition de domaine. Pour cela, le plus simple est d’utiliser l’outil « ADSIEDIT ».

 

Dans mon exemple, je me connecte donc à la partition de domaine « default naming context ». Dans votre cas, il pourrait peut-être s’agir de la partition de configuration, de schéma ou autre…

 

Il me suffit d’accéder aux propriétés de ma partition, et, depuis l’onglet « Sécurité », rajouter les droits manquants et lister par DCDIAG.

{gallery}87-ADREPL-ACCESSDENIED/01{/gallery}

 

 

 

 

 

 

 

 

 

Le cas échéant, on relance le test « dcdiag /test:ncsecdesc » pour valider que nous n’avons rien oublié.

 

La réplication devrait être de nouveau opérationnelle !

 

Pour votre information, Microsoft liste les droits par défaut pour les trois partitions par défaut d’une forêt:

Défragmentation hors-ligne de la base Active Directory

Sommaire

 

 

Introduction

Cet article va me permettre de vous expliquer rapidement ce qu’est une défragmentation hors-ligne de la base Active Directory et comment la réaliser avec succès.

 

 

Pourquoi faire une défragmentation hors-ligne ?

La défragmentation hors-ligne ne sert qu’à une seule chose : gagner de l’espace disque (en tout cas, rien ne laisse penser le contraire).

En réalité, la base Active Directory est régulièrement défragmentée en ligne. L’opération est réalisée automatiquement par le processus « Garbage Collection » (toutes les 12 heures par défaut). Il réorganise la base de données et libère de l’espace disque mais ne réduit pas physiquement le fichier « NTDS.DIT ». Seul le processus de défragmentation hors-ligne permet de réduire la taille du fichier « NTDS.DIT » en fonction de l’espace libéré par la défragmentation en ligne.

Il vous est d’ailleurs possible de visualiser la taille de disque que vous pourriez économiser. Pour cela, il suffit de modifier une clé de registre (http://technet.microsoft.com/en-us/library/cc816652(v=ws.10).aspx) :

  • Nom de la clé : « 6 Garbage Collection »
  • Chemin : « HKLM\SYSTEM\CurrentControlSet\services\NTDS\Diagnostics »
  • Valeur : « 1 »

 

Lors de la prochaine exécution du « Garbage Collection », vous obtiendrez l’évènement système portant l’id « 1646 » depuis le journal « Directory Service » ci-dessous. Dans cet exemple, nous voyons que nous pouvons gagner environ 100Mb d’espace disque.

 

 

Comment réaliser une défragmentation hors-ligne ?

Premièrement, Veillez à disposer d’une sauvegarde de votre base Active Directory (sauvegarde de l’état système). L’opération n’est pas risquée mais sachant que vous manipulez directement le fichier  « NTDS.DIT », il vaut mieux être prudent.

L’opération doit se réaliser hors-ligne, il faut donc arrêter le service Active Directory. L’avantage sur Windows Server 2008 est que nous pouvons le faire sans passer par le mode de démarrage « Restore Mode » (ou « DSRM »). Pour arrêter le service Active Directory, lancez simplement la commande « net stop ntds ».

 

Une fois le service arrêté, lancez « NTDSUTIL » et saisir les commandes suivantes dans l’ordre indiqué :

  • « Activate instance ntds »
  • « Files »
  • « Compact to [CHEMIN] »

 

L’assistant de compactage, vous invite à réaliser le remplacement de l’ancien fichier « NTDS.DIT » par le nouveau fichier compacté et à supprimer les journaux.

 

Mais avant tout, nous vérifions que le compactage a bien été réalisé. Par exemple, ci-dessous, nous voyons que le fichier « NTDS.DIT » a été réduit de près de 120Mb.

 

Remplacez donc le fichier « NTDS.DIT » existant par le nouveau fichier : « Copy [CHEMIN_DE_LA_BASE_COMPACTEE]  [CHEMIN_DE_LA_BASE_PRODUCTION] »

 

Supprimez les fichiers journaux « del  [CHEMIN_REPERTOIRE_LOGS]\*.log ».

 


Vérifications post-opératoires

Pour être sûr que le fichier compacté est intègre, vous pouvez utiliser de nouveau « NTDSUTIL », en lançant les commandes suivantes :

  • « NTDSUTIL »
  • « Activate instance ntds »
  • « Files »
  • « Integrity »

 

Si le test d’intégrité est OK, alors il ne vous reste plus qu’à redémarrer le service Active Directory à l’aide de la commande « net start ntds ».

 

Enfin, pour valider que le contrôleur de domaine est opérationnel, n’hésitez pas à utiliser l’outil « DCDIAG », de naviguer dans la base locale Active Directory avec la console « Utilisateurs et ordinateurs Active Directory », vérifiez t les réplications avec l’outil « repadmin ».