PI Services

Le blog des collaborateurs de PI Services

Orchestrator – Ajouter des images au corps du mail

 

Lors de l’envoi d’un email dans Orchestrator à l’aide de l’activité Send Email, il est possible de choisir entre de choisir entre le format texte brut et le format HTML pour le corps du mail, dans l’onglet Advanced :

clip_image002

Il devient alors tout naturel de vouloir y intégrer des images à l’aide de la balise HTML <img> , afin d’enrichir encore la mise en page.

Il est alors possible d’avoir recours à plusieurs méthodes : la plus classique consiste à stocker ces images à un endroit accessible par tous les destinataires du mail (site web, partage réseau…) ; mais cette technique présente différents inconvénients : les images sont inaccessibles si l’accès à la source n’est pas disponible au moment de la lecture du mail, la plupart des clients mail bloquent leur chargement par défaut…

Une autre solution consiste à intégrer directement ces images dans les pièces jointes, et à les appeler à l’aide d’un Content ID (CID) au lieu d’un lien réseau ou http, à l’aide de la syntaxe suivante : <img src=’’cid:nomdelimage.jpg’’ />

clip_image003

clip_image005

Et c’est tout, les images seront désormais visibles dans le corps du mail. Encore mieux : selon le client mail utilisé, elles n’apparaitront même pas dans les pièces jointes !

Assurez-vous toutefois bien que le serveur Orchestrator soit lui toujours en mesure d’accéder aux images, il les recharge à chaque appel de l’activité Send Email.

SCOM - Créer une vue avec un filtre « NOT »

 

Tout administrateur SCOM qui se respecte a déjà été amené à créer des vues d’alerte ou d’état spécifiques, ciblées sur une classe et filtrées en fonction d‘un niveau de résolution (resolution state), d’une criticité…

clip_image001

clip_image002

Une problématique revient cependant de temps en temps : comment créer une vue qui exclue spécifiquement certaines alertes en fonction de leur nom ?
Autrement dit, comment afficher toutes les alertes SAUF celles correspondant à un certain nom ?

Le filtre « with a specific name » ne permet à première vue pas de réaliser cette exclusion ; il semble plutôt prévu pour fonctionner en mode « inclusif » : seules les alertes répondant à la chaine de caractères entrée seront affichées :

clip_image004

Mais il est en réalité possible d’utiliser une expression d’exclusion dans ce champ, en plus des wildcards « SQL », à l’aide de la syntaxe suivante :

[^AlerteAExclure]

clip_image006

Voici le résultat obtenu :

clip_image008

Il est également possible de combiner plusieures exclusions à l’aide du symbole « pipe » :

[^(AlerteAExclure)|(TestAlert2)]

Attention toutefois, cette astuce exclut en réalité un groupe de caractères et ne supporte donc pas l’utilisation d’espaces.

SCOM - Création et peuplement dynamique de groupes à partir d’une clé de registre

 

Note : cet article est inspiré et enrichi de la solution proposée par Jan Van Meirvenne sur son blog.

Une pratique assez courante en entreprise consiste à publier des informations sur les serveurs (rôle, site géographique…) dans des clés de registre « fiches d’identité » créées à cette fin.

Il est alors pertinent de créer des groupes SCOM correspondant à ces clés, afin de pouvoir créer des overrides, de cibler des rôles… en fonction de l’organisation logique déjà en place.

La solution la plus évidente, supportée nativement et réalisable aisément via la console SCOM consiste à étendre la classe Windows Computer à l’aide d’attributs personnalisés, peuplés à partir des clés de registre ; puis à créer des groupes contenant des instances de cette nouvelle classe étendue en filtrant en fonction du contenu de l’attribut étendu.

Cette solution reste cependant fastidieuse : dans le cas d’un grand nombre d’informations différentes (nombreux sites géographiques ou rôles serveur), créer puis maintenir à jour des dizaines de groupes s’avère complexe et peu fiable.

C’est pourquoi il est très intéressant de créer et peupler ces groupes automatiquement.

Commençons par revenir sur ce qu’est un groupe « normal » dans le modèle SCOM : contrairement à la plupart des objets qui sont des instances de classe créées automatiquement par des règles de découverte et hébergées au niveau de l’agent exécuté sur le serveur où se trouve l’objet (par ex une instance de la classe serveur windows, site IIS etc. ), les groupes sont créés de manière unique lorsque vous utilisez l’assistant correspondant et sont hébergés par les Management Servers : ils ne sont pas découverts, ils « commencent à exister » une fois l’assistant terminé.

Ce fonctionnement est propre aux classes qui possèdent l’attribut « singleton », ce qui en fait des classes qui sont également des objets.

Revenons maintenant à notre problème : nous souhaitons créer des groupes basés sur une règle de découverte classique, avec de multiples instances découvertes : il s’agit donc simplement de créer une classe qui dérive de la classe Microsoft.SystemCenter.InstanceGroup (comme tous les groupes), mais qui n’aurait cette fois pas l’attribut singleton.

Il est également nécessaire d’ajouter une propriété clé (key property) à notre classe : cela permet de ne créer qu’une seule instance de la classe même si la propriété est découverte à l’identique sur plusieurs agents ; autrement dit dans notre cas de ne créer qu’un seul groupe correspondant à un attribut géographique même si cet attribut géographique est retrouvé sur de multiples serveurs.

<ClassType ID="TEST.DynamicGroups.Group" Accessibility="Public" Abstract="false" Base="GroupLib!Microsoft.SystemCenter.InstanceGroup" Hosted="false" Singleton="false" Extension="false">

<Property ID="Territory" Type="string" AutoIncrement="false" Key="true" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" />

</ClassType>

Maintenant que la classe est définie, nous allons pouvoir nous pencher sur la découverte qui découvrira ses instances. Et tant qu’à faire, nous en profiterons pour découvrir également les objets Windows.Computer qui peupleront ces groupes ainsi que la relation qui liera les groupes aux ordinateurs.

La découverte se fera à l’aide d’un script VBS, la seule possibilité pour découvrir à la fois le groupe, l’ordinateur et la relation : évitez donc de définir un intervalle d’exécution trop court pour ne pas surcharger vos agents!

Notez que pour que cette découverte fonctionne, il sera nécessaire d’activer le mode proxy pour tous les serveurs qui seront concernés.

Pensez à modifier la partie en jaune, elle concerne la clé de registre à interroger pour récupérer la valeur qui déterminera le nom du groupe.

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

<Category>Discovery</Category>

<DiscoveryTypes>

<DiscoveryClass TypeID="TEST.DynamicGroups.Group" />

</DiscoveryTypes>

<DataSource ID="GroupDiscoveryDS" TypeID="Windows!Microsoft.Windows.TimedScript.DiscoveryProvider">

<IntervalSeconds>86400</IntervalSeconds>

<SyncTime />

<ScriptName>discoverdynamicgroups.vbs</ScriptName>

<Arguments>$MPElement$ $Target/Id$ $Target/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Arguments>

<ScriptBody>

SetLocale("en-us")

Dim oAPI
Set oAPI = CreateObject("MOM.ScriptAPI")

Dim oArgs
Set oArgs = WScript.Arguments

if oArgs.Count &lt; 3 Then

Call oAPI.LogScriptEvent("dynamicgroupdiscovery.vbs",101,1,"Script was called with fewer than three arguments and was not executed.")

Wscript.Quit -1

End If

Dim SourceID, ManagedEntityId, TargetComputer

SourceId = oArgs(0)

ManagedEntityId = oArgs(1)

TargetComputer = oArgs(2)

Dim oDiscoveryData, oInstManagedServer,oInstServerGroup,Territory,arrSubKeys

'Lecture de la clef d’identification dans la base de registre

Const HKEY_LOCAL_MACHINE = &amp;H80000002

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\localhost\root\default:StdRegProv")

oReg.GetStringValue HKEY_LOCAL_MACHINE,"SOFTWARE\TEST\ID_CARD","Territory",Territory

'Construction du nom du groupe et attribution d’une valeur par defaut si clef vide

If IsNull (Territory) Then Territory = "NA"

GroupName = "TEST - TERRITORY - " &amp; Territory

'Ajout de l’instance de l’objet Computer au propertybag

Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceID, ManagedEntityID)

set oInstManagedServer = oDiscoveryData.CreateClassInstance("$MPElement[Name='Windows!Microsoft.Windows.Computer']$")

call oInstManagedServer.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)

call oDiscoveryData.AddInstance(oInstManagedServer)

'Ajout de l’instance de l’objet Group au propertybag

set oInstServerGroup = oDiscoveryData.CreateClassInstance("$MPElement[Name='TEST.DynamicGroups.Group']$")

call oInstServerGroup.AddProperty("$MPElement[Name='System!System.Entity']/DisplayName$", GroupName)

call oInstServerGroup.AddProperty("$MPElement[Name='TEST.DynamicGroups.Group']/Territory$", Territory)

if Err.Number &lt;&gt; 0 Then

Call oAPI.LogScriptEvent("dynamicgroupdiscovery.vbs",104,1, "Script Error : Can't create ServerGroup (" &amp; Err.Number &amp; ") " &amp; Err.Description)

WScript.Quit -1

End If

call oDiscoveryData.AddInstance(oInstServerGroup)

'Ajout de la relation entre l’objet Computer et l’objet Group

Dim oInstWindowsComputer

set oInstWindowsComputer = oDiscoveryData.CreateClassInstance("$MPElement[Name='Windows!Microsoft.Windows.Computer']$")

call oInstWindowsComputer.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", TargetComputer)

call oDiscoveryData.AddInstance(oInstWindowsComputer)

Set oRelationship = oDiscoveryData.CreateRelationshipInstance("$MPElement[Name='GroupLib!Microsoft.SystemCenter.InstanceGroupContainsEntities']$")

oRelationship.Source = oInstServerGroup

oRelationship.Target = oInstWindowsComputer

Call oDiscoveryData.AddInstance(oRelationship)

if Err.Number &lt;&gt; 0 Then

Call oAPI.LogScriptEvent("dynamicgroupdiscovery.vbs",104,1, "Script Error : Can't create ServerGroup to Computer relationship (" &amp; Err.Number &amp; ") " &amp; Err.Description)

WScript.Quit -1

End If

call oAPI.Return(oDiscoveryData)

</ScriptBody>

<TimeoutSeconds>600</TimeoutSeconds>

</DataSource>

</Discovery>

Le gros de la problématique est maintenant couvert, il ne vous reste plus qu’à intégrer cela à vos propres management packs !

Une dernière note : vu l’utilisation qui sera en général faite de ce MP (overrides, délégations, ciblage pour des vues spécifiques…), il peut s’avérer judicieux de le sceller afin d’être en mesure d’y faire référence depuis d’autres MP.

SCOM - L’import d’un MP échoue avec une erreur vide

Lorsque l’on développe ses propres Management Packs, il arrive fréquemment que l’importe échoue pour des raisons diverses (bout de code oublié, mal placé, mauvaise référence…).

Dans ces cas, l’assistant d’importation des MP retourne normalement une erreur plus ou moins explicite qui permet, après un peu de déchiffrage et avec l’habitude, de localiser assez efficacement la cause du problème.

J’ai par contre été confronté aujourd’hui à un cas inhabituel : après l’ajout manuel (en modifiant le code XML directement à l’aide d’un éditeur de texte) d’une règle à un MP pré-existant, l’assistant a refusé l’import avec une erreur “vide” (ou pour ainsi dire sans erreur ) :

image

 

Après quelques heures de questionnements existentiels, de relecture de mon code, de tests en recréant la règle dans un autre MP (là, ca fonctionnait!), j’ai fini par mettre le doigt sur le problème :

La règle que j’avais ajouté contenait un Consolidator (d’où la création manuelle et pas via la console de SCOM), qui était appelé via la ligne

<ConditionDetection ID=”CD” TypeID=”System!System.ConsolidatorCondition”>

Alors que dans mes déclarations de références, le MP System.Library était déclaré avec l’alias SystemLibrary7585010 et non pas System.

Visiblement, l’assistant d’import de MP n’a pas su me signaler cette simple erreur de référence dans ce contexte précis, alors qu’il en est normalement parfaitement capable…

Une erreur bête qui m’aura tout de même fait perdre plusieurs heures!

Orchestrator 2012 - Récupérer la sortie brute d’une activité Run .NET Script

Dans Orchestrator, l’activité Run .NET Script permet d’exécuter des scripts dans différents langages (Powershell, VB .NET, JScript…) ce qui se révèle très utiles dans les nombreux cas où les activités apportées par les différents Integration Pack se révèlent insuffisantes pour effectuer les tâches dont vous avez besoin.

Cependant, il peut vite devenir compliqué de débugger ces scripts puisque l’activité Run .NET Script ne publie pas le résultat brut de leur exécution dans le databus : impossible alors de savoir où le script a échoué!

En revanche, ce que cette activité peut publier à l’aide de sa fonctionnalité Published Data, c’est le contenu de n’importe quelle variable que contient le script exécuté.

Il ne reste donc plus qu’à utiliser ce fonctionnement afin de stocker le résultat d’exécution du script dans une variable et de la publier via les Published Data.

Prenons l’exemple de ce script Powershell, un simple compteur qui ne présente pas d’intérêt autre que de produire une sortie sur plusieurs lignes :

for ($i=0; $i -le 10; $i++) {write-host $i}

image

 

Il suffit de l’encapsuler comme suit pour récupérer cette sortie dans Orchestrator :

$result = Powershell { for ($i=0; $i -le 10; $i++) {write-host $i} }

image

Puis de publier la variable result dans les Published Data :

image

 

La sortie du script est donc désormais publiée dans le databus.

On peut ensuite la récupérer dans un fichier texte à l’aide de l’activité Append Line, dans un évènement avec Send Event Log Message etc. Attention car dans ce second cas, un évènement sera créé pour chaque ligne si le mode Run Behavior > Flatten n’est pas utilisé!

Prenons l’exemple du fichier texte :

image

On voit bien que l’activité Append Line est appelée une fois par ligne contenue dans la variable result car le flatten n’est pas activé :

image

Et le résultat final :

image

Evidemment, cette astuce sera beaucoup plus utile pour des scripts réels!

SCOM 2012 - Erreur lors de la découverte d’un serveur CentOS 7

A l’occasion du déploiement d’agents Linux à partir d’une infrastructure SCOM 2012 R2 UR4, un client a rencontré le problème suivant pour les serveurs exécutant la distribution CentOS 7 :

image

Failed during SSH discovery. Exit code: 2
Standard Output:
Standard Error: /etc/centos-release: line 1: syntax error near unexpected token `(‘
/etc/centos-release: line 1: `CentOS Linux release 7.0.1406 (Core) ‘
Exception Message:

Il reste possible de procéder à une installation manuelle de l’agent, mais cette solution est beaucoup moins pratique et plus longue.

Pour comprendre d’où provient cette erreur, il est nécessaire de comprendre au préalable que le processus de découverte d’un serveur Linux est réalisé par le script GetOSVersion.sh, disponible dans le dossier d’installation de SCOM : C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents

Lors de la découverte, ce script est copié et exécuté sur les serveurs à découvrir et tente principalement d’identifier la version de Linux exécutée par le serveur afin d’y déployer l’agent approprié.
Pour ce faire, il cherche à récupérer le contenu du fichier standardisé os-release qui contient des informations sur le système, à l’aide des lignes suivantes dans le cas d’un CentOS :

image

Le souci, c’est que la variable . $ReleaseFile pointe vers un fichier nommé centos-release qui contient, ô surprise, la ligne CentOS Linux release 7.0.1406 (Core) à la place des informations attendues au format TAG=VALUE.

Informations qui se trouvent par contre bien dans le fichier os-release… il ne reste alors qu’à corriger le script afin qu’il pointe vers le bon fichier, en remplaçant la ligne
. $ ReleaseFile
Par la ligne
. ${EtcPath}/os-release
Ce qui donne ce résultat :

image

 

Répétez cette opération sur tous les serveurs du Management Pool Linux et votre découverte ne devrait désormais plus poser de problème!

Attention! Cette modification n’est pas supportée par Microsoft et n’a pas été testée en profondeur, elle pourrait donc provoquer d’autres problèmes dans  des contextes différents! 
Par ailleurs, il y a de fortes chances que le fichier GetOSVersion.sh soit écrasé lors de l’installation de mises à jour futures. Il serait alors nécessaire de réappliquer la modification détaillée ici, si Microsoft n’apporte pas de correction.

Merci à Stéphane J. pour son implication sur cette problématique Linux assez spécifique!

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.