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 :
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 :
Le module existe bien.
Vérifions maintenant qu’il est bien enregistré dans la variable d’environnement $env:PSModulePath :
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 !
