Windows PowerShell
Windows PowerShell 2.0 のリモート管理の概要
Don Jones
このコラムは、Windows PowerShell のプレリリース版を基にしています。ここに記載されているすべての情報は、変更される場合があります。
目次
Windows PowerShell 2.0 の最新の Community Technology Preview (CTP) は、お試しになりましたか。最新バージョンである CTP2 には、さらに改良されたリモート管理機能が備わっており、Windows PowerShell 2.0 の新機能について理解を深めるには今が絶好のチャンスです。このコラムを読み進める前に、CTP2 を
まず、いくつかの重要な点を明確にしておきましょう。CTP は、マイクロソフトが提供するベータ版公開前のコードで、私のような熱心なユーザーが、アプリケーションの次のバージョンでマイクロソフトが何を目指しているかを把握できるようになります。CTP の各マイルストーン (通称、ドロップ) は、それ以前のドロップとはまったく異なる場合があります。このような現象が起こるのは、開発チームがユーザーからフィードバックを収集し、そのフィードバックを慎重に確認して、このユーザーからのフィードバックに基づいてアプリケーションを変更するためです。このような方法を採用していることにより、CTP の利用に関して重要なメリットと注意点が生じます。
メリットは、ユーザーが CTP を使用したときに、製品に関するフィードバックを (
connect.microsoft.com Web サイト経由で) 製品の開発段階で送信できるので、開発チームがフィードバックに基づいて作業できるということです。ベータ版 (さらに悪い場合はリリース候補版) がリリースされる段階まで待っていると、ユーザーのフィードバックを組み込むことは非常に難しくなります。CTP の提供中はあらゆる問題が発生する可能性がありますが、開発チームは必要に応じて広範囲にわたる大幅な変更を行うことができます。
このため、CTP は運用環境では使用できないという注意点があります。もちろん、Windows PowerShell™ 2.0 CTP2 は、これまで提供された CTP の中で最も安定したプレリリース コードの 1 つですが、次の CTP ドロップはまったく異なるアプリケーションになる可能性があることを覚えておいてください。そのため、次のバージョンでは最初からやり直すことが必要になる可能性があるので、CTP2 に依存しないでください。
CTP は、Windows PowerShell 1.0 と共存させる形でインストールできない点に注意してください。理想的な環境は、利用可能なすべての機能を有効にするために、システムに Microsoft® .NET Framework 3.5 がインストールされている状態です。.NET Framework 3.5 がインストールされていないと、一部の機能が制限されます。
また、CTP は初期段階のコードなので、マイクロソフトでは今のところ最新のオペレーティング システム (つまり、Windows Vista® と Windows Server® 2008) で動作するアプリケーションを最重要視しています。現時点での OS の互換性は、最終的にリリースされるコードで予想される OS の互換性を示すものではありません。下位バージョンへの移植については、開発サイクルの後半で対処します。
2 種類のリモート処理
通常、リモート管理では、ファンインおよびファンアウトという 2 種類のリモート処理が行われます。ファンイン リモート処理では、複数の管理者が 1 台のサーバーに対して Secure Shell (SSH) 接続を確立します。Windows PowerShell は、区分化された安全な方法でこのような接続を確立できるように設計されています。ですから、たとえば、Exchange Server のホスティング サービスを提供している企業では、サーバーの管理者アクセス権を顧客に与えることができます。ファンイン リモート処理を使用すると、リモート サーバーにインストールされた Windows PowerShell のコピーに、リモートから対話形式で安全にアクセスできます (この機能は Windows PowerShell 2.0 のみで使用できます)。
ファンアウト リモート処理は、リモート サーバー群全体に一連のコマンドを同時に発行する場合に使用します。コマンドは、ワークステーションからサーバー群に対して同時に "ファンアウト" されます。各サーバーでコマンドが実行され、Windows PowerShell オブジェクト形式の結果がワークステーションに返されるので、それらの結果を確認して対応できます。Windows PowerShell では、Windows® Management Instrumentation (WMI) と Windows リモート管理 (WinRM) というファンアウト リモート処理の 2 つの主要なテクノロジをサポートしています。これらのテクノロジは、当初は Windows Server 2008 に同梱されていましたが、Windows PowerShell 2.0 CTP で更新されました。
同期と非同期
実は、Windows PowerShell 1.0 にも、WMI に関連付けられたいくつかの基本的なファンアウト機能が備わっていました。たとえば、次のように簡単にコンピュータ名の配列を作成し、各コンピュータの WMI クラスを取得することができました。
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
–computer $names
Windows PowerShell 1.0 では WMI メソッドを一括で実行する方法が提供されていなかったので、コンピュータを再起動するなどのメソッドを実行するには、もう少し作業が必要でした。しかし、Windows PowerShell 2.0 CTP では Invoke-WmiMethod コマンドレットが導入されたため、次のようなコードを記述すれば済むようになりました。
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem –computer $names | `
Invoke-WmiMethod Reboot
ただし、この技法には問題があります。この技法は同期的です。つまり、一度に 1 台のコンピュータにしか接続できないので、各コンピュータでの処理が完了しないと他のコマンドを実行できません。ただし、この CTP では、このようなコマンドをバックグラウンドで実行できるバックグラウンド ジョブという新しい概念が導入されました。この概念はきわめて単純なので、次のように AsJob パラメータを追加するだけで WMI コマンドをバックグラウンドで実行できます。
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem –computer $names -asjob
実行後のジョブの状態は Get-PSJob を、ジョブの最終結果は Receive-PSJob を実行して確認できます (ジョブ管理の詳細については、今後のコラムで詳しく説明します)。ただし、Invoke-Command コマンドレットを使用すると、次のようにさらに優れた方法でバックグラウンドでコマンドを実行できます。
$command = { Get-WmiObject Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command –computer $names –asjob
このコマンドを実行すると、指定した各コンピュータに Get-WmiObject コマンドが発行され、発行されたコマンドは各コンピュータのローカルで実行されます。通常、Get-WmiObject コマンドは、WMI リモート プロシージャ コール (RPC) 接続に依存しなくても高速に実行されますが、Invoke-Command コマンドレットでは、既定でポート 80 または 443 を使用する WinRM が使用されます。これらのポートを使用すると、簡単にファイアウォールを操作することが可能で、ポートは完全に構成できます。また、Invoke-Command コマンドレットでは、代替の資格情報と調整用の追加パラメータもサポートしているので、何百台ものコンピュータを対象としながら、同時に実行するコンピュータを数台に制限することができます。このため、過密状態や過剰な負荷を回避できます。
再利用可能な実行空間
特定の一連のコンピュータを複数回リモートで管理する予定がある場合は、単純なコンピュータ名の一覧ではなく、実行空間を使用することをお勧めします。Windows PowerShell の実行空間は、単なるシェルのエンジンのインスタンスです。これは、シェル コンソール ウィンドウとしてコンピュータのローカルで実行している場合も、リモート コンピュータのバックグラウンドで実行している場合も同様です。リモートの実行空間は、次のように簡単に開始できます。
$names = @("server1","server2","server2")
New-RunSpace –computer $names
実行空間でも WinRM が使用されるので、既定でポート 80 (–UseSSL パラメータを指定した場合は 443) が使用されます。また、実行空間では、代替の資格情報なども使用できます。次のように、結果の実行空間オブジェクトを取得したら、Invoke-Command コマンドレットに渡すことができます。すると、Windows PowerShell によって、これらの実行空間が存在するコンピュータにコマンドが発行されます。
$command = { Get-WmiObject Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command –runspace $rs –asjob
この方法を使用すると、シェルが起動している間は実行空間がアクティブなままなので、開始した実行空間を再利用してさらにコマンドを実行できるというメリットがあります。
ファンイン リモート処理
実行空間は、ファンイン リモート処理でも重要です。たとえば、図 1 は、リモート コンピュータで実行空間を作成し、その実行空間への参照を取得して、Push-Runspace コマンドレットを使用して実行空間をアクティブにしたことを示しています。この時点では、リモート コンピュータでは、SSH や他のリモート シェル ユーティリティの場合と同様にコマンドを実行していました。
Pop-Runspace コマンドレットを実行すると、元のローカルの実行空間に戻ります。シェル プロンプトにより、いつでも自分の現在地を追跡できます。
.gif)
図 1 実行空間を使用したリモート コンピュータでのコマンドの実行 (画像をクリックすると拡大表示されます)
実際に実行した一連のコマンドは、下記のとおりです。
PS C:\>new-runspace -computer "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32> pop-runspace
PS C:\>
複数の管理者が 1 台のサーバーでリモートの実行空間を対話形式で同時に開くことができるため、この技法はファンインと呼ばれます。つまり、管理者は各自のワークステーションからサーバーに "ファンイン" します。Windows PowerShell 2.0 の新しいセキュリティ モデルにより、各管理者は、作成できるシェルとコマンドレットが制限されるので、グローバルな変更を行うことができず、各自のシェルの範囲に制限されます (このような新しいセキュリティ技法により、.NET Framework 対象の言語でなんらかのカスタム ソフトウェア開発を行うことが必要になります。Windows PowerShell コラムでは、これについては取り上げませんが、このような機能が存在することを覚えておくと役に立ちます)。
Windows PowerShell 2.0 の革新的なアプリケーション
Windows PowerShell 2.0 CTP には、すばらしい一連の新機能が用意されています。個人的な意見ですが、リモート処理は革新的なアプリケーションです。ほぼすべての環境の各管理者が、リモート処理のメリットを享受できます。
これらの機能について理解して、ぜひ製品チームまで提案をお寄せください。グループ ポリシーで WinRM の既定のポートを管理する必要がある場合、コマンドレットの動作が異なる場合、パフォーマンスの問題が発生した場合、WinRM の構成が難しい場合などの事象が発生した際は、
connect.microsoft.com に提案を送るか、私を含む MVP 受賞者とフィードバックを共有して、製品開発にかかわることができます (私に連絡を取りたい場合は、
ScriptingAnswers.com のフォーラムにフィードバックをお寄せください)。ぜひ、製品開発に関与して、次世代の Windows PowerShell の革新的なアプリケーションの構築をサポートしてください。
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved. 許可なしに一部または全体を複製することは禁止されています。