Le Blog Technique

SCOM 2007 : Hériter des tâches depuis un MP parent

par Cyril Azoulay | 12 Mar 2012 | Uncategorized

Ou comment séparer la définition de l’affichage des tâches.

Voici un problème qui m’a été posé par un de nos clients : comment réutiliser des tâches définies dans un premier Management Pack dans un ou plusieurs autres MP, sans avoir à les recoder à chaque fois ? Après recherche, voici la solution qui a été retenue.

Prenons un exemple simple : via la console Authoring, créons dans un nouveau management pack une tâche console qui lance la calculatrice Windows.

Une fois enregistré non-scellé, le code xml de ce management pack très basique est le suivant :

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>MP_ExempleTask</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>MP_ExempleTask</Name>
    <References>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
</Manifest>
<TypeDefinitions>
    <ModuleTypes>
      <ProbeActionModuleType ID="calcType" Accessibility="Public" Batching="false" PassThrough="false">
        <Configuration />
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <ProbeAction ID="PA" TypeID="System!System.CommandExecuterProbe">
                <ApplicationName><![CDATA[%WINDIR%\System32\calc.EXE]]></ApplicationName>
                <WorkingDirectory />
                <CommandLine>/ALL</CommandLine>
                <TimeoutSeconds>30</TimeoutSeconds>
                <RequireOutput>true</RequireOutput>
                <Files />
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="PA" />
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.PropertyBagData</OutputType>
        <InputType>System!System.BaseData</InputType>
      </ProbeActionModuleType>
    </ModuleTypes>
</TypeDefinitions>
<Presentation>
    <ConsoleTasks>
      <ConsoleTask ID="Task.LocalCalc" Accessibility="Internal" Enabled="true" Target="System!System.Entity" RequireOutput="true" Category="MonitoringObject">
        <Application>%systemroot%\system32\calc.exe</Application>
        <WorkingDirectory />
      </ConsoleTask>
    </ConsoleTasks>
</Presentation>
<LanguagePacks>
    <LanguagePack ID="FRA" IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Task.LocalCalc">
          <Name>Ouvrir Calculatrice</Name>
          <Description />
        </DisplayString>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
</LanguagePacks>
</ManagementPack>

La suite de la manœuvre implique d’utiliser un éditeur de texte : il va falloir séparer les parties « manifest », « défintion » et « affichage » de votre management pack.

Le manifest est le code compris entre les balises <Manifest></Manifest> (surligné plus haut en vert) :

<Manifest>
    <Identity>
      <ID>MP_ExempleTask</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>MP_ExempleTask</Name>
    <References>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
</Manifest>

La partie définition est l’ensemble du code compris entre les balises <TypeDefinitions>[…]</TypeDefinitions> (surligné plus haut en bleu). C’est cette partie qui contient le code de « ce que font » les tâches à proprement parler :

<TypeDefinitions>
    <ModuleTypes>
      <ProbeActionModuleType ID="calcType" Accessibility="Public" Batching="false" PassThrough="false">
        <Configuration />
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <ProbeAction ID="PA" TypeID="System!System.CommandExecuterProbe">
                <ApplicationName><![CDATA[%WINDIR%\System32\calc.EXE]]></ApplicationName>
                <WorkingDirectory />
                <CommandLine>/ALL</CommandLine>
                <TimeoutSeconds>30</TimeoutSeconds>
                <RequireOutput>true</RequireOutput>
                <Files />
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="PA" />
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.PropertyBagData</OutputType>
        <InputType>System!System.BaseData</InputType>
      </ProbeActionModuleType>
    </ModuleTypes>
</TypeDefinitions>

La partie “affichage” est quant à elle celle qui est comprise entre les balises <Presentation>[…]</LanguagePacks> (surlignée plus haut en rouge). C’est cette partie qui se charge de faire apparaitre les tâches dans la console SCOM :

<Presentation>
    <ConsoleTasks>
      <ConsoleTask ID="Task.LocalCalc" Accessibility="Internal" Enabled="true" Target="System!System.Entity" RequireOutput="true" Category="MonitoringObject">
        <Application>%systemroot%\system32\calc.exe</Application>
        <WorkingDirectory />
      </ConsoleTask>
    </ConsoleTasks>
</Presentation>
<LanguagePacks>
    <LanguagePack ID="FRA" IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Task.LocalCalc">
          <Name>Ouvrir Calculatrice</Name>
          <Description />
        </DisplayString>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
</LanguagePacks>

Vous avez isolé ces deux parties? Bien, nous allons pouvoir passer à la suite : il faut maintenant construire deux management packs séparés, et ce toujours à l’aide d’un éditeur de texte.
En toute logique, le premier contiendra la partie définitions et le second la partie affichage… ainsi que quelques subtilités :

Pour le premier, c’est assez simple. Créons un fichier texte que nous nommerons par exemple mp1.xml et copions-y la partie « définition » préalablement extraite, précédée du manifest, le tout encadré par les balises <ManagementPack> nécessaires à la conformité de tout MP :

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>MP1</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>MP1</Name>
    <References>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
</Manifest>
<TypeDefinitions>
    <ModuleTypes>
      <ProbeActionModuleType ID="calcType" Accessibility="Public" Batching="false" PassThrough="false">
        <Configuration />
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <ProbeAction ID="PA" TypeID="System!System.CommandExecuterProbe">
                <ApplicationName><![CDATA[%WINDIR%\System32\calc.EXE]]></ApplicationName>
                <WorkingDirectory />
                <CommandLine>/ALL</CommandLine>
                <TimeoutSeconds>30</TimeoutSeconds>
                <RequireOutput>true</RequireOutput>
                <Files />
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="PA" />
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.PropertyBagData</OutputType>
        <InputType>System!System.BaseData</InputType>
      </ProbeActionModuleType>
    </ModuleTypes>
</TypeDefinitions>
</ManagementPack>

Notez que j’ai également modifié l’ID et le Nom de ce MP, qui s’appelle désormais “MP1”.

Une fois ce fichier XML achevé, il faudra le sauvegarder en tant que Management Pack scellé et noter sa clé publique ; autrement il ne sera pas possible de l’importer dans les MP qui devront y faire appel, puisqu’on ne peut pas hériter d’un MP non scellé.

Passons ensuite au MP2 : il contient également le Manifest (auquel j’ai apporté quelques modifications, détaillées plus bas), suivi cette fois uniquement de la partie affichage :

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>MP2</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>MP2</Name>
    <References>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
<Reference Alias="MP1">
<ID>TaskMP1</ID>
<Version>1.0.0.0</Version>
<PublicKeyToken>0823A712C344907</PublicKeyToken>
      </Reference>
    </References>
</Manifest>
<Presentation>
    <ConsoleTasks>
      <ConsoleTask ID="Task.LocalCalc" Accessibility="Internal" Enabled="true" Target="System!System.Entity" RequireOutput="true" Category="MonitoringObject">
        <Application>%systemroot%\system32\calc.exe</Application>
        <WorkingDirectory />
      </ConsoleTask>
    </ConsoleTasks>
</Presentation>
<LanguagePacks>
    <LanguagePack ID="FRA" IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Task.LocalCalc">
          <Name>Ouvrir Calculatrice</Name>
          <Description />
        </DisplayString>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
</LanguagePacks>
</ManagementPack>

Comme vous pouvez le voir dans la partie surlignée, le MP2 hérite du MP1.

Nous avons donc désormais un MP1.mp (MP1 scellé) et un MP2.xml, qu’il ne reste plus qu’à importer dans la console SCOM l’un après l’autre : les tâches stockées dans le MP1 et appelées dans le MP2 apparaissent bien.

Il sera par la suite possible d’appeler de la même façon les tâches définies dans le MP1 dans autant de management packs « enfants » que nécessaire.

SCOM 2012 – Les nouvelles vues Réseaux

par Christophe Jourdan | 8 Mar 2012 | Supervision (SCOM, NAGIOS)

En termes de monitoring, une des nouveautés de SCOM 2012 est la présence de 4 nouveaux types de vues (Dashboard) orientées réseau.

Network Summary, Network Node, Network Interfaces et Vicinity view.

La vue Network Summary est la seule des quatre à s’afficher par défaut dans la hiérarchie des vues de la partie Navigation, les autres étant disponible via un lien sur la vue Network Summary, via les taches a exécuter ou encore dans le menu contextuel des objets (clic-droit)

Cette vue sert essentiellement a voir l’état générale des équipements et interfaces associés de votre réseau.

La vue Network Node fourni des détails sur l’état de santé d’un équipement particulier. Cette vue est constitué de :

– la vue des liens connectés à l’équipement sélectionné

– des jauges sur la disponibilité de l’équipement dans le temps

– la liste des interfaces de l’équipement, avec la possibilité d’activer/désactiver directement la supervision de l’interface par override.

La vue Network Interface est la plus détaillé des vues sur une interface particulière d’un équipement. Il est important de noter que par défaut SCOM 2012 supervise uniquement les interfaces d’équipements supervisés et celles connectées a des ordinateurs Windows également supervisés.

La vue Network Vicinity (Littéralement « Voisinage Réseau ») est la vue qui traduit le plus l’orientation donné a SCOM 2012, à savoir une vue 360 ° de l’objet.

Cette vue affiche un nœud réseau et tous les ordinateurs Windows et autres équipements réseau connecté à ce nœud.

La possibilité est donnée de basculer entre 5 niveaux de détails de connexion et de visualiser les machines connectés ou non.

En sélectionnant une connexion particulière il est possible d’identifier quelle ports d’équipement réseau est impliqué dans l’état d’une liaison.

La principale limitation dans cette première version des vues Network Vicinity est qu’elle fonctionne uniquement avec des ordinateurs Windows et non les agents Linux, qu’elle ne visualise pas la relation entre un hôte Hyper-V et ses machines virtuelles hébergées, et qu’elle n’affiche pas les interfaces réseaux configurés en « Teaming » comme étant « Teamés ».

Ces limitations devraient disparaitre avec l’évolution de SCOM 2012, notamment à travers le premier service pack.

A noter que l’ensemble de ces 4 types de vues sont visualisable a la fois dans la console native et dans la console web de SCOM 2012.

Powershell–Gestion du réseau

par Julien Bausseron | 2 Mar 2012 | PowerShell

Contexte

Il arrive souvent lors de l’installation de certains produits ou fonctionnalitée de devoir réaliser des opérations de vérification des pré-requis. Le premier pré-requis a satisfaire concerne souvent le réseau:

Suis-je en capacité de joindre ma passerelle?
Le ou les contrôleurs hébergeant les rôles FSMO sont-ils joignable?
Mes serveurs DNS sont-ils joignable?

Pour réaliser ces opérations sur quelques serveurs cela peut être réalisé manuellement, mais lorsque le nombre de serveur est conséquent, cela peut s’avéré fastidieux. Je vous propose de travailler en powerShell pour simplifier/automatiser cette opération.

Etape 1: récupérer la configuration de machine

Pour cela rien de bien compliquer, la commande ipconfig /all nous retourne l’ensemble des éléments nécessaire:

Maintenant il faut pouvoir isolé chaque paramètre de réponse (ici identifiés de 1 a 6). Pour cela un traitement sur le retour d’ipconfig est nécessaire:

1. Adresse IPv4: ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]
2. Masque : ((ipconfig | findstr [0-9].\.)[1]).Split()[-1]
3 Passerelle : ((ipconfig | findstr [0-9].\.)[2]).Split()[-1]
4 Serveur DHCP : ((ipconfig /all| findstr [0-9].\.)[3]).Split()[-1]
5 DNS Principal : ((ipconfig /all| findstr [0-9].\.)[5]).Split()[-1]
6 DNS Secondaire ((ipconfig /all| findstr [0-9].\.)[6]).Split()[-1]

Etape 2: Exécuter un ping en powershell

Pour réaliser cette opération les commandes suivante nous retourne un résultat contenant les valeur attendu:

new-object System.Net.NetworkInformation.ping
$reply = $ping.Send(« 192.168.0.254 »)

Nous savons donc que le ping a fonctionné au travers du status. qu’il reste a isoler puis a traiter. Pour l’isolation, l’utilisation des variables nous simplifie la tache:

Etape 3: Automatisation des résultats

Afin de valider le bon fonctionnement des pré-requis lié au réseau, nous pouvons traiter les retours au travers de différents moyens, pour ma part, je préfère utilisé les conditions au travers du If – Else

#***** Stockage des parametre dans une variable*****#
    $IP= ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]
    $IPMask= ((ipconfig | findstr [0-9].\.)[1]).Split()[-1]
    $IPgtw= ((ipconfig | findstr [0-9].\.)[2]).Split()[-1]
    $IPDHCP=((ipconfig /all| findstr [0-9].\.)[3]).Split()[-1]
    $DNS1=((ipconfig /all| findstr [0-9].\.)[5]).Split()[-1]
    $DNS2=((ipconfig /all| findstr [0-9].\.)[6]).Split()[-1]
  
#**Test passerelle**#
    $reply = ""
    $status =""
    $ping = new-object System.Net.NetworkInformation.ping
    $reply = $ping.Send($IPgtw)
  
if ($reply.status -eq "success")
    {
    write-host "Passerelle joignable" -foregroundColor green
    }
    Else
    {
    write-host "Passerelle injoignable" -foregroundColor red
    }
  
#**Test DHCP**#
    $reply = ""
    $status =""
    $ping = new-object System.Net.NetworkInformation.ping
    $reply = $ping.Send($IPDHCP)
  
if ($reply.status -eq "success")
    {
    write-host "DHCP joignable" -foregroundColor green
    }
    Else
    {
    write-host "DHCP injoignable" -foregroundColor red
    }
#**Test passerelle**#
    $reply = ""
    $status =""
    $ping = new-object System.Net.NetworkInformation.ping
    $reply = $ping.Send($DNS1)
  
if ($reply.status -eq "success")
    {
    write-host "DNS joignable" -foregroundColor green
    }
    Else
    {
        $reply = ""
        $status =""
        $ping = new-object System.Net.NetworkInformation.ping
        $reply = $ping.Send($DNS2)
        if ($reply.status -eq "success")
            {
            write-host "DNS joignable" -foregroundColor green
            }
            Else
            {
            write-host "DNS injoignable" -foregroundColor red
            }        
    }
  

Le résultat positif retourne:

Le résultat négatif retourne:

Conclusion

Cette vérification permet de réaliser un enchainement de script ou d’action si et seulement si les paramètres réseaux sont correct. Par exemple en créant un flag si les résultats sont positif !

Toutes les astuces #tech des collaborateurs de PI Services.

Retrouvez les articles à la une

SCOM 2007 : Hériter des tâches depuis un MP parent

SCOM 2012 – Les nouvelles vues Réseaux

Powershell–Gestion du réseau

Contexte

Etape 1: récupérer la configuration de machine

Etape 2: Exécuter un ping en powershell

Etape 3: Automatisation des résultats

Conclusion

Derniers articles

Aucun résultat

Catégories

Archives

Auteurs/Autrices