PI Services

Le blog des collaborateurs de PI Services

Orchestrator – Déployer des Integration Packs en DMZ

 

Dans le cadre d’un déploiement d’Orchestrator 2012 contenant des Runbook Servers dans un réseau isolé (DMZ) du reste de l’infrastructure, le déploiement des Integration Packs peut devenir problématique.

En effet, ces derniers sont normalement enregistrés dans le Management Server (Register IP) puis poussés vers les Runbook Servers et Runbook Designers (Deploy IP) à travers le réseau à l’aide de la console Deployment Manager, située sur le serveur hébergeant le rôle Management Server.

clip_image002

Lorsque les flux réseau sont bloqués, il n’est donc pas possible de pousser les Integration Packs vers leur destination

Deux solutions sont alors disponibles : installer les IP localement sur les serveurs en DMZ, ou ouvrir les flux nécessaires.

Installation locale

Prenons l’exemple de l’intégration pack pour Active Directory.

Il est dans un premier temps nécessaire de l’enregistrer (Register IP) tout à fait classiquement, je ne détaillerais donc pas cette étape ici :

clip_image004

Lors de ce processus, l’Integration Pack est copié sous forme de fichier MSI dans le dossier C:\Program Files (x86)\Common Files\Microsoft System Center 2012\Orchestrator\Management Server\Components\Objects :

clip_image006

Copiez ce fichier vers le Runbook Server ou le Runbook Designer de DMZ, puis exécutez-le.

L’installeur se déroule et se ferme sans aucune intervention de votre part, mais une fois terminé, l’Integration Pack doit être visible dans le Deployment Manager et ses activités doivent apparaitre dans le Runbook Designer (il est nécessaire de le relancer s’il était déjà ouvert) :

clip_image007

clip_image009

Ouverture des flux

Là aussi, il est tout d’abord nécessaire d’enregistrer l’Integration pack de façon classique (Register IP)

Lors du déploiement par la console Deployment Manager, les protocoles utilisés sont SMB et WMI, c’est-à-dire les habituels ports 135 et 445 en TCP, qu’il faudra donc ouvrir entre votre LAN et la DMZ où se trouvent vos Runbook Servers ou Runbook Designers.

Il est bien entendu également nécessaire d’ouvrir ces ports dans un éventuel firewall (Windows ou autre), ainsi que d’autoriser l’accès réseau à l’exécutable %SystemRoot%\SysWOW64\OrchestratorRemotingService.exe ; autrement le déploiement ne fonctionnera pas.

Le déploiement se fait ensuite via la console Deployment Manager de la même manière que si les serveurs cible étaient dans le LAN.

Complément

Attention toutefois, dans le cadre de l’utilisation d’un environnement Orchestrator disposant de serveurs Runbook à la fois dans le LAN et dans la DMZ : il devient alors primordial de bien déterminer quel Runbook devra tourner sur quel serveur, soit à l’aide des propriétés du Runbook à exécuter, soit via l’activité Invoke Runbook du runbook parent qui appelle le Runbook à exécuter (il est dans ce cas possible d’en indiquer plusieurs en les séparant par des point-virgules) :

clip_image011 clip_image013

Orchestrator - Changer les credentials des comptes de service

 

Il peut s’avérer nécessaire de changer les credentials des comptes de service utilisés par Orchestrator, lors d’incidents habituels dans le cycle de vie du produit (perte du mot de passe, politique de sécurité…).

Cependant, cela nécessite une reconfiguration à plusieurs niveaux :

Compte de service Orchestrator

Le premier niveau est le changement de credentials du compte utilisé pour exécutez les services Orchestrator (Management Service, Runbook Services…)

Dans un premier temps, il faut remplacer les mots de passe des services qui se trouvent sur chaque serveur hébergeant un rôle Orchestrator (Management, Runbook…).

Tout ou partie des services suivants peuvent être présents, en fonction des rôles attribués au serveur :

clip_image002

Pour modifier le compte utilisé par ces services, double-cliquez sur chacun d’eux et ouvrez l’onglet Log On :

clip_image004

Indiquez le nouveau login et/ou mot de passe puis cliquez sur OK.

Il est ensuite également nécessaire de modifier le compte utilisé par le pool d’application IIS :

Dans la console IIS Manager, ouvrez les Applications Pools et sélectionnez System Centez 2012 Orchestrator Web Features.

clip_image006

Faire un clic-droit et sélectionnez Advanced Settings.

clip_image008

Dans le champ Identity, cliquez sur l’icône « … »

clip_image010

Cliquez sur Set

clip_image012

Indiquez le nouveau login et/ou mot de passe du compte de service, puis cliquez sur OK dans chacune des fenêtres ouvertes.

Compte d’accès à la base SQL

Le second niveau concerne la modification des credentials du compte utilisé par Orchestrator pour se connecter à sa base SQL : il ne s’agit pas nécessairement du compte de service utilisé précédemment.

Lorsqu’il est modifié, la configuration d’Orchestrator doit être également modifiée sur l’ensemble des serveurs exécutant le rôle Runbook Server et/ou le rôle Web Service.

Runbook Server

Lancez la console Data Store Configuration :

clip_image014

Indiquez le nom du serveur SQL dans le champ Server et les credentials de connexion à l’instance SQL dans les champs Authentication Credentials., puis cliquez sur Next.

clip_image016

Cochez Use an existing data store et sélectionnez la base Orchestrator, puis cliquez sur Finish.

N’oubliez pas de répéter cette opération sur chacun des serveurs de Runbook.

Web Service

Le fichier de configuration du webservice est chiffré, il est donc nécessaire de le déchiffrer avant de le modifier.

Ouvrez un prompt de commande en mode administrateur et exécutez la commande

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pdf "connectionStrings" "D:\Program Files (x86)\Microsoft System Centez 2012 R2\Orchestrator\Web Service\Orchestrator2012"

clip_image018

Dans la console IIS Management, ouvrez l’arborescence Sites/Microsoft System Centez 2012 Orchestrator Web Service/Orchestrator2012.

Ouvrez la configuration des Connection Strings

clip_image020

Ouvrez Orchestrator Context et modifiez les informations de connexion à la base de données (serveur, instance, credentials…) en fonction du besoin.

clip_image022

Chiffrez à nouveau le fichier de configuration à l’aide de la commande C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef "connectionStrings" "D:\Program Files (x86)\Microsoft System Centez 2012 R2\Orchestrator\Web Service\Orchestrator2012"

clip_image024

Enfin, redémarrez IIS à l’aide de la commande iisreset.exe

Ca y est, nous avons désormais fait le tour de cette procédure, assez fastidieuse il est vrai… et malheureusement pas automatisable sous forme de runbook Clignement d'œil

Azure - récupérer l’accès à une VM quand la carte réseau a été désactivée

 

Si vous utilisez Azure pour déployer des VM, vous n’êtes pas sans savoir qu’il n’existe aucun moyen de se connecter à une console « directe » (en mode KVM/Ilo/Idrac).

Les seules possibilités d’accès sont celles basées sur un protocole réseau, par exemple Remote Desktop sous Windows.

Mais alors, que se passe-t-il si vous avez désactivé la carte réseau ? Il n’existe à première vue plus aucun moyen de prendre la main sur votre VM…

Un simple redémarrage ne suffit évidemment pas.

Mais une astuce simple permet de se sortir de ce mauvais pas :

Ouvrez l’ancien portail azure ( https://manage.windowsazure.com ) (au moment de la rédaction de ce billet, la manipulation ne fonctionne pas avec le nouveau).

Ouvrez les propriétés de votre VM et modifiez sa taille (size) en choisissant un autre Tier que celle où elle se trouve déjà (Standard vers Basic, par exemple) :

clip_image002

Le redimensionnement prend quelques secondes et est suivi d’un redémarrage de la VM :

clip_image004

clip_image006

clip_image008

Patientez encore quelques minutes, le temps que la VM termine de démarrer et qu’elle installe les pilotes de la « nouvelle » carte réseau, puis qu’elle monte les services réseau etc.

Vous devriez maintenant pouvoir vous connecter via le Bureau à distance à votre VM, avec son ancienne IP !

On peut également retrouver dans le journal d’événements une trace de l’installation de cette nouvelle carte réseau :

clip_image010

SCOM – Utiliser un Run As dans un script

Dans un précédent billet, je décrivais comment Ajouter un Run-As profile à un moniteur ou à une règle, afin de les faire s’exécuter avec des credentials autres que Local System.

Je vous propose ici un complément sur le même sujet, qui vous permettra d’utiliser en paramètre d’un script un couple login/mot de passe stocké dans un Run-As account, vous permettant ainsi de ne pas coder ces credentials en dur dans le script pour plus de sécurité et de maintenabilité.

Tout le début de cette procédure est exactement identique à celle proposée dans le précédent billet, vous pouvez donc vous y référer si vous ne disposez pas encore d’un couple run as profile/run as account contenant vos credentials.
Notez toutefois qu’il faut ici créer un un run as account de type Simple Authentication et non pas un compte Windows.

Une fois ceci fait et en possession de l’ID du Run As profile, nous pouvons revenir à notre moniteur ou règle de type script.

Dans les paramètres passés au script, il est alors possible de faire appel à ce profil à l’aide la syntaxe

$RunAs[Name="Test.Monitors.RunAsProfile"]/Username$ pour le login et

$RunAs[Name="Test.Monitors.RunAsProfile"]/Password$ pour le mot de passe.

Le login et le mot de passe (automatiquement déchiffré et donc passé en clair au script) seront alors passés au script lors de son exécution.

clip_image002

Il ne reste alors plus qu’à les déclarer et les assigner à une variable dans le script, puis à les utiliser par exemple ici pour se connecter à un serveur SQL :

Dim Username, Password, sConnectString
Username = WScript.Arguments(0)
Password = WScript.Arguments(1)
[…]
sConnectString = "Driver={SQL Server}; Server=SQL\TEST; Database=TESTDB;uid=" & Username & ";password=" & Password
[…]

On le voit, le mot de passe n’est jamais codé en clair dans le script et pour le modifier, il suffit de modifier le Profil et non pas le script.

SCOM - Moniteur de performance multi-instances

Lors de la création d’un moniteur de performance, il peut arriver qu’il soit nécessaire de superviser plusieurs instances du compteur et d’alerter lorsque n’importe laquelle de ces instances dépasse le seuil paramétré.

La solution qui vient alors immédiatement à l’esprit est alors d’utiliser les wildcard (jokers) dans le nom de l’instance :

clip_image002

Malheureusement, voici ce qui se produit dans ce cas :

clip_image004

clip_image006

Le moniteur détecte bien que l’instance w3wp dépasse le seuil paramétré et passe donc en Critical, mais instantanément après le moniteur détecte que l’instance w3wp#10 est elle toujours sous le seuil et il repasse donc en Healthy : la vérification se fait pour chaque instance du compteur l’une après l’autre, et si un seul d’entre eux n’est pas en critical, le moniteur repasse en vert immédiatement.

Et ce manège recommence à chaque exécution du moniteur…

Une première bonne solution consiste alors à utiliser une variable à la place d’un wildcard en tant qu’Instance.

Prenons l’exemple d’un moniteur de performance qui serait ciblé sur la classe Logical Disk.

Cette classe dispose de propriétés, dont plusieurs correspondent au nom des instances de compteurs :

clip_image007

On peut alors réutiliser une de ces variable dans le champ Instance de l’assistant de création du moniteur, à l’aide de la petite flèche située à sa droite :

clip_image008

On aura donc un moniteur pour chaque instance SCOM de la classe logical disk, ciblé uniquement sur l’instance du compteur de performance qui lui correspond.

Il arrive cependant qu’aucune classe SCOM ne dispose de propriétés utilisables en tant que variable,  typiquement en reprenant le premier exemple du process w3wp.exe.

Dans ce cas, une autre solution existe : le module de détection de condition (condition detection module) System.LogicalSet.ExpressionFilter introduit dans SCOM 2007 R2 permet de déterminer quand arrêter le traitement des données provenant d’une datasource lorsque celle-ci renvoie plusieurs résultats (ce qui est le cas quand un System.Performance.DataProvider est ciblé sur plusieurs instances d’un compteur perfmon).

Autrement dit, en utilisant ce module, les valeurs de chaque instance du compteur sont analysées l’une après l’autre. Dès qu’une de ces instances dépasse le seuil défini, le moniteur passe en Critical et s’arrête sans analyser les instances suivantes, empêchant donc le moniteur de repasser en Healthy.

L’utilisation de ce module n’est toutefois pas possible directement depuis la console SCOM et nécessite de créer son propre MonitorType :

<TypeDefinitions>

<MonitorTypes>

<UnitMonitorType ID="MultipleInstance.Perf.MonitorType" Accessibility="Public">

<MonitorTypeStates>

<MonitorTypeState ID="AboveThreshold" NoDetection="false" />

<MonitorTypeState ID="BelowThreshold" NoDetection="false" />

</MonitorTypeStates>

<Configuration>

<xsd:element name="ComputerName" type="xsd:string" />

<xsd:element name="CounterName" type="xsd:string" />

<xsd:element name="ObjectName" type="xsd:string" />

<xsd:element name="InstanceName" type="xsd:string" />

<xsd:element name="AllInstances" type="xsd:boolean" />

<xsd:element name="Frequency" type="xsd:unsignedInt" />

<xsd:element name="Threshold" type="xsd:double" />

</Configuration>

<OverrideableParameters>

<OverrideableParameter ID="Frequency" Selector="$Config/Frequency$" ParameterType="int" />

<OverrideableParameter ID="Threshold" Selector="$Config/Threshold$" ParameterType="double" />

</OverrideableParameters>

<MonitorImplementation>

<MemberModules>

<DataSource ID="DS_PerfData" TypeID="Performance!System.Performance.DataProvider">

<ComputerName>$Config/ComputerName$</ComputerName>

<CounterName>$Config/CounterName$</CounterName>

<ObjectName>$Config/ObjectName$</ObjectName>

<InstanceName>$Config/InstanceName$</InstanceName>

<AllInstances>$Config/AllInstances$</AllInstances>

<Frequency>$Config/Frequency$</Frequency>

</DataSource>

<ConditionDetection ID="BelowThresholdDetection" TypeID="SystemLibrary7585010!System.LogicalSet.ExpressionFilter">

<Expression>

<SimpleExpression>

<ValueExpression>

<XPathQuery Type="Double">Value</XPathQuery>

</ValueExpression>

<Operator>LessEqual</Operator>

<ValueExpression>

<Value Type="Double">$Config/Threshold$</Value>

</ValueExpression>

</SimpleExpression>

</Expression>

<EmptySet>Passthrough</EmptySet>

<SetEvaluation>All</SetEvaluation>

</ConditionDetection>

<ConditionDetection ID="AboveThresholdDetection" TypeID="SystemLibrary7585010!System.LogicalSet.ExpressionFilter">

<Expression>

<SimpleExpression>

<ValueExpression>

<XPathQuery Type="Double">Value</XPathQuery>

</ValueExpression>

<Operator>Greater</Operator>

<ValueExpression>

<Value Type="Double">$Config/Threshold$</Value>

</ValueExpression>

</SimpleExpression>

</Expression>

<EmptySet>Block</EmptySet>

<SetEvaluation>Any</SetEvaluation>

</ConditionDetection>

</MemberModules>

<RegularDetections>

<RegularDetection MonitorTypeStateID="BelowThreshold">

<Node ID="BelowThresholdDetection">

<Node ID="DS_PerfData" />

</Node>

</RegularDetection>

<RegularDetection MonitorTypeStateID="AboveThreshold">

<Node ID="AboveThresholdDetection">

<Node ID="DS_PerfData" />

</Node>

</RegularDetection>

</RegularDetections>

</MonitorImplementation>

</UnitMonitorType>

</MonitorTypes>

</TypeDefinitions>

On constate que ce module se configure très simplement à l’aide de deux balises xml : EmptySet et SetEvaluation.

EmptySet indique le traitement à appliquer : Passthrough (on continue le traitement des données vers les modules suivants dans le workflow, c’est le mode par défaut) ou Block (qui arrête le traitement du wokflow).

SetEvaluation indique si les données de chaque instance doivent correspondre (All), ou si une seule suffit (Any).

Dans l’exemple ci-dessus, on demande donc d’arrêter le traitement (Block) dès que n’importe quelle instance du compteur (Any) passe au dessus du seuil défini.

Ne reste alors plus qu’à implémenter le Moniteur à proprement parler :

<UnitMonitor ID="w3wp.process.privatebytes.monitor" Accessibility="Public" Enabled="false" Target="SharePoint2!Microsoft.SharePoint.2013.SPServiceInstance.Excel" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="MultipleInstance.Perf.MonitorType" ConfirmDelivery="true">

<Category>PerformanceHealth</Category>

<AlertSettings AlertMessage="w3wp.process.privatebytes.monitor_AlertMessageResourceID">

<AlertOnState>Error</AlertOnState>

<AutoResolve>true</AutoResolve>

<AlertPriority>Normal</AlertPriority>

<AlertSeverity>Error</AlertSeverity>

</AlertSettings>

<OperationalStates>

<OperationalState ID="AboveThreshold" MonitorTypeStateID="AboveThreshold" HealthState="Error" />

<OperationalState ID="BelowThreshold" MonitorTypeStateID="BelowThreshold" HealthState="Success" />

</OperationalStates>

<Configuration>

<ComputerName>$Target/Host/Property[Type="MicrosoftWindowsLibrary7585010!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>

<CounterName>Private Bytes</CounterName>

<ObjectName>Process</ObjectName>

<InstanceName>w3wp*</InstanceName>

<AllInstances>false</AllInstances>

<Frequency>300</Frequency>

<Threshold>2000000000</Threshold>

</Configuration>

</UnitMonitor>

Et cette fois-ci le moniteur ne bagotte plus, tant que n’importe laquelle des instances du compteur sera au dessus du seuil, le moniteur restera en Critical :

clip_image009

Pour aller plus loin : https://msdn.microsoft.com/en-us/library/hh442318.aspx?f=255&MSPPError=-2147217396

SCCM 2012 – Un déploiement s’exécute en boucle / L’agent se réinstalle toutes les 5h

 

Après le déploiement d’une tâche de reboot via SCCM (un simple de shutdown /r à intervalle planifiée sur une collection de serveurs), je me suis rendu compte que quelques serveurs rebootaient en boucle toutes les 5h.

Après mal de questionnement et d’analyse de log, je me suis aperçu que l’agent SCCM se réinstallait à la même fréquence, ce qui expliquait la répétition de la tâche de reboot étant donné son paramétrage assez « souple » (pas de maintenance window…).

Restait à identifier la raison de cette réinstallation… Ni les logs, ni la console SCCM ne contenaient d’information utile.

Pire, même en désactivant le service de l’agent (bloquant ainsi toute communication avec le serveur), il continuait à se réinstaller (et donc à se réactiver) !

La solution est finalement venue comme souvent d’une recherche sur internet, après avoir trouvé les bons mots-clés… Et le coupable s’avère être une tâche planifiée créée par CCMSETUP lors du premier déploiement de l’agent SCCM, dans le dossier Microsoft/Configuration Manager/Microsoft/Configuration Manager (oui, deux fois !) :

clip_image001

Cette dernière est paramétrée pour se relancer toutes les 5h et sert normalement lorsque CCMSETUP n’arrive pas à contacter le serveur SCCM, afin de reprendre le déploiement de l’agent ultérieurement.

Sauf que pour une raison quelconque (la répétition de l’arborescence Microsoft/Configuration Manager) peut faire penser à un bug qui créerait la tâche au mauvais endroit), il arrive que cette tâche planifiée ne soit jamais supprimée, et l’agent se réinstalle donc en boucle indéfiniment…

La solution est alors toute trouvée : il suffit de supprimer (ou au minimum de désactiver) cette tâche planifiée et tout rentre dans l’ordre!

SCOM – Alertes Failed to Access the Windows Event Log Veeam Vmware

 

Des alertes « Operations Manager Failed to Access the Windows Event Log” concernant des journaux d’événements Veeam Vmware (nWorks) et provenant de serveurs de management (MS) apparaissent :

clip_image002

Elles sont complétées par des événements 26604 récurrents (toutes les 12 minutes) dans les Event Log de ces serveurs :

clip_image004

The Windows Event Log Provider is still unable to open the Veeam VMware event log on computer 'SRV0'. The Provider has been unable to open the Veeam VMware event log for 1440 seconds.

Most recent error details: The specified channel could not be found. Check channel configuration.

One or more workflows were affected by this.

Workflow name: Veeam.Virt.Extensions.VMware.VMGUEST.CollectEvents

Veeam a publié une KB concernant ce problème : http://www.veeam.com/kb1496#/kb1496

Les causes indiquées dans cette dernière ne semblent pas correspondre au contexte rencontré dans mon cas (les alertes apparaissaient sur deux nouveau MS physiques fraichement ajoutés), mais la solution proposée fonctionne malgré tout :

Dans la console Veeam, exécuter une reconstruction de la topologie Rebuild Full Topology :

clip_image006

Rien n’indiquera que la reconstruction est terminée, mais cela peut prendre plusieurs dizaines de minutes voire plusieurs heures selon la taille de votre infrastructure, mais lorsque cela sera bon les événements 26004 ne doivent plus revenir dans l’Event Log.

Il restera enfin à réinitialiser manuellement les moniteurs en erreur :

clip_image008

Orchestrator 2012 – Récupérer le JobID du runbook en cours

 

D’origine, il est possible via les common Published Data de récupérer dans n’importe quel runbook Orchestrator l’ID d’une activité ou d’un process :

clip_image002

On peut même récupérer l’ID de l’instance en cours d’exécution (Job ID) d’un runbook enfant lorsqu’il est appelé via l’activité Invoke Runbook :

clip_image004

Par contre, il n’y a rien de prévu pour récupérer l’ID de l’instance en cours d’exécution du runbook courant.

Ce Job ID du runbook courant peut cependant avoir son utilité, par exemple à des fins de logging et debug. Dans mon cas, il s’agissait de récupérer le nom de la personne ayant démarré le runbook via le portail self-service EUPSCO.

Il est donc malgré tout possible de récupérer cet ID, en intégrant la requête SQL suivante dans une activité Query Database :

SELECT POLICYINSTANCES.JobID
FROM  POLICYINSTANCES INNER JOIN
ACTIONSERVERS ON POLICYINSTANCES.ActionServer = ACTIONSERVERS.UniqueID
WHERE     (POLICYINSTANCES.ProcessID = <Activity process ID from "Initialize Data">) AND (ACTIONSERVERS.Computer = '<Runbook Server name from "Initialize Data">') AND (POLICYINSTANCES.Status IS NULL)

clip_image006

Explication : cette requête interroge la base de données en lui fournissant l’Activity Process ID (qui est disponible nativement via les Common Published Data) afin de retrouver quel JobID contient cet Activity PRocess ID.

Il peut toutefois arriver que le Process ID soit présent plusieurs fois à l’identique dans la base, c’est pourquoi on filtre un peu plus en indiquant le nom du serveur qui exécute le runbook (Runbook Server Name dans les Common Published Data) et surtout en spécifiant le status « NULL », c’est-à-dire que l’on ne recherche que parmi les runbooks qui sont en cours d’exécution et qui n’ont donc pas encore un statut “success”, “warning” ou “failed”

Si tout s’est bien passé, le champ Full line as a string with fields separated by ‘ ;’ présent en sortie de l’activité Query Database devrait contenir le JobID de votre instance de runbook en cours d’exécution, à vous de le réutiliser à votre guise plus loin dans votre runbook !

SCOM 2012 – Erreur lors de l’installation du MP Lync/SFB 2015

 

Le MP Skype For Business (Lync) 2015 est sorti récemment, mais il ne dispose d’aucune documentation.

Son installation coté SCOM reste des plus classique (import de deux fichiers .mp, activation du mode proxy sur tous les agents de l’infrastructure SFB), mais un problème peut survenir sur les serveurs Edge :

image

[Skype] An internal exception has occurred during discovery.

Ce qui correspond à l’événement suivant :

image

An exception occurred during discovery script, Exception : Could not connect to SQL server : [Exception=System.Data.SqlClient.SqlException (0x80131904): Cannot open database "xds" requested by the login. The login failed.

Login failed for user 'NT AUTHORITY\NETWORK SERVICE'.

Cette erreur induit quelque peu en erreur car elle laisse à penser qu’il s’agit de permissions SQL à rajouter.

En réalité, pour résoudre ce problème, rajoutez simplement le compte Network Service aux groupes locaux RTC Component Local Group et RTC Local Administrators (vous pouvez d’ailleurs constater qu’il est normalement bien présent dans ces groupes sur les serveurs du réseau interne).

clip_image006

Enfin, redémarrez l’agent SCOM sur ces serveurs (service Microsoft Monitoring Agent).

SCOM – Des scripts n’arrivent pas à accéder aux cmdlet powershell SCOM

 

Il peut arriver que des scripts soient incapable d’appeler les cmdlet SCOM.

Dans mon cas, ce problème a été remarqué à cause du Management Pack Service Bus v1.1 et plus précisément à cause de la définition de son moniteur (UnitMonitorType) nommé Related Objects Health State, mais il aurait pu s’agir de n’importe quel script exécuté par un Management Pack ou non.

Il se traduisait ici par des évènements Error avec l’ID 4101 dans le journal d’évènements Operations Manager :

clip_image002

Managegement Group: xxx. Script: RelatedObjectsHealthStateMonitorScript\Main : Error occured during Related Objects Health State monitoring.

Computer:yyy

Reason: The term 'Get-SCOMRelationship' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Voyons comment fonctionne ce Monitor Type. Il est basé sur un script powershell qui commence par les commandes suivantes :

param($objectId, $relationshipId, $relatedObjectClassId, $relatedObjectMonitorId, $ignoreUnavailable, $ignoreInMaintenanceMode)
#TODO: Discuss event id
$SCRIPT_EVENT_ID = 4101 
#Event Severity values
$INFORMATION_EVENT_TYPE = 0
$ERROR_EVENT_TYPE = 1 
function GetRelatedObjectsHealthState7Version
{
param
(
$objectId,
$relationshipId,
$relatedObjectClassId,
$relatedObjectMonitorId,
[bool]$ignoreUnavailable,
[bool]$ignoreInMaintenanceMode
)
Import-Module -Name "OperationsManager"
$constUnintializedHealthState = "Uninitialized"
$constSuccessHealthState = "Success"
$constWarningHealthState = "Warning"
$constErrorHealthState = "Error"
#
# Get Relationship
#
$relationship = Get-SCOMRelationship -Id $relationshipId
if($relationship -eq $null)
{
$exceptionMsg = "Relationship with Id {0} not found." -f $relationshipId
$argumentException = New-Object System.ArgumentException -ArgumentList $exceptionMsg 
throw $argumentException
}

Les premières cmdlet SCOM réellement exécutées sont celles surlignées en jaune , les autres lignes ne sont que des définitions de variables ou des appels indépendants de SCOM.

Or, l’évènement indique un échec dès l’appel du cmdlet Get-SCOMRelationship : Reason: The term 'Get-SCOMRelationship' is not recognized as the name of a cmdlet, function, script file, or operable program.

On peut donc supposer qu’en réalité, le script n’a pas été en mesure de charger le module OperationsManager et qu’il ne reconnait donc pas le cmdlet.

On constate également que l’import manuel du module OperationsManager dans un shell PowerShell échoue.

Vérifions donc qu’il est bien présent sur le serveur où remonte l’alerte. Il doit se trouver dans le dossier d’installation de SCOM, sous-dossier Powershell > OperationsManager :

clip_image004

Le module existe bien.

Vérifions maintenant qu’il est bien enregistré dans la variable d’environnement $env:PSModulePath :

clip_image006

Manifestement, il est bien enregistré… Mais pas au bon endroit !

En effet, la variable d’environnement pointe vers C:\Program Files\System Center 2012\Operations Manager\Powershell\ alors que le module se trouve en réalité dans C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager !

La solution est alors toute trouvée : rajouter le bon chemin à la variable d’environnement à l’aide des commandes suivantes :

$originalpaths = (Get-ItemProperty -Path ‘Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment’ -Name PSModulePath).PSModulePath

$newPath=$originalpaths+’;C:\Program Files\System Center 2012\Operations Manager\Powershell\OperationsManager\’

Set-ItemProperty –Path ‘Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment’ -Name PSModulePath –Value $newPath

Il ne reste plus qu’à redémarrer le serveur pour que la modification soit prise en compte et le problème résolu !