System Center, by Yann Gainche

Je suis tombé récemment sur un cas intéressant chez un client qui souhaitait suivre le volume de connexions à Active Directory depuis des postes clients sans information de site.

Le problème

Lorsqu’un ordinateur se connecte à Active Directory, il tente de localiser un contrôleur de domaine sur son site. Pour cela, il fait des requêtes DNS du type _ldap._tcp.<SiteName>._sites.dc._msdcs.<DnsDomainName>. Si aucun contrôleur de domaine local n’est disponible alors, le poste se replie sur un autre contrôleur de domaine (situé dans un hub parent dans le cas d’une topologie Branch Office) en faisant appel aux enregistrements génériques. La requête DNS est du type _ldap._tcp.dc._msdcs.<DnsDomainName>.

Il y a plusieurs circonstances qui font que la localisation d’un contrôleur de domaine passe par les enregistrements génériques parmi lesquelles:

1. Aucun contrôleur local n’est accessible.
2. Le poste vient d’être installé et ne connais pas son site.
3. Une demande d’authentification en provenance d’une machine en dehors de la forêt Active Directory.
4. Le sous-réseau du client n’est associé à aucun site Active Directory.

Les contrôleurs de domaine qui publient les enregistrements génériques  effectuent un suivi des demandes de connexions en publiant dans le journal Système un évènement ID 5807 source NETLOGON :

Event ID: 5807
Source: NETLOGON
User: N/A
Computer: ComputerName
Description:
During the past [X] hours there have been [Y] connections to this Domain Controller from client machines whose IP addresses don’t map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client’s site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites. The names and IP addresses of the clients in question have been logged on this computer in the following log file…

Cet évènement est publié à peu près toutes les 4 heures et indique le nombre de connexions de clients sans information de site dans la période.

La méthode

Dans mon cas, je souhaitai récupérer la valeur du nombre de connexions [Y] et la publier dans la base de données Operations Manager.

La méthode est la suivante :

Le schéma du Workflow

Pour ce faire, il faut créer un module DataSource composite et l’utiliser pour créer un nouveau type de règle de collecte. Le module Performance.DataGenericMapper permet de transformer le Property Bag générique du module DataSource en Performance Data. Il s’agit d’un module de type Condition Detection Module.

Le Workflow est composé de la sorte :

On pourrait bien sur créer un Typed PropertyBag de type Performance et se passer du module Condition Detection mais l’avantage d’utiliser un PropertyBag générique dans le DataSource permet de réutiliser le DataSource dans un autre workflow tel qu’un moniteur.

L’implémentation

Le module DataSource

Il s’agit d’un module DataSource composite qui comporte un module DataSource standard EventProvider pour récupérer l’évènement suivi d’un module Probe Action de type ScriptPropertyBag. Le script fait un simple parsing du la description de l’évènement pour extraire le nombre de connexions et la renvoyer dans un PropertyBag.

Le module EventDS est plutôt classique et indique la source et le N° d’évènement.

Le module Probe Action passe la description de l’évènement comme paramètre au script.

Le script récupère la valeur dans la description et la publie dans un Property Bag.

La règle de collecte

Cette règle ressemble à une règle classique de récupération d’évènement avec le DataSource créé précédemment et deux modules Write Action pour publier l’information dans la base de données Operations Manager ainsi que dans la base de données du DataWareHouse.

On y a juste ajouté un module Condition Detection pour transformer la donnée générique fournie par le script du module DataSource en une donnée de performance.

Les paramètres du module Performance.DataGenericMapper  effectuent une correspondance entre la donnée retournée par le script et une donnée de performance.

Le résultat en images

Conclusion

Les modules de transformation du type Performance.DataGenericMapper permettent de multiplier les utilisations d’une source de données et facilitent la mise en œuvre des mécanismes d’optimisation (CookDown) de l’agent Operations Manager.

Vous pouvez retrouver les sources de ce pack d’administration ici : http://fichiers.gainche.net/Documents/AD.GenericRecords.xml

Vous pouvez utiliser ce pack d’administration pour suivre l’évolution de votre mise en œuvre des principes d’architecture Active Directory Branch Office ou simplement pour vous en inspirer pour vos propres besoins.