PI Services

Le blog des collaborateurs de PI Services

SCOM - A read operation on a large objects failed while sending data to the client

Pour cet article, nous allons nous intéresser à un cas peu commun.

Une erreur passée inaperçue pendant plusieurs mois car visée par aucune règle ou moniteur se reproduisait très régulièrement, aléatoirement sur l’un ou l’autre des Management Servers :

clip_image002

Evénement 26319, An exception was thrown while processing GetObjectsFromReader for session ID uuid:2f0f5bab-011d-4002-98d1-4c500cc449a2;id=103303.
Exception message : A transport-level error has occurred when receiving results from the server. (provider TCP Provider, error 0 – The specified network name is no longer available).

La partie “provider TCP Provider, error 0 – The specified network name is no longer available” fait immanquablement penser à une erreur SQL, et le fait que la source de l’événement soit OpsMgr SDK Service est un indice supplémentaire en ce sens.

Une verification dans le journal d’événements Applications du serveur SQL de la base OperationsManager montre qu’effectivement, un événement 7886 est présent pour chaque événement 26319 sur les Management Servers :

clip_image004

A read operation on a large objects failed while sending data to the client. A common cause for this is if the application is running in READ UNCOMMITTED isolation level. This connection will be terminated.

« Une cause courante pour cette erreur est si le niveau d’isolation est READ UNCOMMITED »… Vérifions donc cela dans la base OperationsManager, à l’aide de la commande DBCC USEROPTIONS :

clip_image006

Manifestement, ce n’est pas le cas, elle est bien en committed…

Je me tourne donc vers mon moteur de recherche préféré, qui une fois n’est pas coutume ne m’aide qu’assez peu. Un lien retient cependant mon attention : https://scomblog.wordpress.com/2012/02/29/469/.

La plupart des informations abordées dans cet article n’ont rien à voir avec le cas qui nous intéresse aujourd’hui, mais le dernier point est des plus intéressant (malgré sa syntaxe assez douloureuse) : il nous apprend que cette erreur peut se produire lorsque une lecture d’une alerte dans la base de données survient au même moment que la mise à jour de cette même alerte (cas d’une alerte dont le RepeatCount s’incrémente), ce qui provoque un conflit.
Le cas de figure le plus évident serait donc celui d’une console SCOM ouverte sur une alerte qui s’incrémente très régulièrement lorsqu’un rafraîchissement de la console survient au moment de la mise à jour de l’alerte en base. En plus, cet environnement a effectivement quelques alertes dont le RepeatCount est élevé (plusieurs dizaines de milliers).

Sauf qu’après une petite enquête auprès des utilisateurs, aucun ne semble avoir de problème récurrent avec la console (popup d’erreur, déconnexions…) qui devraient pourtant se produire lorsque l’incident survient.

Pour en avoir le cœur net, une trace SQL est prise avec l’aide du support Microsoft. Elle révèle que les requêtes qui provoquent le problème sont toutes semblables à ceci :

clip_image008

Cette requête récupère les détails d’une alerte (source, description etc) ; elle est donc parfaitement légitime et il est normal d’en rencontrer un grand nombre. Elle cadre d’ailleurs avec l’explication préalablement analysée.
Un détail attire cependant mon attention : ici, la requête est effectuée pour TOUTES les alertes présentes dans l’environnement, puisque la variable @Id0, supposée contenir l’ID de l’alerte à récupérer, contient ici le caractère %, autrement dit le « joker » du langage SQL !
Il s’agit donc d’une requête particulièrement lourde, et qui n’a pas réellement de raison d’être effectuée par une utilisation normale de la console.

Peut-être est-il alors possible de retrouver par quel compte utilisateur cette requête est déclenchée ? Cela nous aiderait à comprendre comment elle survient…

Revenons donc à notre événement sur le Management Server SCOM. Ce n’est pas très lisible, mais il nous indique quelle session a rencontré le problème via l’information id=. Il s’agit donc ici de la session 103303.

clip_image010

En descendant un peu dans le journal d’événement, il doit normalement exister un événement 26328 qui correspond à la création de cette session et qui contient le compte l’ayant créé :

clip_image012

Voilà qui est intéressant ! Dans cet environnement, tous les utilisateurs se connectent avec leur compte nominal personnel. Le compte « SCOM2012_admin » n’est utilisé que pour l’exécution de scripts qui font appel à SCOM.

Il n’y a ici pas de moyen technique permettant de savoir quel est ce script ni à partir d’où il est exécuté, mais une bonne connaissance de l’environnement m’a permis d’avoir des soupçons sur un script en particulier qui s’exécutait très régulièrement et effectuait des traitements sur les alertes.

Une analyse du script a révélé qu’il exécutait le cmdlet Get-SCOMAlert | Where {blabla}, c’est-à-dire qu’il récupérait l’intégralité des alertes avec toutes leurs propriétés puis les filtrait à l’aide de la clause Where ; ce qui correspond parfaitement à ce qu’indiquait la trace SQL : nous tenons manifestement notre coupable !

Et la correction est en plus assez simple : il suffit de réaliser le filtrage dans la requête, ce qui a pour conséquence de l’alléger considérablement, en modifiant le cmdlet de la sorte : Get-SCOMAlert –Criteria {blablabla}.

Suite à cette modification, l’événement ne s’est plus reproduit et, pour ne rien gâcher, le serveur qui exécutait le script a vu son occupation CPU et RAM diminuer fortement :)

SCOM 2016 – Active Directory et contrôleurs de domaine

Pour commencer, une bonne nouvelle : le Management Pack Active Directory, connu des amateurs pour sa complexité et son manque de fiabilité, vient d’être en grande partie réécrit !

La nouvelle version ne nécessite plus OOMADS, la supervision de la réplication AD est entièrement nouvelle et simplifiée…

Attention ce nouveau MP ne met pas à jour l’ancien qui pourra donc être désinstallé avant de déployer le nouveau, ou conservé en parallèle. Par ailleurs, il n’est compatible qu’avec les contrôleurs de domaine sous Windows 2012 (R2) et 2016, quel que soit le niveau fonctionnel de votre AD.

Venons-en maintenant au problème qui nous intéresse : SCOM 2016 est sorti il y a quelques semaines, et avec lui son (petit) lot de nouveautés sur lesquels nous reviendrons probablement dans de prochains articles.

Une de ces nouveautés concerne le déploiement d’un agent sur un contrôleur de domaine : sans intervention de votre part, l’agent passera presque immédiatement en grisé et une alerte System Center Management Health Service Unloaded System Rule(s) est générée.

clip_image001

Une vérification sur le contrôleur de domaine concerné montre effectivement un très grand nombre d’événements 1102 dans le journal OperationsManager :

clip_image003

Mais il faut remonter plus loin, juste après le déploiement de l’agent, pour trouver l’événement qui nous intéresse :

clip_image005

Cet événement 7017 indique The health service blocked access to the windows credential NT AUTHORITY\SYSTEM because it is not authorized on management group <MG>. You can run the HSLockdown tool to change which credentials are authorized.

Ce message d’erreur rappelle une vieille KB Microsoft : https://support.microsoft.com/en-us/kb/946428

Et effectivement, il suffit d’exécuter l’outil HSLockdown (il se trouve dans le dossier d’installation de l’agent SCOM) pour, dans un premier temps, vérifier que le compte LocalSystem est bien bloqué :

clip_image007

Puis, dans un second temps, l’autoriser :

clip_image008

Ne reste plus qu’à redémarrer l’agent (HealthService), et tout rentre dans l’ordre.

Quant à savoir pourquoi ce comportement a changé depuis SCOM 2012, avec lequel LocalSystem n’était pas bloqué sur les DC… mystère !

SCOM 2012 - Des bugs dans le MP DHCP 2012

Malgré des mises à jour relativement suivies, le Management Pack DHCP conserve des erreurs y compris dans sa version la plus récente à ce jour (6.0.7301.0).

Deux problèmes en particulier me semblent particulièrement récurrents :

- Une alerte “Power Shell Script failed to run” caracterisée par sa description : “System.Management.Automation.RuntimeException: Method invocation failed because [System.String[]] doesn't contain a method named 'Item'.
At line:65 char:20
+ $OS = $CurrVer.Item <<<< (0) + "." + $CurrVer.Item(1) »

- Une absence de retour en Healthy du moniteur DHCP IPv4 Runtime Active Directory Availability Monitor.

Attardons nous donc sur ces deux problèmes.

Dans le premier cas, le message d’erreur nous indique qu’il s’agit de l’échec de l’exécution de la découverte Microsoft.Windows.DHCPServer.2012.R2.ClusterServer.Discovery. Cette dernière permet, comme son nom l’indique, de découvrir les clusters DHCP 2012 R2 et elle utilise pour ce faire le script powershell DiscoverDHCPClusterServer2012R2.

Cette découverte est ciblée sur la classe Virtual Server, c’est-à-dire tous les clusters Windows (et pas uniquement ceux sous Windows 2012), mais le script de découverte vérifie bien la version de Windows dont il s’agit en début d’exécution à l’aide du code suivant :

$CurrOS = Get-WmiObject -Namespace "root\cimv2" -Query "select Version from Win32_OperatingSystem"
$OSVer = $CurrOS.Version
$CurrVer = $OSVer.Split(".")
$OS = $CurrVer.Item(0) + "." + $CurrVer.Item(1)
if ($OS -ne $TargetOSVersion)
{
Write-Host "$SCRIPT_NAME - No Target Operating System"
$discoveryData
exit
}
else
{ exécution de la découverte }

On retrouve dans ce bloc de code la commande indiquée dans la description de l’erreur, $OS = $CurrVer.Item(0) + "." + $CurrVer.Item(1) .

La raison de cette erreur est assez simple : Powershell v2 ne supporte pas la méthode Item, comme l’indique clairement le message d’erreur « Method invocation failed because [System.String[]] doesn't contain a method named 'Item’ ». L’exécution du script échoue donc sur tous les serveurs Windows 2008 ou antérieurs pour lesquels powershell n’a pas été mis à jour !

La résolution est aussi plutôt évidente, il suffit d’utiliser la syntaxe suivante (compatible avec toutes les versions de powershell) à la place :

$OS = $CurrVer[0] + "." + $CurrVer[1]

Passons maintenant au second problème.

Le moniteur est de type Event Reset, c’est-à-dire qu’il doit revenir en Healthy lorsqu’un événement indiquant un retour à la normal apparaît dans le journal d’événement ; par défaut l’événement 1048.

Il semble toutefois que cet événement soit incorrect, ou en tout cas qu’il ne soit pas le seul qui puisse être généré. Dans le cas de l’environnement où j’ai constaté le bug, cet événement n’est jamais généré mais par contre un événement 1044 qui semble valider le même retour à la normal est lui bien présent.

Il faut donc rajouter cet événement au moniteur.

Malheureusement, pour nos deux problèmes, il s’agit d’un management pack scellé. Il est donc impossible de modifier directement le script de la découverte ou la configuration du moniteur.

La solution consiste alors à créer un management pack correctif, qui implémentera donc les bonnes versions de ces workflows et désactivera les versions d’origines erronées.

Et pour ceux qui ne se sentent pas l’âme d’un développeur, un tel Management Pack réalisé par mes soins est disponible ici : Microsoft.Windows.DHCPServer.Fix.xml

Note : ce management pack a été testé dans un environnement spécifique, rien ne garantit qu’il fonctionnera ou qu’il ne posera aucun problème dans le vôtre. Prenez donc le temps de le valider avant de le déployer en production !

Azure Stack - TP2 v2, VPN et Windows 7

 

La sortie il y a quelques jours de la seconde version de la TP2 d’Azure Stack (dite “refresh”) a enfin été pour moi l’occasion de tester ce produit qui s’annonce très prometteur (pour rappel, il s’agit de la possibilité de déployer Azure dans votre Datacenter).

Je ne reviendrais pas ici sur le détail de son déploiement, il existe déjà de nombreux articles à ce sujet.

Notez simplement que cette seconde édition de la TP2 apporte le support du PaaS (par exemple pour déployer des bases SQL) ainsi qu’un script de déploiement amélioré : j’ai pu réaliser l’installation du début à la fin sans erreur, alors qu’une précédente tentative avec la TP2 d’origine s’était avérée nettement plus réticente. Cette nouvelle version nécessite une réinstallation complète du POC (il n’est pas possible de mettre à jour depuis la TP2 d’origine) et est disponible ici : https://azure.microsoft.com/en-us/blog/new-azure-paas-services-available-for-azure-stack-technical-preview-2-tp2/

Attention cependant, une étape manuelle reste nécessaire à la fin du déploiement si vous avez utilisé une IP statique, autrement votre infrastructure deviendra inutilisable au bout de 10 jours : https://social.msdn.microsoft.com/Forums/azure/en-US/home?forum=AzureStack&announcementId=f35560ea-b0d2-4be0-b407-e20fe631d9fe

Une fois déployée, vous avez deux possibilités pour accéder au portail web Azure Stack :

- Vous connecter à la VM console (mas-con01) via la console Hyper-V ou en Bureau à distance depuis votre serveur hôte puis ouvrir le raccourci « Microsoft Azure Stack Portal » qui se trouve sur le bureau

- Créer une connexion VPN vers votre infrastructure Azure Stack afin d’y accéder directement depuis votre poste client.

Cette seconde possibilité est évidemment la plus pratique, mais je me suis heurté à un problème : la procédure proposée sur Technet ( https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-connect-azure-stack chapitre « connect with VPN ») ne fonctionne pas sous Windows 7, même en ayant installé Powershell 5, en raison de l’absence des cmdlet powershell dédiés au VPN.
Comme je ne disposais que d’un poste sous Windows 7 dans l’environnement où a été réalisé ce déploiement de test, j’ai eu recours à une solution de contournement :

Dans le centre réseau et partage, cliquez sur Configurer une nouvelle connexion ou un nouveau réseau :

clip_image002

Sélectionnez Connexion à votre espace de travail :

clip_image004

Sélectionnez Utiliser ma connexion Internet (VPN) :

clip_image006

Indiquez l’adresse IP de votre réseau de la VM MAS-BGPNAT01. Il s’agit de l’IP indiquée dans le paramètre -NatIPv4Address si vous avez réalisé un déploiement avec une adresse statique. Indiquez également un nom explicite, AzureStack par exemple, et cochez la case Ne pas me connecter maintenant (il faudra faire des modifications à la configuration par défaut avant qu’elle puisse fonctionner).

clip_image008

Indiquez les détails du compte azurestack\azurestackadmin puis cliquez sur créer :

clip_image010

Rouvrez maintenant les propriétés de cette connexion VPN :

clip_image012

Dans l’onglet Gestion de réseau, sélectionnez Propriétés internet version 4, cliquez sur Propriétés. Cliquez sur Avancé dans la fenêtre qui s’ouvre, puis décochez Utiliser la passerelle par défaut :

clip_image014

A l’aide de la commande route print, récupérez le numéro de l’interface réseau AzureStack :

clip_image016

Ajoutez les deux routes statiques suivantes (où « XX » est le numéro récupéré juste avant) :

route add 192.168.105.0 mask 255.255.255.224 192.168.200.225 IF XX -p

route add 192.168.102.0 mask 255.255.255.224 192.168.200.225 IF XX -p

Enfin, si votre navigateur (Internet Explorer vivement recommandé, le portail fonctionne assez mal avec Firefox et Chrome ! ) passe par un proxy pour accéder à internet, pensez à en exclure toutes les url du domaine azurestack.local et de ses sous-domaines (*.azurestack.local ), autrement vous ne pourrez pas charger (ou pas complètement) le portail !

clip_image018

 

Voilà, vous pouvez maintenant vous connecter au VPN, puis ouvrir votre navigateur à l’adresse http://portal.azurestack.local et commencer à découvrir Azure Stack!

SCOM - La console plante depuis les patchs de sécurité d’Octobre

Quoi de plus frustrant pour reprendre le travail que de se retrouver face à son outil préféré devenu soudain inutilisable?

Si depuis quelques jours, votre console SCOM fait des siennes et plante à chaque fois que vous tentez d’accéder à une vue de type “état” (telle que Windows Computers par exemple), avec l’erreur suivante :

image

Et qu’en même temps, vous retrouvez un message d’erreur similaire au suivant dans votre journal d’évènements Application :

Faulting application name: Microsoft.EnterpriseManagement.Monitoring.Console.exe, version: 7.1.10226.1177, time stamp: 0x5697e092 Faulting module name: ntdll.dll, version: 6.3.9600.18438, time stamp: 0x57ae642e Exception code: 0xc0000374 Fault offset: 0x00000000000f1b70 Faulting process id: 0xfac Faulting application start time: 0x01d2254a42863351 Faulting application path: <C:\Program Files\Microsoft System Center 2012 R2 \Operations Manager\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

Le coupable est tout trouvé, il s’agit des patchs de sécurité Windows du mois d’Octobre, en particulier MS16-118 et MS16-126 (concernant Internet explorer notamment), comme le confirme la KB suivante : https://support.microsoft.com/en-us/kb/3200006

Il ne vous reste plus qu’à appliquer sur les machines hébergeant vos consoles SCOM (serveurs SCOM, postes d’administration, serveurs Citrix…) le hotfix proposé.

Attention, ce hotfix n’est pas spécifique à SCOM et sa dénomination dans le catalogue Microsoft peut donc être trompeuse : il s’agit par exemple de “Mise à jour pour Internet Explorer 11 pour Windows Server 2012 R2 (KB3200006) “ dans le cas du hotfix pour Win 2012 R2.

L’installation de ce hotfix ne nécessite normalement pas de redémarrage, mais si le problème persiste après l’installation cela aidera à le résoudre définitivement.

SCOM – Les Management Packs HP

Si vous disposez de matériel Hewlette Packard/HPE (Proliant, BladeSystem) dans votre parc, vous avez probablement déployé le Management Pack qui va avec… ou peut-être avez-vous abandonné au vu de la difficulté pour trouver les bonnes versions, les bons liens, la bonne documentation etc.

Voici donc un résumé qui devrait vous simplifier la tâche !

Télécharger les Management Packs

Première étape de votre quête : télécharger les management packs ! Entre les liens corrompus, les fichiers sans rapport, les différentes versions… difficile de s’y retrouver.

Ne cherchez plus, les fichiers contenant les derniers management packs se trouvent ici : https://h20392.www2.hpe.com/portal/swdepot/displayProductInfo.do?productNumber=Z7500-63235

Une fois enregistré et connecté, téléchargez le fichier HP OneView for Microsoft System Center 8.0 ZIP - October 2015. Il contient beaucoup de choses inutiles pour ce qui nous intéresse, mais aussi et surtout le fichier hpscomkit-x64-3.2.1.exe avec tous les management packs et les consoles nécessaires (à exécuter en tant qu’administrateur pour éviter toute mauvaise surprise !)

clip_image002

Tableau de synthèse

Commençons par un tableau synthétique de ce qui est supporté à travers quel management pack, nous détaillerons par la suite les différentes possibilités :

clip_image003

Supervision Agentless

La supervision sans agent du matériel HP est distincte de la supervision sans agent au sens SCOM du terme : il s’agit ici de déployer le service Device Management Service (DMS) et sa console Device Management Console (DMC), puis d’y renseigner tous les matériels HP que vous souhaitez superviser sans agent.

Cette console DMC permet d’ajouter trois types de matériel :

- Le mode BladeSystem pour les chassis, via leur Onboard Administrator (v4.01 et supérieures)

- Le mode Linux (RHEL5-6-7, SLES10-11-12)/ESX 4.x (mais pas ESX 5.x et supérieurs !)

- Le mode Agentless Server, par défaut en quelque sorte, qui supporte tous les serveurs Gen8 et supérieurs via leur iLO quel que soit le système d’exploitation (Windows, Linux, ESX…).

clip_image005

Notez également qu’il est vivement recommandé d’installer le DMS sur un serveur qui n’est pas un serveur SCOM, ou au moins un serveur SCOM n’effectuant pas de supervision réseau car le service peut utiliser SNMP pour communiquer avec les différents matériels !

Il faut toutefois que le serveur qui héberge DMS dispose d’un agent SCOM.

clip_image006

Agentless Management Service

L’AMS est un module complémentaire qui permet d’obtenir plus d’informations en cas de supervision Agentless.

Son installation est détaillée dans le document suivant (pages 113 et suivantes) : http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c03334051

clip_image008

Cas particulier

Supervision ESX4 via le mode Linux/ESX, supervision tous OS à partir des Gen8 pour le mode Agentless Server… Mais alors, qu’en est-il des serveurs Gen6 ou 7 sous ESX5.x, que l’on retrouve parfois ?

Eh bien, ils ne sont tout simplement pas supportés, comme le confirme Stephan Roth qui a posé la question à HP Suisse : https://stefanroth.net/2012/11/04/scom-2012-hp-hardware-monitoring-on-vmware-esxi-servers/

Supervision de serveurs sous Windows :

La solution la plus simple pour superviser les serveurs (toutes générations) sous Windows est de d’abord déployer l’agent HP Insight, puis d’utiliser les MP Proliant SNMP et WBEM : la découverte se fera alors automatiquement, à la façon « SCOM » habituelle en quelque sorte.

Il n’est donc plus nécessaire dans ce cas d’ajouter chaque serveur dans la console DMC, ce qui simplifie grandement la gestion. De plus, ce mode permet de superviser toutes les générations de serveurs HP et pas uniquement les Gen8 et supérieurs.

Il s’agit donc clairement de la solution à préférer pour les serveurs Windows !

Pour aller plus loin

Les documents à jour concernant la supervision du matériel HP sont eux aussi assez compliqués à trouver.

En voici deux qui vous permettront de mieux cerner la problématique :

Managing Mixed Environnements with HPE SCOM MP : http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5390822&docId=emr_na-c04347838&docLocale=en_US

HPE SCOM Integration kit : http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5390822&docId=emr_na-c04605146&docLocale=en_US

SCOM 2012 – Lister toutes les alertes provenant des serveurs d’un groupe

Selon le mode de fonctionnement de votre service informatique, il est possible que vous n’ayez pas une équipe de supervision dédiée mais plutôt que cette tâche incombe à chaque équipe pour son périmètre de serveurs donné.

Si en plus vous utilisez un Resolution State différent pour attribuer les alertes à chaque équipe, l’idée peut vite vous venir de scripter cette tâche !

A priori, rien de bien compliqué.

Commençons par récupérer le groupe :

$group = Get-SCOMGroup –Displayname “Nom du groupe”

Puis les instances présentes dans ce groupe. Cette fois-ci, pas de cmdlet natif, il faut utiliser la méthode GetRelatedMonitoringObjects du groupe :

$groupinstances = $group.GetRelatedMonitoringObjects('Recursive')

Et enfin les alertes non attribuées (Resolution State 0) provenant de ces instances :

$alerts = Get-SCOMAlert -instance $groupinstances -ResolutionState 0

Hélas, si le groupe visé est un minimum conséquent, on obtient l’erreur suivante :

The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Too many parameters were provided in this RPC request. The maximum is 2100.

Cette erreur provient directement de SQL et n’est pas propre à SCOM (cf. https://blogs.msdn.microsoft.com/emeadaxsupport/2009/09/01/how-to-fix-sql-error-too-many-parameters-were-provided-in-this-rpc-request/ )

De plus, le cmdlet Get-SCOMAlert est très lent à exécuter et il n’est donc pas envisageable de l’utiliser dans un script qui aurait vocation à s’exécuter régulièrement.

Heureusement, une autre méthode de $group existe :

$alerts = $group.GetMonitoringAlerts([Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive)

De cette façon, on n’a même plus besoin de récupérer les instances du groupe, on prend les alertes directement… et cette méthode est particulièrement véloce !

Attention toutefois, elle récupère toutes les alertes, y compris les alertes déjà attribuées ou déjà fermées. Il est donc nécessaire de les filtrer dans la dernière étape, celle de l’affectation de l’alerte à la bonne équipe à l’aide d’un ResolutionState :

$alerts | where resolutionstate -eq 0 | Set-SCOMAlert -ResolutionState xxx

On résume ? La solution n’était pas si évidente, mais au final 3 lignes suffisent :

$group = Get-SCOMGroup –Displayname “Nom du groupe”

$alerts = $group.GetMonitoringAlerts([Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive)

$alerts | where resolutionstate -eq 0 | Set-SCOMAlert -ResolutionState xxx

A vous maintenant de les intégrer à vos scripts en fonction de vos besoins !

SCOM 2012 : créer un grand nombre de règles en quelques minutes

Lors de la création d’un nouveau Management Pack pour une application métier, il arrive qu’un grand nombre de règles ou de moniteurs similaires (alerte sur événement windows, collecte de compteur de performance…) doivent être ajoutées.

Il est bien sûr toujours possible de les créer les une après les autres à l’aide de la console SCOM, de l’outil MP Author ou d’un notepad, mais cela peut rapidement devenir très répétitif et inutilement consommateur en temps.

En effet, à l’aide de Visual Studio (qui est disponible en « community edition » gratuite depuis maintenant quelques années, plus d’excuses !) et des Authoring Extensions, il est possible d’automatiser en grande partie ce processus !

Commençez par créer un nouveau projet de type Management Pack 2007 R2 (nul besoin de sélectionner 2012 car nous ne ferons rien qui le justifie ici, et cela permet de conserver la rétrocompatibilité du MP) :

clip_image002

Dans l’explorateur de solutions, faites un clic-droit sur le nom de votre projet et sélectionnez ajouter > nouvel élément.

clip_image004

Sélectionnez Snippet Template, nommez-le et cliquez sur ajouter :

clip_image006

Un bloc de code pré-rempli apparaît (il s’agit du template par défaut, un règle de collecte de compteur de performance; mais rien ne vous empêche d’y substituer votre propre code comme nous le verrons plus loin) :

clip_image008

On remarque immédiatement que les balises les plus couramment modifiées lors de la création d’un MP (ID de la règle, cible, nom du compteur, fréquence de collection…) apparaissent surlignées en jaune, et que leur valeur est quelque peu inhabituelle : il s’agit en fait de variables, qui seront remplacées à la volée lors de l’étape suivante.

Ces variables sont de trois types : #text (une simple chaine de caractères), #choice (une liste déroulante) et #alias (elles permettent de résoudre automatiquement l’alias vers vos MP référencés).

Voyons donc maintenant comment alimenter ces variables.

Retournez dans ajouter > nouvel élément, mais sélectionnez cette fois Snippet Data :

clip_image010

Pour l’instant, cela ne crée rien de bien utile :

clip_image012

Cliquez sur Select snippet type et sélectionnez le Snippet Template préalablement créé :

clip_image014

Cette fois-ci, différentes colonnes sont présentes (elles correspondent aux différentes variables présentes dans le template), et deux possibilités nous sont offertes : ajouter des données manuellement (click here to add a new item) ou les importer depuis un fichier CSV (bouton Import from CSV file) :

clip_image016

Commençons par la première possibilité. En cliquant sur click here to add a new item, une ligne vierge apparait. A vous de renseigner les différents champs :

clip_image018

Imaginons maintenant que nous ayons des dizaines de compteurs à collecter via des règles différentes : les ajouter à la main l’un après l’autre de cette facon reste beaucoup plus pratique (et plus propre !) que de créer les règles les unes après les autres dans la console SCOM, mais on peut faire encore plus rapide à l’aide d’un fichier CSV :

clip_image020

Cliquez sur Import from CSV file et sélectionnez votre fichier CSV. Les valeurs qu’il contient sont automatiquement ajoutées à votre Snippet :

clip_image022

Une fois que vous avez entré les valeurs pour toutes les règles que vous souhaitez créer, cliquez sur enregistrer clip_image024 .

Ici, une erreur se produit car le MP System.Performance.Library est référencé dans le Snippet Template, mais pas dans le projet :

clip_image026

Il faut donc l’ajouter : clic-droit sur References > ajouter dans l’explorateur de solutions et sélectionnez le fichier .mp manquant. Vous pouvez le retrouver sur votre serveur SCOM, ou directement dans le dossier d’installation des VSAE pour les MP les plus communs (C:\Program Files (x86)\System Center Visual Studio Authoring Extensions\References\OM2007R2\Microsoft.Windows.Library.mp )

clip_image027

Répétez l’opération pour chaque MP référencé manquant, puis cliquez à nouveau sur Sauvegarder.

Un nouveau fichier doit apparaître dans l’arborescence de votre explorateur de solutions :

clip_image029

Ouvrez le : il contient le code correspondant à toutes vos règles, généré automatiquement en fonction de vos paramètres d’entrée :

clip_image031

Libre à vous maintenant de laisser libre cours à votre imagination pour créer vos propres Snippet Template correspondant à des moniteurs d’évènements, des scripts vbs etc…

Pour cela, rien de plus simple : recopiez vos bouts de codes en reprenant la nomenclature vue ci-dessus pour les variables, créez un nouveau Snippet de Data et alimentez-le à l’aide d’un fichier csv ou manuellement, comme nous venons de le voir.

clip_image033 Attention : si lors de vos développements, vous utilisez des colonnes contenant « true » ou « false » (par exemple si vous souhaitez définir si une règle ou un moniteur sera activé ou non par défaut), il faut obligatoirement que ces valeurs soient écrites en minuscules ; vous rencontrerez une erreur lors de la sauvegarde dans le cas contraire.

Une fois ces fragments de code obtenus, vous pouvez soit continuer votre développement dans Visual Studio et générer votre MP lorsqu’il est terminé, soit les intégrer par copier/coller dans le code XML d’un MP existant que vous souhaitiez enrichir.

Un grand merci au maitre SCOM Kevin Holman pour l’idée originale de cet article ainsi que pour l’ensemble de son œuvre :)

Powershell/Azure/Orchestrator : Formatage des volumes additionnels

 

Lors de la création d’une machine virtuelle, on ne se contente en général pas d’un seul « disque dur » (vhd/vmdk). Il est d’usage de conserver le volume principal pour le système, et d’ajouter un ou plusieurs volumes pour les données, les sauvegardes…

Lors de la création de la VM, ces volumes y sont bien rattachés mais ils sont dans un état « brut » : non initialisés, ni partitionnés, ni formatés, ni nommés, et ne disposant pas de lettre de lecteur.

Et si ces opérations peuvent s’avérer fastidieuses lorsqu’il s’agit d’un déploiement manuel, elles deviennent inacceptables lorsqu’il s’agit de VM déployées automatiquement via un portail self-service déclenchant un processus d’orchestration : la VM doit être livrée « prête à fonctionner » à l’utilisateur qui en a fait la demande.

Heureusement, le vénérable outil diskpart peut être scripté, automatisant ainsi le procédé.

Le script powershell que je vous propose ci-dessous doit être exécuté en tant qu’administrateur local, dès que la VM est démarrée. Il détecte tous les disques qui ne disposent d’aucune partition, les initialise, les partitionne (une seule partition primaire), les formate, les renomme DATAxxx et leur attribue la première lettre disponible.

$datadisks = get-wmiobject win32_diskdrive | where partitions -eq 0

$i = 1

foreach ($disk in $datadisks) {

$diskID = $disk.index

$diskname = "DATA" + $i

$dpscript = @"

SELECT DISK $diskID

ATTRIBUTES DISK CLEAR READONLY

CREATE PARTITION PRIMARY

FORMAT fs=ntfs quick label=$diskname

ASSIGN

"@

$i++

$dpscript | diskpart

}

Il ne reste plus qu’à intégrer ce script à votre processus de déploiement, qu’il s’agisse d’une tâche post-installation dans SCVMM ou d’un runbook Orchestrator :

clip_image002

Il s’agit ici d’un déploiement de VM dans Azure ne disposant que d’un compte administrateur local hors domaine. On commence par monter le disque D : de la VM (disque temporaire créé automatiquement) en tant que partage, puis on y crée le script proposé ci-dessus, on l’exécute à l’aide de la commande powershell.exe -ExecutionPolicy ByPass "& ""D:\diskpart.ps1"""  et on termine en démontant le partage réseau.

L’exécution du script ne prend que quelques minutes même avec plusieurs volumes à formater, et il s’adapte automatiquement quel que soit leur nombre.

Powershell/Azure : utiliser un proxy dans un script

 

Certains scripts powershell peuvent nécessiter un accès au Web, comme par exemple ceux utilisés pour piloter un tenant Azure.

Or, la majorité des organisations utilisent aujourd’hui des proxy pour contrôler ces accès à Internet et il est préférable d’éviter autant que possible les exceptions à cette règle, y compris lorsque c’est un script qui a besoin de se connecter.

Certains cmdlet ont en plus une facheuse tendance à ignorer les paramètres de proxy de l’utilisateur qui les exécute (c’est le cas des cmdlet Azure Powershell tels que Login-AzureRmAccount), et il n’est pas toujours possible ou souhaitable de définir un proxy au niveau du système, via la commande netsh winhttp set proxy…

Heureusement, il est possible de spécifier ces paramètres directement au sein du script !

Dans un premier temps, il est nécessaire de spécifier l’adresse du Proxy :

$proxyAddress = "http://1.2.3.4:8080"

$proxyUri = new-object System.Uri($proxyAddress)

[System.Net.WebRequest]::DefaultWebProxy = new-object System.Net.WebProxy ($proxyUri, $true)

Si le proxy accepte les connexions anonymes, cela peut suffire.

Autrement, il sera nécessaire de spécifier des credentials autorisés à s’y connecter. Dans ce cas, deux possibilité :

- Soit vous ré-utilisez les credentials de l’utilisateur qui exécute le script :

[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

- Soit vous utilisez les credentials d’un autre compte  :

$proxyAccountName = "domain\user"

$proxyPassword = ConvertTo-SecureString "PASSWORD" -AsPlainText -Force

$proxyCred = New-Object System.Management.Automation.PSCredential($proxyAccountName, $proxyPassword)

[System.Net.WebRequest]::DefaultWebProxy.Credentials = $proxycred

En plaçant ces quelques lignes avant toute exécution de cmdlet nécessitant un accès au Web, vous ne devriez plus rencontrer de problème!