System Center

Windows PowerShell dans System Center Operations Manager

Marco Shaw

 

En un coup d'œil :

• Interface de commande Operations Manager
• Fournisseur d'analyse Operations Manager
• Automation de tâches administratives courantes
• Quelques exemples réels Windows PowerShell

Sommaire

Interface de commande Operations Manager
Fournisseur d'analyse Operations Manager
Automation de tâches courantes
Le monde réel
Conclusion

System Center Operations Manager 2007 (OpsMgr) permet aux administrateurs d'accéder à Windows PowerShell, un nouveau puissant langage de script pour l'automation de tâches. Présenté au public en novembre 2006, il a été téléchargé plus de deux millions de fois depuis.

Dans cet article, je parlerai de Windows PowerShell® et de comment il s'applique à Operations Manager. J'indiquerai quelques unes des tâches courantes que Windows PowerShell vous aidera à exécuter beaucoup plus facilement et de manière plus automatisée. J'indiquerai également certains sites Web qui fournissent des scripts et des explications utiles. J'ai rassemblé des conseils et blogs de nombreux experts qui utilisent Windows PowerShell.

Bien que Microsoft ait commencé le lancement des versions CTP de Windows PowerShell 2.0, ces versions ne sont pas prêtes pour l'intégration à la production, elles n'ont pas été mises à l'essai avec Operations Manager et ne doivent pas être installées sur un système de production.

Interface de commande Operations Manager

Dans Operations Manager, vous accédez à Windows PowerShell par l'interface de commande, qui est similaire à l'environnement de Windows PowerShell par défaut, sauf qu'elle charge un fichier de console de même qu'un script qui initialise l'environnement avec des applets de commande et des fonctions d'Operations Manager et une connexion par défaut.

Vous pouvez démarrer l'interface de commande à partir d'une icône dans le menu Démarrer d'Operations Manager ou en cliquant, avec le bouton droit de la souris, sur un nom d'ordinateur dans la console d'interface utilisateur d'Operations Manager (voir figure 1). Ceci vous mène directement au chemin de lecteur d'analyse d'Operations Manager (que j'aborderai bientôt).

Figure 1 Ouverture de l'interface de commande à partir de l'interface utilisateur d'Operations Manager (cliquez sur l'image pour l'agrandir)

Windows PowerShell s'intègre à Operations Manager grâce au kit de développement logiciel d'Operations Manager. Heureusement pour les administrateurs, des applets de commande ont déjà été prévues pour la plupart des tâches que vous souhaiteriez automatiser ou terminer depuis une ligne de commande. S'il n'y a pas d'applets de commande pour une tâche particulière, vous pouvez utiliser Windows PowerShell pour interagir avec le SDK.

Les commandes fournies par l'interface de commande d'Operations Manager sont contenues dans un logiciel enfichable, une DLL (bibliothèque de liens dynamiques) chargée par Windows PowerShell qui contient des applets de commande pour l'administration d'Operations Manager. Le composant logiciel enfichable inclut également le fournisseur Windows PowerShell d'analyse d'Operations Manager. Également connu comme le fournisseur d'analyse, cet outil permet d'accéder à des connexions, groupes et objets d'analyse, ce qui ressemble beaucoup à la navigation dans un système de fichiers.

Vous pouvez obtenir une liste de toutes les applets de commande spécifiques à Operations Manager en utilisant l'applet de commande Get-OperationsManager­Command, comme illustré à la figure 2. (Dans la première version, cette fonction ne prenait pas en charge la tabulation. Elle est devenue une applet de commande dans la version SP1.) La version originale d'Operations Manager comprenait 74 applets de commande, alors qu'Operations Manager SP1 en compte 87.

Figure 2 Obtenir une liste des applets de commande d'Operations Manager (cliquez sur l'image pour l'agrandir)

Fournisseur d'analyse d'Operations Manager

En utilisant l'applet de commande Set-Location (ou son alias "cd") vous pouvez naviguer dans la disposition des groupes et des ordinateurs. La disposition de base du lecteur d'analyse (Monitoringdrive) par défaut ressemble à ce qui suit :

Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)

À partir de là, vous pouvez avoir des objets plus spécifiques. Notez que le cas que nous analysons ici est simple et qu'il ne comprend qu'un seul serveur d'administration. Le premier serveur d'administration installé dans un groupe d'administration est connu sous le nom de serveur d'administration racine (RMS).

Lorsque vous démarrez l'interface de commande, celle-ci créé un lecteur nommé Monitoring (analyse), mappe le lecteur vers le fournisseur d'analyse d'Operations Manager et définit le chemin vers la racine du lecteur d'analyse. L'interface de commande recherche alors le registre pour le nom du RMS par défaut auquel se connecter. Si la connexion au RMS réussit, l'emplacement ou le chemin actuel est attribué au nom de la connexion, ou RMS, comme illustré à la figure 3.

Figure 3 L'emplacement de l'interface de commande est défini sur le RMS (cliquez sur l'image pour l'agrandir)

Automation des tâches courantes

Voyons comment Windows PowerShell peut gérer quelques unes des tâches administratives les plus courantes.

Gestion du mode de maintenance Quelle que soit la tâche que vous devez exécuter, vous voudrez probablement spécifier la date et l'heure à laquelle elle doit être exécutée. Observons rapidement l'applet de commande Get-Date : vous verrez à quel point cette opération est facile. La figure 4 illustre quelques exemples.

Figure 4 Utilisation de l'applet de commande Get-Date (cliquez sur l'image pour l'agrandir)

Comme vous pouvez le constater, j'ai créé une variable $date qui contient un objet représentant l'heure actuelle. Ensuite, j'ai utilisé quelques méthodes documentées et prises en charge par l'objet pour illustrer comment vous pouvez facilement obtenir la date et l'heure cinq minutes plus tard, puis cinq heures plus tard. Si je voulais obtenir des valeurs du passé, j'utiliserais simplement (-5) au lieu de (5).

Lorsque vous devez bloquer toutes les alertes venant d'un ordinateur, vous pouvez activer le mode de maintenance. Operations Manager 2007 vous permet de mettre en mode de maintenance un service Windows®, ou même une base de données en particulier, au lieu d'un ordinateur ou d'un groupe entier. Il existe trois applets de commande qui gèrent tout particulièrement des tâches du mode de maintenance : Get-MaintenanceWindow, New-MaintenanceWindow et Set-MaintenanceWindow.

Pour mettre un ordinateur en mode de maintenance depuis l'interface de commande, accédez à l'ordinateur ou l'objet d'analyse souhaité en utilisant le fournisseur d'analyse et invoquez l'applet de commande New-MaintenanceWindow, comme illustré à la figure 5. Comme vous pouvez le voir, cette action met l'ordinateur nommé Denver.contoso.com en mode de maintenance. J'ai également défini l'heure de démarrage de la fenêtre de maintenance à l'heure actuelle et l'heure de fin dans exactement une heure. Notez que, mettre un ordinateur en mode de maintenance avec cette méthode ne permet pas d'annuler toutes les alertes puisque les instances HealthService et HealthService­Watcher sont toujours activées.

Figure 5 Utilisation de l'applet de commande New-MaintenanceWindow (cliquez sur l'image pour l'agrandir)

Boris Yanushpolsky, responsable de programme de l'équipe Microsoft Operations Manager, a donné un code Windows PowerShell très utile que l'on peut utiliser pour définir tous les objets relatifs à un ordinateur en mode de maintenance. Il a, en outre, expliqué comment l'utiliser une fois que vous avez créé un script. Pour davantage d'informations à ce sujet, lisez son blog à l'adresse blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.

Parfois vous devez déterminer si des objets qui sont en mode de maintenance ne doivent pas l'être. Mais parcourir tous les objets pour résoudre cette question peut s'avérer difficile. Heureusement, encore une fois, Boris Yanushpolsky nous propose une solution avec un script de Windows PowerShell qui utilise le kit de développement logiciel d'Operations Manager. Vous pouvez copier le code directement depuis son blog (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) et le coller dans une fenêtre de l'interface de commande pour obtenir une liste de tous les objets en mode de maintenance.

Lorsqu'un objet est en mode de maintenance, vous pouvez vouloir terminer la période de maintenance avant l'heure de fin spécifiée à l'origine. Si vous connaissez un peu Windows PowerShell, vous vous attendez peut-être à une applet de commande avec un verbe d'arrêt ou d'élimination. En réalité, vous devez utiliser Set-MaintenanceWindow, comme illustré à la figure 6.

Figure 6 Utilisation de Set-MaintenanceWindow pour modifier l'heure de fin (cliquez sur l'image pour l'agrandir)

Gestion des agents Souvent, les administrateurs travaillent avec des agents et il existe six applets de commande et une fonction (depuis la version originale) qui traitent les différentes tâches relatives aux agents. Vous pouvez en obtenir une liste avec cette commande :

Get-Command *-agent*

Depuis la version SP1, Install-AgentBy­Name n'est plus empaqueté sous forme de fonction, mais d'applet de commande. Il est recommandé d'utiliser l'applet de commande d'Install-AgentByName car il constitue une meilleure base pour la prise en charge et la cohérence.

L'aide intégrée à l'interface de commande offre quelques exemples intéressants d'utilisation des applets de commande Install-Agent et Uninstall-Agent. Roger Sprague, ingénieur logiciel senior au sein de l'équipe Microsoft Operations Manager, a publié sur son blog une méthode alternative illustrée à la figure 7 (voir le message de blog original à l'adresse blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).

Ce script fonctionne correctement avec la version RTM d'Operations Manager (vous devez vous trouver dans la racine du fournisseur d'analyse. Dans cet article, \oxford.contoso.com), mais il ne marche pas avec Operations Manager SP1. Pour le faire fonctionner avec Operations Manager SP1, il faut modifier la première commande de la figure 7 comme suit :

 $managementServer = Get-RootManagementServer

Figure 7 Installation d'un agent

# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects

À ce stade, l'agent est installé sur le système distant devant être analysé, mais il y a encore une étape à franchir : le serveur de gestion doit accepter le nouvel agent pour que l'analyse complète puisse avoir lieu. Si aucune autre action n'est effectuée, le serveur d'analyse accepte automatiquement le nouvel agent pour l'analyse. Mais il est possible d'accélérer ce processus d'acceptation en utilisant l'applet de commande Get-AgentPendingAction. Cette applet de commande uniligne accélère le processus d'acceptation de l'agent :

Get-AgentPendingAction | Where Object {$_.AgentName –like 
'computer*'} | Approve-AgentPendingAction

En canalisant le processus vers Reject-AgentPending­Action au lieu d’Approve-AgentPending Action, si l'action est encore en suspens vous pouvez bloquer l'acceptation de cet agent par le serveur Operations Manager. Si elle n'est pas en suspens, utilisez l'applet de commande Uninstall-Agent.

Comme je l'ai dit, vous pouvez également utiliser Install-­AgentByName pour spécifier un ordinateur directement à la ligne de commande sur laquelle doit être installé l'agent.

Utilisation de packs d'administration Il y a quatre applets de commande qui vous aideront à gérer les différentes tâches des packs d'administration. Vous pouvez en obtenir une liste comme indiqué ci-après :

Get-Command –noun ManagementPack

Cette commande simple fournit les packs d'administration actuellement installés et leurs numéros de version :

Get-ManagementPack | Format-Table –autosize

Maintenant, j'utiliserai l'interface de commande pour installer deux packs d'administration courants en utilisant ces programmes d'installation :

• Internet Information Services System Center Operations Manager2007 Management Pack.msi
• Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.

Puisque mon objectif ici est de montrer comment l'interface de commande peut faciliter différentes tâches, j'utiliserai le moins de commandes possible (comme illustré à la figure 8). J'aurais pu modifier cette procédure d'installation pour transmettre l'option de fermeture au programme d'installation (les fichiers .msi), mais j'ai voulu sélectionner l'emplacement où les fichiers seront extraits manuellement.

Figure 8 Installer des packs d'administration (cliquez sur l'image pour l'agrandir)

Ensuite, je dois installer les bibliothèques communes, ce que je peux faire comme suit :

Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}

Puis, j'installe les autres packs d'administration requis :

Get-ChildItem –Path C:\MPs –filter *200?.mp | 
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}

Comme le montre la figure 9, l'aide intégrée à l'interface de commande est un parfait exemple de l'utilisation de l'applet de commande Export-ManagementPack pour exporter des packs d'administration descellés. Si vous souhaitez exporter tous les packs d'administration, modifiez cette ligne

 $mps=Get-ManagementPack | 
Where-Object {$_.Sealed –eq $false} 

 $mps=Get-ManagementPack

Figure 9 Exportation d'un pack d'administration (cliquez sur l'image pour l'agrandir)

Manipulation des rôles d'utilisateur L'applet de commande Get-UserRole offre quelques fonctionnalités permettant d'administrer des utilisateurs, mais, curieusement, il n'est pas accompagné d'un applet de commande Set supplémentaire et, normalement, il n'est pas utilisé pour faire des modifications ni des mises à jour (selon la documentation du kit de développement logiciel de Windows PowerShell). Comme vous pouvez le voir à la figure 10, j'obtiens d'abord une liste des rôles d'utilisateur actuels, puis j'ajoute un utilisateur au groupe des opérateurs en lecture seule (voir figure 11).

Figure 10 Afficher des rôles d'utilisateur (cliquez sur l'image pour l'agrandir)

Figure 11 Ajouter un utilisateur (cliquez sur l'image pour l'agrandir)

Activer Audit Collection Services (ACS) L'ACS est une nouvelle fonction facultative d'Operations Manager 2007 qui fournit une méthode centralisée de gestion des informations sur l'audit de sécurité. L'ACS n'est pas activé par défaut et, généralement, il faudra le configurer durant une phase de déploiement ultérieure d'Operations Manager.

Lorsqu'il faut activer un grand nombre d'agents pour l'ACS, Windows PowerShell peut faciliter l'automatisation de la configuration. Quand la version bêta d'Operations Manager est sortie, Microsoft a fourni un script pour activer l'ACS sur tous les agents. Neale Browne, collaborateur et blogueur pour SystemCenterForum.org, est allé plus loin en ajoutant la prise en charge de paramètres supplémentaires.

Le site SystemCenterForum.org (un site communautaire qui fournit des solutions Microsoft® System Center) a produit deux scripts Windows PowerShell différents pour automatiser la configuration de l'ACS. Pour configurer tous les agents dans un groupe particulier, utilisez systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Pour configurer tous les agents analysés, téléchargez systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip.

Activer le proxy d'agent Votre environnement Operations Manager peut inclure des périphériques analysés sans agent. Ces périphériques doivent être attribués à un serveur d'administration ou à un périphérique administré par agent qui assurera l'analyse à distance. Vous trouverez une description détaillée de l'utilisation du script Windows PowerShell pour configurer un grand nombre d'agents à l'adresse systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell. Une version mise à jour du script est disponible à l'adresse systemcenterforum.org/wp-content/uploads/Set­AgentProxyBulk_FQDN.zip.

Il existe d'autres conditions dans lesquelles certains packs d'administration nécessitent qu'un agent soit configuré pour servir également de proxy. Pour plus de détails, consultez la documentation du pack d'administration.

Le monde réel

Voici quelques exemples pratiques illustrant comment Windows PowerShell peut faciliter l'automation.

Résoudre des alertes Vous avez certainement déjà dû effacer plusieurs alertes sur un ordinateur. Peut-être y a-t-il eu un problème avec une application ou les alertes n'avaient pas été résolues. Voici une commande uniligne qui résoudra toutes les alertes avec un état de résolution zéro :

Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null

Dans l'exemple suivant, le résultat obtenu est identique, sauf que la commande s'exécute beaucoup plus rapidement dans un environnement plus grand et un nombre plus grand d'alertes :

Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null

La différence de performance est due au fait que, lors de l'utilisation du paramètre de critère, la valeur transmise est communiquée directement à la base de données SQL Server® et que seules les données pertinentes sont renvoyées. Ceci réduit le nombre d'objets qui doivent être retransmis à la console Windows PowerShell.

Maintenant, vous disposez d'une façon rapide de supprimer toutes les alertes en suspens sur un ordinateur. Selon vos besoins, vous pouvez configurer l'exécution automatique.

Enfin, vous disposez d'une commande rapide qui vous permet d'afficher toutes les alertes pour un jour spécifique :

Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''

Vous pouvez modifier très facilement la valeur de date et rediriger la sortie vers l'applet de commande Resolve-Alert.

Test d'alertes Parfois vous souhaitez surveiller certains événements dans l'Observateur d'événements Windows et les tester. Ces deux lignes créent rapidement une entrée dans le journal des événements :

 $api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")

Par défaut, cependant, cette opération enregistrera l'entrée dans le journal des événements d'Operations Manager, qui n'est probablement pas l'endroit où vous cherchez les événements enregistrés. Heureusement, Stefan Stranger, ingénieur de terrain principal chez Microsoft, a écrit un script qui permet de créer des événements dans l'Observateur d'événements. Ce script offre donc une plus grande flexibilité en permettant d'enregistrer dans un journal spécifique. Vous trouverez le script à l'adresse go.microsoft.com/fwlink/?LinkId=120308. (Stefan a empaqueté le script dans un fichier .cab. Vous devrez télécharger le fichier, puis cliquer dessus avec le bouton droit de la souris pour extraire le script).

La seule chose à remarquer, avec le script de Stefan, est que la valeur entrée pour la source d'événement détermine sur quel journal l'entrée sera écrite. Peut-être la façon la plus facile pour assurer qu'une alerte est dirigée vers le bon journal est d'ouvrir l'Observateur d'événements de Windows et rechercher la source de la dernière entrée.

Définir le propriétaire Parfois, il peut être utile de définir automatiquement le propriétaire d'une alerte. Voici une façon simple de le faire à partir de l'interface de commande :

 $alert = Get-Alert 
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")

La première ligne de ce code obtient l'ID d'un objet événement spécifique et le transmet à la variable $alert. Dans la deuxième ligne, cette variable est utilisée pour définir le propriétaire, et, enfin, la mise à jour est appliquée à la base de données d'Operations Manager. Si vous vérifiez le propriétaire de l'alerte avec la commande suivante, vous verrez qu'il a changé :

Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner

Pour définir le propriétaire pour une série entière d'alertes, vous pouvez simplifier le code comme ceci :

Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}

Restaurer l'état d'analyse Il est probable que vous ayez déjà rencontré des agents dont l'état était « non analysé ». Dans ce cas, vous devrez peut-être restaurer rapidement l'état d'analyse complète de tous les agents, puis essayer de comprendre ce qui s'est passé. L'exécution du script à la figure 12 directement depuis l'interface de commande devrait restaurer l'état d'analyse complète de tous les agents concernés.

Figure 12 Réinitialisation du magasin du service de contrôle d'intégrité

 $all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}

Examinez le code de la figure 12. Après avoir déclaré une variable, j'obtiens une liste de tous les agents de ce RMS et j'applique un filtre aux éléments qui semblent poser problème. Ensuite, j'appelle de manière asynchrone une tâche qui réinitialise le magasin du service de contrôle d'intégrité sur tous les agents de la liste filtrée.

Associer des alertes à des packs d'administration La figure 13 illustre comment obtenir une liste de toutes les nouvelles alertes ainsi que le pack d'administration associé à chacune d'entre elles.

Quelques astuces étaient requises pour que le code puisse résoudre tous les noms de pack d'administration. Les applets de commande varient selon que l'alerte provient d'une règle ou d'un moniteur. (Remarquez que, à la figure 13, j'ai dû implémenter une petite solution de contournement pour l'applet de commande Get-Monitor. Depuis Operations Manager SP1, l'applet de commande prend en charge un nouveau paramètre d'ID qui simplifie légèrement le code).

Figure 13 Rechercher le pack d'administration

Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }  
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}

Création facile d'un rapport Lorsque vous mettez à jour votre environnement, il peut être utile d'auditer la version de tous les agents installés. Il suffit d'un simple script pour imprimer un rapport en bonne et due forme :

Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}

La figure 14 illustre la sortie générée par le script. Ce script est une version développée des exemples indiqués ici systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.

Figure 14 Sortie indiquant la version de certains agents (cliquez sur l'image pour l'agrandir)

Planifier une tâche Vous souhaitez peut-être exécuter régulièrement un script Windows PowerShell. Imaginons que vous utilisez un ordinateur client pour vous connecter et gérer votre serveur Operations Manager et que les outils d'administration d'Operations Manager sont installés localement. Supposons aussi que vous souhaitiez exécuter le rapport de version d'agent tous les jours et enregistrer la sortie dans un fichier dont le nom sera la date actuelle. Vous pouvez utiliser le planificateur des tâches intégré de Windows pour exécuter le script depuis votre ordinateur local.

Pour cela, il vous suffit de définir une nouvelle tâche en utilisant le programme powershell.exe (généralement situé dans C:\Windows\System32\WindowsPowerShell\v1.0). Après avoir créé la tâche, éditez-la et configurez la commande pour que l'exécution ressemble à ce qui suit :

C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe 
  –Command "& {& 'c:\agent_report2.ps1'}"

Il s'est avéré qu'un grand nombre de modifications du code Windows PowerShell d'origine étaient nécessaires, comme vous pouvez le voir à la figure 15. J'ai dû ajouter le composant logiciel enfichable Operations Manager PowerShell, créer un lecteur d'analyse mappé sur le fournisseur Operations­ManagerMonitoring et créer une connexion au RMS. Je charge également le script personnalisé Ops­Mgr de Windows PowerShell (Microsoft.Enterprise­Management.OperationsManager.ClientShell.Startup.ps1) pour charger des fonctions spécifiques d'Operations Manager.

Figure 15 Planification du script de version d'agent

Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file

Mais ce n'est pas tout. Vous remarquerez peut-être que, à chaque fois que vous exécutez le programme, une fenêtre de console noire surgit à l'écran comme si quelqu'un était connecté au système sur lequel le script est exécuté. Vous trouverez une petite astuce qui vous permettra de résoudre cela. Elle nous est offerte par Don Jones et Jeffery Hicks de Sapien à l'adresse suivante : blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell.

Essentiellement, vous devez encapsuler le script dans un VBScript. Pour cela, utilisez un code comme celui de la figure 16 au lieu d'appeler ce qui suit à partir de votre tâche planifiée :

C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"

Figure 16 Masquer les fenêtres publicitaires

Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths 
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34) 

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0

La tâche utilise alors le programme wscript.exe et l'appel ressemble à ceci :

C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs 

Enfin, je peux créer des rapports automatisés. Le processus sera alors masqué pour les utilisateurs connectés.

Conclusion

Nous n'avons parcouru que très rapidement les fonctions d'automation d'Operations Manager 2007. Tout ceci n'est qu'un avant-goût de ce que vous pouvez demander à Windows PowerShell pour l'administration Operations Manager.

J'aimerais remercier toutes les personnes mentionnées dans cet article ainsi que Pete Zerger, fondateur de SystemCenterForum org.et MVP MOM, pour leur aide précieuse.

Marco Shaw est analyste systèmes informatiques pour une entreprise de télécommunications canadienne. Il travaille dans le secteur informatique depuis plus de 10 ans et a récemment reçu la récompense MVP Windows PowerShell. Marco est également directeur adjoint du nouveau site Web communautaire PowerShell à l'adresse powershellcommunity org. Vous trouverez son blog à l'adresse marcoshaw.blogspot.com.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. La reproduction partielle ou totale sans autorisation est interdite.