第3回 進化したPowerShell 2.0：Windows Server 2008 R2の真価（4/4 ページ）
イベンティング機能
PowerShell 2.0では.NETオブジェクトが発生させるイベントを捕捉できるようになった。このイベンティング機能を用いると、System.Timers名前空間に存在するTimerクラスなどを利用できるようになる。
Timerオブジェクトのイベントの確認PowerShell 2.0では.NETオブジェクトが発生させるイベントを捕捉できるようになった。
（1）New-Objectコマンドレットを用い、System.Timers名前空間にあるTimerクラスをインスタンス化（オブジェクトとして実体化）する。
（2）Get-Memberコマンドレットを用い、オブジェクトのメンバを表示する。
（3）従来から利用可能だったMemberTypeがMethod（メソッド）やProperty（プロパティ）のほかに、Event（イベント）が利用可能になっていることが分かる。
Timerクラスであれば、New-Objectコマンドレットでインスタンス化したあと、Intervalプロパティでイベント発生間隔をミリ秒単位で指定し、Enableプロパティを$trueに設定してやると、Elapsedイベントが指定した間隔で発生する。従来はこのイベントを捕捉する方法がなかったが、PowerShell 2.0では新たに追加されたイベンティング用のコマンドレットRegister-ObjectEventを用いると可能になる。以下、実際の手順を見ていただきたい。
Timerオブジェクトのイベントの捕捉PowerShell 2.0では新たに追加されたイベンティング用のコマンドレットRegister-ObjectEventを用いると、Timerオブジェクトのイベントの捕捉が可能になっている。
（1）Timerオブジェクトのインスタンス化。
（2）イベント発生間隔であるIntervalプロパティを2000ミリ秒（2秒）に設定する。
（3）Register-ObjectEventコマンドレットを用いてオブジェクトのイベントをサブスクライブする。
-InputObjectパラメータ：イベントをサブスクライブするオブジェクトを指定する。
-EventNameパラメータ：捕捉するイベント名を指定する。ここでは指定時間が経過したときに発生する「Elapsed」を指定している。
-SourceIdentifilerパラメータ：このイベント・サブスクリプションの名前（任意のものを指定可能。これはイベント監視バックグラウンド・ジョブ名となる）。
-Actionパラメータ：イベントが発生したときに実行するスクリプト・ブロックを指定する。ここではシステム・ビープを鳴らすスクリプトを指定している。
（4）Timerオブジェクトを有効化する。これを実行すると、2秒おきにビープ音が鳴るようになる。
（5）Unregister-Eventコマンドレットを用い、サブスクリプションを解除する。以降、イベントを捕捉しなくなる（ビープ音が止まる）。
このように、PowerShell 2.0では任意の.NETオブジェクトのイベントを捕捉することが可能となった。他にもイベンティング関係のコマンドレットにはイベントが発生するまで処理を待つWait-Eventコマンドレットや、WMIのイベントを捕捉するRegister-WmiEventコマンドレットなどがある。
Windows PowerShell ISEを用いたGUIベースの開発
バッチ・ファイルやWSHスクリプト、そしてPowerShell 1.0にはスクリプトの開発環境がデフォルトでは用意されていなかった。そのため多くの管理者は汎用のテキスト・エディタを用いてスクリプトを記述していたであろう。テキスト・エディタにはキーワードの色分け程度は可能なものもあるが、キーワードの補完入力やデバッグ機能などは存在しない。そのため、テキスト・エディタでスクリプトを記述して実行し、エラーが出た場合、そのスクリプトは強制終了するのでまたエディタに戻り、原因を突き止めて修正を加えて再実行……、という作業を繰り返す必要がある。時には、エラーが発生する原因を調べるため、本筋とは関係のない、スクリプト内に変数の中身を表示させるコードを挿入したりする必要すらあった。
PowerShell 2.0の新機能である「Windows PowerShell ISE（Integrated Scripting Environment）」を使えば、そのような苦行からは解放される。ISEはスクリプトを記述するための高機能な開発環境であり、スクリプトの実行テストおよびデバッグを簡単に行うことができる。
PowerShell ISEの実行画面PowerShell 2.0ではGUIの開発環境が用意された。エディット機能やデバッグ機能、対話的なコマンドの実行機能などを持っている。
（1）スクリプト・ウィンドウ：スクリプトを記述する
（2）出力ウィンドウ：実行結果が表示される
（3）コマンド・ウィンドウ：対話的コマンド入力を行う
ISEをエディタとしてみると、一般的なテキスト・エディタが持つ行番号表示、検索や置換、アンドゥやリドゥ、タブ表示などといった基本的な機能はもちろんのこと、キーワードやコメントの色分け機能、タブ・キーでのキーワード入力補完機能、［F1］キー押下によるキーワードのヘルプ参照機能などが搭載されている。またスクリプトの実行がISEウィンドウから行えるのはもちろん、ブレークポイント（処理を一時停止させる行の指定）の挿入、ステップ実行（処理を1行ずつ実行）などが可能であり、Visual Studioのような統合開発環境さながらの高機能を有している。
ISEがVisual Studioなどと異なって特徴的なのは、スクリプトを記述するスクリプト・ウィンドウ、実行結果を表示する出力ウィンドウのほかに、対話的なコマンド入力が可能なコマンド・ウィンドウが存在することであろう。このコマンド・ウィンドウは、PowerShellコンソールと同様、任意のコマンドレットなどを実行することができる。そしてその結果は出力・ウィンドウに表示されるため、スクリプト開発中にお試しでコマンドを実行したり、スクリプトを実行させるために必要な前処理を行ったりすることが容易に行える。またスクリプト実行中、ブレークポイントやステップ実行などでスクリプトが一時停止したときにはコマンド・ウィンドウはデバッグ用コンソールとして機能し、現在の変数の値などを参照し出力ペインに表示したりすることが可能である。ISEはPowerShellスクリプト開発に特化された環境であるといえよう。
ISEはデフォルトでは使用できず、サーバの機能の追加で「Windows PowerShell Integrated Scripting Environment(ISE)」を追加する必要がある（Windows 7では最初から利用可能）。またISEを追加するには、「.NET Framework 3.5.1の機能」も追加する必要がある。PowerShellは.NET Framework 2.0をベースに動作し、デフォルトでは3.5.1が有効化されていないのでそこだけ注意する必要がある。余談であるが、ISEを追加すると、コマンドレットの結果をグリッド・ビュー形式のウィンドウで表示するコマンドレットであるOut-GridViewが使用可能となる。
このように、PowerShell 2.0ではさまざまな新機能が搭載された。ここで挙げたもの以外にも、国際化対応が行われたり、try〜catch〜finallyステートメントの追加やマルチライン・コメントのサポートなど、文法にもいくつか機能追加がされている。また、ほかの物も合わせるとコマンドレットが100種ほど増えている。PowerShell 2.0はより強力な「使える」シェルになったことを感じていただけたであろうか。
PowerShellの使用シーンと今後
これまでPowerShellの紹介を行ってきたが、では実際にPowerShellを現場で使用する際、どういう局面で用いるのが適しているのか、そしてPowerShellの今後はどのようになるのかについて最後に述べておきたい。
そもそもPowerShellは、サーバ管理者が絶対にマスターして利用しなければならないものであるかというと、必ずしもそうではないというのが筆者の考えである。あくまでもWindows Serverでは、ウィンドウを複数開いてオペレーションを行うのが基本であろう。ただ最初の方で述べたが、ウィンドウに対して行うマウス・オペレーションは、繰り返し作業が大変であるという弱点を抱えている。そういった場合はPowerShellのコマンドレットを実行することで、さまざまなリソースに対して情報の参照や設定をまとめて行える。さらにスクリプト化すれば同じ処理を何度も自動的に再現することができるようになる。つまりPowerShellを覚えておけばサーバの管理業務において大きな省力化を図ることが可能になる。
本稿ではWindows Server 2008 R2に標準で付属しているモジュールについて述べたが、各種サーバ製品（SQL Server 2008、Exchange Server 2007など）にもそれぞれモジュールもしくはPSスナップインが付属し、PowerShellから利用が可能である。というよりも、今後リリースされるサーバ製品のGUIの管理ツールは（少なくともMicrosoft製品に関しては確実に）PowerShellのコマンドレットを内部的に呼び出す形にシフトしていくことになる(すでにリリースされているものではExchange Server 2007などが挙げられる)。構造的にはPowerShellコマンドレットの上にGUI管理ツールが載る形となる。すなわちPowerShellは管理者が気付かないうちに使用しているという世界になるのである。この流れはWindows Server自体の管理ツールについても同様で、Active Directoryモジュールがその一例である。これに対応するGUI管理ツールが「Active Directory 管理センター」であり、このツールは内部的にはActive Directory モジュールに含まれるコマンドレットを呼び出して処理を行っている。PowerShellを知らないでいても問題はないが、知っているとOSやサーバ製品群の管理において繰り返し処理や自動化がたやすく行えるようになる。
さらに、Windows Server 2008 R2に対応するクライアントOS、Windows 7にもPowerShell 2.0が標準機能として備わっている（［スタート］メニューの［すべてのプログラム］−［アクセサリ］−［Windows PowerShell］）。よって、Windows 7クライアントをドメインに参加させれば、Windows 7クライアントのPowerShellでPSRemoting機能を用い、リモートのWindows Server 2008 R2サーバの操作が可能となる。Windows 7はクライアントOSだけあって.NET Framework 3.5.1が有効であり、ISEも最初から使用可能である。よって、サーバで実行するスクリプトをクライアントで開発するというシナリオも想定されるだろう（ISEには「リモートPowerShellタブを作成する」というメニューがある）。また、Windows 7のみならずWindows VistaやWindows XP用のPowerShell 2.0も間もなくリリースされる予定なので、これを利用すればWindows 7と同様のことが可能になる。
当面はPowerShellを覚えなくてもWSHやバッチ・ファイルで乗り切れるという意見も確かにあるだろう。しかしこれらの環境は今後も互換性のために維持されるだろうが、新製品や新機能に関してはこれらの環境では対処できなくなってくることが予想される。すでにあるスクリプト資産を捨てる必要はないが、これらの情勢を見据えてPowerShellへの移行を検討してみるのもよいだろう。PowerShellから既存のスクリプト・ファイルを実行することももちろん可能なので、部分的な移行から始めてみるのも手だ。逆に現時点ではコマンド・プロンプトの外部コマンドやWSHのオブジェクトでしか実現できない機能もあり、それらは適宜PowerShellから呼び出すことになる。
以上、本稿ではWindows Server 2008 R2の新機能の1つであるPowerShell 2.0について述べた。PowerShellをすでに知っている人には新機能をひもとく手助けになり、知らなかった人にはPowerShellを始めてみるきっかけになれば幸いである。
Copyright© Digital Advantage Corp. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。