Le blog technique

Vous savez (et regrettez !) probablement déjà que la console Authoring présente dans SCOM 2007 n’existe plus dans SCOM 2012.

Il est toujours possible d’utiliser l’ancienne version pour créer un management pack, puis d’importer ce dernier dans SCOM 2012 : ca fonctionne, ca SCOM 2012 sait lire et convertir le format de MP 2007.

L’inverse n’est par contre malheureusement pas vrai : il est impossible d’ouvrir dans la console Authoring un MP exporté depuis SCOM 2012.

Voici ce que vous obtiendrez en boucle si vous vous y risquez :

“Referenced management pack not found”

Et vous aurez beau vous acharner et indiquer le MP demandé, rien n’y fera.

Mais pire encore, malheur à vous si vous avez essayé de référencer les MP de base de SCOM 2012 dans les options de la console Authoring en espérant que cela permette de les utiliser !

En effet, ce genre de réglage provoquera l’apparition en boucle du message précédent réclamant le MP System.Library Management Pack, sans possibilité de le sélectionner ni de revenir en arrière sur ce réglage !

Pour y remédier, rendez vous dans l’éditeur de registre (regedit) et ouvrez la clé HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Authoring\Settings\References

Supprimez le contenu de la ligne Value Data et cliquez sur OK.

La console Authoring est désormais à nouveau accessible.

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}