PI Services

Bien que ce sujet puisse sembler dépassé, il peut en réalité encore servir aujourd’hui précisément dans le cadre d’une migration Exchange 2003 vers Exchange 2010 (par exemple pour ne migrer que les utilisateurs disposant d’une version d’Outlook supérieure ou égale à la 2007).

Il n’est pas possible de retrouver cette information directement à l’aide d’un cmdlet Powershell pré-existant, mais une requête WMI (classe Exchange_Logon du namespace root\MicrosoftExchangev2) exécutée via Powershell le permet :

Get-wmiobject -class Exchange_Logon -Namespace ROOT\MicrosoftExchangev2 -ComputerName ServerA -filter "LoggedOnUserAccount != 'NT AUTHORITY\\SYSTEM'" | select-object MailboxDisplayName,ClientVersion

La commande précédente permet donc de lister la version du client utilisée par chaque utilisateur pour se connecter.
On remarque qu’elle est nécessairement ciblée sur un serveur Exchange 2003 spécifique (-ComputerName ServerA).

Cependant, dans le cas où Exchange est configuré en cluster, il faut obligatoirement interroger le noeud actif pour obtenir cette information.
Il peut donc s’avérer utile de retrouver quel est le nœud actif d’un cluster à l’aide d’un script, encore une fois via WMI et Powershell (classe mscluster_nodetoactivegroup du namespace root\mscluster) puisque là non plus, Powershell ne permet pas nativement de retrouver cette information :

Get-WmiObject –ComputerName NomVirtuelduCluster –Namespace\root\mscluster –class mscluster_nodetoactivegroup  | select groupcomponent,partcomponent

Afin de ne conserver de ce résultat que la partie qui nous intéresse, à savoir le nom du noeud actif à proprement parler, on utilise la commande suivante :

$activenode = (( Get-WmiObject -ComputerName $myLegacyExchangeCluster -Namespace root\mscluster -Class mscluster_nodetoactivegroup -ErrorAction SilentlyContinue | Where-Object { $_.PartComponent -like "*Exchange Group*" } ).GroupComponent ).Split('"')[1]

Il ne reste alors plus qu’à réintégrer cette valeur à la première commande via le paramètre  –ComputerName $activenode afin d’obtenir un fonctionnement automatisé.

Lors du déploiement d’un management pack dont les découvertes sont basées sur des scripts locaux (par exemple Exchange 2010) dans SCOM 2007 R2 dans un environnement où les serveurs sont protégés par McAfee VirusScan Enterprise, les services concernés ne sont pas découverts et leur état n’apparait donc pas dans l’écran Supervision de SCOM.

En parallèle, des processus cscript.exe tournent sans fin sur les serveurs concernés et des alertes « Workflow Initialization Failed to start a workflow that runs a process or script » remontent dans SCOM :

Des erreurs cscript.exe sont également enregistrées dans l’Application Event Log de Windows sur les serveurs où se trouvent les services et applications qui devraient être découverts :

Ce problème est lié au module ScriptScan de McAfee VSE en version 8.8 qui se comporte de façon assez inattendue : lorsqu’il est désactivé, il empêche malgré tout l’exécution des scripts (dont ceux nécessaires à la détection des composants que SCOM cherche à monitorer) et ce même si les exclusions adéquates sont positionnées.

Trois solutions sont alors disponibles :

• Activer le module ScriptScan
• Complètement désinstaller la fonctionnalité ScriptScan en désenregsitrant la dll SCRIPTSN.dll sur chaque serveur :
  cd "C:\Program Files\Common Files\McAfee\SystemCore"
  regsvr32.exe /u SCRIPTSN.dll
• Déployer la version 8.8 patch 1 mise à disposition par McAfee.

C’est bien entendu cette dernière solution qu’il faudra privilégier. Pour plus de détails sur ce blocage, McAfee a également publié une KB à ce sujet : https://kc.mcafee.com/corporate/index?page=content&id=KB71660

Les « tâches console » sont comme leur nom l’indique des tâches qui s’exécutent sur la console, par opposition aux tâches Agent qui sont elles exécutées sur les ordinateurs monitorés et dont le résultat est ensuite affiché dans la console.

Elles permettent de lancer un exécutable sur l’ordinateur exécutant la console, éventuellement en lui passant des paramètres récupérés dans la console.

Exemple concret : on peut ainsi lancer un ping ou une session bureau à distance automatiquement vers le l’ordinateur sélectionné dans  la console.

Je détaillerai ici le cas rencontré chez un client qui souhaitait pouvoir accéder aux incidents créés indépendamment de SCOM dans un système de gestion de tickets tiers à la suite de la remontée de certaines alertes dans SCOM.
Ce système de ticket étant accessible via un simple navigateur web sur une url fixe prenant l’ID du ticket en paramètre (ID préalablement renseignée dans un CustomField de l’alerte par le helpdesk), nous avons procédé de la sorte :

Dans la console Authoring (et non pas la vue authoring de la console Operations, cette dernière ne permet pas de créer ce genre de tâche!), créer un nouveau management pack.
Se rendre dans la vue Presentation et sélectionner Console Tasks dans le menu de gauche, puis faire un clic-droit à sélectionner New>Console Task (attention à ne pas confondre avec les Agent Tasks qui se trouvent elles dans la vue Health Model!) :

Nommer cette nouvelle tâche :

Lui donner un nom d’usage, qui apparaitra dans SCOM et choisir l’élément qu’elle ciblera :

Dans l’onglet Command Line, renseigner la partie fixe de la commande lancée par la tâche.
Dans notre cas il s’agit donc d’appeler le navigateur web et de lui passer la partie invariable de l’URL du système de gestion de tickets, mais plutôt que d’indiquer le chemin absolu vers l’exécutable du browser, nous avons choisi d'appeler le navigateur par défaut du système à l’aide du raccourci rundll32 url.dll,FileProtocolHandler http://suivi.tickets.local/?ticketID= .
Cela permet d’éviter les potentiels soucis liés à l’utilisation de navigateurs différents suivant les ordinateurs et respecte ainsi les préférences de l’utilisateur de la console SCOM.
Il faut ensuite indiquer en paramètre que l’on souhaite récupérer le CustomField de l’alerte contenant l’ID du ticket.
Oui mais… par défaut, seul le Display Name est disponible en paramètre :

Afin de modifier ce comportement, se rendre dans l’onglet Options et cliquer sur Category [Value=MonitoringObject]. Cela dévoile des options qui étaient jusque là invisibles et il est alors possible de sélectionner la catégorie Alert :

En retournant dans l’onglet CommandLine, on constate qu’il est maintenant possible de sélectionner les CustomField  comme paramètres (ainsi que bien d’autres, libre à vous d’adapter suivant vos besoins!) :

Il ne reste plus qu’à enregistrer le management pack et à le publier dans SCOM.

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.

Trop souvent, les souscriptions d’alertes ne sont pas utilisées à leur plein potentiel : une seule souscription est créée, ce qui peut bien entendu suffire dans certains cas mais pourraient être largement optimisé dans d’autres.

On peut ainsi définir de vrais scénarios d’escalade : par exemple si aucune action n’a été effectuée pour résoudre une alerte après un délai imparti, on peut décider d’envoyer un SMS à un responsable ou bien de transférer l’alerte à un autre service.

Prenons l’exemple de la souscription suivante, nommée « Alerte Linux » :

Il s’agit d’une souscription des plus classique, où toutes les nouvelles alertes (resolution state 0) concernant les serveurs membres du groupe Unix Computers (donc tous les ordinateur Unix/Linux monitorés par SCOM) et de priorité moyenne ou haute seront adressées par mail à l’utilisateur « Support_Linux ».

Imaginons maintenant que nous souhaitons que cette alerte soit automatiquement transmise par SMS à un responsable si elle n’est pas prise en charge au bout d’une heure.
Il suffit pour ce faire de créer une alerte avec des conditions de déclenchement identiques en tous points à la précédente, que nous nommerons par exemple « Alerte Linux (+1h) » et qui sera cette fois destinée à l’utilisateur « Manager_Linux » avec un délai (alert aging) d’une heure :

En se basant sur ce système, il devient très simple de créer des scénarios d’escalade en fonction du niveau de résolution, de l’heure de la journée (en créant des subscribers valables uniquement la nuit pour les astreintes par exemple) ; ou bien de n’envoyer l’alerte par mail que si elle n’a pas été prise en compte directement dans la console… les possibilités sont vastes !

Et comme il peut être fastidieux de recopier à l’identique les conditions de déclenchement d’une subscription (sans parler du risque de se tromper), Timothy McFadden (PFE chez Microsoft) a developpé un outil très pratique, Subscription Copier :

Il permet de sélectionner une subscription initialement créée avec les bons paramètres de la copier autant de fois que vous en aurez besoin pour votre scénario d’escalade. Il permet également de prédéfinir un délai (alert aging) qui s’incrémente de copie en copie.
Disponible sur son blog : http://www.scom2k7.com/subscription-copier/