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 ) :

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!

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}

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} }

Puis de publier la variable result dans les Published Data :

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 :

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é :

Et le résultat final :

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

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 :

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 :

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 :

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!

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 :

Indiquez un nom explicite et une description :

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.

Cliquez sur Finish puis sur Close

Créons ensuite le Subscriber :

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

Laissez coché Always send notifications

Cliquez sur Add

Indiquez un nom (toujours le même…)

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

Laissez coché Always send notification

Cliquez sur Finish

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)

Cliquez sur Add

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

Cliquez sur Next

Cliquez sur Add

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

Cliquez sur OK

Cliquez sur Finish

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

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 :

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 :

- 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 :

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 :

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).

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.

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.

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:

Exemple 4 colonnes:

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:

Exemple 5 cellules:

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

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’ : 

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

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) :

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.

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é.

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

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

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

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.

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.

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

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 :

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.