PI Services

Le blog des collaborateurs de PI Services

SCOM 2012 – collecter et formater des évenements syslog

 

Comme vous le savez probablement déjà, SCOM permet de créer des règles d’alerte basées sur la collecte d’événements syslog.

Ces événements collectés ont malheureusement le gros défaut d’être « bruts », sans aucun formatage ni filtrage des champs : ils sont stockés comme un gros bloc de texte dans la base de donnée.

Ce n’est pas idéal si votre objectif est de leur appliquer un traitement complexe, par exemple à l’aide d’un script (plus de détails à ce sujet dans un prochain billet).

Il est cependant simple d’y remédier, à condition d’accepter de mettre la main à la pâte, car la DataSource utilisée n’est disponible dans aucune template prédéfini… on n’a rien sans rien.

Avant de débuter, un petit rappel : une règle utilisant une datasource Syslog doit être ciblée sur la classe « Agent » et elle va activer l’écoute de l’agent SCOM sur le port syslog pour tous les serveurs ciblés : il est donc fortement recommandé de la désactiver par défaut, et de créer un override d’activation ciblé sur un groupe contenant le ou les agents responsables de la collecte d’évènements syslog.

Voyons maintenant la structure logique de notre Management Pack :

- Classe pour le groupe qui contient les agents responsables de la collecte
- Découverte qui peuple le groupe
- Règle de collecte
- DisplayStrings

C’est bien évidement la règle de collecte qui nous intéresse le plus. Détaillons son contenu :

<Rules>
      <Rule ID="Test.Syslog.CollectionRule" Enabled="false" Target="SC!Microsoft.SystemCenter.Agent" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>Custom</Category>
        <DataSources>
          <DataSource ID="SyslogDS" TypeID="ApplicationLog!System.ApplicationLog.SysLog.EventProvider">
            <Port>514</Port>
          </DataSource>
        </DataSources>
        <ConditionDetection ID="GenericDataMapperCD" TypeID="System!System.Event.GenericDataMapper">
          <EventOriginId>$Target/Id$</EventOriginId>
          <PublisherId>$MPElement$</PublisherId>
          <PublisherName>$Data/EventData/DataItem/PriorityName$</PublisherName>
          <Channel>Syslog</Channel>
          <LoggingComputer>$Data/EventData/DataItem/HostName$</LoggingComputer>
          <EventNumber>54321</EventNumber>
          <EventCategory>0</EventCategory>
          <EventLevel>0</EventLevel>
          <UserName />
          <Description>$Data/EventData/DataItem/Message$</Description>
          <Params />
        </ConditionDetection>
        <WriteActions>
          <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
         
        </WriteActions>
      </Rule>
    </Rules>

Cette règle est, comme vu plus haut, ciblée sur la classe Microsoft.SystemCenter.Agent et désactivée par défaut (enabled=false).

Son workflow est constitué de trois éléments principaux :

- une DataSource de type System.ApplicationLog.SysLog.EventProvider, qui permet d’activer l’écoute de message syslog sur le port spécifié (attention, on ne peut pas avoir deux règles syslog qui s’exécutent sur le même serveur avec le même port!)
- un GenericDataMapper : c’est lui qui va faire la correspondance entre les champs d’un évènement SCOM (EventOrigin, PublisherId, PublisherName, Logging Computer, Description…) et les champs issus du message Syslog. J’utilise aussi des champs aux valeurs hardcodées dans cet exemple (EventNumber, EventLevel…)
- Une WriteAction, qui écrit l’évènements formaté dans la base de donnée.

Simple, non?

Une fois le MP importé et l’override d’activation défini, les évènements devraient apparaitre dans la base de donnée. Attention, la DB de SCOM contient 20 tables pour les évènements, utilisés en roulement. Il est donc bien plus pratique et efficace de passer par la vue EventView qui les regroupe!

 

Pour une vue plus globale, voici un exemple de MP de collecte Syslog complet (il ne reste plus qu’à peupler le groupe et à créer l’override d’activation sur la règle de collecte) :

<?xml version="1.0" encoding="utf-8"?><ManagementPack ContentReadable="true" SchemaVersion="2.0" OriginalSchemaVersion="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <Manifest>
    <Identity>
      <ID>Test.Syslog</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>Test.Syslog</Name>
    <References>
      <Reference Alias="ApplicationLog">
        <ID>System.ApplicationLog.Library</ID>
        <Version>7.0.8432.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="SCDW">
        <ID>Microsoft.SystemCenter.DataWarehouse.Library</ID>
        <Version>7.0.8432.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>7.5.8501.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="MicrosoftSystemCenterInstanceGroupLibrary7585010">
        <ID>Microsoft.SystemCenter.InstanceGroup.Library</ID>
        <Version>7.5.8501.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>7.5.8501.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="SC">
        <ID>Microsoft.SystemCenter.Library</ID>
        <Version>7.0.8432.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="Health">
        <ID>System.Health.Library</ID>
        <Version>7.0.8432.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
  </Manifest>
  <TypeDefinitions>
    <EntityTypes>
      <ClassTypes>
        <ClassType ID="Test.Syslog.Collector.Group" Accessibility="Public" Abstract="false" Base="MicrosoftSystemCenterInstanceGroupLibrary7585010!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="true" Extension="false" />
      </ClassTypes>
    </EntityTypes>
  </TypeDefinitions>
  <Monitoring>
    <Discoveries>
      <Discovery ID="Test.Syslog.Collector.Group.DiscoveryRule" Enabled="true" Target="Test.Syslog.Collector.Group" ConfirmDelivery="false" Remotable="true" Priority="Normal">
        <Category>Discovery</Category>
        <DiscoveryTypes>
          <DiscoveryRelationship TypeID="MicrosoftSystemCenterInstanceGroupLibrary7585010!Microsoft.SystemCenter.InstanceGroupContainsEntities" />
        </DiscoveryTypes>
        <DataSource ID="GroupPopulationDataSource" TypeID="SC!Microsoft.SystemCenter.GroupPopulator">
          <RuleId>$MPElement$</RuleId>
          <GroupInstanceId>$MPElement[Name="Test.Syslog.Collector.Group"]$</GroupInstanceId>
          <MembershipRules>
            <MembershipRule Comment="EMPTY_RULE_8eadaced-59c8-4ebc-a4e4-b8428a374442">
              <MonitoringClass>$MPElement[Name="System!System.Entity"]$</MonitoringClass>
              <RelationshipClass>$MPElement[Name="MicrosoftSystemCenterInstanceGroupLibrary7585010!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass>
              <Expression>
                <SimpleExpression>
                  <ValueExpression>
                    <Value>True</Value>
                  </ValueExpression>
                  <Operator>Equal</Operator>
                  <ValueExpression>
                    <Value>False</Value>
                  </ValueExpression>
                </SimpleExpression>
              </Expression>
            </MembershipRule>
          </MembershipRules>
        </DataSource>
      </Discovery>
    </Discoveries>
    <Rules>
      <Rule ID="Test.Syslog.CollectionRule" Enabled="false" Target="SC!Microsoft.SystemCenter.Agent" ConfirmDelivery="true" Remotable="true" Priority="Normal" DiscardLevel="100">
        <Category>Custom</Category>
        <DataSources>
          <DataSource ID="SyslogDS" TypeID="ApplicationLog!System.ApplicationLog.SysLog.EventProvider">
            <Port>514</Port>
          </DataSource>
        </DataSources>
        <ConditionDetection ID="GenericDataMapperCD" TypeID="System!System.Event.GenericDataMapper">
          <EventOriginId>$Target/Id$</EventOriginId>
          <PublisherId>$MPElement$</PublisherId>
          <PublisherName>$Data/EventData/DataItem/PriorityName$</PublisherName>
          <Channel>Syslog</Channel>
          <LoggingComputer>$Data/EventData/DataItem/HostName$</LoggingComputer>
          <EventNumber>54321</EventNumber>
          <EventCategory>0</EventCategory>
          <EventLevel>0</EventLevel>
          <UserName />
          <Description>$Data/EventData/DataItem/Message$</Description>
          <Params />
        </ConditionDetection>
        <WriteActions>
          <WriteAction ID="WriteToDB" TypeID="SC!Microsoft.SystemCenter.CollectEvent" />
          <WriteAction ID="WriteToDW" TypeID="SCDW!Microsoft.SystemCenter.DataWarehouse.PublishEventData" />
        </WriteActions>
      </Rule>
    </Rules>

  </Monitoring>
  <LanguagePacks>

    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Test.Syslog">
          <Name>Test.Syslog</Name>
        </DisplayString>
        <DisplayString ElementID="Test.Syslog.CollectionRule">
          <Name>Syslog - Collection Rule</Name>
          <Description>Cette regle est en charge de la collecte de tous les evenements syslog, quel que soit l'emmeteur.
Chaque agent en charge de la reception des messages syslog doit etre ajoute au groupe Test.Syslog.Collector</Description>
        </DisplayString>
        <DisplayString ElementID="Test.Syslog.Collector.Group">
          <Name>Test.Syslog.Collector</Name>
        </DisplayString>
        <DisplayString ElementID="Test.Syslog.Collector.Group.DiscoveryRule">
          <Name>Populate Test.Syslog.Collector</Name>
          <Description>This discovery rule populates the group 'Test.Syslog.Collector'</Description>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPack>

 

SCOM 2012 : Deux outils de développement gratuits

 

Si vous êtes administrateur de longue date d’une supervision SCOM, vous regrettez très probablement la disparition de la console Authoring présente dans SCOM 2007.

Elle permettait le développement rapide et (en partie) graphique de Management Packs relativement complexes avec une création assez visuelle des workflow de supervision.

L’arrivée de SCOM 2012 a malheureusement signé l’arrêt de son support : il est toujours possible de créer un MP avec la console Authoring et de l’importer sur une plateforme SCOM 2012, mais il n’est par la suite plus possible de le rouvrir pour le modifier. Il n’est évidemment pas possible non plus de tirer profit des nouvelles fonctionnalités propres à SCOM 2012 (nouveaux Dashboard, nouvelles fonctionnalités de supervision réseau…).

La préconisation de Microsoft était alors de se rabattre sur Visual Studio avec les extensions VSAE (Visual Studio Authoring Extensions), ou sur Visio à l’aide de VMPD (Visio Management Pack Designer) pour les management pack les plus simples.
Nous avions donc le choix entre une solution peu pertinente et très limitée (Visio) et la solution la plus complète qui soit, mais également la moins accessible aussi bien en terme de complexité de mise en œuvre que de coût.

MP Author

Heureusement, après presque 2 ans de disette, les développeurs de Silect (une filiale de Bridgeways, un éditeur de Management Pack) ont entendu notre appel et ont publié l’outil gratuit MP Author (http://www.silect.com/mp-author ), qui rappelle la console Authoring par bien des aspects.

Reprenons par exemple l’exemple classique de la création d’un MP contenant une classe et une découverte à l’aide d’une clé de registre :

L’installation est assez directe (suivant -> suivant -> ok), notez cependant qu’il est nécessaire que la console SCOM 2012 (R2) soit présente.

On crée ensuite un nouveau MP :

clip_image002

On indique un ID, un nom et une description

clip_image004

Dossier d’export

clip_image006

MPs à référencer

clip_image008

Il est préférable de sélectionner Empty Management Pack car le template Single Server Application crée des objets inutiles à une supervision basique

Nous arrivons maintenant à l’écran principal de l’outil, d’une apparence plutôt familière si on a l’habitude de la console Authoring.

Cliquer sur Target > New > Create New Registry Target :

clip_image010

Il est possible de se connecter à un serveur distant pour parcourir sa base de registre à la recherche de la clé appropriée, ou bien d’entrer à la main les informations :

clip_image012

Sélectionner la clé de registre sur laquelle se basera la découverte :

clip_image014

Donner un ID et un nom à la classe :

clip_image016

De même pour la découverte :

clip_image018

Définir une expression pour la découverte :

clip_image020

Définir un intervalle de découverte :

clip_image022

A l’aide d’un assistant très similaire, on ajoute un moniteur qui supervisera le service DHCP :

clip_image024

clip_image026

clip_image028

clip_image030

Il ne reste plus qu’à exporter votre management pack, soit directement vers SCOM à l’aide d’un clic droit sur la racine de l’arborescence à gauche > Import Management Pack :

clip_image032

Soit en sauvegardant le MP sous forme de fichier XML et en l’important via la console SCOM.

Certes, cet outil est moins complet que l’ancienne console Authoring et perfectible sur bien des points, mais il devrait permettre de gagner un temps précieux et remplace avantageusement la solution Visio proposée par Microsoft!

Visual Studio

Le but ici n’est pas de vous proposer une introduction complète à l’utilisation de Visual Studio pour le développement de Management Pack, mais plutôt de vous révéler une astuce : en effet, le titre de ce billet est « deux outils de développement gratuits »…

Et il n’est effectivement pas nécessaire de débourser le moindre centime, ni même de se lancer dans le téléchargement fastidieux d’un iso de plusieurs Go pour obtenir un Visual Studio exécutant les Authoring Extensions de manière parfaitement fonctionnelle !

Voici ce dont vous aurez besoin :

Microsoft Visual Studio 2012 Shell (Isolated) Redistributable Package (220 mo) : www.microsoft.com/en-us/download/details.aspx?id=30670

Microsoft Visual Studio 2012 Shell (Integrated) Redistributable Package (1,5 mo) : http://www.microsoft.com/en-us/download/details.aspx?id=30663

System Center 2012 Visual Studio Authoring Extensions (32 mo) : http://www.microsoft.com/en-us/download/details.aspx?id=30169

Et… c’est tout ! L’installation est des plus classique (suivant -> suivant -> OK) et vous permet d’obtenir un Visual Studio en bonne et due forme, avec les templates nécessaires au développement de Management Packs :

clip_image034

Bon développement !

SCOM 2012 – Repasser des agents en Remotely Manageable

 

Lorsqu’un agent a été installé manuellement, par exemple en raison d’un flux bloqué temporairement ou d’une installation réalisée par une personne peu habituée à utiliser SCOM, cet agent se retrouve impossible à gérer de façon centralisée depuis la console :

clip_image002

clip_image004

Il n’est malheureusement pas possible de modifier cet état en passant par la console, ni en passant par Powershell ; la seule solution officielle est donc de désinstaller cet agent, puis de le réinstaller en le déployant cette fois depuis la console.

En réalité, cet état est stocké sous forme de « flag » dans la base de données OperationsManager.

La requête SQL suivante permet de lister tous les agents flaggés comme étant « non remotely manageable » :

select bme.DisplayName from MT_HealthService mths

INNER JOIN BaseManagedEntity bme on bme.BaseManagedEntityId = mths.BaseManagedEntityId

where IsManuallyInstalled = 1

clip_image006

On peut donc modifier l’état « non remotely manageable » simplement en passant le flag IsManuallyInstalled de 1 à 0 dans la base de données.

Attention, les modifications en base de données ne sont pas supportées par Microsoft ! Une sauvegarde de la base avant d’y exécuter des requêtes reste toujours vivement recommandé.

  • · Pour modifier le flag sur l’intégralité des serveurs et tous les passer en « Remotely Manageable », on utilise la requête SQL suivante :

UPDATE MT_HealthService
SET IsManuallyInstalled=0
WHERE IsManuallyInstalled=1

  • · Pour modifier le flag sur un unique serveur, on utilise la requête SQL suivante (note : le BaseManagedTypeID AB4C891F-3359-3FB6-0704-075FBFE36710 correspond au HealthService)

UPDATE MT_HealthService
SET IsManuallyInstalled=0
WHERE IsManuallyInstalled=1
AND BaseManagedEntityId IN
(select BaseManagedEntityID from BaseManagedEntity
where BaseManagedTypeId = 'AB4C891F-3359-3FB6-0704-075FBFE36710'
AND DisplayName = 'server.pouet.lan')

En effet, elle contient l’intégralité des serveurs qui s’authentifient par certificat et ces derniers sont dans la majorité des cas des serveurs installés manuellement pour une bonne raison (DMZ etc). Il n’est donc pas souhaitable de les repasser en RemotelyManageable.

Nous allons donc dans un premier temps lister l’ensemble des instances de cette classe à l’aide de powershell (à l’exception des serveurs MS et des gateway, qui sont bien des agents possédant un certificat mais que l’on souhaite gérer de facon centralisée)

Cette liste sera créée sous une forme directement exploitable dans une requête SQL :

$managementservers = Get-SCOMManagementServer | ForEach-Object {$_.displayname}

$certagents = get-scomclassinstance -class (Get-SCOMClass -name "MP_AgentCertificate.Server") | where {$managementservers –notcontains $_.displayname }

foreach ($certagent in $certagents) {"AND DisplayName != '" + $certagent.displayname + "'"}

clip_image008

Il ne reste plus qu’à copier la liste générée (les lignes AND DisplayName != ‘serveurxxx’ ) et à l’intégrer dans la requête SQL précédente :

UPDATE MT_HealthService
SET IsManuallyInstalled=0
WHERE IsManuallyInstalled=1
AND BaseManagedEntityId IN
(select BaseManagedEntityID from BaseManagedEntity
where BaseManagedTypeId = 'AB4C891F-3359-3FB6-0704-075FBFE36710'
AND DisplayName != 'server001'
AND DisplayName != 'server002'
AND DisplayName != 'server003'
AND DisplayName != 'server004'
)

Une fois la requête appropriée exécutée, vos agents devraient apparaitre comme RemotelyManageable dans la console SCOM quasi instantanément (un refresh de la console peut aider si ce n’est pas le cas).

SCOM 2012 – Identifier les agents authentifiés par certificat

Dans une infrastructure SCOM, il arrive couramment qu’une petite partie des agents nécessite une authentification par certificat, la plupart du temps lorsqu’ils sont installés sur des serveurs en DMZ, Workgroup ou sur des serveurs membres de domaines ne disposant pas de relation d’approbation.

De ce fait, ils sont la plupart du temps installés manuellement et non pas déployés depuis la console SCOM.

Ces agents nécessitent une attention particulière, car leur gestion diffère des agents déployés plus traditionnellement : ils nécessitent un renouvellement de certificat à échéance régulière, ils ne peuvent pas être mis à jour automatiquement…

Il n’existe pourtant par défaut pas de classe ni de groupe ni de vue dans SCOM qui permette de les identifier rapidement.

J’ai donc développé une classe pour y remédier. Elle se base sur un script VBS qui tourne toutes les 24h et identifie la présence de la chaine ChannelCertificateSerialNumber dans la clé HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings et peuple une classe MP_AgentCertificate.Server basée sur Microsoft.Windows.Computer.

Définition de la classe :

<ClassType ID="MP_AgentCertificate.Server" Accessibility="Internal" Abstract="false" Base="Windows!Microsoft.Windows.Computer" Hosted="false" Singleton="false" Extension="false" />

Définition de la découverte :

<Discovery ID="MP_AgentCertificate.Discovery" Enabled="true" Target="Windows!Microsoft.Windows.Computer" ConfirmDelivery="false" Remotable="true" Priority="Normal">

<Category>Discovery</Category>
<DiscoveryTypes>
<DiscoveryClass TypeID="MP_AgentCertificate.Server" />
</DiscoveryTypes>
<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.DiscoveryProvider">
<IntervalSeconds>86400</IntervalSeconds>
<SyncTime />
<ScriptName>regcertdiscovery.vbs</ScriptName>
<Arguments>$MPElement$ $Target/Id$ $Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Arguments>

<ScriptBody>
Dim oAPI
Set oAPI = CreateObject("MOM.ScriptAPI")
Dim oArgs
Set oArgs = WScript.Arguments
' Check for the required script arguments.
if oArgs.Count &lt; 3 Then
' If the script is called without the required arguments,
' create an information event and then quit.
Call oAPI.LogScriptEvent("regcertdiscovery.vbs",101,0,"script was called with fewer than three arguments and was not executed.")
Wscript.Quit -1
End If
Dim SourceID, ManagedEntityId, TargetComputer, strComputer

SourceId = oArgs(0) ' The GUID of the discovery object that launched the script.
ManagedEntityId = oArgs(1) ' The GUID of the computer class targeted by the script.
TargetComputer = oArgs(2) ' The FQDN of the computer targeted by the script.
Dim oDiscoveryData, oInst

Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)
Const HKEY_LOCAL_MACHINE = &amp;H80000002
strComputer = "."
Set StdOut = WScript.StdOut
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &amp; strComputer &amp; "\root\default:StdRegProv")
strKeyPath = "SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings"
strValueName = "ChannelCertificateSerialNumber"

oReg.GetBinaryValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

if IsNull(strValue) then
StdOut.WriteLine "no cert found"
Call oAPI.LogScriptEvent("regcertdiscovery.vbs",101,0,"no cert found")

else
Call oAPI.LogScriptEvent("regcertdiscovery.vbs",101,0,"cert found")

' Discovered the application. Create the application instance.

Set oInst = oDiscoveryData.CreateClassInstance("$MPElement[Name='MP_AgentCertificate.Server']$")

' Define the property values for this instance. Available

' properties are determined by the Management Pack that

' defines the class.

Call oInst.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)
Call oDiscoveryData.AddInstance(oInst)

end if

' Submit the discovery data for processing.

Call oAPI.Return(oDiscoveryData) </ScriptBody>

<TimeoutSeconds>600</TimeoutSeconds>
</DataSource>
</Discovery>

Libre à vous ensuite d’intégrer ces éléments à votre propre MP et d’y ajouter des moniteurs ou de créer une vue listant les instances de la classe MP_AgentCertificate.Server etc.

Note : il peut être utile de créer une override qui exécute cette découverte toutes les 10 minutes dans un premier temps, puis de la supprimer lorsque tous les serveurs sont découverts.

Attention si vous utilisez les instances de cette classe pour effectuer des traitements par lot : elle contient tous les agents possédant un certificat, y compris les MS et les Gateways !

Vous trouverez un exemple d’utilisation de cette classe dans l’article Passer des agents en remotely manageable

SCOM 2012 – Impossible de modifier un UserRole

 

Lors de la modification des propriétés d’un User Role (par exemple un changement dans le Scope), le message Parameter UserRoleDisplayName cannot be null apparait au moment de sauvegarder ces changements.

clip_image002

Bien entendu, dans la console SCOM, le champ « user role name » n’est pas vide.

A quoi peut donc être due cette erreur ?

Allons faire un tour dans la base de données, là où sont stockées les localisations :

clip_image004

select LanguageCode,LTValue from LocalizedText

where LTValue like ('operations manager %operators')

On remarque immédiatement que le rôle qui nous pose problème (ici Operations Manager Report Operators, mais cela pourrait être n’importe quel role créé après l’installation) comporte un LanguageCode différent, qui correspond normalement à la langue du système depuis lequel a été créé ce role.

On en déduit donc rapidement qu’un rôle créé depuis une console SCOM installée localement sur votre poste personnel (et dont le Windows est en général en francais) prend le LanguageCode correspondant à ce système et devient impossible à modifier depuis une console installée sur un système localisé dans une autre langue, par exemple depuis la console installée sur le serveur SCOM qui est généralement lui en anglais !

En attendant que Microsoft corrige ce problème, les contournements possibles sont assez évidents :

  • Utiliser une console installée sur un Windows localisé dans la même langue que celle qui a servi à créer le rôle
  • Modifier le champ LanguageCode des rôles problématiques afin de les passer en ENU. Notez cependant que Microsoft ne fournit pas de support si vous effectuez des modifications manuelles en base de données en dehors de leurs propres instructions.

SCOM - Modifier la criticité d’une alerte Exchange

Modifier la sévérité d’une alerte est une problématique qui peut sembler des plus basique dans le suivi d’une infrastructure SCOM, mais pour laquelle il est utile de préciser quelques subtilités lorsqu’il s’agit du management pack Exchange 2010 et de son correlation engine.

Comme vous ne l’ignorez probablement pas, le fonctionnement de ce management pack est particulier : la génération d’alertes repose sur un service externe, le correlation engine, qui s’occupe d’agréger toutes les remontées d’erreur afin d’en générer une seule alerte la plus pertinente possible.

clip_image002

Première subtilité : si pour créer votre override vous cliquez directement sur le champ Alert Rule contenant le nom de la règle KHI […], puis allez dans l’onglet Overrides et faites un Override > For all of Objects of Class […], cette dernière sera incorrecte.

Cette procédure est parfaitement valable en temps normal, mais pas ici. En effet, l’override doit être créée pour le serveur d’où provient réellement l’alarme, c'est-à-dire celui qui exécute le Correlation Engine, donc le RMS (ou RMS Emulator sous SCOM 2012). Or, par défaut la procédure mentionnée va cibler le rôle d’où l’alerte est supposée provenir, c'est-à-dire OWA dans notre exemple :

clip_image004

Il est donc ici nécessaire de créer l’override For all objects of another class, et de sélectionner la classe RMS (ou RMS Emulator sous SCOM 2012) :

clip_image006

Voilà déjà un écueil évité.

Seconde subtilité : une fois arrivé à l’écran de création de l’override à proprement parler, vous pouvez être surpris par la valeur par défaut du paramètre Severity, traditionnellement utilisé pour modifier la criticité d’une alerte. C’est là aussi dû au Correlation Engine.

clip_image008

Mais ne vous laissez pas impressionner par cette longue variable : il suffit d’indiquer en valeur d’override 0, 1 ou 2 selon la criticité souhaitée (info, warning, critical) !

N’oubliez pas d’enregistrer cet override dans un management pack dédié à Exchange.

SCOM 2012 – Console Authoring bloquée

Vous savez (et regrettez !) probablement déjà que la console Authoring présente dans SCOM 2007 n’existe plus dans SCOM 2012.

Il est toujours possible d’utiliser l’ancienne version pour créer un management pack, puis d’importer ce dernier dans SCOM 2012 : ca fonctionne, ca SCOM 2012 sait lire et convertir le format de MP 2007.

L’inverse n’est par contre malheureusement pas vrai : il est impossible d’ouvrir dans la console Authoring un MP exporté depuis SCOM 2012.

Voici ce que vous obtiendrez en boucle si vous vous y risquez :

clip_image002

“Referenced management pack not found”

Et vous aurez beau vous acharner et indiquer le MP demandé, rien n’y fera.

Mais pire encore, malheur à vous si vous avez essayé de référencer les MP de base de SCOM 2012 dans les options de la console Authoring en espérant que cela permette de les utiliser !

clip_image004

En effet, ce genre de réglage provoquera l’apparition en boucle du message précédent réclamant le MP System.Library Management Pack, sans possibilité de le sélectionner ni de revenir en arrière sur ce réglage !

Pour y remédier, rendez vous dans l’éditeur de registre (regedit) et ouvrez la clé HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Authoring\Settings\References

clip_image006

clip_image008

Supprimez le contenu de la ligne Value Data et cliquez sur OK.

La console Authoring est désormais à nouveau accessible.

SCOM 2012 - Ajouter un RunAs profile à un Moniteur ou à une Règle

Il peut arriver d’avoir besoin de créer une règle ou un moniteur qui s’exécute avec un RunAs Profile (lié à un runas account) spécifique, par exemple dans le cas d’un moniteur de type script qui interroge une base de données SQL pour laquelle un login particulier est requis.

Avec la console Authoring présente dans SCOM 2007, cette possibilité était accessible graphiquement : il suffisait de sélectionner un profil dans une liste déroulante dans les propriétés du moniteur.

Malheureusement, la console Authoring n’existe plus dans SCOM 2012, et la console Operations ne permet pas de sélectionner un RunAs profile lors de la création d’un moniteur… nous voilà donc réduits à modifier le management pack contenant ce moniteur directement en XML.

Si le RunAs Profile et son Account associé ne sont pas encore créés, il est cependant possible de les ajouter au management pack voulu à l’aide la console Operations :

Rendez-vous dans l’onglet Administration et faites un clic-droit sur Run-As Configuration –> Profiles. Sélectionnez Create Run As Profile

clip_image002

Cliquez sur Next

clip_image004

Choisissez un nom pour le run-as profile et enregistrez le dans un management pack (important : si le moniteur ou la règle qui qui doit être associé à ce profil est contenu dans management pack non scellé, il est obligatoire d’enregistrer le run-as profile dans le même management pack !), puis cliquez sur Next.

clip_image006

Cliquez sur Add pour ajouter un run-as account puis sélectionnez le Run-As account à associer avec ce profil (ou créez-en un nouveau) et sélectionnez l’étendue qui vous convient le mieux puis cliquez sur OK. Cliquez sur Next.

clip_image008

clip_image010

Pensez à distribuer le run-as account sur les serveurs où il sera utilisé s’il est configuré en more secure, puis cliquez sur Close.

clip_image012

Une fois le run-as profile créé et configuré dans le bon management pack, il faut exporter ce management pack pour travailler dessus.

Allez dans Administration -> Management Packs, recherchez le MP qui contient les moniteurs et règles à modifier et cliquez sur Export Management Pack. Choisiseez un dossier de destination pour le fichier XML enregistrez le.

clip_image014

Ouvrez ce fichier XML dans un éditeur de texte et localisez le bloc SecureReferences. Il contient un champ SecureReference (au singulier), qui indique l’ID de votre RunAs profile (si vous l’avez créé dans la console comme expliqué précédemment, il aurait un ID généré automatiquement beaucoup plus long) :

<SecureReferences>
<SecureReference ID="Test.Monitors.RunAsProfile" Accessibility="Internal" Context="System!System.Entity" />
</SecureReferences>

Notez cet ID, il va nous servir juste ensuite.

Il y a maintenant deux possibilités, selon que vous souhaitiez ajouter ce RunAs profile à un moniteur ou à une règle.

Cas du moniteur :

Localisez la ligne UnitMonitor correspondant au moniteur auquel vous souhaitez ajouter le RunAs Profile, par exemple :

<UnitMonitor ID="UIGeneratedMonitorff3366f355ae45a391b645c36c9d1ba3" Accessibility="Public" Enabled="true" Target="Test.Class" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="Windows!Microsoft.Windows.TimedScript.TwoStateMonitorType" ConfirmDelivery="false">

Il suffit maintenant d’ajouter à cette ligne le paramètre RunAs="Test.Monitors.RunAsProfile", et le tour est joué :

<UnitMonitor ID="UIGeneratedMonitorff3366f355ae45a391b645c36c9d1ba3" Accessibility="Public" Enabled="true" Target="Test.Class" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" RunAs="Test.Monitors.RunAsProfile " TypeID="Windows!Microsoft.Windows.TimedScript.TwoStateMonitorType" ConfirmDelivery="false">

Cas de la règle :

Là aussi, c’est très simple, à une subtilité près : il ne faut pas ajouter le paramètre RunAs="Test.Monitors.RunAsProfile " à la règle elle-même (ligne Rule), mais à sa DataSource.

Commencez donc par localiser la ligne Rule correspondant à la règle à modifier, par exemple

<Rule ID="MomUIGeneratedRule7fbfb108d804460e9b8e13deb1ea1b0c" Enabled="true" Target="Test.Class" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100" >

Quelques lignes plus bas doit se trouver la ligne DataSource correspondante :

<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.PerformanceProvider">

Il suffit d’ajouter à cette dernière notre paramètre RunAs :

<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.PerformanceProvider" RunAs="Test.Monitors.RunAsProfile ">

Une fois la modification apportée à tous les moniteurs et règles souhaités, sauvegardez le fichier XML (en pensant à incrémenter son champ Version !) et réimportez le dans SCOM.

Le RunAs profile s’applique désormais aux moniteurs et règles désirés :)

SCOM 2012 : impossible d’ajouter des Knowledge

Si vous essayez de remplir des Knowledge (base de connaissance) dans SCOM 2012, il y a de fortes chances que vous rencontriez le message d’erreur suivant :

clip_image002

Failed to launch Microsoft Word. Please make sure Microsoft Word is installed. Here is the error message :
Could not load file or assembly « Microsoft.Office.Interop.word, Version 11.0.0.0, Culture = Neutral, PublicKeyToken=71e9bce111e9429c or one of its dependencies. The system cannot find the file specified.

Microsoft propose un contournement non officiel en attendant une mise à jour future qui résoudra ce bug.

Il est dans un premier temps nécessaire de s’assurer que les prérequis sont précisément remplis, car cette fonctionnalité y est très sensible :

1. Installer Word 2010 en version x86 uniquement

2. Installer les VSTOR 2005 (Visual Studio 2005 Tools for Office Second Edition Runtime) (éventuellement en complément d’une version ultérieure, mais cette version 2005 SE est impérative !) http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=20479

3. Rebooter la machine sur laquelle Word et les VSTOR sont installés, même si l’installeur de VSTOR n’a rien demandé.

Il est maintenant temps de mettre en place le contournement à proprement parler.

Récupérer le fichier suivant : http://blogs.technet.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-03-52-52-89/KnowledgeEditingNewFiles.zip (mis à disposition par l’équipe SCOM sur son blog : http://blogs.technet.com/b/momteam/archive/2012/10/10/how-to-get-knowledge-editing-to-work-in-operations-manager-2012-with-office-2010.aspx ) et le décompresser dans le répertoire X:\Dossier dinstallation\System Center 2012\Operations Manager\Console à la place des fichiers knowledge.dot et Microsoft.EnterpriseManagement.Monitoring.Console.exe.config qui s’y trouvent déjà (vous pouvez renommer les anciens au lieu de les écraser pour conserver une trace des modifications).

Comme le fichier knowledge.dot de remplacement contient des macro et provient d’internet, il est nécessaire de le déverrouiller (clic droit -> propriétés -> unblock):

clip_image004

Il devrait maintenant être possible d’ajouter des knowledge dans SCOM 2012 en utilisant la procédure habituelle.

SCOM–Impossible d’accéder aux sites de l’APM

Quelques temps après le déploiement d’une infrastructure SCOM 2012, un client a souhaité mettre en place une de ses nouvelles fonctionnalités, à savoir le monitoring applicatif (APM).

Après avoir mis en supervision quelques applications Web, nous nous sommes rendus compte que les sites permettant l’analyse de cette supervision (nommés respectivement Application Diganostics et Application Advisor) ne fonctionnaient pas : lors d’une tentative d’accès, ils renvoyaient tous deux une erreur « An error has occured : The additional error information can be found in the Windows Application Log. We apologize for any inconvenience caused by this temporary service outage. »

clip_image002

Un tour dans l’event viewer nous en apprend effectivement un peu plus :

clip_image004

Le message complet indique :

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 01/03/2013 16:52:22
Event time (UTC): 01/03/2013 15:52:22
Event ID: b5c9f03cbae94f40b2e35d1a28651518
Event sequence: 8
Event occurrence: 1
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1/ROOT/AppAdvisor-2-130066267234915799
Trust level: Full
Application Virtual Path: /AppAdvisor
Application Path: D:\OpsMgr\WebConsole\AppDiagnostics\AppAdvisor\Web\
Machine name: BT1SVX2K

Process information:
Process ID: 2868
Process name: w3wp.exe
Account name: IIS APPPOOL\OperationsManagerAppMonitoring

Exception information:
Exception type: OleDbCommandException
Exception message: Exception has been thrown by the target of an invocation.
Command text: SELECT apm.IsInstallCompleted ()
Connection: Provider=SQLOLEDB;Server=BTCISQL03\OPSVMM;database=OperationsManagerDW;Integrated Security=SSPI;

at Avicode.AX5.Data.OleDb.OleDb.ExecuteScalar(OleDbCommand oleDbCommand)
at Avicode.Intercept.SEManager.Core.DBAccess.DB.ExecuteScalar(String query)
at Avicode.Intercept.SEManager.WebViewer.Pages.Authenticate.Page_Load(Object sender, EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Exception has been thrown by the target of an invocation.
at Avicode.AX5Base.IdentityThread.Execute(Action action)
at Avicode.AX5.Data.OleDb.OleDb.ExecuteScalar(OleDbCommand oleDbCommand)

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
at System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection)
at System.Data.OleDb.OleDbConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.OleDb.OleDbConnection.Open()
at Avicode.AX5Base.IdentityThread.ActionItem.ExecutionBody(Object actionItem)

Request information:
Request URL: http://localhost/AppAdvisor/Pages/Authenticate.aspx?ReturnUrl=/AppAdvisor
Request path: /AppAdvisor/Pages/Authenticate.aspx
User host address: ::1
User:
Is authenticated: False
Authentication Type:
Thread account name: IIS APPPOOL\OperationsManagerAppMonitoring

Thread information:
Thread ID: 15
Thread account name: IIS APPPOOL\OperationsManagerAppMonitoring
Is impersonating: False
Stack trace: at Avicode.AX5.Data.OleDb.OleDb.ExecuteScalar(OleDbCommand oleDbCommand)
at Avicode.Intercept.SEManager.Core.DBAccess.DB.ExecuteScalar(String query)
at Avicode.Intercept.SEManager.WebViewer.Pages.Authenticate.Page_Load(Object sender, EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

La partie intéressante étant Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON', puisqu’elle indique qu’ASP a refusé une connexion anonyme.

Il est donc temps d’aller faire un tour du coté de la MMC IIS, plus précisément dans les Applications Pool. Voici ce qu’on y trouve :

clip_image006

Configuré de la sorte, cela ne permet pas d’accéder à la base de données, d’où notre erreur. Il faut donc les modifier et mettre un compte qui a les droits sur la base via les Advanced Settings :

clip_image008

clip_image010

Répéter l’opération pour le second Application Pool, puis recycler les deux.

Voilà, désormais l’accès est possible !