Windows PowerShell: Windows PowerShell ワークフロー環境について
今年は、Don Jones が Windows PowerShell ワークフローに関する 12 部構成のチュートリアルを毎月 1 部ずつお届けします。2013 年 1 月号から始まるシリーズは順番にお読みいただくことをお勧めします。
Don Jones
先月説明したとおり、Windows PowerShell ワークフローは、Windows Management Framework 3.0 の新しい機能です。Windows PowerShell ワークフローは、Windows Server 2012 と Windows 8 に、あらかじめインストールされていますが、Windows 7、Windows Server 2008、および Windows Server 2008 R2 でも使用することができます。ワークフローを実行するには、これらの OS のいずれかが必要になります。また、実行するタスクにもよりますが、ワークフローはあらゆるバージョンの Windows を対象とする (あらゆるバージョンの Windows に対してタスクを実行する) ことができます。
Windows PowerShell ワークフローを使用するための主な前提条件には、Windows PowerShell 3.0 の標準のシステム要件以外に 2 つあります。1 つは、バンドルされた PSWorkflow モジュールを使用してシェル内部のワークフロー機能を有効にすることです。もう 1 つは、Windows PowerShell ワークフローの実行対象となるコンピューターで Windows PowerShell リモート処理を有効にすることです。
ワークフローを実行するコンピューターでリモート処理が実行されている必要はありませんが、インベントリ、構成、または管理の対象となるコンピューターで、リモート処理が有効になっている必要があります。Windows PowerShell ワークフローでは、リモート処理を主な通信プロトコルとして使用します。リモート処理を使用しないワークフローも作成できますが、そのようなワークフローは、きわめてまれです。
リモート処理は非常に誤解されやすい Windows PowerShell のコンポーネントです。多くの組織の IT セキュリティ担当者は、リモート処理を展開しないアプローチを採用しています。これは的外れで残念なアプローチです。IT セキュリティ担当者は、リモート デスクトップ プロトコル (RDP)、リモート プロシージャ コール (RPC)、HTTP など他の多くの管理通信プロトコルを問題なく使用しています。
リモート処理は、Windows 環境内で通信を管理するための一歩前進です。マイクロソフトは、近いうちに上記のような以前からあるプロトコルをリモート処理に統合し始めるでしょう。HTTP と HTTPS を使用するリモート処理は、簡単に構成や管理を行うことが可能で、グループ ポリシー オブジェクト (GPO) を使用して一元的に制限することができます。また、リモート処理は、以前のプロトコルと比べて、一般的に安全性が高く、監査や管理をより簡単に実行することができます。リモート処理とリモート処理のアーキテクチャのセキュリティのしくみの詳細については、無料の『Secrets of PowerShell Remoting』(PowerShell.org、2012 年) 電子ブックを参照してください。
ワークフローの内部
Windows PowerShell ワークフローに取り組むうえで最も難しい点は、Windows PowerShell ワークフローが Windows PowerShell スクリプト (特に関数) と見た目が同じでも別物だということを覚えておくことです。“Windows PowerShell 言語” で記述したコードは外部言語 (XAML) に変換されます。その後、コードは、Windows PowerShell テクノロジ以外のテクノロジで実行されます。
そのため、いくつかの異なるルールがあります。このうちのいくつかは完全な構文規則です。一般的に、実行するコマンドレットは、完全なコマンドレット名を指定する必要があり、位置指定パラメーターや省略されたパラメーター名は使用できません。完全なパラメーター名を使用する必要があります。
さらに難しい点は、ワークフロー内の全体的な環境です。ワークフローにおいて重要な点は、意図的にワークフローを中断および再開したり、環境で停電などの問題が起こったときの対応として、ワークフローを中断および再開できる点です。
つまり、ワークフローの各コマンドは、本質的にスタンドアロンでなければなりません。コマンドは、他のコマンドが実行した処理を認識せず、コマンド間でデータを保持するネイティブな手段を持たないようにする必要があります。つまり、1 つのコマンドの出力を保持するために変数を設定して、この変数を他のコマンドに入力として渡すこともできません。この処理はまったく機能しません。また、追加のコマンドを含むモジュールを読み込むこともできません。モジュールを読み込む永続的な環境はありません。
ワークフローで使用できるようになった特別な InlineScript{} ブロックが頼りになります。各 InlineScript ブロックは、基本的に 1 つの単位として実行します。Windows Workflow Foundation (WWF) では、Windows PowerShell のコピーを実行し、Windows PowerShell のコピーがすべての InlineScript ブロックをまとめて実行します。InlineScript ブロックのコンテンツは、従来の Windows PowerShell スクリプトのように動作します。
また、暗黙的な InlineScript ブロックもあります。実際、WWF では、InlineScript ブロックの外部で Windows PowerShell コマンドを実行することはできません。ワークフローで Windows PowerShell コマンドレットを使用する場合、Windows PowerShell では、WWF に対応したネイティブなコマンドレットが利用できるかどうかを確認し、このようなコマンドレットを代わりに実行するように WWF に伝えます。
Windows PowerShell チームは、Windows PowerShell の多くのネイティブなコマンドレットについて対応する WWF バージョンのコマンドレットを記述しましたが、対応する WWF バージョンのコマンドレットがない Windows PowerShell のネイティブなコマンドレットを使用するときには、Windows PowerShell によって、コマンドが InlineScript ブロックで暗黙的にラップされます。これにより、WWF では Windows PowerShell を起動してコマンドを実行したら、起動した Windows PowerShell のインスタンスを終了します。
このようにコマンド間に永続性がないため、Windows PowerShell ワークフローでは、スクリプトを再開することができます。これは、Windows PowerShell ワークフローがスクリプトでコマンドを並列処理できる核心となる部分です。Windows PowerShell ワークフローでは、並列処理するコマンドをマルチスレッド化された自動化マシンに変換します。しかし、永続性がない点は、通常の Windows PowerShell スクリプトや関数が動作する方法と大きく異なります。スクリプトが適切に動作するには、多くの追加の計画が必要になります。
たくさんの InlineScript ブロックで構成されているワークフローは珍しくありません。また、1 つの長い InlineScript ブロックだけで構成されたワークフローも珍しくありません。
このようなワークフローでは、並列処理が制限されたり (または列行処理が含まれない)、再開機能が制限されたりします。InlineScript ブロックは 1 つの実行単位です。ワークフローではなく、リモート処理を使用して、このようなスクリプトを通常の関数として単純に実行しようとするかもしれません。この方法では、Windows PowerShell ワークフローの実際の利点をほんの少ししか活用できません。
データを保持するには
Windows PowerShell ワークフローに明らかにないものは、コマンド間でワークフローのデータを保持する手段です。データを保持できれば、ワークフローは幅広い状況で便利に使えるようになります。ワークフローが中断されて再開された場合、コマンドでは、簡単に IP アドレス、コンピューター名、ユーザー名などの状態情報を再度作成して実行を続行できます。
このようにネイティブにデータを保持する機能がないので、この機能を自分で作成しようと思うかもしれません。SQL Server インスタンス (無料の Express インスタンスでも可能) をセットアップし、ワークフローがデータを保存できるデータベース テーブルを作成します。ワークフローでは、各ワークフローのインスタンスが対象とするワークフロー名やコンピューター名など、一意に自分を識別できるなんらかの手段が必要です。
ワークフローは、多くの個別の InlineScript ブロックで構成されている可能性があります。各 InlineScript ブロックは、データベースから現在の状態を読み取り、いくつかのタスクを実行し、必要であればデータベースを新しい情報で更新します。Windows PowerShell ワークフローの機能でこの処理を自動化できないことは残念です。内部で XML ファイルまたは SQL Server を使用する “$workflow:variable” アーキテクチャが役に立つ可能性がありますが、現在のバージョンでは利用できず、将来のバージョンで利用できるようになる予定です。
朗報は、SQL Server を使用して、簡単に永続性を "自分で展開" できることです。SQL Server は、より拡張性があり、複数のネットワーク ロケーションからより簡単にアクセスすることが可能で、一度に複数のインスタンスからの同時アクセスをサポートしているため、XML ファイルより望ましい選択肢になります。
Microsoft .NET Framework の System.Data.Sql.SqlClient クラスは簡単に使用できます。サンプルについては、『Learn PowerShell Toolmaking in a Month of Lunches』(Manning Publications、2012 年) 電子ブックを参照してください。事実、共著者と私は書籍のサンプル スクリプトの一部として、無料でダウンロードして、再利用できるモジュールを作成しました。
前提条件についての説明が完了したので、基本的なワークフローがどのようなものかを学習する準備ができました。来月のコラムでは、基本的なワークフローについて説明します。
.jpg)
Don Jones は、Windows PowerShell MVP の受賞者で、TechNet マガジンの寄稿編集者でもあります。彼は、Windows PowerShell と Windows PowerShell リモート処理を使用して HTML 形式のレポートを作成する方法について説明した無料の書籍を含む、Windows PowerShell 3.0 ついて 4 冊の書籍を共同執筆しています。すべての書籍は PowerShellBooks.com (英語) で確認できます。また、PowerShell.org (英語) のディスカッション フォーラムでは、彼に質問することができます。