Le blog technique

Il peut arriver d’avoir besoin de créer une règle ou un moniteur qui s’exécute avec un RunAs Profile (lié à un runas account) spécifique, par exemple dans le cas d’un moniteur de type script qui interroge une base de données SQL pour laquelle un login particulier est requis.

Avec la console Authoring présente dans SCOM 2007, cette possibilité était accessible graphiquement : il suffisait de sélectionner un profil dans une liste déroulante dans les propriétés du moniteur.

Malheureusement, la console Authoring n’existe plus dans SCOM 2012, et la console Operations ne permet pas de sélectionner un RunAs profile lors de la création d’un moniteur… nous voilà donc réduits à modifier le management pack contenant ce moniteur directement en XML.

Si le RunAs Profile et son Account associé ne sont pas encore créés, il est cependant possible de les ajouter au management pack voulu à l’aide la console Operations :

Rendez-vous dans l’onglet Administration et faites un clic-droit sur Run-As Configuration –> Profiles. Sélectionnez Create Run As Profile

Cliquez sur Next

Choisissez un nom pour le run-as profile et enregistrez le dans un management pack (important : si le moniteur ou la règle qui qui doit être associé à ce profil est contenu dans management pack non scellé, il est obligatoire d’enregistrer le run-as profile dans le même management pack !), puis cliquez sur Next.

Cliquez sur Add pour ajouter un run-as account puis sélectionnez le Run-As account à associer avec ce profil (ou créez-en un nouveau) et sélectionnez l’étendue qui vous convient le mieux puis cliquez sur OK. Cliquez sur Next.

Pensez à distribuer le run-as account sur les serveurs où il sera utilisé s’il est configuré en more secure, puis cliquez sur Close.

Une fois le run-as profile créé et configuré dans le bon management pack, il faut exporter ce management pack pour travailler dessus.

Allez dans Administration -> Management Packs, recherchez le MP qui contient les moniteurs et règles à modifier et cliquez sur Export Management Pack. Choisiseez un dossier de destination pour le fichier XML enregistrez le.

Ouvrez ce fichier XML dans un éditeur de texte et localisez le bloc SecureReferences. Il contient un champ SecureReference (au singulier), qui indique l’ID de votre RunAs profile (si vous l’avez créé dans la console comme expliqué précédemment, il aurait un ID généré automatiquement beaucoup plus long) :

<SecureReferences>
<SecureReference ID="Test.Monitors.RunAsProfile" Accessibility="Internal" Context="System!System.Entity" />
</SecureReferences>

Notez cet ID, il va nous servir juste ensuite.

Il y a maintenant deux possibilités, selon que vous souhaitiez ajouter ce RunAs profile à un moniteur ou à une règle.

Cas du moniteur :

Localisez la ligne UnitMonitor correspondant au moniteur auquel vous souhaitez ajouter le RunAs Profile, par exemple :

<UnitMonitor ID="UIGeneratedMonitorff3366f355ae45a391b645c36c9d1ba3" Accessibility="Public" Enabled="true" Target="Test.Class" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="Windows!Microsoft.Windows.TimedScript.TwoStateMonitorType" ConfirmDelivery="false">

Il suffit maintenant d’ajouter à cette ligne le paramètre RunAs="Test.Monitors.RunAsProfile", et le tour est joué :

<UnitMonitor ID="UIGeneratedMonitorff3366f355ae45a391b645c36c9d1ba3" Accessibility="Public" Enabled="true" Target="Test.Class" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" RunAs="Test.Monitors.RunAsProfile " TypeID="Windows!Microsoft.Windows.TimedScript.TwoStateMonitorType" ConfirmDelivery="false">

Cas de la règle :

Là aussi, c’est très simple, à une subtilité près : il ne faut pas ajouter le paramètre RunAs="Test.Monitors.RunAsProfile " à la règle elle-même (ligne Rule), mais à sa DataSource.

Commencez donc par localiser la ligne Rule correspondant à la règle à modifier, par exemple

<Rule ID="MomUIGeneratedRule7fbfb108d804460e9b8e13deb1ea1b0c" Enabled="true" Target="Test.Class" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100" >

Quelques lignes plus bas doit se trouver la ligne DataSource correspondante :

<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.PerformanceProvider">

Il suffit d’ajouter à cette dernière notre paramètre RunAs :

<DataSource ID="DS" TypeID="Windows!Microsoft.Windows.TimedScript.PerformanceProvider" RunAs="Test.Monitors.RunAsProfile ">

Une fois la modification apportée à tous les moniteurs et règles souhaités, sauvegardez le fichier XML (en pensant à incrémenter son champ Version !) et réimportez le dans SCOM.

Le RunAs profile s’applique désormais aux moniteurs et règles désirés 🙂

Il existe une méthode de l’objet powershell scom get-scomagent permettant de positionnez la failover management server vers lequel basculera vos agent en cas de crash de leur Primary Management Server.

Les commandes suivantes présentent la logique d’execution de ce positionnement:

On attribue a deux variables le Primary Management Server et le Failover Management Server

$primaryms=Get-SCOMManagementServer -Name "MyPrimaryServer1.home.com"

$failoverms=Get-SCOMManagementServer -Name "MyFailoverServer1.home.com"

On attribue a une variable tout les agents qui ont comme Primary Management Server le serveur "MyPrimaryServer1.home.com”

$agentstomove=Get-SCOMAgent | where-object {$_.primarymanagementservername -eq "MyPrimaryServer1.home.com”}

Vous pouvez vous assurez qu’aucun des agents ne possede un failover server érroné avec la commande suivante qui positionne cette valeur a Null

$agentstomove | foreach {Set-SCOMParentManagementServer -agent $_ -Failoverserver $null}

Enfin pour positionner le Failover Management Server.  Je vous conseille dans ce cas la de mettre l’option Verbose, surtout si le nombre d’agent a traiter est important afin de voir le résultat

$agentstomove | foreach {Set-SCOMParentManagementServer -agent $_ -Failoverserver $failoverms –verbose}

Les alertes “Workflow Runtime: Failed to run a process or script” ou “Workflow Runtime: Failed to run a WMI query” révèle un problème d’exécution d’une règle ou d’un moniteur.

1er cas: ce problème est ponctuel. Le champ repeat count de l’alerte est peu élevé et la dernière occurrence (champ Last Modified) n’est pas très récent:

Dans la plupart de ces cas, le workflow exécuté a l’origine de cette erreur n’a pas pu aboutir pour des problèmes ponctuels de performance ou de disponibilité de la machine cible. Vous pouvez essayez de faire le parallèle entre l’heure de l’alerte et les éventements présent dans les eventlog Application et Systeme de la machine cible.

2nd cas: Ce problème est récurrent. Le champ repeat count de l’alerte est élevé et la dernière occurrence (champ Last Modified) est récente: Cela signifie que le workflow concerné échoue systématiquement pour cette la machine cible.

Action:

Il est important de lire le champ Description de l’alerte pour voir plus de détail sur la commande ou la requête exécutée, le workflow impacté et la machine cible.

Exemples:

*************************************************************

Command executed: "C:\Windows\system32\cscript.exe" /nologo "IsHostingMSCS.vbs" {1C0CCF64-D32D-B64C-A66A-792E7F0934D6} {6E52A2D1-E55F-7E00-A150-D4CFAB747EFE} (…) (…)

Working Directory: C:\Program Files\System Center Operations Manager\Agent\Health Service State\Monitoring Host Temporary Files 2960\58276\

One or more workflows were affected by this.

Workflow name: System.Mom.BackwardCompatibility.Computer.IsHostingMSCS.Discovery

Instance name: Machine1.home.com

*************************************************************

***************************************************************

Object enumeration failed

Query: ‘SELECT ServiceName, StartName, DisplayName FROM SqlService WHERE ServiceName="SQLAgent$REC_FR_CI_AS"’

HRESULT: 0x800706be

Details: The remote procedure call failed.

One or more workflows were affected by this.

Workflow name: Microsoft.SQLServer.2008.AgentDiscovery

Instance name: MSSQLSERVER

Instance ID: {6AD519E3-D3C0-7B1B-EE4A-92367A4CDCEC}

***************************************************************

Connectez vous sur la machine concernée par l’alerte

Pour les alertes concernant une erreur d’exécution d’un script, tentez d’exécutez dans une fenêtre de commande le script et les argument associés tel que la commande apparait dans le champ Description de l’alerte (Command Executed:…)

Les scripts de supervision des règles/moniteurs retourne dans la plupart des cas leurs données au format XML, ce qui signifie que le script a abouti a une transmission des données récoltées. Dans la cas contraire, le retour affiché par l’exécution de ce script peut être une erreur vbscript ou powershell lié au contenu du script lui-même.

Pour les alertes concernant une erreur d’exécution d’une requête wmi, vérifiez sur la machine que la requête wmi précisée dans le champ description de l’alerte (Query:…) peut être effectuée.

=> Utilisez wbemtest.exe présent nativement sur tout les OS Windows pour exécutez la requête wmi.

De plus le code situé apres “HRESULT” dans la description de l’alerte indique le type d’erreur wmi. ces types sont disponible sur le lien http://msdn.microsoft.com/en-us/library/aa394559%28v=vs.85%29.aspx