Intégration avec System Center Operations Manager

fournies dans les Management Packs et le second permet de transférer les alertes afin de générer automatiquement des incidents. Nous allons commencer par synchroniser l’inventaire SCOM.

Connecteur d’inventaire SCOM

La première étape consiste à importer un ensemble de Management Packs afin que SCSM dispose de la définition des classes d’objets découverts par SCOM. Pour cela, lancez Powershell en tant qu’administrateur sur le Serveur de Gestion SCSM et taper les commandes suivantes :

Get-ExecutionPolicy (noter le résultat)
Set-ExecutionPolicy Unrestricted
Set-Location \"Program Files\Microsoft System Center\Service Manager
2010\Operations Manager Management Packs"
.\installOMMPs.ps1
Set-ExecutionPolicy RemoteSigned (valeur notée lors de la première
commande)
Exit

Nous venons d’importer les Management Packs « par défaut » de SCOM. Si vous avez importé d’autres Management Packs dans votre environnement SCOM, il sera nécessaire de les importer également dans SCSM afin d’étendre l’inventaire aux classes contenues dans ces derniers. Nous allons ensuite créer le connecteur. Pour cela ouvrir la console SCSM avec un compte administrateur, aller dans le panneau Administration, sélectionner Connectors puis dans la liste de tâches à droite de l’écran sélectionner Create Connector puis Operations Manager CI Connector. L’assistant de configuration du connecteur vous permet ensuite de définir le Root Management Server (RMS) SCOM auquel se connecter, de définir un compte d’action pour se connecter au RMS, de sélectionner les Management Pack à synchroniser et par conséquent les classes d’objets à synchroniser et finalement la fréquence de synchronisation (nul besoin d’une fréquence élevée, l’inventaire SCOM est peu variant).

Une fois le connecteur créé, une première synchronisation est initiée automatiquement. Les objets de base sont ensuite visibles dans le panneau Configuration Items. Nous allons maintenant ajouter les bases SQL détectées par SCOM dans notre CMDB. Pour cela, il faut :

• Importer le Management Pack SQL dans SCSM
• Modifier notre connecteur afin de prendre en compte le Management Pack SQL
• Relancer une synchronisation

Une fois cette configuration faite, les nouveaux objets sont synchronisés dans la CMDB. Pour les afficher, nous devons créer une nouvelle vue dans ce dernier et afficher par exemple les objets de type SQL Database.

Connecteur d’alerte SCOM

Nous allons maintenant tester le second type de connecteur SCOM, le connecteur d’alerte. De la même manière que précédemment, créez un nouveau connecteur mais cette fois-ci sélectionnez Operations Manager Alert Connector. L’assistant nous permet de la même façon de choisir le RMS SCOM auquel se connecter et de sélectionner le compte d’action utilisé pour cette connexion. Nous avons également la possibilité de créer des règles afin de rediriger les alertes SCOM vers différents modèles d’incident SCSM. Nous utiliserons le modèle d’incident par défaut pour les alertes SCOM. Finalement nous configurons notre connecteur afin que la synchronisation soit bidirectionnelle (Clore l’alerte SCOM ferme l’incident SCSM et vice-versa).

Une fois le connecteur créé dans la console SCSM nous devons configurer SCOM. Pour cela, ouvrir la console SCOMavec un compte administrateur, aller dans le panneau Administration puis Product Connectors, Internal Connectors. Un nouveau connecteur doit être présent avec comme nom Alert Sync :. Faire un clic-droit et sélectionner Propriétés. Ici nous allons configurer un abonnement à l’identique des abonnements de notifications SCOM. Il est ainsi possible de filtrer les alertes transférées à SCSM. Dans notre exemple, nous n’enverrons que les alertes critiques concernant SQL Server.

Afin de tester le connecteur d’alerte, nous allons arrêter l’agent SQL sur un des serveurs SQL supervisés par SCOM. Une alerte est ainsi générée dans la console SCOM. Et un incident est automatiquement créé dans SCSM.

Remarque : Le connecteur d’alerte est à utiliser une fois votre environnement SCOM parfaitement configuré. Dans le cas contraire, un trop plein d’alertes submergerait le Helpdesk d’incidents non pertinents.