System Center

System Center Operations Manager で Windows PowerShell を使用する

Marco Shaw

概要 :

• OpsMgr のコマンド シェル
• OpsMgr の Monitoring プロバイダ
• 一般的な管理タスクの自動化
• Windows PowerShell の実例

Operations Manager のコマンド シェル
OpsMgr の Monitoring プロバイダ
一般的なタスクを自動化する
実際の使用例
まとめ

管理者は System Center Operations Manager 2007 (OpsMgr) で、タスクを自動化するための強力な新しいスクリプト言語である Windows PowerShell を利用できます。Windows PowerShell は、2006 年 11 月のリリース以来 200 万回以上ダウンロードされています。

この記事では、Windows PowerShell® について、および Windows PowerShell を Operations Manager で使用する方法について説明します。また、Windows PowerShell を使用することによってはるかに簡単かつ自動化された方法で実行できる一般的なタスクの一部を取り上げ、便利なスクリプトや説明が提供される Web サイトもいくつか紹介します。現在 Windows PowerShell を使用している多くの専門家からの意見やブログ記事を集めました。

マイクロソフトから Windows PowerShell 2.0 の Community Technology Preview (CTP) 版がリリースされていますが、CTP 版は運用環境で使用する準備が整っておらず、OpsMgr でもテストされていないので、運用システムにはインストールしないようにしてください。

Operations Manager のコマンド シェル

OpsMgr では、コマンド シェルを使用して Windows PowerShell にアクセスします。コマンド シェルは既定の Windows PowerShell 環境に似ていますが、コンソール ファイルを読み込んだり、OpsMgr のコマンドレット、関数、および既定の接続によって環境を初期化するスクリプトを読み込んだりする点が異なります。

コマンド シェルは、[スタート] メニューで提供される OpsMgr のアイコンから起動するか、OpsMgr の UI コンソールでコンピュータ名を右クリックして起動できます (図 1 参照)。コマンド シェルを起動すると、直接 OpsMgr の Monitoring ドライブのパス (後で簡単に説明します) に移動します。

図 1 OpsMgr の UI から起動できるコマンド シェル (画像をクリックすると拡大表示されます)

Windows PowerShell は OpsMgr SDK を介して OpsMgr と対話します。管理者にとって幸運なことに、自動化したりコマンド ラインから実行したりすることが多いタスクの大部分を実行できるコマンドレットが既に提供されています。特定のタスクを実行するためのコマンドレットが提供されていない場合は、Windows PowerShell を使用して SDK と対話できます。

Operations Manager のコマンド シェルで提供されるコマンドはスナップインに含まれています。このスナップインは Windows PowerShell によって読み込まれる DLL で、OpsMgr の管理用コマンドレットを含んでいます。また、このスナップインには OperationsManagerMonitoring という Windows PowerShell プロバイダも含まれています。Monitoring プロバイダとも呼ばれるこのツールを使用すると、ファイル システム内を移動するかのように、接続、グループ、および監視オブジェクト間を移動できます。

Get-OperationsManagerCommand コマンドレットを使用すると、図 2 のように、OpsMgr のみで使用できるコマンドレットの一覧を表示できます (最初のバージョンでは Get-OperationsManagerCommand が関数として提供されていたので、Tab キーによる補完機能はサポートされていませんでしたが、SP1 ではこの関数がコマンドレットとして提供されます)。Operations Manager の最初のリリースでは 74 種類のコマンドレットが提供されましたが、OpsMgr SP1 では 87 種類のコマンドレットが提供されます。

図 2 OpsMgr で使用できるコマンドレットの一覧表示 (画像をクリックすると拡大表示されます)

OpsMgr の Monitoring プロバイダ

Set-Location コマンドレット、またはそのエイリアスである cd を使用すると、グループやコンピュータの構造内を移動できます。既定の Monitoring ドライブの基本的な構造を次に示します。

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

この場所から、さらに具体的なオブジェクトにアクセスできます。今回は、管理サーバーを 1 台のみ使用する単純な環境を扱うことに注意してください。最初に管理グループにインストールされた管理サーバーは、ルート管理サーバー (RMS) と呼ばれます。

コマンド シェルの起動時に Monitoring という名前のドライブが作成され、このドライブが OperationsManagerMonitoring プロバイダのルートにマップされた後、現在の場所またはパスが Monitoring ドライブのルートに設定されます。続いて、接続先となる既定の RMS の名前がレジストリ内から検索されます。RMS への接続が成功すると、現在の場所またはパスが接続 (RMS) の名前に設定されます (図 3 参照)。

図 3 コマンド シェルの場所が RMS に設定された状態 (画像をクリックすると拡大表示されます)

一般的なタスクを自動化する

では、Windows PowerShell を使用して最も一般的ないくつかの管理タスクを実行する方法について説明します。

メンテナンス モードを制御する どのタスクを構成する場合でも、通常はそのタスクが実行される日時を指定する必要があります。ここでは、Get-Date コマンドレットの概要について説明し、日時の指定がどれぐらい簡単であるかを示します。図 4 の画面に表示されているいくつかの例をご覧ください。

図 4 Get-Date コマンドレットの使用 (画像をクリックすると拡大表示されます)

ご覧のとおり、この例では現在の時刻を表すオブジェクトを格納した $date 変数を作成しています。次に、このオブジェクトでサポートされており、ドキュメントで説明が提供されているメソッドを使用して簡単に 5 分後の日時を取得し、続いて 5 時間後の日時を取得しています。過去の値を取得するには、(5) の代わりに (-5) を使用するだけです。

コンピュータから出力されるすべてのアラートをブロックする必要がある場合は、メンテナンス モードを有効にします。OpsMgr 2007 を使用すると、コンピュータやグループ全体ではなく、Windows® サービスや特定のデータベースをメンテナンス モードに切り替えることができます。メンテナンス モードのタスクを実行することに特化したコマンドレットは 3 つあります。これらは、Get-MaintenanceWindow、New-MaintenanceWindow、および Set-MaintenanceWindow です。

コマンド シェル内からコンピュータをメンテナンス モードに切り替えるには、Monitoring プロバイダを使用して目的のコンピュータまたは監視オブジェクトに移動し、New-MaintenanceWindow コマンドレットを呼び出します (図 5 参照)。ご覧のとおり、この処理によって Denver.contoso.com というコンピュータがメンテナンス モードに切り替わります。また、メンテナンス モードがすぐに開始されるようにメンテナンス時間帯の開始時刻を設定し、ちょうど 1 時間後に終了するように終了時刻を設定します。この方法を使用してコンピュータをメンテナンス モードに切り替えても、すべてのアラートが出力されなくなるわけではありません。その理由は、このオブジェクトの HealthService インスタンスと HealthServiceWatcher インスタンスが引き続き有効になっているからです。

図 5 New-MaintenanceWindow コマンドレットの使用 (画像をクリックすると拡大表示されます)

マイクロソフトの OpsMgr チームでプログラム マネージャを務めている Boris Yanushpolsky によって、非常に便利な Windows PowerShell のコードが提供されています。このコードを使用すると、あるコンピュータに関連するすべてのオブジェクトをメンテナンス モードに切り替えることができます。彼は、スクリプトを作成した後にそのコードを使用する方法についても説明しています。詳細については、彼のブログ (blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx) を参照してください。

場合によっては、オブジェクトが不必要にメンテナンス モードに切り替わっていないかどうかを確認する必要があります。ただし、すべてのオブジェクトを順番に処理してこのことを確認するのは大変な作業になる可能性があります。さいわい、ここでも Boris Yanushpolsky が、OpsMgr SDK を使用する Windows PowerShell スクリプトによって助け船を出しています。彼のブログ記事 (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) から直接コードをコピーしてコマンド シェル ウィンドウに貼り付けると、メンテナンス モードになっているすべてのオブジェクトを一覧表示できます。

オブジェクトがメンテナンス モードになっている場合、最初に指定した終了時刻よりも早くメンテナンス期間を終了できます。Windows PowerShell に詳しい皆さんは動詞部分が stop や remove などのコマンドレットを予想するかもしれませんが、実際には Set-MaintenanceWindow を使用する必要があります (図 6 参照)。

図 6 Set-MaintenanceWindow を使用した終了時刻の変更 (画像をクリックすると拡大表示されます)

エージェントを管理する 管理者はかなり頻繁にエージェントを操作します。OpsMgr では、エージェントに関するさまざまなタスクを実行できる 6 つのコマンドレットと 1 つの関数 (リリース時点の状況です) が提供されます。次のコマンドを使用すると、これらのコマンドレットと関数の一覧を表示できます。

Get-Command *-agent*

SP1 のリリースでは、Install-AgentByName は関数ではなくコマンドレットとしてパッケージ化されています。優れたサポートと一貫性を提供するための基盤として、このコマンドレットを使用することをお勧めします。

コマンド シェルに組み込まれているヘルプでは、Install-Agent コマンドレットと Uninstall-Agent コマンドレットの使用方法がよくわかる例が提供されます。マイクロソフトの OpsMgr チームでシニア ソフトウェア デザイン エンジニアを務める Roger Sprague は、彼のブログで別の方法を紹介しています。図 7 はこのブログから引用したコードです (元の記事については、blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx を参照してください)。

このスクリプトは OpsMgr RTM では問題なく動作します (Monitoring プロバイダのルートに移動する必要があります。この記事の場合は monitoring:\oxford.contoso.com です) が、OpsMgr SP1 では失敗します。OpsMgr SP1 でこのスクリプトを動作させるには、図 7 の最初のコマンドを次のように変更する必要があります。

 $managementServer = Get-RootManagementServer

# 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

これでエージェントが監視対象のリモート システムにインストールされましたが、最後に手順が 1 つ残っています。完全にこのシステムを監視する前に、管理サーバーで実際に新しいエージェントを承認する必要があります。何も操作を行わなかった場合、新しいエージェントを監視に使用することが監視サーバーによって自動的に承認されます。ただし、Get-AgentPendingAction コマンドレットを使用すれば、この承認処理を高速に実行できます。これを行うには、次の 1 行のコードを使用します。

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

結果を Approve-AgentPendingAction ではなく Reject-AgentPendingAction に渡すと、承認が完了していない場合に、OpsMgr サーバーでこのエージェントの承認をブロックできます。承認が完了している場合は、代わりに Uninstall-Agent コマンドレットを使用します。

前述のように、Install-AgentByName を使用することによって、エージェントをインストールするコンピュータを直接コマンド ラインで指定することもできます。

管理パックを操作する さまざまな管理パックのタスクを実行するのに役立つコマンドレットが 4 つ提供されます。次のコマンドを使用すると、これらのコマンドレットを一覧表示できます。

Get-Command –noun ManagementPack

次の単純なコマンドを実行すると、現在インストールされている管理パックとそのバージョン番号が表示されます。

Get-ManagementPack | Format-Table –autosize

では、コマンド シェルで次のインストーラを使用して、2 つの一般的な管理パックをインストールしましょう。

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

この記事の目的は、コマンド シェルを使用すると通常のタスクをどれぐらい簡単に実行できるかを示すことなので、できる限り少数のコマンドを使用してインストールを実行します (図 8 参照)。このインストール処理を変更してインストーラ (.msi ファイル) に quiet フラグを渡すこともできますが、ここではファイルの展開先を手動で選択することにします。

図 8 管理パックのインストール (画像をクリックすると拡大表示されます)

次に、共通ライブラリをインストールします。これを行うには、次のコマンドを使用します。

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

続いて、必要なその他の管理パックをインストールします。

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

図 9 のように、コマンド シェルに組み込まれているヘルプでは、シールされていない管理パックを Export-ManagementPack コマンドレットを使用してエクスポートするすばらしい例が提供されます。すべての管理パックをエクスポートするには、次の行をその下に記載されている行のように変更します。

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

 $mps=Get-ManagementPack

図 9 管理パックのエクスポート (画像をクリックすると拡大表示されます)

ユーザー ロールを操作する Get-UserRole コマンドレットではユーザーを管理するための機能が提供されますが、奇妙なことに、対になる Set コマンドレットが提供されないので、通常はこのコマンドレットを使用して変更や更新を行うことはありません (この情報は Windows PowerShell SDK のドキュメントに記載されています)。図 10 のように、まず現在のユーザー ロールを一覧表示し、次にユーザーを読み取り専用オペレータのグループに追加します (図 11 参照)。

図 10 ユーザー ロールの表示 (画像をクリックすると拡大表示されます)

図 11 ユーザーの追加 (画像をクリックすると拡大表示されます)

監査コレクション サービス (ACS) を有効にする ACS は Operations Manager 2007 の新しいオプション機能です。簡単に説明すると、この機能を使用してセキュリティの監査情報を一元的に管理できます。ACS は既定で有効になっておらず、通常は OpsMgr の展開におけるその後の段階で構成されます。

ACS 用に多くのエージェントを有効にする場合は、Windows PowerShell を使用してセットアップを自動化すると便利です。OpsMgr のベータ版では、すべてのエージェントで ACS を有効にするためのスクリプトが提供されました。SystemCenterForum.org の寄稿者でありブログ執筆者でもある Neale Browne は、このスクリプトを強化して他のパラメータのサポートを追加しました。

SystemCenterForum.org サイト (Microsoft® System Center ソリューションを提供しているコミュニティ サイト) では、ACS のセットアップを自動化できる 2 つの Windows PowerShell スクリプトが公開されています。特定のグループに属するすべてのエージェントで ACS のセットアップを実行するには、systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip を使用します。また、監視しているすべてのエージェントで ACS のセットアップを実行するには、systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip を使用します。

エージェントのプロキシ処理を有効にする OpsMgr の環境では、エージェントレスでデバイスを監視する場合があります。このようなデバイスは、エージェントによって管理される、リモートで監視できるデバイスに割り当てるか、管理サーバーに割り当てる必要があります。Windows PowerShell スクリプトを使用して多くのエージェントを構成する方法の詳細については、systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell を参照してください。このスクリプトの更新版は、systemcenterforum.org/wp-content/uploads/SetAgentProxyBulk_FQDN.zip からダウンロードできます。

他にも、特定の管理パック用にエージェントをプロキシとして動作するように設定する必要が生じる場合があります。詳細については、管理パックのドキュメントを参照してください。

実際の使用例

このセクションではいくつかの実例を紹介し、Windows PowerShell がどれぐらい自動化に役立つかについてさらに詳しく説明します。

アラートを解決する 特定のコンピュータに設定された複数のアラートを削除することになった経験はあるでしょうか。この操作が必要になる状況としては、アプリケーションでエラーが発生した場合や、アラートが動的に解決されなかった場合が考えられます。次の 1 行のコマンドを使用すると、解決状態が 0 になっているすべてのアラートを解決できます。

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

次の例では最初の例と同じ処理を実行しますが、未解決のアラート数が多い大規模な環境では、実行速度がはるかに速くなります。

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

パフォーマンスが向上する理由は、criteria パラメータを使用すると、渡される値が直接 SQL Server® データベースに提供され、関連するデータのみが返されるからです。これによって、Windows PowerShell コンソールに返されるオブジェクトの数が減少します。

これで、1 つのコンピュータに設定されたすべての未解決のアラートを簡単に削除できるようになりました。必要に応じて、このコマンドが自動的に実行されるように設定することもできます。

最後に、特定の日付に設定されたすべてのアラートを表示できる簡単なコマンドを以下に示します。

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

日付値の変更は非常に簡単です。また、この出力を Resolve-Alert コマンドレットに渡すこともできます。

アラートをテストする Windows イベント ビューアで特定のイベントを監視し、それらのイベントに関するテストを実行することが必要になる場合があります。次の 2 行のコマンドを使用すると、簡単なイベント ログのエントリを作成できます。

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

ただし既定では、このエントリは Operations Manager のイベント ログに記録されます。このイベント ログは、特定のイベントの記録先として想定される場所ではないと思います。さいわい、マイクロソフトのプレミア フィールド エンジニアである Stefan Stranger によって、Windows イベント ビューアにイベントを作成できるスクリプトが提供されたので、さらに柔軟に特定のログへの記録を実行できるようになりました。このスクリプトについては、go.microsoft.com/fwlink/?LinkId=120308 を参照してください (このスクリプトは .cab ファイルにパッケージ化されているので、ファイルをダウンロードしたら、ファイルを右クリックしてスクリプトを展開する必要があります)。

Stefan のスクリプトについて唯一注意が必要な点は、イベント ソースとして入力された値によって、エントリの記録先となるログが決定されることです。アラートが適切なログに記録されたかどうかを確認するための最も簡単な方法は、Windows イベント ビューアを開いて最新のエントリのソースを確認することです。

担当者を設定する アラートの担当者を自動的に設定すると役立つ場合があります。コマンド シェルからこの設定を行うための単純な方法を次に示します。

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

このコードの 1 行目では、特定のアラートを表すオブジェクトの ID を取得して、$alert 変数に渡しています。2 行目では、変数を使用して担当者を設定し、最後の行では OpsMgr データベースに更新を適用しています。次のコマンドを使用してアラートの担当者を確認すると、担当者が変更されていることがわかります。

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

すべてのアラートに担当者を設定するには、次のようにコードを単純化します。

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

監視の状態を復元する "監視しない" 状態になっているエージェントに遭遇する場合があります。このような場合、すべてのエージェントを完全に監視されている状態にすばやく復元してから問題の内容を特定することが必要になる可能性があります。図 12 のスクリプトをコマンド シェルから直接実行すると、影響を受けるすべてのエージェントを、完全に監視されている状態に復元できます。

 $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
}

図 12 のコードをご覧ください。変数を宣言した後、この RMS 上で実行されているすべてのエージェントの一覧を取得し、問題が発生している可能性があるエージェントをフィルタ選択します。続いて非同期にタスクを呼び出し、このタスクで、フィルタ選択したすべてのエージェントの正常性サービス ストアをリセットします。

アラートと管理パックを関連付ける 図 13 は、すべての新しいアラートと、各アラートが関連付けられた管理パックの一覧を表示する方法を示しています。

すべての管理パック名を確実に解決するには、コードにいくつか工夫を施す必要がありました。アラートの発生元がルールとモニタのいずれであるかによって、使用するコマンドレットは異なります (図 13 では、Get-Monitor コマンドレット用のちょっとした回避策を実装する必要がありました。OpsMgr SP1 では、このコマンドレットで新しい ID パラメータがサポートされるようになったので、コードが若干単純になるはずです)。

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}
         }
   }
}

レポートを簡単に生成する 環境をアップグレードする場合、インストールされているすべてのバージョンのエージェントを監査すると役立つことがあります。次のような単純なスクリプトを実行するだけで、便利なレポートを出力できます。

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)"}
    }
  }
}

図 14 は、このスクリプトの出力を示しています。このスクリプトは、systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell で公開されている例を拡張したものです。

図 14 いくつかのバージョンのエージェントを示す出力 (画像をクリックすると拡大表示されます)

タスクをスケジュールする Windows PowerShell を定期的に実行することもできます。たとえば、OpsMgr サーバーを管理するためにクライアント コンピュータからそのサーバーに接続しており、OpsMgr の管理ツールをローカルにインストールしているとします。さらに、エージェントのバージョンを示すレポートを毎日実行し、現在の日付が名前に含まれたファイルに出力を保存する必要があるとします。このような場合、Windows に組み込まれているタスク スケジューラを使用して、スクリプトをローカル コンピュータから実行できます。

これを行うには、新しいタスクを作成し、実行するプログラムとして powershell.exe (通常の場所は C:\Windows\System32\WindowsPowerShell\v1.0) を設定するだけです。タスクを作成したら、そのタスクを編集し、次のような内容でコマンドが実行されるようにします。

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

結局、元の Windows PowerShell コードに多くの変更を加えることになりました (図 15 参照)。まず、OpsMgr の PowerShell スナップインを追加し、OperationsManagerMonitoring プロバイダにマップされた Monitoring ドライブを作成し、RMS への接続を作成する必要がありました。また、OpsMgr 用のカスタム Windows PowerShell スクリプト (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1) を読み込むことによって、OpsMgr のみで提供される機能を読み込む必要がありました。

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

ただし、他にも問題はあります。お気付きになると思いますが、このスクリプトを実行するシステムにユーザーがログオンしている場合、タスクが実行されるたびに黒いコンソール ウィンドウが表示されます。Sapien の Don Jones と Jeffery Hicks によって、この問題を解決するためのちょっとした工夫が施されました。詳細については、blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell を参照してください。

簡単に言えば、スクリプトを VBScript でラップする必要があります。これを行うには、スケジュールしたタスクから次のコードを呼び出す代わりに、図 16 のようなコードを使用します。

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

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

これで wscript.exe プログラムがタスクで使用されるようになったので、次の呼び出しを実行します。

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

これによって自動的にレポートを作成できるようになり、ログオンしているユーザーにその処理が表示されなくなります。

まとめ

この記事では、OpsMgr 2007 で使用できる新しい自動化機能について駆け足で説明しました。紹介できたのは、Windows PowerShell を使用して OpsMgr を管理する方法のほんの一部にすぎません。

この記事で紹介したすべての方々、および MOM MVP であり SystemCenterForum.org の創設者でもある Pete Zerger の貴重な協力に感謝します。

Marco Shaw は、カナダの電気通信企業に勤務する IT システム アナリストです。彼は IT 業界に 10 年以上携わっており、最近 Windows PowerShell の MVP を受賞しました。Marco は powershellcommunity.org で公開されている新しい PowerShell コミュニティ Web サイトのコミュニティ責任者補佐でもあります。彼のブログは marcoshaw.blogspot.com で公開されています。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved. 許可なしに一部または全体を複製することは禁止されています。