PI Services

Le blog des collaborateurs de PI Services

SCOM 2012 – Console Authoring bloquée

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 :

clip_image002

“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 !

clip_image004

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

clip_image006

clip_image008

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

La console Authoring est désormais à nouveau accessible.

SCOM 2012 - Ajouter un RunAs profile à un Moniteur ou à une Règle

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

clip_image002

Cliquez sur Next

clip_image004

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.

clip_image006

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.

clip_image008

clip_image010

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

clip_image012

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.

clip_image014

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 :)

SCOM 2012 : impossible d’ajouter des Knowledge

Si vous essayez de remplir des Knowledge (base de connaissance) dans SCOM 2012, il y a de fortes chances que vous rencontriez le message d’erreur suivant :

clip_image002

Failed to launch Microsoft Word. Please make sure Microsoft Word is installed. Here is the error message :
Could not load file or assembly « Microsoft.Office.Interop.word, Version 11.0.0.0, Culture = Neutral, PublicKeyToken=71e9bce111e9429c or one of its dependencies. The system cannot find the file specified.

Microsoft propose un contournement non officiel en attendant une mise à jour future qui résoudra ce bug.

Il est dans un premier temps nécessaire de s’assurer que les prérequis sont précisément remplis, car cette fonctionnalité y est très sensible :

1. Installer Word 2010 en version x86 uniquement

2. Installer les VSTOR 2005 (Visual Studio 2005 Tools for Office Second Edition Runtime) (éventuellement en complément d’une version ultérieure, mais cette version 2005 SE est impérative !) http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=20479

3. Rebooter la machine sur laquelle Word et les VSTOR sont installés, même si l’installeur de VSTOR n’a rien demandé.

Il est maintenant temps de mettre en place le contournement à proprement parler.

Récupérer le fichier suivant : http://blogs.technet.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-03-52-52-89/KnowledgeEditingNewFiles.zip (mis à disposition par l’équipe SCOM sur son blog : http://blogs.technet.com/b/momteam/archive/2012/10/10/how-to-get-knowledge-editing-to-work-in-operations-manager-2012-with-office-2010.aspx ) et le décompresser dans le répertoire X:\Dossier dinstallation\System Center 2012\Operations Manager\Console à la place des fichiers knowledge.dot et Microsoft.EnterpriseManagement.Monitoring.Console.exe.config qui s’y trouvent déjà (vous pouvez renommer les anciens au lieu de les écraser pour conserver une trace des modifications).

Comme le fichier knowledge.dot de remplacement contient des macro et provient d’internet, il est nécessaire de le déverrouiller (clic droit -> propriétés -> unblock):

clip_image004

Il devrait maintenant être possible d’ajouter des knowledge dans SCOM 2012 en utilisant la procédure habituelle.

SCOM–Impossible d’accéder aux sites de l’APM

Quelques temps après le déploiement d’une infrastructure SCOM 2012, un client a souhaité mettre en place une de ses nouvelles fonctionnalités, à savoir le monitoring applicatif (APM).

Après avoir mis en supervision quelques applications Web, nous nous sommes rendus compte que les sites permettant l’analyse de cette supervision (nommés respectivement Application Diganostics et Application Advisor) ne fonctionnaient pas : lors d’une tentative d’accès, ils renvoyaient tous deux une erreur « An error has occured : The additional error information can be found in the Windows Application Log. We apologize for any inconvenience caused by this temporary service outage. »

clip_image002

Un tour dans l’event viewer nous en apprend effectivement un peu plus :

clip_image004

Le message complet indique :

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 01/03/2013 16:52:22
Event time (UTC): 01/03/2013 15:52:22
Event ID: b5c9f03cbae94f40b2e35d1a28651518
Event sequence: 8
Event occurrence: 1
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1/ROOT/AppAdvisor-2-130066267234915799
Trust level: Full
Application Virtual Path: /AppAdvisor
Application Path: D:\OpsMgr\WebConsole\AppDiagnostics\AppAdvisor\Web\
Machine name: BT1SVX2K

Process information:
Process ID: 2868
Process name: w3wp.exe
Account name: IIS APPPOOL\OperationsManagerAppMonitoring

Exception information:
Exception type: OleDbCommandException
Exception message: Exception has been thrown by the target of an invocation.
Command text: SELECT apm.IsInstallCompleted ()
Connection: Provider=SQLOLEDB;Server=BTCISQL03\OPSVMM;database=OperationsManagerDW;Integrated Security=SSPI;

at Avicode.AX5.Data.OleDb.OleDb.ExecuteScalar(OleDbCommand oleDbCommand)
at Avicode.Intercept.SEManager.Core.DBAccess.DB.ExecuteScalar(String query)
at Avicode.Intercept.SEManager.WebViewer.Pages.Authenticate.Page_Load(Object sender, EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Exception has been thrown by the target of an invocation.
at Avicode.AX5Base.IdentityThread.Execute(Action action)
at Avicode.AX5.Data.OleDb.OleDb.ExecuteScalar(OleDbCommand oleDbCommand)

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
at System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection)
at System.Data.OleDb.OleDbConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.OleDb.OleDbConnection.Open()
at Avicode.AX5Base.IdentityThread.ActionItem.ExecutionBody(Object actionItem)

Request information:
Request URL: http://localhost/AppAdvisor/Pages/Authenticate.aspx?ReturnUrl=/AppAdvisor
Request path: /AppAdvisor/Pages/Authenticate.aspx
User host address: ::1
User:
Is authenticated: False
Authentication Type:
Thread account name: IIS APPPOOL\OperationsManagerAppMonitoring

Thread information:
Thread ID: 15
Thread account name: IIS APPPOOL\OperationsManagerAppMonitoring
Is impersonating: False
Stack trace: at Avicode.AX5.Data.OleDb.OleDb.ExecuteScalar(OleDbCommand oleDbCommand)
at Avicode.Intercept.SEManager.Core.DBAccess.DB.ExecuteScalar(String query)
at Avicode.Intercept.SEManager.WebViewer.Pages.Authenticate.Page_Load(Object sender, EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

La partie intéressante étant Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON', puisqu’elle indique qu’ASP a refusé une connexion anonyme.

Il est donc temps d’aller faire un tour du coté de la MMC IIS, plus précisément dans les Applications Pool. Voici ce qu’on y trouve :

clip_image006

Configuré de la sorte, cela ne permet pas d’accéder à la base de données, d’où notre erreur. Il faut donc les modifier et mettre un compte qui a les droits sur la base via les Advanced Settings :

clip_image008

clip_image010

Répéter l’opération pour le second Application Pool, puis recycler les deux.

Voilà, désormais l’accès est possible !

SCOM–Alertes charge CPU Agent suite à migration 2012

Lors d’une migration SCOM 2007 R2 vers SCOM 2012 en side by side (avec des agents en multi-homing qui continuent à renvoyer des informations vers les deux infrastructures en parallèle), un problème sur la remontée de la charge CPU de l’agent SCOM est à prévoir.

En effet, le script qui s’occupe de mesurer cette métrique a été mis à jour dans la version 2012, ce qui occasionne des remontées totalement incohérentes dans les compteurs de performance de la console 2007, ainsi qu’un grand nombre d’alertes associées :

clip_image002

On constate sur ce graphique que l’utilisation CPU par l’agent SCOM (en rouge) est plus importante que l’utilisation CPU totale (en jaune), ce qui n’est évidemment pas possible dans la réalité.

En vérifiant les même compteurs dans la console SCOM 2012, voici le graphique que l’on obtient :

clip_image004

Ici, les informations sont bien plus normales, et conformes à ce qu’il est possible de vérifier directement dans le gestionnaire de taches/ressources des serveurs concernés : la piste du bug est confirmée.

La solution est alors toute trouvée : créer un Override qui désactive la règle « Collect Agent Processor utilization » sur l’infrastructure 2007.

En résumé : si lors d’une migration SCOM 2007 vers 2012 en side by side avec agents multi-homés (qui remontent vers les deux infrastructures) vous rencontrez soudainement un grand nombre d’alertes CPU sur la plateforme 2007 uniquement, pas de panique : il ne s’agit très probablement que d’un bug lié à un script différent, qui se réglera en désactivant la règle incriminée.

SCOM–Erreur MOMCertImport 0xc000007b

Lors de la mise en place d’un serveur Gateway dans une infrastructure SCOM 2012, le bug suivant m’a laissé perplexe pendant de longues heures… cet article vous permettra peut être de bénéficier de mes erreurs !

En suivant scrupuleusement la fiche technet détaillant l’installation du rôle Gateway, on constate que de nombreuses étapes préparatoires sont requises avant de procéder au déploiement du rôle à proprement parler.

L’une d’entre elle concerne plus spécifiquement le déploiement du certificat qui sera nécessaire à la bonne communication de la Gateway avec son Management Server (cf. http://technet.microsoft.com/en-us/library/hh467905.aspx )

Tout se passe bien jusqu’à la dernière étape, la validation du certificat par MOMCertImport qui fait remonter cette erreur :

clip_image002

The application was unable to start correctly (0xc000007b). Click OK to close the Application.

Un joli message d’erreur, détaillé et explicite comme on les aime.

Après avoir passé en revue les réponses classiques à ce genre de problème (UAC qui bloque ? Utilisation de la binaire x86 au lieu de la x64 ou vice-versa ? Et en runas administrator, ca passe ? En récupérant MOMCertImport sur un media d’installation différent ?), il s’avère finalement que MOMCertImport est en réalité incapable de s’exécuter sans certaines DLL… qui ne sont présentes que si SCOM est installé (et donc si le rôle Gateway est déjà présent !).

Il ne reste donc plus qu’à installer le rôle gateway, puis à finaliser l’import du certificat… et tant pis pour l’ordre préconisé par Technet.

A noter que cette problématique peut se présenter de façon parfaitement identique dans le cadre du déploiement d’un agent en DMZ, puisqu’il nécessite de la même façon la présence d’un certificat validé par MOMCertImport.

SCOM : passer automatiquement les serveurs qui redémarrent en mode maintenance

Dans une grosse infrastructure composée de nombreux serveurs, les redémarrages peuvent s’avérer assez fréquents.

Malheureusement, un serveur qui redémarre peut entrainer la remontée de différentes alertes dans SCOM puisque ni son agent ni les services qu’il exécute ne répondent plus.

C’est pourquoi il est recommandé de basculer les serveurs à redémarrer dans mode « Maintenance » dans la console SCOM avant de les stopper : cela indique à SCOM qu’il doit arrêter de les superviser pendant un temps prédéfini, empêchant ainsi toute remontée d’alerte.

Dans le cadre de grosses infrastructures, réparties entre des services divers, il n’est toutefois pas toujours pratique de solliciter la bonne personne au bon moment pour procéder à cette mise en mode maintenance, d’où l’intérêt de pouvoir procéder à cette action automatiquement lorsqu’un redémarrage est détecté.

Cette automatisation sera réalisée à l’aide d’une règle qui détectera un événement 1074 (source USER32) dans le journal d’événement System et créera une alerte, qui sera interceptée à l’aide d’un Notification Channel, qui déclenchera enfin l’exécution d’un script PowerShell qui procèdera à la mise en mode maintenance.

Commençons donc par créer la règle de détection d’événement :
Indiquer un nom pour la règle, une description, une catégorie, la cibler sur la classe Windows Computer et sélectionner un management pack différent du Default pour l’enregistrer.

clip_image002

Les events 1074 sont créés dans le journal d’évènement System lorsqu’un redémarrage est initié.

clip_image004

Leur ID est 1074 et leur source est USER32

clip_image006

L’alerte n’est pas destinée à être lue par un opérateur humain, son nom et sa description importent donc peu tant qu’ils restent suffisamment spécifiques. De la même façon, la sévérité pourra être définie à Information.

clip_image008

 

Une fois la règle mise en place, nous allons créer un ensemble de règles de Notification (channel de notification, subscriber, subscription). Ce sont eux qui détecteront la création de l’alerte et commanderont le lancement du powershell de mise en mode maintenance. Une recovery task aurait également pu remplir le même rôle, mais son mode de fonctionnement induit une réaction plus lente qui pourrait ici être préjudiciable puisqu’il faut que la mise en maintenance soit faite avant que le serveur ne cesse de répondre.

Commençons donc par créer un nouveau Notification Channel.
Entrer un nom et une description :

clip_image010

Dans le champ Full path of the command file, indiquer le chemin vers l’executable de powershell. Il s’agit par défaut de C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Dans le champ Command line parameters, indiquer les paramètres suivants (pensez à remplacer le chemin du script par le chemin où se trouvera le script dans votre cas) :
-Command "& '"D:\chemin\vers\script\scriptmaintenancemode.ps1"'" -alertid '$Data/Context/DataItem/AlertId$' -computerPrincipalName '$Data/Context/DataItem/ManagedEntityDisplayName$'

clip_image012

 

Passons ensuite au Subscriber.

Indiquer un nom

clip_image002[3]

Laisser la sélection par défaut pour la plage d’utilisation (Alwas send notifications)

clip_image004[3]

Cliquer sur Add. Indiquer à nouveau un nom (le même fera parfaitement l’affaire).

clip_image006[3]

Sélectionner le Channel Type nommé Command et le Notification Channel qui vient d’être créé, Mode Maintenance dans cet exemple.

clip_image008[3]

Ici aussi, laisser Always send notifications coché et cliquer sur Finish.

clip_image010[3]

De retour sur l’écran du Notification Subscriber Wizard, l’addresse qui vient d’être créée doit apparaitre. Cliquer sur Finish.
clip_image012[3]

 

Reste à paramétrer la Subscription.
Là aussi indiquer un nom (toujours le même…) et une description.

clip_image014[4]

En Critère de déclenchement , cocher Created by specific rules or monitors et indiquer la règle précédemment créée.

clip_image016[4]

Cliquer sur Add et sélectionner le Subscriber préalablement créé.

clip_image018[4]

De la même facon, cliquer sur Add et indiquer le Channel.

clip_image020[4]

Cliquer sur Finish.


Il ne reste plus qu’à créer le script powershell à proprement parler. Pensez à modifier la variable $RMS de façon à ce qu’elle indique le nom de votre RMS et la variable $minutes avec la durée de mise en mode maintenance que vous souhaitez utiliser, ainsi qu’a enregistrer le fichier .ps1 à l’endroit de votre choix correspondant à ce que vous avez indiqué lors de la création du Notification Channel:

#
# SCHEDULE MAINTENANCE MODE
# Version originale de base : http://lucamihailescu.blogspot.com/2010/01/operations-manager-maintenance-mode.html
#

Param($alertid, $computerPrincipalName, $minutes, $comment)

$RMS = "localhost"

if (!$minutes) {$minutes = 15}
if (!$comment) {$comment = "Mode Maintenance Automatique Suite a Detection de Redemarrage"}

function fixalert {
$alert = Get-Alert -Id $alertid
Resolve-Alert -Comment $args[0] -Alert $alert
}

if ((Get-PSSnapin | Where {$_.Name -eq 'Microsoft.EnterpriseManagement.OperationsManager.Client'}) -eq $null) {

Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"

}

New-ManagementGroupConnection $RMS
Set-Location "OperationsManagerMonitoring::"
Set-Location $RMS
$agent = Get-Agent | Where {$_.PrincipalName –eq $computerPrincipalName}
$computer = $agent.HostComputer

if (!$agent) { fixalert "Alerte cloturee par le Script MaintenanceMode. Le Mode Mainenance n’a pas pu etre active (le serveur en cours de redemarrage est un RMS ou MS)"; Exit }

$startTime = [DateTime]::Now

$endTime = $startTime.AddMinutes($Minutes)

New-MaintenanceWindow -StartTime $startTime -EndTime $endTime -MonitoringObject $computer -Comment $comment

fixalert "Alerte cloturee par le Script MaintenanceMode. Mode Maintenance actif!"

Voilà, c’est terminé… vous pouvez maintenant redémarrer un de vos serveur supervisé pour vérifier qu’il passe bien automatiquement en mode maintenance!

 

Orchestrator : créer son propre Integration Pack (partie 2 : compiler et importer l’oip)

 

Dans le billet précédent, nous avons vu comment créer une Assembly, c'est-à-dire le fichier dll contenant la « mécanique » de l’Integration Pack. Cependant, pour obtenir un Integration Pack finalisé et prêt à être déployé sur une infrastructure Orchestrator, il est nécessaire de packager cette Assembly pour en faire un fichier .oip.

Lancer l’outil Orchestrator Integration Pack Wizard

image

Cliquer sur Next ou sur Import Integration Pack pour reprendre un OIP préexistant

image

Remplir les champs obligatoires (marqués par une étoile).

image

Product Name correspond au nom qui apparaitra dans le Deployment Manager.

image

 

Category Name correspond au nom de la catégorie d’activité qui apparaitra dans le Runbook Designer :

image

Resource File est le fichier qui contient les icones et d’autres ressources. Dans cet exemple on conserve celui par défaut.

Une fois les champs remplis, cliquer sur Next.

Dans le champ Library, sélectionner la dll de l’assembly créée dans la première partie ainsi que la classe correspondante. Indiquer un Display Name (nom qui apparaitra dans le Runbook Designer). Sélectionner une icône pour l’activité, et cliquer sur OK

image

Au besoin, sélectionner les fichiers nécessaires au bon fonctionnement de l’activité (par exemple un exécutable si l’activité repose dessus) en cliquant sur Add. Dans notre exemple, il n’y a rien à ajouter puisque le fonctionnement de l’activité repose sur du code PowerShell directement intégré dedans. Cliquer sur Next.

image

Indiquer le chemin où enregistrer fichier OIP final puis cliquer sur Next.

image

L’assistant compile l’OIP…

image

Une fois terminé, cliquer sur Finish.

Il reste maintenant à déployer notre OIP au Management Server, Runbook Server et/ou Runbook Designer. Cette procédure est identique quel que soit l’OIP à déployer, mais un rappel pourra toujours servir :

Lancer la console Deployment Manager et faire un clic-droit sur Integration Packs. Cliquer sur Register IP with the Orchestrator Management Server.

image

Cliquer sur Next.

image

Cliquer sur Add et sélectionner l’OIP à déployer.

image

Cliquer sur Finish.

image

Une fois enregistré avec le Management Server, l’OIP apparait dans la liste des Integration Packs. Faire un clic-droit sur son nom et cliquer sur Deploy IP to Runbook Server or Runbook Designer.

image

Cliquer sur Next.

image

Sélectionner l’OIP à déployer et cliquer sur Next.

image

Indiquer le ou les serveurs cible(s) via le champ Computer et le bouton Add puis cliquer sur Next

image

 

Indiquer si vous souhaitez procéder au déploiement à une heure précise ainsi que si vous préférer arrêter tous les runbooks avant de procéder au déploiement. Cela peut s’avérer nécessaire pour certains OIP, ou pour le déploiement d’un hotfix, mais pas dans le cas de notre exemple. Cocher Install the Integration Packs […] et cliquer sur Next.

image

Cliquer sur Finish.

image

 

Relancer la console Runbook Designer pour en rafraichir le contenu. L’activité doit maintenant être présente et il ne reste plus qu’à l’utiliser comme n’importe quelle autre dans vos runbooks :

image

Orchestrator : créer son propre Integration Pack (partie 1 : créer l’assembly)

 

Orchestrator est livré d’origine avec un bon nombre d’activités pré-installées, qui permettent de mettre en place nativement un large panel de scénarios. Il est également possible d’étendre ces capacités à l’aide d’Integration Packs (appelés OIP), qui peuvent être disponibles au téléchargement auprès de Microsoft ou d’éditeurs tiers ou bien développés directement par les administrateurs en fonction de leurs besoin spécifiques.
Nous allons nous intéresser ici à ce dernier cas.

Dans un premier temps, il est nécessaire de télécharger et d’installer Orchestrator Integration Toolkit, le package qui contient les outils nécessaires à la création de ces OIP. Il est disponible ici : http://www.microsoft.com/en-us/download/details.aspx?id=28725 (System_Center_2012_Orchestrator_Integration_ToolKit.exe)

L’installer et importer l’OIP « integration toolkit » fourni avec dans votre infrastructure Orchestrator (management server et runbook designer, se référer à la fin de la partie 2 pour de l’aide à ce sujet).

Une fois ces pré-requis complétés, nous pouvons démarrer la création de l’Integration Pack à proprement parler. La première étape consiste à créer une « Assembly », qui est un fichier dll contenant le « moteur» de l’OIP. La seconde étape consistera à packager cette dll pour en faire un fichier OIP à proprement parler.

Nous étudierons ici l’exemple d’un OIP contenant une unique activité permettant d’ajouter des évènements au journal d’évènements (Event Viewer). Cette activité existe déjà d’origine via l’activité « Send Event Log Message », mais elle est très limité : elle ne permet pas de sélectionner le journal d’évènement cible, ni l’ID de l’évènement, ni sa source, ni sa criticité. L’OIP que nous allons développer ici offrira toutes ces possibilités.

Lancer l’outil Orchestrator Command-Line Activity Wizard.

clip_image002

Cliquer sur Next à l’écran d’accueil (ou sur Load existing assembly  pour reprendre un projet en cours).

clip_image004

Nommer le projet et indiquer le chemin où enregistrer l’assembly (le fichier dll source) puis cliquer sur Next

clip_image006

Il est également possible d’ajouter des détails sur le projet (description, nom de la compagnie, version… ) en cliquant sur Assembly Information

clip_image008

Cliquer sur Add

clip_image010

Dans l’onglet General, nommer l’activité et indiquer son mode de fonctionnement (Run Command, Run Windows PowerShell, Run Program ou Run SSH Command).
Dans notre cas, la création d’événement dans le journal d’événements se reposera sur une commande PowerShell ; nous choisissons donc Run Windows Powershell.
Cliquer sur l’onglet Arguments.

clip_image012

L’onglet Arguments est celui dans lequel nous déterminons les paramètres d’entrée de l’activité ainsi que le code PowerShell qui la fera fonctionner.

clip_image014

Dans Parameters, cliquer sur Add. Indiquer le nom du paramètre d’entrée, son mode de fonctionnement (dans notre cas Command Argument), son type (champs texte, champs mot de passe, liste déroulante, browse button…) et éventuellement une valeur par défaut. Ci-dessous deux exemples , un en type Text et l’autre en type Text with Selection (liste déroulante).

clip_image016

clip_image018

Pour réaliser notre exemple d’ajout d’événement dans le journal d’événements, les paramètres suivants sont nécessaires :

Name

Usage mode

Display Style

Options

Log Name

Command Argument

Text

-

Source

Command Argument

Text

-

Content

Command Argument

Text

-

Event ID

Command Argument

Text

-

Event Severity

Command Argument

Text with Selection

Verbose|Information|Warning|Error|Critical

Computer Name

Command Argument

Text

-

Une fois tous les paramètres ajoutés, cliquer sur Insert afin d’entrer le code PowerShell qui sera le « moteur » de notre activité :
Write-eventlog -logname "$(Log Name)" -ComputerName "$(Computer Name)" -Source "$(Source)" -Message "$(Content)" -id "$(Event ID)" -EntryType "$(Event Severity)"

L’onglet Published Data permet d’indiquer quelles informations seront republiées dans le Bus Orchestrator, afin d’être ensuite réutilisées par d’autres activités. Nous n’en rajouterons pas dans cet exemple, mais il est tout à fait possible d’imaginer publier l’ID et le contenu de l’évenement, par exemple.

Cliquer sur OK.

clip_image020

Cliquer sur Next

clip_image022

L’assembly compile…

clip_image024

Voilà, c’est compilé. L’assistant propose de passer directement au packaging de l’Integration Pack, mais il est préférable de commencer par tester notre assembly afin de s’assurer qu’elle fonctionne comme souhaité.

Cliquer sur Finish.

clip_image026

Lancer le Runbook Designer, créer un nouveau runbook et y ajouter les activités Initialize Data et Invoke .NET. Cette dernière est disponible grâce à l’Integration Toolkit importé en début d’article et permet d’exécuter une assembly au format dll comme s’il s’agissait d’un OIP finalisé et packagé, ce qui permet donc de la tester rapidement.

clip_image028

Ouvrir les propriétés de l’activité Invoke .NET. Dans le champ Assembly, sélectionner la dll de l’assembly préalablement crée. Dans Class, sélectionner la class correspondante (dans notre exemple il n’y en a qu’une). Laisser Setup vide (ce champ ne sert que pour les classes développées à l’aide du SDK).

clip_image030

Dans l’onglet Properties, remplir les paramètres de l’activité puis cliquer sur Finish.

clip_image032

Attention ! Il est nécessaire que le journal d’événement ainsi que la source indiqués soient déjà enregistrés sur l’ordinateur cible ! Au besoin, il est possible de les créer à l’aide du PowerShell suivant :
New-EventLog -logname $JournalDevenement -Source $Source -ComputerName $ComputerName -ErrorVariable Err

Dans l’exemple ci-dessus, le journal utilisé est Application (présent par défaut) et la source est TestOIP (n’existe pas d’origine). Nous la créons donc ainsi :
New-EventLog -LogName "Application" -ComputerName "localhost" -source "TestOIP" -ErrorVariable Err

clip_image034

 

Lancer le Runbook Tester et cliquer sur Run.

clip_image036

Si tout s’est bien passé, voilà ce qui doit apparaitre dans l’Event Viewer :

clip_image038

Voilà, le « moteur » de notre Integration Pack fonctionne. Il ne reste plus qu’à le packager pour pouvoir le déployer sous forme d’OIP à notre infrastructure Orchestrator, ce que nous aborderons dans la seconde partie.

Utiliser la console Web de SCOM 2012 sous Windows XP

 

Microsoft ayant pris la décision de ne pas assurer la compatibilité de la console “lourde” SCOM 2012 avec Windows XP, il n’est plus possible de l’installer sur des ordinateurs exécutant encore ce système.

Toutefois, il peut toujours s’avérer nécessaire d’accéder à une console SCOM 2012 depuis un de ces ordinateurs et pour ce faire, la console Web semble être une solution parfaitement adaptée.

Malheureusement, une nouvelle mauvaise surprise vous attend : après avoir installé l’extension Silverlight SilvelightClientConfiguration.exe (proposée automatiquement à la première connexion) et tenté d’ouvrir une session, le message d’erreur suivant vous accueille et la console ne se charge pas :

The procedure entry point LocaleNameToLCID could not be located in the dynamic link library Kernel32.dll.

Cette erreur se produit car l’API LocaleNameToLCID n’est présente dans Kernel32.dll qu’à partir de Windows Vista (cf. http://msdn.microsoft.com/en-us/library/windows/desktop/dd318711%28v=vs.85%29.aspx ). Décidemment, cette console refuse de s’ouvrir sous Windows XP…

A l’aide de l’outil Procmon, on constate que SilverlightClientConfiguration.exe doit normalement créer des entrées dans la base de registre, correspondant à des certificats propres à SCOM 2012 et SCOM 2012 UR1 respectivement.

Il est donc possible de contourner le problème en important directement ces entrées dans la base de registre via le fichier OM2012WebConsoleFix.reg (disponible ici : http://blogs.technet.com/b/mihai/archive/2012/05/08/making-the-om-2012-web-console-accessible-from-a-windows-xp-client.aspx ), sans passer par SilverlightClientConfiguration.exe.

Il est cependant vraisemblable que les futures mises à jour de la console Web induiront des certificats différents.
Afin de pouvoir les retrouver (sur un client Vista ou supérieur) pour les exporter et les réimporter sur vos clients Windows XP, il est intéressant de noter que la clé de registre utilisée est HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Silverlight pour les Windows 64bits et HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Silverlight pour le Windows 32bits ainsi que HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\TrustedPublisher\Certificates\19F8F76F4655074509769C20349FFAECCECD217D dans tous les cas.

Une fois cette modification apportée au registre, la console Web SCOM 2012 est accessible sans avoir besoin d’installer SilverlightClientConfiguration.exe ni nécessiter de redémarrage.