PI Services

Le blog des collaborateurs de PI Services

SCOM – Créer un moniteur d’échantillons consécutifs de performance à 3 états – 2/2

Au cours de l’un ou l’autre des développements de Management Pack que j’ai été amené à réaliser, il est arrivé à plusieurs reprises que l’on me demande de mettre en place un moniteur de performances fonctionnant sur plusieurs mesures consécutives et ayant trois états (healthy/warning/critical), ou autrement dit deux seuils de déclenchement distincts.

Prises séparément, ces deux contraintes ne posent aucune difficulté particulière puisqu’il est possible de créer nativement via la console SCOM des moniteurs de performance de type « consecutive samples » (mesure d’échantillons consécutifs à deux états/un seul seuil) et « double thresholds » (trois états/deux seuils mais déclenchement sur une seule mesure).

Réunir ces deux besoins nécessite par contre d’en passer par un peu d’authoring, ce dont je profiterai pour présenter deux façons de procéder :

- Fusionner deux types de moniteurs natifs

- Utiliser la Suppression, une propriété méconnue de l’expression filter natif (cet article)

Nous avons vu dans la première partie de cet article que nous pouvions utiliser la fusion de deux types de moniteurs natifs pour arriver à nos fins. Cette solution est tout à fait adaptée et peut en plus être réutilisée très largement et s’appliquer à bien d’autres problématiques, mais il existe une autre solution, peut être encore plus élégante à notre problème : le paramètre « Suppression » de l’ExpressionFilter de SCOM.

Dans l’article précédent, j’avais présenté le fonctionnement du type de moniteur Double Threshold et notamment son utilisation de trois Expression Filter successifs.

clip_image002

En allant voir la définition de ce filtre, on constate qu’en plus de travailler sur une Expression, il est capable de travailler sur une Suppression, bien que ce second élément ne soit pas exploité dans la configuration native du type de moniteur Double Threshold :

clip_image004

Ce paramètre de Suppression fonctionne à l’aide de trois paramètres :

- MatchCount : le nombre de fois que l’élément Expression doit matcher avant que le property bag de sortie ne soit effectivement généré

- Sample Count : le nombre de fois que l’Expression Filter doit être évalué avant qu’il soit possible de générer le property bag de sortie.

- Within Seconds : la plage de temps au cours de laquelle l’élément Expression doit matcher avant qu’il soit possible de générer le property bag de sortie.

Il est donc possible d’utiliser Match Count seul ou en combinaison soit avec Sample Count, soit Within Seconds (mais pas les deux) afin d’obtenir une condition de type « l’expression matche 5 fois sur les 10 dernières occurrences » ou « l’expression matche 5 fois sur les 10 dernières minutes ».

Et il est extrêmement simple à utiliser !

Reprenons une fois de plus l’exemple du type de moniteur Double Threshold, et ajoutons une Suppression à la suite de son Expression dans sa condition CDUnderThresold1 :

clip_image005

Voilà, le tour est joué, il ne reste plus qu’à ajouter NumSamples à la configuration de notre type de moniteur personnalisé.

Et comme ici aussi un bon exemple vaut tous les longs discours, voici un fragment complet :

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <TypeDefinitions>
    <MonitorTypes>
      <UnitMonitorType ID="Test.ThreeStateConsecutiveThreshold.Suppression.MonitorType" Accessibility="Public">
        <MonitorTypeStates>
          <MonitorTypeState ID="UnderThreshold1"/>
          <MonitorTypeState ID="OverThreshold1UnderThreshold2"/>
          <MonitorTypeState ID="OverThreshold2"/>
        </MonitorTypeStates>
        <Configuration>
          <xsd:element name="ComputerName" type="xsd:string" minOccurs="0" maxOccurs="1"/>
          <xsd:element name="CounterName" type="xsd:string"/>
          <xsd:element name="ObjectName" type="xsd:string"/>
          <xsd:element name="InstanceName" type="xsd:string" minOccurs="0" maxOccurs="1"/>
          <xsd:element name="AllInstances" type="xsd:boolean" minOccurs="0" maxOccurs="1"/>
          <xsd:element name="Frequency" type="xsd:unsignedInt"/>
          <xsd:element name="ScaleBy" type="xsd:double" minOccurs="0" maxOccurs="1"/>
          <xsd:element name="Threshold1" type="xsd:double"/>
          <xsd:element name="Threshold2" type="xsd:double"/>
          <xsd:element name="NumSamples" type="xsd:int"/>
        </Configuration>
        <OverrideableParameters>
          <OverrideableParameter ID="Frequency" ParameterType="int" Selector="$Config/Frequency$"/>
          <OverrideableParameter ID="Threshold1" ParameterType="double" Selector="$Config/Threshold1$"/>
          <OverrideableParameter ID="Threshold2" ParameterType="double" Selector="$Config/Threshold2$"/>
          <OverrideableParameter ID="NumSamples" ParameterType="double" Selector="$Config/NumSamples$"/>
        </OverrideableParameters>
        <MonitorImplementation>
          <MemberModules>
            <DataSource TypeID="Perf!System.Performance.DataProvider" ID="DS1">
              <ComputerName>$Config/ComputerName$</ComputerName>
              <CounterName>$Config/CounterName$</CounterName>
              <ObjectName>$Config/ObjectName$</ObjectName>
              <InstanceName>$Config/InstanceName$</InstanceName>
              <AllInstances>$Config/AllInstances$</AllInstances>
              <Frequency>$Config/Frequency$</Frequency>
              <ScaleBy>$Config/ScaleBy$</ScaleBy>
            </DataSource>
            <ConditionDetection TypeID="System!System.ExpressionFilter" ID="CDUnderThreshold1">
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery Type="Double">Value</XPathQuery>
                  </ValueExpression>
                  <Operator>Less</Operator>
                  <ValueExpression>
                    <Value Type="Double">$Config/Threshold1$</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <SuppressionSettings>
                <MatchCount>$Config/NumSamples$</MatchCount>
              </SuppressionSettings>
            </ConditionDetection>
            <ConditionDetection TypeID="System!System.ExpressionFilter" ID="CDOverThreshold1UnderThreshold2">
              <Expression>
                <And>
                  <Expression>
                    <SimpleExpression>
                      <ValueExpression>
                        <XPathQuery Type="Double">Value</XPathQuery>
                      </ValueExpression>
                      <Operator>GreaterEqual</Operator>
                      <ValueExpression>
                        <Value Type="Double">$Config/Threshold1$</Value>
                      </ValueExpression>
                    </SimpleExpression>
                  </Expression>
                  <Expression>
                    <SimpleExpression>
                      <ValueExpression>
                        <XPathQuery Type="Double">Value</XPathQuery>
                      </ValueExpression>
                      <Operator>LessEqual</Operator>
                      <ValueExpression>
                        <Value Type="Double">$Config/Threshold2$</Value>
                      </ValueExpression>
                    </SimpleExpression>
                  </Expression>
                </And>
              </Expression>
              <SuppressionSettings>
                <MatchCount>$Config/NumSamples$</MatchCount>
              </SuppressionSettings>
            </ConditionDetection>
            <ConditionDetection TypeID="System!System.ExpressionFilter" ID="CDOverThreshold2">
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery Type="Double">Value</XPathQuery>
                  </ValueExpression>
                  <Operator>Greater</Operator>
                  <ValueExpression>
                    <Value Type="Double">$Config/Threshold2$</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <SuppressionSettings>
                <MatchCount>$Config/NumSamples$</MatchCount>
              </SuppressionSettings>              
            </ConditionDetection>
          </MemberModules>
          <RegularDetections>
            <RegularDetection MonitorTypeStateID="UnderThreshold1">
              <Node ID="CDUnderThreshold1">
                <Node ID="DS1"/>
              </Node>
            </RegularDetection>
            <RegularDetection MonitorTypeStateID="OverThreshold1UnderThreshold2">
              <Node ID="CDOverThreshold1UnderThreshold2">
                <Node ID="DS1"/>
              </Node>
            </RegularDetection>
            <RegularDetection MonitorTypeStateID="OverThreshold2">
              <Node ID="CDOverThreshold2">
                <Node ID="DS1"/>
              </Node>
            </RegularDetection>
          </RegularDetections>
        </MonitorImplementation>
      </UnitMonitorType>
    </MonitorTypes>
  </TypeDefinitions>
  
  
  <Monitoring>
    <Monitors>
      <UnitMonitor ID="Test.ThreeStateConsecutiveThreshold.Suppression.Perf.Monitor" Accessibility="Public" Enabled="true" Target="MWSL!Microsoft.Windows.Server.6.2.LogicalDisk" ParentMonitorID="Health!System.Health.PerformanceState" Remotable="true" Priority="Normal" TypeID="Test.ThreeStateConsecutiveThreshold.Suppression.MonitorType" ConfirmDelivery="false">
        <Category>PerformanceHealth</Category>
        <AlertSettings AlertMessage="Test.ThreeStateConsecutiveThreshold.Suppression.Perf.Monitor.Alert.Message">
          <AlertOnState>Warning</AlertOnState> 
          <AutoResolve>true</AutoResolve>
          <AlertPriority>Normal</AlertPriority>
          <AlertSeverity>MatchMonitorHealth</AlertSeverity>  <!-- Common options for AlertSeverity are MatchMonitorHealth, Information, Warning, Error -->
          <AlertParameters>
            <AlertParameter1>$Data/Context/ObjectName$</AlertParameter1>
            <AlertParameter2>$Data/Context/CounterName$</AlertParameter2>
            <AlertParameter3>$Data/Context/InstanceName$</AlertParameter3>
            <AlertParameter4>$Data/Context/Value$</AlertParameter4>
            <AlertParameter5>$Data/Context/TimeSampled$</AlertParameter5>
          </AlertParameters>
        </AlertSettings>
        <OperationalStates>
          <OperationalState ID="Healthy" MonitorTypeStateID="OverThreshold2" HealthState="Success" />
          <OperationalState ID="Warning" MonitorTypeStateID="OverThreshold1UnderThreshold2" HealthState="Warning" />
          <OperationalState ID="Critical" MonitorTypeStateID="UnderThreshold1" HealthState="Error" />
        </OperationalStates>
        <Configuration>
          <ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
          <CounterName>% Free Space</CounterName>
          <ObjectName>LogicalDisk</ObjectName>
          <InstanceName>$Target/Property[Type="Windows!Microsoft.Windows.LogicalDevice"]/DeviceID$</InstanceName>
          <AllInstances>false</AllInstances>
          <Frequency>60</Frequency>  <!-- 60 seconds is a good recommended interval for a native module perfmon monitor -->
          <Threshold1>65</Threshold1>
          <Threshold2>80</Threshold2>
          <NumSamples>3</NumSamples>

    
      </Configuration>
      </UnitMonitor>
      
    </Monitors>
  </Monitoring>
  <Presentation>
    <StringResources>
      <StringResource ID="Test.ThreeStateConsecutiveThreshold.Suppression.Perf.Monitor.Alert.Message" />
    </StringResources>
  </Presentation>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.Suppression.Perf.Monitor">
          <Name>Test 3State Consecutive Free Disk Space Perf Monitor (Using Suppression)</Name>
          <Description />
        </DisplayString>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.Suppression.Perf.Monitor" SubElementID="Healthy">
          <Name>Healthy</Name>
        </DisplayString>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.Suppression.Perf.Monitor" SubElementID="Warning">
          <Name>Warning</Name>
        </DisplayString>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.Suppression.Perf.Monitor" SubElementID="Critical">
          <Name>Critical</Name>
        </DisplayString>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.Suppression.Perf.Monitor.Alert.Message">
          <Name>Test 3 state consecutive counter has breached a threshold</Name>
          <Description>The monitor breached a threshold

Object: {0}
Counter {1}
Instance {2}
Has a value {3} 
At time {4}
          </Description>
        </DisplayString>
 
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

 

SCOM – Créer un moniteur d’échantillons consécutifs de performance à 3 états – 1/2

Au cours de l’un ou l’autre des développements de Management Pack que j’ai été amené à réaliser, il est arrivé à plusieurs reprises que l’on me demande de mettre en place un moniteur de performances fonctionnant sur plusieurs mesures consécutives et ayant trois états (healthy/warning/critical), ou autrement dit deux seuils de déclenchement distincts.

Prises séparément, ces deux contraintes ne posent aucune difficulté particulière puisqu’il est possible de créer nativement via la console SCOM des moniteurs de performance de type « consecutive samples » (mesure d’échantillons consécutifs à deux états/un seul seuil) et « double thresholds » (trois états/deux seuils mais déclenchement sur une seule mesure).

Réunir ces deux besoins nécessite par contre d’en passer par un peu d’authoring, ce dont je profiterai pour présenter deux façons de procéder :

- Fusionner deux types de moniteurs natifs (cet article)

- Utiliser la Suppression, une propriété méconnue de l’expression filter natif

Comme vu dans l’introduction, il existe nativement dans SCOM deux types de moniteurs qui, s’ils pouvaient être assemblés, formeraient une solution évidente à notre problème.

Et il se trouve que SCOM permet ce genre de fantaisie assez facilement, bien que cela nécessite de mettre les mains dans le code…

Commençons par aller regarder la « définition » de ces deux types de moniteurs, à l’aide de l’indispensable systemcenter.wiki : ConsecutiveSamplesThreshold et DoubleThreshold

On remarque immédiatement qu’ils sont basés sur une construction très similaire : ils comportent tous les deux en point d’entrée une source de données (Data Source) qui leur permet de récupérer la valeur du compteur de performance qui nous intéressent :
clip_image001

Cette Data Source est suivie par un ensemble de conditions de détection (Condition Detection) qui leur permettent de déterminer quand l’un ou l’autre état du moniteur est atteint.

Pour comprendre leur fonctionnement, il faut imaginer que la valeur relevée par la DataSource passe successivement par chaque Condition Detection, qui, si les conditions qui les définissent sont réunies, vont renvoyer un property bag.

Dans le cas du Consecutive Sample, on trouve trois Condition Detections :

- La première, de type System.Performance.ConsecutiveSamplesCondition, permet de compter le nombre de fois où la valeur du compteur est passée au delà du seuil configuré. Elle n’agit pas directement sur l’état du moniteur.
clip_image002

- La seconde et la troisième, de type ExpressionFilter permettent quant à elles de déterminer deux états pour le moniteur, en fonction de la valeur renvoyée par la première (nombre d’échantillons au-delà du seuil suffisant ou non pour changer l’état).
clip_image004

Dans le cas du Double Threshold, on retrouve également trois Condition Detection, mais ici chacune des trois servent à déterminer l’état du moniteur directement en fonction de la valeur renvoyée par la Data Source (sous le premier seuil, entre les deux seuils ou au-dessus du second):

clip_image006

En se basant sur ces constations, on réalise que rien n’empêche d’écrire nous-même un Monitor Type qui contiendrait à la fois une Condition Detection de type ConsecutiveSamplesCondition pour compter le nombre d’échantillons au-dessus du seuil de détection, suivie de trois ExpressionFilter pour déterminer 3 états différents qui vérifieraient à la fois la valeur du compteur et le nombre de fois qu’il est passé au  delà du seuil!
Le filtre pour l’état « entre deux seuils » ressemblerait donc à cela :

clip_image007

On voit bien que pour que le moniteur prenne l’état « Warning », j’ai simplement créé une expression qui nécessite la réunion de 3 conditions : un nombre de mesures (NumSamples) au-delà du seuil défini et une valeur de ces mesures inférieure à un premier seuil et supérieure à un second.

Et comme un bon exemple complet vaut mieux que tous les longs discours, voici ici le fragment intégral, implémenté pour le compteur « Logical Disk / Free Space % :

<ManagementPackFragment SchemaVersion="2.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <TypeDefinitions>
    <MonitorTypes>
  <UnitMonitorType ID="Test.ThreeStateConsecutiveThreshold.ConditionDetection.MonitorType" Accessibility="Internal">
    <MonitorTypeStates>
      <MonitorTypeState ID="Healthy" NoDetection="false" />
      <MonitorTypeState ID="Warning" NoDetection="false" />
      <MonitorTypeState ID="Critical" NoDetection="false" />
    </MonitorTypeStates>
    <Configuration>
      <xsd:element name="Frequency" type="xsd:integer" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
      <xsd:element name="WarningThreshold" type="xsd:double" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
      <xsd:element name="CriticalThreshold" type="xsd:double" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
      <xsd:element name="NumSamples" type="xsd:integer" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
      <xsd:element name="Direction" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
      <xsd:element name="ComputerName" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
      <xsd:element name="CounterName" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
      <xsd:element name="ObjectName" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
      <xsd:element name="InstanceName" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
      <xsd:element name="AllInstances" type="xsd:boolean" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
    </Configuration>
    <OverrideableParameters>
      <OverrideableParameter ID="Frequency" Selector="$Config/Frequency$" ParameterType="int" />
      <OverrideableParameter ID="WarningThreshold" Selector="$Config/WarningThreshold$" ParameterType="double" />
      <OverrideableParameter ID="CriticalThreshold" Selector="$Config/CriticalThreshold$" ParameterType="double" />
      <OverrideableParameter ID="NumSamples" Selector="$Config/NumSamples$" ParameterType="int" />

    </OverrideableParameters>
    <MonitorImplementation>
      <MemberModules>
        <DataSource ID="DS" TypeID="Perf!System.Performance.DataProvider">
          <ComputerName>$Config/ComputerName$</ComputerName>
          <CounterName>$Config/CounterName$</CounterName>
          <ObjectName>$Config/ObjectName$</ObjectName>
          <InstanceName>$Config/InstanceName$</InstanceName>
          <AllInstances>$Config/AllInstances$</AllInstances>
          <Frequency>$Config/Frequency$</Frequency>
        </DataSource>
        <ConditionDetection ID="ConsecutiveSamples" TypeID="Perf!System.Performance.ConsecutiveSamplesCondition">
          <Threshold>$Config/WarningThreshold$</Threshold>
          <Direction>$Config/Direction$</Direction>
        </ConditionDetection>
        <ConditionDetection ID="HealthyCondition" TypeID="System!System.ExpressionFilter">
          <Expression>
            <And>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery Type="Double">SampleValue</XPathQuery>
                  </ValueExpression>
                  <Operator>GreaterEqual</Operator>
                  <ValueExpression>
                    <Value Type="Double">$Config/WarningThreshold$</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery Type="Double">SampleValue</XPathQuery>
                  </ValueExpression>
                  <Operator>GreaterEqual</Operator>
                  <ValueExpression>
                    <Value Type="Double">$Config/CriticalThreshold$</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
            </And>
          </Expression>
        </ConditionDetection>
        <ConditionDetection ID="WarningCondition" TypeID="System!System.ExpressionFilter">
          <Expression>
            <And>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery Type="Integer">Value</XPathQuery>
                  </ValueExpression>
                  <Operator>GreaterEqual</Operator>
                  <ValueExpression>
                    <Value Type="Integer">$Config/NumSamples$</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery Type="Double">SampleValue</XPathQuery>
                  </ValueExpression>
                  <Operator>LessEqual</Operator>
                  <ValueExpression>
                    <Value Type="Double">$Config/WarningThreshold$</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery Type="Double">SampleValue</XPathQuery>
                  </ValueExpression>
                  <Operator>Greater</Operator>
                  <ValueExpression>
                    <Value Type="Double">$Config/CriticalThreshold$</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
            </And>
          </Expression>
        </ConditionDetection>
        <ConditionDetection ID="CriticalCondition" TypeID="System!System.ExpressionFilter">
          <Expression>
            <And>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery Type="Integer">Value</XPathQuery>
                  </ValueExpression>
                  <Operator>GreaterEqual</Operator>
                  <ValueExpression>
                    <Value Type="Integer">$Config/NumSamples$</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <XPathQuery Type="Double">SampleValue</XPathQuery>
                  </ValueExpression>
                  <Operator>LessEqual</Operator>
                  <ValueExpression>
                    <Value Type="Double">$Config/CriticalThreshold$</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
            </And>
          </Expression>
        </ConditionDetection>
      </MemberModules>
      <RegularDetections>
        <RegularDetection MonitorTypeStateID="Healthy">
          <Node ID="HealthyCondition">
            <Node ID="ConsecutiveSamples">
              <Node ID="DS" />
            </Node>
          </Node>
        </RegularDetection>
        <RegularDetection MonitorTypeStateID="Warning">
          <Node ID="WarningCondition">
            <Node ID="ConsecutiveSamples">
              <Node ID="DS" />
            </Node>
          </Node>
        </RegularDetection>
        <RegularDetection MonitorTypeStateID="Critical">
          <Node ID="CriticalCondition">
            <Node ID="ConsecutiveSamples">
              <Node ID="DS" />
            </Node>
          </Node>
        </RegularDetection>
      </RegularDetections>
    </MonitorImplementation>
  </UnitMonitorType>
  </MonitorTypes>
  </TypeDefinitions>
  <Monitoring>
    <Monitors>
      <UnitMonitor ID="Test.ThreeStateConsecutiveThreshold.ConditionDetection.Perf.Monitor" Accessibility="Public" Enabled="true" Target="MWSL!Microsoft.Windows.Server.6.2.LogicalDisk" ParentMonitorID="Health!System.Health.PerformanceState" Remotable="true" Priority="Normal" TypeID="Test.ThreeStateConsecutiveThreshold.ConditionDetection.MonitorType" ConfirmDelivery="false">
        <Category>PerformanceHealth</Category>
        <AlertSettings AlertMessage="Test.ThreeStateConsecutiveThreshold.ConditionDetection.Perf.Monitor.Alert.Message">
          <AlertOnState>Warning</AlertOnState>
          <AutoResolve>true</AutoResolve>
          <AlertPriority>Normal</AlertPriority>
          <AlertSeverity>MatchMonitorHealth</AlertSeverity>
          <AlertParameters>
            <AlertParameter1>$Data/Context/ObjectName$</AlertParameter1>
            <AlertParameter2>$Data/Context/CounterName$</AlertParameter2>
            <AlertParameter3>$Data/Context/InstanceName$</AlertParameter3>
            <AlertParameter4>$Data/Context/SampleValue$</AlertParameter4>
            <AlertParameter5>$Data/Context/TimeSampled$</AlertParameter5>
          </AlertParameters>
        </AlertSettings>
        <OperationalStates>
          <OperationalState ID="Healthy" MonitorTypeStateID="Healthy" HealthState="Success" />
          <OperationalState ID="Warning" MonitorTypeStateID="Warning" HealthState="Warning" />
          <OperationalState ID="Critical" MonitorTypeStateID="Critical" HealthState="Error" />
        </OperationalStates>
        <Configuration>
          <Frequency>60</Frequency>
          <WarningThreshold>80</WarningThreshold>
          <CriticalThreshold>65</CriticalThreshold>
          <NumSamples>3</NumSamples>
          <Direction>Less</Direction>
          <ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
          <CounterName>% Free Space</CounterName>
          <ObjectName>LogicalDisk</ObjectName>
          <InstanceName>$Target/Property[Type="Windows!Microsoft.Windows.LogicalDevice"]/DeviceID$</InstanceName>
          <AllInstances>false</AllInstances>
        </Configuration>
      </UnitMonitor>
    </Monitors>
  </Monitoring>
  <Presentation>
    <StringResources>
      <StringResource ID="Test.ThreeStateConsecutiveThreshold.ConditionDetection.Perf.Monitor.Alert.Message" />
    </StringResources>
  </Presentation>
  <LanguagePacks>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.ConditionDetection.Perf.Monitor">
          <Name>Test 3State Consecutive Free Disk Space Perf Monitor (Condition Detection)</Name>
        </DisplayString>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.ConditionDetection.Perf.Monitor" SubElementID="Healthy">
          <Name>Healthy</Name>
        </DisplayString>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.ConditionDetection.Perf.Monitor" SubElementID="Warning">
          <Name>Warning</Name>
        </DisplayString>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.ConditionDetection.Perf.Monitor" SubElementID="Critical">
          <Name>Critical</Name>
        </DisplayString>
        <DisplayString ElementID="Test.ThreeStateConsecutiveThreshold.ConditionDetection.Perf.Monitor.Alert.Message">
          <Name>Test 3 state consecutive counter has breached a threshold</Name>
          <Description>
            The monitor breached a threshold

            Object: {0}
            Counter {1}
            Instance {2}
            Has a value {3}
            At time {4}
          </Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPackFragment>

 

Direct Access : Mode single-NIC avec deux cartes réseau

Bien qu’il ne s’agisse pas forcément de la configuration la plus fréquente (ni la plus recommandée) dans un environnement de production, il peut arriver qu’il soit nécessaire de réaliser un déploiement de serveurs DirectAccess en mode « single network adapter behind an edge device », autrement dit avec une seule carte réseau connectée dans une DMZ au lieu du fonctionnement plus classique avec une carte réseau sur le LAN et une autre sur Internet :

clip_image002

(image provenant du whitepaper F5 : https://f5.com/resources/white-papers/f5-and-windows-server-2012-directaccessremote-access-services)

Et il peut également arriver que même dans cette configuration, une seconde carte réseau soit présente sur les serveurs DirectAccess, connectée à un réseau totalement différent (par exemple un réseau d’administration isolé, permettant la prise en main à distance des machines de la DMZ).

Dans ce dernier cas, bien que la configuration soit parfaitement correcte (ce qui n’est déjà pas toujours une mince affaire avec DirectAccess…), les clients ne peuvent pas se connecter et on constate des événements IPSec Main Mode « No Policy Configured ».
Par contre, en désactivant la seconde carte réseau puis en redémarrant, le fonctionnement est rétabli ; et a contrario en réactivant la seconde carte le fonctionnement est maintenu tant qu’aucun redémarrage n’a eu lieu.

Ce phénomène se produit lorsqu’au niveau du firewall Windows, la seconde carte réseau est détectée comme ayant un profil « public » et la raison est la suivante : lors du paramétrage de DirectAccess, les règles du firewall permettant de créer le tunnel IPhttps sont créées uniquement pour le profil de firewall « domain », ce qui est souhaité puisque c’est normalement bien le cas de la carte permettant l’accès aux ressources du LAN.

Or l’interface réseau virtuelle IPhttps s’attache de préférence aux cartes réseau dont le profil est « private » ou « public » lorsqu’elles sont présentes : dans ce cas les règles de firewall deviennent donc inopérantes.

Il y a donc deux solutions possibles : faire en sorte que la seconde carte réseau soit également détectée avec un profil « domain » (ce qui n’est pas toujours réalisable), ou modifier la GPO Direct Access afin qu’elle s’applique à tous les profils :

$gposession = Open-NetGPO –PolicyStore <Name of the server GPO>

Set-NetIPsecRule –DisplayName <Name of the IPsec policy> –GPOSession $gposession –Profile Any

Save-NetGPO –GPOSession $gposession

On notera que pour une fois, ce contournement est bien détaillé sur Technet (https://technet.microsoft.com/en-us/library/jj134204.aspx )… mais sur une page où il a bien peu de chances d’être trouvé, puisqu’elle concerne un stade de la configuration de Direct Access ou la GPO n’existe pas et où il n’y a donc aucune raison d’envisager d’y apporter des modifications !

Enfin, attention : il est fort probable qu’il faille réappliquer le contournement à chaque fois que la configuration DirectAccess est modifiée en utilisant l’assistant, puisque ce dernier met à jour la GPO.

PKI : OCSP et bug de certutil

Commençons par quelques rappels : dans le cadre d’un déploiement d’une PKI (public key infrastructure, autrement dit le système permettant l’émission de certificats en entreprise), il est nécessaire d’inclure un ou plusieurs mécanismes de vérification de la révocation des certificats.

Le plus fréquemment utilisé s’appelle la CRL, ou certificate revocation list : il s’agit simplement d’une sorte de fichier texte contenant la liste des certificats révoqués par une autorité donnée, accessible via une classique adresse http. Bien qu’il existe des mécanismes de mise en cache, l’accès à cette liste de révocation peut s’avérer problématique lorsqu’elle commence à devenir volumineuse ou lorsqu’elle est accédée très souvent par de nombreux autres systèmes.

Un autre mécanisme nommé OCSP (online certificate status protocol) permet de pallier à ces limitations : au lieu de télécharger la liste intégrale des certificats révoqués à chaque vérification, il devient possible d’interroger ce service pour lui demander si le certificat n°XXXXX provenant de l’autorité Y est révoqué ou non.

C’est ce second mécanisme qui nous intéresse aujourd’hui, et plus précisément un bug assez surprenant que j’ai rencontré au cours d’un déploiement récent chez un client.

Lors d’un test de la chaine de validation des certificats à l’aide de la commande certutil -urlfetch -verify testcertificat.cer (très utile pour identifier à quel niveau un certificat est refusé, plus d’informations ici par exemple : https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=13 ), je me suis retrouvé avec une exécution incomplète et en boucle des différents tests :

clip_image002

Suivie au bout de quelques secondes par un plantage pur et simple de certutil :

clip_image004

Quelques vérifications rapides me permirent de constater que lorsque le serveur OCSP était rendu indisponible, certutil retrouvait un fonctionnement normal (et indiquait bien sûr l’indisponibilité de l’OCSP) mais impossible d’aller plus loin dans la résolution, et Internet semblait pour une fois muet sur ce souci.

C’est finalement grâce à un collègue qui avait déjà rencontré ce cas que la solution a été trouvée : il s’avère le certificat OCSP Signing doit être émis par l’autorité pour laquelle le serveur OCSP réalise la vérification de révocation, autrement certutil présente ce comportement ; alors que dans ce déploiement c’est l’autorité émettrice qui avait été utilisée pour émettre les certificats OCSP Signing pour la vérification de l’autorité émettrice mais aussi de l’autorité racine (standalone et hors ligne).

La résolution du problème s’impose alors d’elle-même : il faut générer le certificat OCSP Signing sur chacune des autorités dont la vérification sera assurée par le répondeur OCSP, y compris lorsqu’il s’agit d’autorités standalone.

La procédure dans ce cas précis est détaillée sur ce blog : https://blogs.technet.microsoft.com/askds/2009/06/30/implementing-an-ocsp-responder-part-iv-configuring-ocsp-for-use-with-standalone-cas/ .
Notez également qu’il est nécessaire d’ajouter l’extension id-pkix-ocsp-nocheck au préalable (à l’aide de la commande certutil -v -setreg policy\EnableRequestExtensionList +1.3.6.1.5.5.7.48.1.5), car elle n’est par défaut pas disponible sur les autorités standalone.

Enfin, on regrettera que les informations disponibles à ce sujet sur les ressources officielles soient contradictoires, puisqu’on retrouve sur technet les deux passages suivants :

Windows Vista SP1 and Windows Server 2008 enable the OCSP signing certificate implemented by the OCSP responder to use a certificate that terminates in a different root CA than the CA whose revocation information is reported in the OCSP responses. This feature enables an organization with a diverse PKI to limit sources of revocation information and the CAs that can issue OCSP signing certificates.
(https://technet.microsoft.com/en-us/library/ee619736(v=ws.10).aspx au chapitre Independent OCSP signing certificate)

Online Certificate Status Protocol (OCSP) Response Signing certificates need to be signed by the same certification authority (CA) key that was used to sign the end-entity certificates that they provide status for.
( https://technet.microsoft.com/en-us/library/cc754774(v=ws.11).aspx )

SCOM – MP Powershell par SquaredUp

Tous les admins SCOM vous le diront : créer des nouvelles règles dans la console classique peut s’avérer terriblement frustrant, en particulier par son manque de flexibilité et de liberté.

Un exemple particulièrement récurrent est l’impossibilité d’utiliser autre chose que le Visual Basic pour créer des règles ou moniteurs scriptés, alors qu’il est parfaitement possible d’utiliser Powershell en passant par des outils tiers (MP Author de Silect, voire VisualStudio).

Une première tentative de simplifier les choses avait été réalisée par Wei Lim, avec un management pack qui apportait un wizard permettant la création de moniteurs en powershell directement dans la console SCOM : https://blogs.msdn.microsoft.com/wei_out_there_with_system_center/2015/07/09/opsmgr-new-sample-wizard-to-create-powershell-monitors-in-the-ops-console/

Cela restait cependant assez limité, il n’était par exemple pas possible de passer de paramètres aux scripts au début (ce qui fut corrigé dans une release ultérieure) et seule la création de moniteurs à 2 états était possible.

Depuis peu, SquaredUp (société bien connue pour son excellente console web éponyme, nous en reparlerons surement un jour) propose également un management pack gratuit, qui apporte enfin à la console SCOM les fonctionnalités que nous étions en droit d’attendre : création de moniteurs à 2 et 3 états, de tous types de règles, de tâches… en powershell, à l’aide de wizards fort bien concus !

clip_image002

clip_image004

Le Management Pack est disponible ici : https://squaredup.com/free-powershell-management-pack/

Agent SCOM 2012 R2 UR12 (et ultérieur) sur Windows 2003

Lors de la finalisation d’une migration side by side SCOM 2007 vers SCOM 2012 R2, j’ai rencontré un problème assez inattendu : il ne restait alors plus que quelques agents Windows 2003 à déployer et quelques autres à mettre à jour avec le dernier UR, et je n’anticipais pas de problème particulier dans cette phase déjà réalisée à maintes reprises sur d’autres serveurs de cet environnement ainsi que sur d’autres environnements.

J’ai donc eu la mauvaise surprise de constater que ces agents s’arrêtaient dès leur démarrage, parfois sans aucun message d’erreur (arrêt « propre » matérialisé par les événements 103 puis 101), parfois avec un message d’erreur assez peu parlant (événement 1000 après l’événement 103) :

clip_image001

clip_image002

Faulting application healthservice.exe, version 7.1.10292.0, stamp 585161d0, faulting module unknown, version 0.0.0.0, stamp 00000000, debug ? 0, fault address 0x000c9ba0.

J’ai alors décidé de prendre une trace de l’agent, afin d’obtenir un diagnostic plus poussé (cf. https://blog.piservices.fr/post/2017/09/30/SCOM-Prendre-une-trace-de-lagent1).

Fort heureusement le problème était très simple à reproduire (un simple démarrage de l’agent…), et m’a permis d’obtenir l’erreur suivante :

clip_image004

Unable to create self-signed certificate : -2146893816(NTE_BAD_ALGID).

L’agent échoue donc à créer un certificat auto-signé lors de son démarrage, et plante dans la foulée.

Mais pourquoi chercherait-il à générer un certificat ? Comme le précise Stefan Roth dans cet article très détaillé (https://stefanroth.net/2016/03/02/scom-how-data-is-encrypted/), ce certificat est utilisé lorsque le Management Server transmet un RunAs Account à un agent afin d’apporter un niveau de chiffrement supplémentaire.

Ce certificat est donc créé lors du premier démarrage de l’agent, ainsi que lorsqu’il expire (sa durée de vie est d’un an) :

clip_image006

Nous constatons sur la capture ci-dessus que le certificat est bel et bien présent dans le magasin.

Pourquoi l’agent cherche-t-il a le régénérer, et pourquoi échoue-t-il ?

La réponse à la première question se trouve (de façon assez peu claire il est vrai) dans les release notes de l’UR12 de SCOM 2012 R2 :

  • SHA2 support for certificates:  SHA1 is deprecated for the System Center 2012 R2 Operations Manager Agent and SHA2 is now supported.

Autrement dit, le certificat auto-signé de l’agent est maintenant signé avec l’algorithme SHA2 (SHA256RSA) et non plus avec SHA1.

Tant mieux pour la sécurité, SHA1 est aujourd’hui considéré comme déprécié et ne devrait plus être utilisé.

La réponse à la seconde question se trouve encore une fois chez Microsoft : Windows 2003 (et par extension Windows XP) ne supporte pas les algorithmes de la famille SHA2 sans un hotfix qui n’a jamais été intégré aux mises à jour régulières, comme l’indique la KB suivante : http://support.microsoft.com/kb/938397

Une fois le hotfix installé et le serveur redémarré, on constate que l’agent démarre sans encombre et qu’un certificat signé en SHA256 est généré :

clip_image008

Et voilà, problème réglé !

SCOM – Prendre une trace de l’agent

Il peut arriver qu’un agent SCOM rencontre un problème (plantage, supervision qui échoue…) sans raison identifiable dans les journaux d’événement.

Dans ce cas, il reste une dernière solution : prendre une trace de debug.

Les outils le permettant sont disponibles nativement sur tous les serveurs où l’agent est installé.

Préparation

Dans un premier temps, il est nécessaire de se connecter au serveur où se trouve l’agent pour lequel vous souhaitez réaliser une trace puis localisez le dossier d’installation de l’agent, normalement C:\Program Files\System Center Operations Manager\Agent\Tools pour un SCOM 2012 ou C:\Program Files\Microsoft Monitoring Agent\Agent\Tools pour un SCOM 2012 R2.

Ouvrez une ligne de commande cmd.exe en mode administrateur, puis rendez vous dans le dossier en question et exécutez la commande StopTracing.cmd afin de vous assurer que toutes les traces préalables sont bien arrêtées.

clip_image002

Profitez-en pour relever le dossier où se trouvent les logs, indiqué à la ligne Log Filename (ici C:\Windows\Logs\OpsMgrTrace ) et supprimez tous les fichiers qu’il contient, afin de faire place nette pour la nouvelle trace à venir.

Prise de la trace

Toujours depuis votre invite de commande, tapez StartTracing.cmd VER (respectez bien les majuscules pour VER) puis attendez que le problème se reproduise ou, mieux, essayez de forcer sa reproduction : plus la trace durera longtemps et plus elle sera longue à traiter et à analyser…

clip_image004

Une fois le problème survenu, arrêtez la trace (toujours avec Stoptracing.cmd).

Traitement et analyse de la trace

Les fichiers ETL de trace sont, à la base, totalement illisibles : il faut donc les convertir en quelque chose que vous puissiez analyser.

Pour ce faire, lancez la commande formattracing.cmd. Elle peut être assez longue à s’exécuter selon la durée de votre trace.

clip_image006

Une fois terminée, vous constaterez que des fichiers .log ont été créés dans le dossier de logs. Ce sont eux que vous allez pouvoir ouvrir pour tenter de comprendre les soucis rencontrés par l’agent.

Mais même s’ils sont lisibles dans un notepad, ils restent assez peu digestes :

clip_image008

Vous pouvez utiliser l’outil CMTrace, issu du toolkit de SCCM ( https://www.microsoft.com/en-us/download/details.aspx?id=50012 ), pour obtenir un résultat un peu plus facilement exploitable :

clip_image010

Ensuite, à vous de jouer et de repérer les lignes avec des erreurs (normalement signalées par une balise [ERROR]) pour identifier l’origine de votre problème.

Agent SCOM 2012 R2 UR12 (et ultérieur) sur Windows 2003

Lors de la finalisation d’une migration side by side SCOM 2007 vers SCOM 2012 R2, j’ai rencontré un problème assez inattendu : il ne restait alors plus que quelques agents Windows 2003 à déployer et quelques autres à mettre à jour avec le dernier UR, et je n’anticipais pas de problème particulier dans cette phase déjà réalisée à maintes reprises sur d’autres serveurs de cet environnement ainsi que sur d’autres environnements.

J’ai donc eu la mauvaise surprise de constater que ces agents s’arrêtaient dès leur démarrage, parfois sans aucun message d’erreur (arrêt « propre » matérialisé par les événements 103 puis 101), parfois avec un message d’erreur assez peu parlant (événement 1000 après l’événement 103) :

clip_image001

clip_image002

Faulting application healthservice.exe, version 7.1.10292.0, stamp 585161d0, faulting module unknown, version 0.0.0.0, stamp 00000000, debug ? 0, fault address 0x000c9ba0.

J’ai alors décidé de prendre une trace de l’agent, afin d’obtenir un diagnostic plus poussé (cf. https://blog.piservices.fr/post/2017/09/30/SCOM-Prendre-une-trace-de-lagent ).

Fort heureusement le problème était très simple à reproduire (un simple démarrage de l’agent…), et m’a permis d’obtenir l’erreur suivante :

clip_image004[5]

Unable to create self-signed certificate : -2146893816(NTE_BAD_ALGID).

L’agent échoue donc à créer un certificat auto-signé lors de son démarrage, et plante dans la foulée.

Mais pourquoi chercherait-il à générer un certificat ? Comme le précise Stefan Roth dans cet article très détaillé (https://stefanroth.net/2016/03/02/scom-how-data-is-encrypted/), ce certificat est utilisé lorsque le Management Server transmet un RunAs Account à un agent afin d’apporter un niveau de chiffrement supplémentaire.

Ce certificat est donc créé lors du premier démarrage de l’agent, ainsi que lorsqu’il expire (sa durée de vie est d’un an) :

clip_image006[5]

Nous constatons sur la capture ci-dessus que le certificat est bel et bien présent dans le magasin.

Pourquoi l’agent cherche-t-il a le régénérer, et pourquoi échoue-t-il ?

La réponse à la première question se trouve (de façon assez peu claire il est vrai) dans les release notes de l’UR12 de SCOM 2012 R2 :

  • SHA2 support for certificates:  SHA1 is deprecated for the System Center 2012 R2 Operations Manager Agent and SHA2 is now supported.

Autrement dit, le certificat auto-signé de l’agent est maintenant signé avec l’algorithme SHA2 (SHA256RSA) et non plus avec SHA1.

Tant mieux pour la sécurité, SHA1 est aujourd’hui considéré comme déprécié et ne devrait plus être utilisé.

La réponse à la seconde question se trouve encore une fois chez Microsoft : Windows 2003 (et par extension Windows XP) ne supporte pas les algorithmes de la famille SHA2 sans un hotfix qui n’a jamais été intégré aux mises à jour régulières, comme l’indique la KB suivante : http://support.microsoft.com/kb/938397

Une fois le hotfix installé et le serveur redémarré, on constate que l’agent démarre sans encombre et qu’un certificat signé en SHA256 est généré :

clip_image008[5]

Et voilà, problème réglé !

SCCM – Le déploiement du client sur un Management Point additionnel échoue

 

Lors du déploiement du client SCCM sur un serveur hébergeant déjà le rôle Management Point, l’installation échoue.

Une analyse du log c:\windows\ccmsetup\logs\ccmsetup.log révèle le message d’erreur suivant :

"MSI: Setup was unable to register the CCM_Service_HostingConfiguration endpoint
The error code is 80041002"

"File C:\Windows\ccmsetup\{72875A95-4007-4DAC-88D8-66366F9A5045}\client.msi installation failed. Error text: ExitCode: 1603
Action: CcmRegisterHostingConfiguration.
ErrorMessages:
Setup was unable to register the CCM_Service_HostingConfiguration endpoint
The error code is 80041002"

Une rapide recherche permet de trouver la KB suivante, qui indique de supprimer le rôle MP, d’installer le client puis de réinstaller le rôle MP : https://support.microsoft.com/en-us/help/2905359/installation-of-the-configuration-manager-client-agent-fails-with-error-code-80041002

Cette solution, bien que fonctionnelle, n’est pas très satisfaisante : d’autres clients SCCM peuvent dépendre de ce serveur MP, qui peut se trouver dans un réseau isolé etc.

Heureusement, une autre solution existe : il faut installer le client via la ligne de commande, en spécifiant manuellement le chemin vers le patch le plus récent disponible, copié manuellement dans un dossier de votre choix au préalable :

C:\SMS\Client\ccmsetup.exe /mp;SERVEURMP.LAN.LOCAL INSTALL="ALL" SMSSITECODE="XXX" CCMHTTPPORT="80" CCMHTTPSPORT="443" CCMHTTPSSTATE="480" FSP="XXX.LAN.LOCAL" CCMFIRSTCERT="1" patch="C:\SMS\Client\configmgr2012ac-sp2r2sp1-kb3100144-x64.msp"

Et le tour est joué !

WSUS – La synchronisation échoue pour un nouveau déploiement

Suite à un nouveau déploiement de WSUS, toutes les tentatives de synchronisation échouent :

clip_image002

SoapException: Fault occurred
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetUpdateData(Cookie cookie, UpdateIdentity[] updateIds)
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetUpdateData(UpdateIdentity[] updateIds, List`1 allMetadata, List`1 allFileUrls, Boolean isForConfig)
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.GetUpdateDataInChunksAndImport(List`1 neededUpdates, List`1 allMetadata, List`1 allFileUrls, Boolean isConfigData)
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)

L’étude des fichiers de log Wsus et IIS montrent que l’appel au ServerSyncWebService échoue avec une erreur 500 :

clip_image004

clip_image006

Mais il s’agit d’une fausse piste.

En réalité, le problème provient d’une installation précédente de WSUS sur ce serveur. Bien qu’il ait été désinstallé proprement préalablement à la réinstallation (suppression du rôle Windows et de la base WID), le dossier C:\Windows\Softwaredistribution était toujours présent.

Après sa suppression (ou son renommage) et le redémarrage du service wuauserv, la synchronisation se lance.

 

clip_image009

clip_image007

clip_image011