PI Services

Le blog des collaborateurs de PI Services

SCOM 2012 - Réinitialiser automatiquement le moniteur lorsque l’alerte correspondante est fermée manuellement

 

Une problématique très commune dans la gestion quotidienne d’une infrastructure SCOM est la cloture par un opérateur humain d’alertes générées par un moniteur : dans ce cas, le moniteur reste dans son état warning ou critical mais l’alerte n’est plus présente et n’est jamais re-générée, empêchant donc les opérateurs de s’apercevoir du problème.

La bonne pratique est bien entendu de résoudre le problème à l’origine de l’alerte, ce qui permettra au moniteur de revenir à son état Healthy et donc à l’alerte de se cloturer automatiquement.

Afin de se prémunir contre ce genre de problème, il est possible de déclencher une action automatique qui vérifiera si une alerte cloturée l’a été par un compte autre que “System” a été générée par un moniteur : le cas échéant, un script réinitialisera le moniteur à l’origine de l’alerte, de facon à ce qu’il puisse repasser en critical ou warning et que l’alerte soit régénérée au passage.

Ce genre de solution est réalisable à l’aide d’Orchestrator ( http://stefanroth.net/2012/05/05/reset-monitor-using-scom-2012-and-orchestrator-a-must-have-runbook/ ) ou d’outils tiers comme Green Machine ( http://blogs.technet.com/b/timhe/archive/2014/07/25/greenmachine-2012.aspx )  mais j’ai ici préféré une approche réalisable sans produit autre que SCOM.

 

Commençons par créer le script qui réalisera les tâches décrites ci-dessus. Il devra être présent dans le même répertoire sur tous les serveurs membres du management pool Notification.
Je me suis très largement inspiré du script de de Stefan Roth pour cette étape, en l’adaptant aux contraintes du mode de fonctionnement retenu. Pensez à modifier scom01 par le nom de votre serveur SCOM :

#checkresetmonitoralert.ps1

Param($alertid)

# Import Operations Manager Module and create Connection
Import-Module OperationsManager;
New-SCOMManagementGroupConnection scom01;

$alerts = Get-SCOMAlert -Id $alertid | where { ($_.ismonitoralert -eq $true) -and ($_.resolvedby -ne "System") }

foreach ($alert in $alerts)

{

# Get IDs
$mrid = $alert.monitoringruleid
$mcid = $alert.monitoringclassid
$moid = $alert.monitoringobjectid

# Get Objects
$monitor = Get-SCOMMonitor -id $mrid
$monitoringclass = Get-SCOMClass -id $mcid
$monitoringobject = Get-SCOMMonitoringobject -class $monitoringclass | where {$_.id -eq $moid}

# Reset Monitor
$monitoringobject | foreach{$_.ResetMonitoringState($monitor)}

}

Nous allons ensuite créer un ensemble de règles de Notification (Channel,Subscriber,Subscription) qui nous permettront d’appeler ce script à chaque fois qu’une alerte est clôturée.
D’abord le Channel, qui sera de type Command :

clip_image002_thumb[2]

Indiquez un nom explicite et une description :

clip_image004_thumb[1]

Dans le champ Full path of the command file, indiquer le chemin vers l’executable de powershell. Il s’agit par défaut de C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Dans le champ Command line parameters, indiquer les paramètres suivants (pensez à remplacer le chemin du script par le chemin où se trouvera le script dans votre cas) :
-Command "& '"D:\chemin\vers\script\checkresetmonitor.ps1"'" -alertid '$Data/Context/DataItem/AlertId$' -computerPrincipalName '$Data/Context/DataItem/ManagedEntityDisplayName$'

Dans le champ Startup folder indiquer le chemin du dossier où se trouve le script.

clip_image006_thumb[1]

Cliquez sur Finish puis sur Close

clip_image008_thumb[1]

 

Créons ensuite le Subscriber :

Indiquez un nom (le même que pour le Channel, par exemple) :

clip_image010_thumb[1]

Laissez coché Always send notifications

clip_image012_thumb[1]

Cliquez sur Add

clip_image014_thumb[1]

Indiquez un nom (toujours le même…)

clip_image016_thumb[1]

Dans la liste Channel Type, indiquez Command. Dans la liste Command Channel, sélectionnez le channel créé précédemment.

clip_image018_thumb[1]

Laissez coché Always send notification

clip_image020_thumb[1]

Cliquez sur Finish

clip_image022_thumb[1]

 

Il reste à créer la Subscription.

Indiquez un nom (oui, encore le même).
Cochez with specific resolution state et indiquez l’état Closed (255)

clip_image024_thumb[1]

clip_image040_thumb[2]

Cliquez sur Add

clip_image026_thumb[1]

Ajoutez le Subscriber précédemment créé et cliquez sur OK

image_thumb[2]

Cliquez sur Next

clip_image030_thumb[1]

Cliquez sur Add

clip_image032_thumb[1]

Ajoutez le Channel précédemment créé et cliquez sur OK

image_thumb[4]

Cliquez sur OK

clip_image036_thumb[2]

Cliquez sur Finish

clip_image038_thumb[1]

 

Désormais, toutes les alertes qui seront cloturées seront analysées par le script powershell, qui réinitialisera le moniteur correspondant au besoin.

SCOM - ”Dé-découvrir” des objets récalcitrants

Le mécanisme de découverte est un des principe fondamentaux de SCOM et constitue un de ses atout majeur : il permet de trouver automatiquement les objets à superviser sur tous les serveurs disposant d’un agent, sans qu’un opérateur n’ait besoin d’indiquer manuellement à chaque nouveau serveur ce qu’il faut superviser dessus.

L’inverse est également vrai : lors de la suppression d’une application ou d’un service sur un serveur, SCOM est capable de s’en rendre compte et cesse de le superviser.

Du moins, la plupart du temps : il arrive parfois que SCOM ne se rende pas compte de ces désinstallations et génère alors un grand nombre d’erreurs infondées.

Quelle en est la raison, et comment y remédier?

Prenons un exemple concret :

image

Un serveur hébergeait le rôle contrôleur de domaine et ce rôle a été décomissionné.

Cependant, les objets de type SysVol (et d’autres objets propres à un contrôleur de domaine comme Netlogon, NTDS..) sont toujours présents dans SCOM et toujours supervisés, et remontent donc en erreur en générant des alertes.

Si l’on remonte la piste de la découverte de ces objets, on se rend compte qu’il s’agit ici comme souvent d’une découverte en 2 étapes :
- D’abord une découverte légère ciblée sur Windows Computer qui se base sur une requête WMI pour découvrir les instances de la classe Windows Domain Controller :
image

- Puis une découverte beaucoup plus lourde ciblée sur ces Windows Domain Controllers et qui utilise elle un gros script VBS. C’est cette dernière qui découvre les instances des différentes classes Sysvol, Netlogon & co :
image

image

 

Jusqu’ici, rien d’inhabituel, ce mécanisme est très commun dans les gros management pack.

Imaginons maintenant que nous supprimions le rôle Contrôleur de Domaine d’un serveur. Que se passe t’il dans SCOM?

1. La première découverte ciblée sur Windows Computer s’exécute normalement, se rend compte que la requête WMI n’indique plus la présence d’un DC et supprime donc l’instance de la classe Windows Domain Controller pour notre serveur.

2. Comme il n’existe plus d’instance de la classe Windows Domain Controller pour notre serveur, la seconde découverte ne s’exécute plus sur ce serveur.

Seulement voilà : une découverte qui ne s’exécute pas, ce n’est pas la même chose qu’une découverte qui indique qu’un élément n’existe plus sur le serveur, et les objets Sysvol & co. ne sont donc jamais “dé-découverts”!

Comment maintenant remédier à cette situation?

Il existe un cmdlet Remove-SCOMDisabledClassInstance (Remove-DisabledMonitoringObject dans SCOM 2007) dont l’utilité est de parcourir toutes les règles de découverte présente dans votre environnement SCOM et de supprimer les instances des objets découverts par une règle donnée quand celle-ci est désactivée (via un override) pour l’objet cible de cette découverte.
Autrement dit, il suffirait de créer un Override > for a specific object of class Windows Domain Controller > Enabled = False sur la règle de découverte AD DC local discovery (DC Role), pour l’objet Windows Domain Controller correspondant à notre DC décommissionné.

Sauf que justement, cet objet n’existe plus puisque la première découverte a elle parfaitement fonctionné…
Il faut donc ruser un peu en créant un groupe qui contient l’objet Windows Computer correspondant au DC décommissionné, et d’ensuite créer notre override pour ce groupe :
image

image

 

Une fois l’override crée, on peut enfin exécuter le cmdlet Remove-SCOMDisabledClassInstance. Selon la taille de votre infrastructure, son exécution peut être assez longue comme vous l’indique le message en rouge (à titre d’exemple, il a pris environ 1 à 2 minutes sur un environnement contenant ~200 serveurs et autant de MP).

image

 

Et si tous s’est bien passé, les objets découverts par la règle AD DC local discovery (DC Role) sur le contrôleur de domaine décomissionné doivent maintenant avoir disparu.

SCOM 2012 - Dashboards et Widgets

Depuis la sortie du RU 2 pour SCOM 2012 R2 (et du RU6 pour SCOM 2012 SP1), de nouveaux widgets sont disponibles et enrichissent grandement les possibilités de dashboards.

Une bonne occasion de centraliser ce qu’il est possible de faire en la matière et de résumer brièvement les possibilités offertes par ces modules!

Widgets

Les widgets sont les éléments qui composent les dashboards, il en existe de nombreux types.

Widget

Description

Example

Alert Widget

Affiche les alertes propres à un objet, une classe ou un groupe d’objets.

clip_image026

clip_image028

Contextual Alert Widget

Identique au précédent sauf qu’il cible les alertes en fonction d’un objet sélectionné dans un autre widget du dashboard.

clip_image029

Object Health Widget

Vue de l’état de santé des moniteurs qui s’appliquent sur un objet prédéfini et les sous-objets qu’il contient

clip_image031

Contextual Health Widget

Identique au précédent sauf qu’il cible un objet sélectionné dans un autre widget du même dashboard.

clip_image032

Details Widget (Contextual)

Affiche les propriétés d’un objet sélectionné dans un autre widget (de type alerte ou state) du même dashboard

clip_image034

clip_image036

Instance Details Widget

Identique au précédent mais pour un objet présélectionné

clip_image038

Image Widget

Affiche une image.

clip_image040

Object Detail Tiles Widget

Affiche des briques de tuiles (état de santé et alertes, SLA, compteurs de performance…) pour un objet

clip_image042

Object SLA Widget

Affiche le SLA d’un objet sur lequel s’applique une règle de SLA

clip_image044

SLA Widget

Identique au précédent mais peut afficher plusieurs SLA dans le même widget

clip_image046

SLA Tiles Widget

Affiche des SLA sous forme de tuiles.

clip_image048

Objects by Performance

Widget type “Top 10” (permet en réalité de faire des top N de 1 à 20, et des affichages dégressifs)

Utilisé particulièrement pour afficher les N serveurs (ou instances SQL..) les plus chargés en CPU, RAM, disque dur…

clip_image049

Performance Widget

Affiche un ou plusieurs compteurs de performance pour des objets prédéfinis

clip_image051

clip_image053

Powershell Grid Widget

Affiche le résultat d’un script powershell dans une grid.

clip_image055

PowerShell Web Browser Widget

Affiche une page web (possibilité de lui passer des paramètres provenant d’un script powershell, par ex pour faire automatiquement une recherché sur une erreur sélectionnée dans un Alert widget)

clip_image057

Web Browser Widget

Affiche une page web, contenant éventuellement l’id d’une alerte

clip_image059

State Tiles Widget

Affiche l’état d’objets et le nombre d’alertes liées sous forme de tuiles

clip_image061

State Widget

Affiche l’état de santé d’un ou plusieurs objets prédéfinis sous forme de liste

clip_image063

clip_image065

Topology Widget

Affiche une image représentant l’état de santé pour un ou plusieurs objets avec une autre image en fond (carte géographique, schéma de datacenter…)

clip_image067

     

 

Types de dashboards

Pour rappel, un dashboard SCOM est une vue synthétique permettant d’afficher des informations de différentes manières et depuis différentes sources. 

On retrouve 4 types de disposition de dashboards :

  • Affichage de widgets en colonne
  • Affichage de widgets en grille
  • Template de niveau de service (Service Level Dashboard)
  • Template de résumé (Summary Dashboard)

Widgets en colonne

Jusqu’à 5 colonnes cote à cote contenant un widget chacune

Exemple 2 colonnes:

clip_image002

Exemple 4 colonnes:

clip_image004

Widgets en grille

Il est possible de créer des grilles de 1, 2, 3, 4, 5,6 et 9 cellules avec les dispositions suivantes:

clip_image006clip_image008

clip_image010clip_image012

clip_image014

clip_image016clip_image018

Exemple 5 cellules:

clip_image020

Service Level Dashboard:

Ce dashboard est préconfiguré, on ne peut pas modifier sa disposition ni ses widgets  mais seulement leur configuration.

Il affiche un apercu de l’état de SLA pour des objets prédéfinis

clip_image022

Summary Dashboard:

Le dashboard summary (résumé) est préconfiguré pour créer une grille de 3 cellules contenant les widgets 'Object by Performance’, ‘Performance’ et ‘State’ : 

clip_image024

 

 

Vous disposez maintenant de tous les éléments pour réaliser des dashboards à la fois utiles, pertinents et agréables à l’oeil!

 

Note : les captures d’écran de ce billet proviennent de différentes sources web

SCOM - The RPC server is unavailable.(0x800706BA)

Le fonctionnement normal du Health Service SCOM (qu’il se trouve sur un Management server ou un agent supervisé) implique qu’il essaye régulièrement de vérifier la validité des RunAs Accounts (à chaque démarrage du service, à chaque changement de configuration, à réception d’un nouveau Management Pack etc).

Il peut arriver que cette vérification échoue, provocant alors une alerte de type The Health Service cannot verify the future validity of the RunAs account. (évènement 7016 dans le journal Operations Manager)

Cette alerte peut avoir de nombreuses origines, et le message qui l’accompagne peut normalement aider à identifier la cause.

Intéressons-nous ici plus spécifiquement à l’évènement “The RPC server is unavailable.(0x800706BA)”, observé chez un client qui dispose d’une forêt multi-domaines. Certains serveurs supervisés se trouvent dans un domaine différent de celui où se trouve le compte SCOM Action.

Ce message laisse supposer des difficultés pour joindre un contrôleur de domaine capable d’authentifier le compte.

Commençons donc par identifier quel est le DC qui est contacté, en exécutant la commande nltest /dsgetdc:corp.domaine.lan sur le serveur d’où l’erreur provient (et où corp.domaine.lan correspond au domaine qui héberge le RunAs account problématique) :

image

Le champ DC indique quel est ce contrôleur de domaine.

Il faut s’assurer qu’il est joignable sur les ports 88 (kerberos) et 389 (LDAP), et ce à la fois en passant par son FQDN et par son nom court

C’était ici la cause de notre problème : la résolution DNS ne permettait pas d’interroger ce DC via son nom court. Un simple ajout de suffixes DNS dans la configuration de la carte réseau a donc permis de corriger l’erreur.

Astuce supplémentaire : afin de forcer une revérification des credentials par le Health Service, il suffit de redémarrer ce dernier.

Office 365 - Nettoyer un compte

 

Lorsqu’on se contente de supprimer un compte dans Office365, que ca soit via la console Web ou via powershell, il n’est pas réellement totalement détruit et cela peut occasionner des comportements étranges s’ils sont resynchronisés par la suite.

Afin d’y remédier, il est possible de forcer la suppression totale de ce compte via powershell.

Commencer par supprimer de facon classique le compte :
Remove-MsolUser -UserPrincipalName utilisateur@domaine.com

Puis forcer le nettoyage :
 Get-MsolUser -ReturnDeletedUsers -UserPrincipalName utilisateur@domaine.com | Remove-MsolUser RemoveFromRecycleBin -Force

Il est maintenant possible de relancer un DirSync et l’utilisateur sera intégralement resynchronisé comme s’il n’avait jamais existé.

Office 365 - Synchroniser des utilisateurs en mailuser avec DirSync

 

Si vous utilisez Office 365 dans votre infrastructure, il y a de fortes chances que vous soyez déjà utilisateur de DirSync pour synchroniser votre AD local.

Synchronisation d’utilisateurs locaux en utilisateurs distants ou de Mail Enabled Users locaux en MailUser distants ne vous posent évidemment aucun souci particulier.

Mais comment faire si vous souhaitez sortir des sentiers battus et synchroniser vos utilisateurs en mailuser distants (ce qui constitue un prérequis à l’utilisation de certains outils de migration)?

Commençons par le début : qu’est-ce qui définit un MailUser? Ce blog technet nous apprend qu’il suffit que les attributs mailNickName, DisplayName et TargetAddress soient peuplés.

Seulement voilà : si vos utilisateurs disposent normalement déjà d’un mailnickname et d’un displayname, il en va tout autrement de la targetaddress qui est normalement utilisée afin de rediriger les mails qui leur sont adressés : aucune chance donc que leurs comptes comportent déjà cet attribut, encore moins paramétré vers leur propre adresse, ce qui créerait des boucles de routage.

Il faut donc trouver un moyen de rediriger l’adresse mail de l’utilisateur local vers le champ targetadress de son compte synchronisé dans office 365.

Et cette solution, c’est DirSync : moyennant quelques paramétrages, il va nous permettre ce tour de passe-passe.

Lancez la console MIIS DirSync (elle se trouve par défaut ici : "C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe" ) et ouvrez l’onglet Management Agents

image

Double-cliquez sur Active Directory Connector puis cliquez sur l’onglet Configure Attribute Flow

image

Déplier la catégorie Object Type : user.

Dans le menu déroulant Data source object type, sélectionner user puis dans la liste Data source attribute, sélectionner mail.
Dans mapping type, cocher Direct.
Dans Flow Direction, cocher Import
Dans le menu déroulant Metaverse object type, sélectionner person
Dans la liste Metaverse attribute, sélectionner targetAddress

Cliquer sur New puis sur OK

image

 

Et… c’est tout. Désormais, lorsque les utilisateurs seront synchronisés depuis l’AD vers la metaverse (base de donnée intermediaire de DirSync), l’attribut targetAddress sera peuplé avec leur adresse mail; puis quand DirSync synchronisera la metaverse vers Office365, les utilisateurs seront synchronisés en tant que MailUser.

SCOM 2012 – Faire fonctionner l’enregistrement de session de navigation Web dans Internet Explorer 10 et 11

 

Si l’on s’en fie à Technet, ( http://technet.microsoft.com/en-us/library/hh457546.aspx ), l’utilisation d’IE 10 (et par extension IE 11) n’est pas supportée pour réaliser l’enregistrement d’une session de navigation Web dans SCOM.

Un test rapide le confirme : le plugin Web Recorder ne se charge pas.

On pourrait croire qu’il s’agit du problème bien connu de compatibilité du plugin avec IE x86/x64 (http://social.technet.microsoft.com/wiki/contents/articles/1307.scom-howto-use-the-webrecorder-on-windows-64bit.aspx), mais il n’en est rien…

Fort heureusement, il reste possible de faire fonctionner l’enregistrement dans IE 10 et 11 moyennant quelques ajustements.

Dans Internet Explorer, ouvrir le menu Outils > Options Internet, onglet Avancé.
Vérifier que les cases Activer les extensions tierce partie du navigateur (Enable third party browser extensions) et Activer le mode protégé amélioré (Enable Enhanced Protected Mode) sont cochées et les cocher si elles ne le sont pas.

clip_image002

Quitter IE et ouvrir l’éditeur de registre regedit.

Naviguer jusqu'à la clé de registre suivante : HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main
Ajouter une entrée de type DWORD nommée TabProcGrowth et lui donner la valeur 0

clip_image004

Puis naviguer jusqu’à la clé HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories64\
Supprimer les deux sous-clés {00021493-0000-0000-C000-000000000046} et {00021494-0000-0000-C000-000000000046} . Ces clés correspondent à un cache d’information concernant le plugin WebRecorder, les supprimer force donc IE à remettre en cache ces informations.

Redémarrer l’ordinateur sur lequel est effectuée la capture si des modifications ont été apportées aux paramétrages avancés d’Internet Explorer.

Relancer une capture depuis SCOM. Au lancement d’IE, la barre apparait :

clip_image006

Alternativement, un prompt d’activation du plugin peut apparaitre au lancement d’IE (accepter l’activation) et il peut être nécessaire d’afficher la barre Web Recorder via le menu Affichage > Volets d’Exploration.

SCOM 2012 - exploiter le contenu d’évènements stockés dans la base de donnée pour créer une alerte

 

De nombreux Management Pack SCOM créent des évènements dans la base SCOM (visibles dans la console SCOM via les vues Events).

C’est notamment le cas du MP de collecte  et de formatage d’évènements Syslog que je vous ai proposé dans un billet précédent.

Ces évènements n’ont bien sur que peu d’utilité s’ils ne sont pas traités pour obtenir des alertes ou des courbes de performance…

Je vais ici expliquer comment exploiter ces informations à l’aide d’une règle d’alerte qui exécute un script powershell.

Contexte : il a été demandé de générer une alerte lorsqu’un évènement syslog provenant d’un device réseau n’est pas recu un certain nombre de fois dans un laps de temps donné…. J’ai retourné le problème dans tous les sens mais il n’est à ma connaissance pas possible d’y répondre à l’aide d’un workflow utilisant des datasource et des conditions des librairies “standard”.

La solution la plus simple est alors de stocker tous les évènements syslog proprement formatés dans la base SCOM, et de les traiter à l’aide d’un script.

Voyons d’abord comment il est constitué dans son ensemble, je détaillerai chaque partie ensuite :

                <ScriptBody>
param($IPAddress)

$api = new-object -comObject 'MOM.ScriptAPI'
$bag = $api.CreatePropertyBag()


$SQLServer = (Get-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\').databaseservername
$SQLDBName = (Get-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup\').databasename
$SqlQuery = "SELECT TOP 2 * FROM [OperationsManager].[dbo].[EventView] where channel like 'syslog' AND LoggingComputer = '" +  $ipaddress + "'  AND EventData like '%Sophos pattern update failed: File transfer failed%' ORDER BY TimeGenerated DESC"
$sqlquery

$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = "Server = $SQLServer; Database = $SQLDBName; Integrated Security = True"

$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $SqlQuery
$SqlCmd.Connection = $SqlConnection

$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd

$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)

$SqlConnection.Close()

$referencedate = (get-date).addhours(-4).touniversaltime()

$result = ($DataSet.Tables[0] | where {$_.timegenerated -gt $referencedate} | measure).count

if ($result -ge "2")
{
$status = "KO"
$api.LogScriptEvent('Mirapoint CheckSophosTransferFailed Result : KO ',20,4,$ipaddress)
}

else {$status = "OK"
$api.LogScriptEvent('Mirapoint CheckSophosTransferFailed Result : OK ',20,4,$ipaddress)
}


if ($status -eq "KO") { $bag.AddValue('Status','Bad') }
else { $bag.AddValue('Status','Good') }

$bag

</ScriptBody>

Passons aux explications détaillées :

param($IPAddress) permet juste de récupérer l’adresse IP, passée en paramètre du script. C’est elle qui nous permet d’identifier les évènements correspondant au bon device réseau supervisé.

$SQLServer et $SQLDBName sont des variables qui récupèrent le nom du serveur et de la base SQL de SCOM dans la base de registre du serveur MS sur lequel s’execute le script (comme la règle est ciblée sur des device réseau, le script s’execute sur le MS qui gère le périphérique et non pas sur l’agent)

$SqlQuery est la requête SQL sur laquelle va s’appuyer le traitement du script. La partie “FROM [OperationsManager].[dbo].[EventView]” est obligatoire car il faut requêter la vue EventView pour accéder aux évènements SCOM. Pour le reste, libre à vous d’adapter à votre besoin!

Tout le bloc entre $SqlConnection et $SqlConnection.close() peut être recopiée tel quel, il contient les cmdlet permettant d’effectuer la connexion à la base SQL, d’exécuter la requête et de récupérer son résultat dans la variable $DataSet.Tables[0] .

Le reste du code contient la logique du script et dépend donc de vos besoins, rappelez vous simplement de finir votre script en peuplant puis en retournant le propertybag :

if ($status -eq "KO") { $bag.AddValue('Status','Bad') }
else { $bag.AddValue('Status','Good') }

$bag

Je ne saurais trop vous recommander de tester votre script “en dehors” du management pack avant de l’y intégrer car il peut vite devenir complexe… une fois satisfait, créez votre règle basée sur une probe Microsoft.Windows.PowerShellPropertyBagProbe par exemple comme le décrit Microsoft : https://social.technet.microsoft.com/wiki/contents/articles/16752.management-pack-composition-exercise-2-creating-a-monitor-based-on-a-windows-powershell-script.aspx

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 !