 TechNet Magazine January 2008

TechNet Magazine January 2008

System Center: Virtual Machine Manager 2007 を使用した現実の管理

組織は、仮想化を利用してリソースを統合し、資金を節約することができます。ただし、実装するバーチャル マシンの数が増加し始めると、それらを管理するための便利な方法が必要になります。この記事では、Virtual Machine Manager をセットアップする方法と、Virtual Machine Manager の一元的なインターフェイスを使用して管理作業を行う方法について説明します。

Edwin Yuen System Center: Data Protection Manager 2007 を使用してバックアップを強化する

Data Protection Manager の最新バージョンでは、さまざまな新機能と、強力で柔軟なバックアップ管理ソリューションが提供されます。ここでは、DPM を使用して、Exchange や SQL Server からブランチ オフィスや SharePoint サイトに至るまで、あらゆるものをどのように保護できるかについて説明します。

Calvin Keaton System Center: オンライン サービスを利用してソフトウェア インベントリを簡素化する

ソフトウェア資産管理は、規模の大小を問わず、すべての企業にとってきわめて重要な作業です。しかし、現在企業が購入して展開するソフトウェアの量を考えると、ソフトウェア資産を管理することは、ほとんど不可能に感じられます。ここでは、マイクロソフトから新しく提供される Asset Inventory Service の有用性について説明します。

Paul Bourgeau グループ ポリシー: グループ ポリシー用の ADM テンプレートと ADMX テンプレートの内部

ADM ファイルは必要なファイルですが、わかりづらいファイルでもあります。だからと言って、グループ ポリシーに対する取り組みの手を緩めないでください。この記事では、ADM ファイルと新しい ADMX 形式の内部、これらのファイルの処理に使用できるツール、ファイルの最適な使用方法を理解するのに役立つ情報を提供します。

Jeremy Moskowitz グループ ポリシー: グループ ポリシーのパフォーマンスを最適化する

すべてのグループ ポリシーは同じものではありません。それぞれの種類間の違いを知っておくと、システムでのパフォーマンスを調整する際に役立ちます。この記事では、モノリシック GP と機能別 GP、グループ ポリシーの処理方法、およびグループ ポリシーが変更された場合の動作について説明します。

Darren Mar-Elia グループ ポリシー: Advanced Group Policy Management コンソールの調査

AGPM (Advanced Group Policy Management) は、他のツールでは実現できない方法でグループ ポリシーを操作できる便利なツールです。現在、このツールは、マイクロソフト ソフトウェア アシュアランス プログラムの契約者に提供されています。今月は、AGPM を使用して、オフラインで GPO を編集したり、管理作業を委任したり、変更を追跡したりする方法を紹介します。

Derek Melber 編集長から: 皮肉家を納得させる

Joshua Hoffman レター: 読者の皆さんからの声

ツールボックス: IT プロフェッショナル向けの新製品

Greg Steen Exchange Queue & A: 音声プロンプトの追加、PBX の選択など

Exchange ユニファイド メッセージングに関して質問はありませんか。私たちがお答えします。今月の Exchange Queue & A では、ユニファイド メッセージングに注目し、電話機能と FAX 機能を実装したり、高可用性を実現したり、音声プロンプトを設定したりする方法などをご紹介します。

Seema Rahman ユーティリティ スポットライト: Windows Easy Transfer Companion

この無償のツールを使用すると、重要なアプリケーションを簡単に Windows XP から Windows Vista に移行できます。

Lance Whitney The Cable Guy: Windows Server 2008 における DNS の機能拡張

Windows Server 2008 では、DNS サーバーに多数の機能強化が施されています。この記事では、これらの機能拡張により、名前解決の迅速化、IPv6 サポートの強化、DNS の管理における柔軟性の強化がどのように実現されているのかを紹介します。

Joseph Davies Windows PowerShell: 悪意のあるコードを回避する

Windows PowerShell のセキュリティには、設計時にさまざまな考えが盛り込まれました。しかし他のソフトウェアと同様、Windows PowerShell も悪意のあるコードから攻撃される可能性があります。この記事では、実行ポリシーを選択してシステムのセキュリティを強化する際の推奨事項について説明します。

Don Jones Hey, Scripting Guy!: 正規表現で間違いをなくす

間違いを回避する方法をお探しですか。手始めに検証を行うようにすると良いでしょう。今月は、正規表現を使用して、スクリプトで文字のパターン マッチングを実行する方法を紹介します。

The Microsoft Scripting Guys セキュリティ ウォッチ: 島巡り : 魅惑的なベンダの配布物

セキュリティの脅威をもたらすのは、電子メールや悪意のある Web サイトだけではありません。この記事では、USB フラッシュ ドライブやソーシャル エンジニアリングを利用して、ネットワーク全体へのアクセスがどのように行われるのかについて紹介します。また、このような脅威に対するネットワーク保護を強化する方法についても説明します。

Jesper M. Johansson デスクトップ ファイル: Windows SteadyState で共有コンピューティングを管理する

新しい Windows SteadyState ツールキットを使用すると、共用環境にある Windows XP システムのセキュリティを強化し、管理を簡略化することができます。この記事では、その方法を紹介します。

Wes Miller フィールド ノート: 1 日で最も重要な作業

プロジェクトに従事しているとき、考えたり、計画を立てたり、優先順位を付けたりする時間を確保することの重要性について説明します。

Eric N. Bush Windows 秘話: 二度としないように言ってください

適切なプラグ アンド プレイ デバイスが登場するまで、ハードウェアの検出は非常に恐ろしい作業でした。この記事ではその理由について説明します。

Raymond Chen


 System Center: Virtual Machine Manager 2007 を使用した現実の管理
System Center Edwin Yuen

Virtual Machine Manager 2007 を使用した現実の管理
概要:
  • System Center Virtual Machine Manager 2007 の主な機能
  • VMM をインストールする方法
  • 物理コンピュータまたはバーチャル マシンを VM に変換する

System Center Virtual Machine Manager 2007 は、仮想インフラストラクチャ全体を管理するための統合型インターフェイスを提供する新しいソリューションです。
Virtual Machine Manager (VMM) を使用すると、既存の Microsoft® Virtual Server 2005 のインストールを管理できるだけでなく、新しいバーチャル マシン (VM) ホストに Virtual Server 2005 R2 SP1 をインストールすることもできます。また、一元的なインターフェイスから複数の Virtual Server のインストールにアクセスして管理作業を行うことができるため、従来の Virtual Server 2005 の管理作業がはるかに効率化されます。
さらに、VMM では Virtual Server 向けの新機能が導入されます。たとえば、物理-バーチャル (P2V) 変換、VMware Virtual Machine Disk Format (VMDK) ディスクから Virtual Server バーチャル ハード ディスク (VHD) へのバーチャル-バーチャル (V2V) 変換、仮想インフラストラクチャ オブジェクトの一元的なライブラリで提供されるテンプレートと構成済み VHD を使用した迅速な VM の展開などがあります。
以降のページでは、VMM について、および IT 管理者が利用できる VMM の一連の強力な機能について説明します。その後、VMM のインストールを作成するための要件と手順について説明します。最後に、VMM のいくつかの魅力的な機能について詳しく説明し、作業の開始に役立つヒントをいくつか紹介します。

Virtual Machine Manager 2007 の概要
System Center Virtual Machine Manager 2007 は、企業の Microsoft Virtual Server 2005 で実行されているバーチャル マシンを一元管理できるスタンドアロン アプリケーションです。Virtual Machine Manager は System Center ファミリの製品であり、他の System Center 製品と連動して、物理インフラストラクチャと仮想インフラストラクチャのエンド ツー エンドの管理を提供します。図 1 は、Virtual Machine Manager のさまざまなコンポーネント、および VMM と Virtual Server ホストとの関連を示しています。
図の左側の欄は VMM サーバーのアーキテクチャ、右側の欄はバーチャル マシン ホストのアーキテクチャを表しています。必要に応じて、VMM コンポーネントを別々のサーバーにインストールして、パフォーマンスとスケーラビリティを向上させることもできます。この記事では、主要な VMM コンポーネントが 1 台のコンピュータにすべてインストールされている図 1 のモデルを使用して説明します。VMM 製品の中核となるのは、左側の欄の中央に位置する Virtual Machine Manager サービスです。Virtual Machine Manager サービスの上には、Windows PowerShellTM インターフェイス、管理者コンソール、および準備を委任できる管理機能が提供されるセルフサービス ポータルという 3 つの異なるインターフェイスが位置しています。VMM を支えるのは、Microsoft SQL Server® 2005 データベース (SQL Server の完全インストールか SQL Server 2005 Express Edition のいずれかを使用できます)、およびバーチャル インフラストラクチャ コンポーネント用のファイル共有である一元的なライブラリです。
図 1 System Center Virtual Machine Manager 2007 のアーキテクチャ
図 1 System Center Virtual Machine Manager 2007 のアーキテクチャ
図 1 の右側の欄は、VMM が管理する Virtual Server 2005 R2 バーチャル マシン ホストを表しています。底辺に位置するのはホスト オペレーティング システム (ここでは Windows Server® 2003 R2) です。VMM がバーチャル マシン ホストにインストールするエージェントによって、VMM と Virtual Server 2005 R2 との間の通信が容易になります。エージェントは物理ホストにのみインストールされ、VM や ゲスト OS にはインストールされません。ホスト コンピュータに Virtual Server がインストールされていない場合、管理されているサーバーの一覧にホストが追加されると、VMM によって自動的に Virtual Server がインストールされます。
System Center 製品ファミリの Virtual Machine Manager では、管理者コンソールに (従来の MMC スナップインではなく) 新しい System Center (または Outlook® 形式の) インターフェイスが使用されています。VMM 管理者コンソール (図 2 参照) は Microsoft .NET Framework 2.0 を使用して構築されており、その基盤には Windows PowerShell 1.0 が使用されています。実際に、管理者コンソールでなんらかの操作を実行すると、関連付けられている Windows PowerShell コマンドが呼び出されます。そのため、管理者コンソールで呼び出されるコマンドや関数は、Windows PowerShell でコマンド ラインを使用して直接呼び出すこともできます。
図 2 管理されているバーチャル マシンが表示された VMM の管理用 UI
図 2 管理されているバーチャル マシンが表示された VMM の管理用 UI
管理者コンソールの各ウィザードには、実行するコマンドに関連付けられている Windows PowerShell スクリプトを表示する [View Script] (スクリプトの表示) ボタンも用意されています。この機能は、Windows PowerShell の VMM に関連する部分について学習する際に役立ちます。VMM で Windows PowerShell を使用することに慣れれば、VMM を使用して一括操作を実行するスクリプトを作成できるようになります。
IT 管理者は、Virtual Machine Manager から 3 つの重要なメリットを得ることができます。これらのメリットとは、リソースを最大限に活用できること、敏捷性が向上すること、および既存のスキルを利用できることです。VMM のいくつかの機能によって、これらのメリットがもたらされます。まず、VMM では、物理サーバーをバーチャル マシンに変換する P2V 変換という方法が提供されるため、リソースを最大限に活用することができます。この方法を使用することによって、既存の物理コンピュータを再インストールすることなくバーチャル マシンに統合することができます。P2V 変換では、ハードウェアの使用率が低い複数のコンピュータを 1 つの物理ハードウェアに統合できるため、それらのコンピュータを変換する場合には特にメリットが大きくなります。この方法は、たとえば、ほとんど使用しないが年に 1 度実行するために維持しておく必要がある古いソフトウェア (規制会計ソフトウェアなど) がインストールされたコンピュータがある場合は、特に役立ちます。VMM を System Center Operations Manager 2007 と組み合わせて使用すると、サーバーに統合するコンピュータの候補を示すレポートを作成して、物理インフラストラクチャ内で P2V の候補となる可能性が高いコンピュータを確認できます。
VMware の VMDK 形式のバーチャル マシンが既に存在する場合、V2V 変換を実行して既存の VMDK ファイルを VHD 形式に変換できます。これにより、Virtual Server 2005 環境をすばやく構築し、運用することができます。
VMM は、新しい展開であるか変換を使用した展開であるかに関係なく、すべての展開で Intelligent Placement (インテリジェント配置) という処理を使用してバーチャル マシン ホストに VM を展開します。VMM は、Intelligent Placement を使用して、管理されているすべてのバーチャル マシン ホストを照会し、これらのホストが使用するリソースの可用性を示すいくつかのパラメータを取得して、VM の展開先として推奨されるホストを示す、重み付けされた一覧を返します。図 3 からわかるとおり、その後、管理者は推奨されたホストを使用するか、特定のニーズに合わせてアルゴリズムを調整するか、任意のサーバーに VM を展開することができます。Intelligent Placement によって、仮想インフラストラクチャと推奨されるホストを同時に確認できるようになるため、VM の展開に関連する作業を大幅に軽減できます。
図 3 Intelligent Placement によって推奨された Virtual Server ホスト
図 3 Intelligent Placement によって推奨された Virtual Server ホスト
大きなメリットをもたらすその他の VMM 機能には、一元的なライブラリと、準備を委任できるセルフサービス ポータルがあります。ライブラリ (図 4 参照) では、仮想インフラストラクチャの構築に必要なすべてのコンポーネントが一元的に提供されます。これらのコンポーネントには、展開に使用できる作成済みの VHD、OS とハードウェアが構成されたテンプレート、ISO ファイル、スクリプト、プロファイルなどがあります。これらのコンポーネントから新しい VM を作成して展開することができます。また、テンプレートとプロファイルを使用して、複数の VM 間でハードウェアとソフトウェアの構成を統一することができます。さらに、VMM では分散ライブラリもサポートされており、遠隔地にコンポーネントを格納できるため、大きな転送ファイルを遠隔地内で保持しながら、コンポーネントを一元管理することができます。
図 4 仮想インフラストラクチャ用のすべての構成要素が提供される VMM のライブラリ
図 4 仮想インフラストラクチャ用のすべての構成要素が提供される VMM のライブラリ
セルフサービス ポータルは、VMM サービスと IIS のインストールが統合された Web サイトです。このポータルでは、Active Directory® の承認されたユーザーとグループに VM へのアクセスが許可されます。使用できる機能は、そのユーザーまたはグループ用に作成されたポリシーに応じて決まります。これらの機能には、VM の表示や VM へのアクセス、VM の実行とシャットダウン、委任された特定のリソースを使用した新しい VM の作成などがあります。
管理者は、Active Directory のユーザーとグループ、特定のバーチャル マシン ホストまたはホスト グループ、および特定の VM とテンプレートに特定の機能を提供するセルフサービス ポリシーを作成します。管理者は、セルフサービス ポータルを使用して、安全に機能をエンド ユーザーに委任できます。セルフサービス ポータルを使用しなかった場合、VM を管理させるためにエンド ユーザーに管理者コンソールへのアクセスを許可したり、各機能を使用する必要が生じるたびにエンド ユーザーから使用許可の要請を受けたりする必要があります。そのため、VM の起動やリセットなどの操作を実行するためだけに、電子メールを送信したり、電話をかけたりする手間が発生します。

Virtual Machine Manager のインストール
現在、VMM で管理できるのは、Active Directory ドメイン (または信頼関係のあるドメイン) に参加している Window Server 2003 SP1 以降のコンピュータにインストールされた Virtual Server 2005 以降です。また、VMM で提供される境界ネットワークのサポートを使用して、ドメインに参加していないホストも管理することができます。Windows® XP などのデスクトップ オペレーティング システムにインストールされた Virtual Server はサポートされていません。P2V 操作は、VMM サーバーと同じドメイン (または信頼関係のあるドメイン) に参加している物理コンピュータでのみ実行できます。
運用環境では、各 VMM コンポーネントを別々のサーバーにインストールすることをお勧めしますが、ここでは 1 台のサーバーにインストールする場合の手順を説明します。VMM をインストールするサーバーのハードウェア構成として推奨されるのは、x86 または x64 ベースのサーバーに 2 GB 以上の RAM と 2.8 GHz 以上の CPU が搭載された構成です。ここでは、1 台のサーバーに VMM をインストールし、ローカルの SQL Server データベースを使用するため、7 GB のハード ディスク領域が必要です。リモート データベースを使用する場合は、1 GB あれば VMM をインストールできます。ローカルにライブラリをインストールする場合は、さらに 80 GB のディスク領域を確保することをお勧めします。
また、VMM サーバー、すべてのバーチャル マシン ホスト、および VMM によって管理されるすべてのライブラリ サーバーに WinRM 1.1 をインストールしておく必要があります。WinRM は、Web Services for Management (WS-Management) プロトコルをマイクロソフトが実装したものです。WinRM は、さまざまなベンダが提供するハードウェアやソフトウェアとの相互運用と相互管理を可能にする、ファイアウォールに対応した SOAP ベースのプロトコルです。VMM は、WinRM を使用して、VMM サーバー、バーチャル マシン ホスト、およびライブラリ サーバーにまたがった操作を実行します。WinRM 1.1 は、go.microsoft.com/fwlink/?LinkId=103610 からダウンロードできます。
他の前提条件として、.NET Framework 2.0 と 3.0、Windows PowerShell 1.0、およびセルフサービス ポータルで使用される IIS が必要です。その他のすべてのソフトウェア要件は、VMM ソフトウェアのインストール中に確認され、適切なインストーラを入手できるページへのリンクが表示されます。これらのすべての要件が満たされない限り、インストールは続行されません。
VMM のインストールを開始すると、メイン メニューに Virtual Machine Manager サーバー、管理者コンソール、およびセルフサービス ポータルという 3 つの選択肢が表示されます。ここでは、Virtual Machine Manager サーバーから始めて、3 つのコンポーネントすべてを 1 台のコンピュータにインストールします。セットアップ プロセスが開始すると、最初の画面でシステムの前提条件を満たしているかどうかが確認されます。すべての前提条件を満たしていない限り、インストールを続行することはできません。
前提条件を満たしたら、インストール オプション (特に SQL Server データベース関連) を確認する必要があります。VMM では、SQL Server 2005 Express Edition をインストールするか、既存の SQL Server 2005 データベースを使用するかを選択できます。この例では、SQL Server 2005 Express Edition を使用します。
VMM インストール ウィザードの次の手順では、一元管理されるライブラリの場所を指定します。この場所には、VMM サーバー上のローカル ディレクトリ (このローカル ディレクトリに共有が作成されます) か、既存のファイル共有のいずれかを指定できます。既定の場所は、C:\Documents and Settings\All Users\Shared Documents\Virtual Machine Manager Library Files です。
次の手順では、ポートを割り当てます。ここでは、管理者コンソールから主要な VMM サーバー サービスへの接続に使用するポート (ポート 8100)、WinRM が管理機能を実行するために使用するポート (標準の HTTP ポートであるポート 80)、およびバックグラウンド インテリジェント転送サービス (BITS) がバーチャル マシン ホストにファイルを移動するために使用するポート (標準の HTTPS ポートであるポート 443) を構成します。これらの情報をすべて指定し終わると、概要ページが表示され、Virtual Machine Manager サーバーのインストールを完了することができます。
では次に、管理者コンソールをインストールしましょう。システムの前提条件は VMM サーバーの場合と似ており、.NET Framework 2.0 と 3.0、および Windows PowerShell 1.0 をインストールする必要があります。確認する構成オプションは、主要な VMM サーバー サービスへの接続に使用する通信ポートのみです。VMM サーバーのインストール時に構成したように、ポート 8100 を指定する必要があります。インストールの最後に、管理者コンソールのデスクトップ ショートカットを作成するオプションと、セットアップの終了時に管理者コンソールを起動するオプションが表示されます。両方のオプションを選択することをお勧めします。管理者コンソールを初めて起動したときに、サーバーへの接続に関する情報を入力する必要があります。1 台のサーバーにインストールする場合、ポート 8100 を使用して localhost に接続し、Enter キーを押してコンソールを起動します。
最後に、このサーバーにセルフサービス ポータルをインストールしましょう。セルフサービス ポータルをインストールするには、IIS、.NET Framework 2.0 と 3.0、および Windows PowerShell 1.0 が必要です。確認する構成オプションは、セルフサービス ポータルで使用されるポート関連のオプションのみです。1 つ目は主要な VMM サービスに接続するためのポートです。管理者コンソールの場合と同じように、ポート 8100 を指定します。2 つ目は、ポータルの実行に使用するポートです。既定のポートは 80 ですが、おそらくほとんどの構成ではこのポートが既に使用されています。必要に応じて、開いている別のポート (81 など) に変更してください。
インストーラによって Microsoft System Center Virtual Machine Manager 2007 セルフサービス ポータルと呼ばれる Web サイトが作成されます。この Web サイトの構成は IIS マネージャで変更できます。ここで、容易にインストールを行うためのヒントを紹介しましょう。IIS マネージャを起動し、[Microsoft System Center Virtual Machine Manager 2007 Self-Service Portal properties] (Microsoft System Center Virtual Machine Manager 2007 セルフサービス ポータルのプロパティ) ダイアログ ボックスを開きます。Web サイトの ASP.NET の構成を確認し、ASP.NET のバージョンが 2.0 に設定されていることを確認します。セルフサービス ポータルは、ASP.NET 1.1 では動作しません。また、IIS と .NET Framework のバージョンをどのような順序でインストールしたかによって、これらの設定は異なる可能性があります。
IIS のインストールが完了したら、Internet Explorer® で http://localhost:81 を参照して Web サイトを開くことができます。Web サイトを開くときに認証が要求された場合、その原因は Internet Explorer のセキュリティ設定にあります。セルフサービス ポータルは、Internet Explorer のイントラネット コンテキストで実行する必要があります。そのため、ローカル構成のイントラネット サイトの一覧に VMM サーバーを追加することが必要になる場合があります。この変更が完了したら、VMM でセルフサービス ポリシーを作成して使用することができます。

Virtual Machine Manager の機能
VMM では多くの魅力的な機能が提供されますが、最も興味を引くと思われる 2 つの機能は物理-バーチャル機能とバーチャル-バーチャル機能です。どちらの機能も管理者コンソールでサポートされています。VMM 管理者コンソールは Windows PowerShell に基づいて構築されているため、すべてのコマンドは Windows PowerShell でも実行できます。ここでは、管理者コンソールを使用する P2V 処理と Windows PowerShell を使用する V2V 処理について説明します。

物理-バーチャル変換
P2V 変換を実行するには、VMM 管理者コンソールを使用します。変換する物理コンピュータには、いくつかの要件があります。まず、物理コンピュータは、現在のドメインまたは信頼関係のあるドメインのメンバである必要があります。VMM はその物理コンピュータに接続して P2V エージェントをインストールし、必要な情報を転送します。また、変換元のコンピュータでは、サポートされているオペレーティング システムが実行されている必要があります。P2V でサポートされているオペレーティング システムは、Windows Server 2003、Windows 2000 Server、および Windows XP Professional です。変換元のコンピュータで Windows Server 2003 または Windows XP が実行されている場合、VMM はボリューム シャドウ コピー サービス (VSS) を使用してハード ドライブを統合し、バーチャル ハード ディスクにデータを流し込みます。これにより、ダウンタイムを発生させずにコンピュータを変換できるため、P2V イメージを作成するためにサーバーのダウンタイムのスケジュールを設定する必要はありません。Windows 2000 の場合は、Windows PE 起動ディスクを作成して、容易に P2V イメージを作成できます。この例では、変換先として Windows Server 2003 を使用します。
P2V 処理を開始するには、管理者コンソールの右上にある [Actions] (操作) の [Convert physical server] (物理サーバーの変換) を選択します。この操作を行うと、図 5 のような P2V ウィザードが起動します。まず [Select Source] (変換元コンピュータの選択) ページが表示されます。このページでは、変換するコンピュータを指定します。接続して管理する変換元コンピュータの DNS 名と適切なドメイン資格情報を入力します。次の手順では、変換後の VM に名前を付けることができます。
図 5 VMM の 管理用 UI に組み込まれているウィザード ベースの &#xA;P2V 機能
図 5 VMM の 管理用 UI に組み込まれているウィザード ベースの &#xA;P2V 機能
次に、変換元コンピュータから情報を収集する処理が開始されます。[Gather System Information] (システム情報の収集) をクリックすると、変換元コンピュータのオペレーティング システム、ハード ドライブ、およびネットワーク アダプタに関する必要な情報を取得する P2V エージェントがインストールされます。[Next] (次へ) をクリックすると、変換を妨げる既知の問題がないかどうかを確認する検証画面が表示されます。問題が見つかった場合は、考えられる解決策が表示されます。
構成情報の取得が完了したら、変換するハード ディスク パーティションを選択できます。既定では、ブート パーティションが選択されていますが、その他のパーティションも選択できます。変換操作の一環として、保持するパーティションを選択することもできます。P2V はスマート コピー プロセスです。つまり、常にハード ドライブ全体のイメージとサイズを転送するのではなく、指定されたパーティションのデータのみを転送します。
最後に、Virtual Server の起動時の構成や前述の Intelligent Placement の処理など、標準的な VMM の展開手順に進みます。ウィザードの手順が完了すると、[Jobs] (ジョブ) ウィンドウがポップアップ表示されます。このウィンドウには、P2V のすべての処理とその進行状況が表示されます。
既定では、新しく変換された VM は自動的には起動しません (停止状態に変換されます)。また、P2V 処理が中断されることも、変換元コンピュータの実行状態が変更されることもありません。これが P2V の非破壊的な処理です。新しい VM のコンピュータ名、IP アドレス、および MAC アドレスには変換元サーバーと同じものが使用されるため、変換元サーバーをシャットダウンしてから VM を起動する必要があります。変換元コンピュータをシャットダウンしたり、新しく変換された VM を自動的に起動したりする必要がある場合は、その処理を Windows PowerShell のコマンド ラインで実行することができます。この処理の一環として、P2V を実行し、変換後の VM をテスト環境で実行して、すべてのデータが正常に変換されたかどうか確認することをお勧めします。

バーチャル-バーチャル変換
V2V を実行するには、(VMDK ファイル形式の) VMWare バーチャル マシンと、変換先のバーチャル マシン ホストが指定されている有効な VMM のインストールが必要です。VMM の V2V 処理に使用される Windows PowerShell コマンドレットの new-v2v では、monolithicSparse、monolithicFlat、twoGbMaxExtentSparse、および twoGbMaxExtentFlat の 4 つの VMDK ファイル形式がサポートされています。ほとんどの既存の VMDK ファイルは、これらのいずれかの形式に分類されます。
V2V 処理は、オフラインの VMDK ファイルのみに使用できます。ただし、P2V 処理を使用すると、現在実行中の VMware バーチャル マシンを変換できます。VMware バーチャル マシンは、2 つの主要コンポーネントで構成されます。これらは、バーチャル ハード ディスクとしてデータを格納する VMDK ファイルと、バーチャル マシンの構成情報を格納する VMX ファイルです。VMDK ファイルと、関連付けられている VMX をライブラリに配置すれば、変換元サーバーにあるこれらのファイルへのアクセスを許可する必要なく、VMware バーチャル マシンにアクセスして変換を実行できます。
V2V 処理では、VMDK ファイルが VHD ファイルに変換され、ゲスト オペレーティング システムが Virtual Server で動作するようにクリーンアップされて、可能な限り変換元の構成が再現された新しいバーチャル マシンが作成されます。その際、Virtual Server でサポートされているバーチャル ハードウェアに必要な変更も行われます。変換処理の各部分を Windows PowerShell から別々に管理することができるため、新しいバーチャル マシンのホストを割り当てる前に、形式を一括で変換することができます。この例では、VHD の変換および展開を実行します。
V2V は、管理者コンソールと Windows PowerShell のどちらを使用しても実行できますが、この例では Windows PowerShell を使用します。V2V 処理を開始するには、Windows PowerShell ウィンドウを起動して VMM コマンドレットを読み込みます。この操作を行うには、[スタート] ボタンをクリックし、[すべてのプログラム]、[Microsoft System Center]、[Virtual Machine Manager 2007]、[Windows PowerShell—Virtual Machine Manager] を順にクリックします。
[Windows PowerShell—Virtual Machine Manager] というウィンドウが表示されます。ウィンドウ名が異なる場合は、VMM コマンドレットが読み込まれていない可能性があります。Windows PowerShell が起動したら、次のコマンドを実行して new-v2v コマンドのヘルプを確認できます。
get-help new-v2v –full | more
このコマンドを実行すると、new-v2v コマンドの構文と V2V を実行する方法の例が出力されます。この記事の例では、VMM サーバーの名前を vmmserver.contoso.com、変換先バーチャル マシン ホストの名前を vshost1.contoso.com とします。また、VMDK はライブラリ サーバー vmmserver.contoso.com から入手できます。
まず、get-vmmserver コマンドを使用して、V2V の実行に使用する VMM サーバーのコンテキストを指定します。get-vmmserver は、すべての Windows PowerShell コマンドと同様に、動詞と名詞を組み合わせた形式に従い、パラメータの指定にはハイフンを使用します。VMM サーバーを指定するためのコマンドを次に示します。
get-vmmserver –computername "vmmserver.contoso.com"
このコマンドを実行すると、vmmserver.contoso.com が以降のコマンドの VMM サーバー コンテキストとして設定されます。上記のコマンドの結果として、vmmserver.contoso.com に関する情報の詳細な一覧が出力されます。コマンドが不適切であるか構文が間違っている場合、問題の内容を示すエラー メッセージが赤色で表示されます。
次に、変換先のバーチャル マシン ホストを指定します。このバーチャル マシン ホストは、変換後の VMDK や VHD が割り当てられる Virtual Server ホストです。では、Windows PowerShell で次のコマンドを使用して、バーチャル マシン ホストの値を変数 $vmhost に代入しましょう。
$vmhost = get-vmhost –computername
"vshost1.contoso.com"
このコマンドを実行しても、コマンド ウィンドウにフィードバックは出力されませんが、Windows PowerShell プロンプトで「$vmhost」と入力して Enter キーを押すだけで、変数が正しく設定されているかどうかを容易に確認できます。この操作を行うと、$vmhost に格納されている情報 (前述の VMM サーバーに関する情報と同様の vshost1.contoso.com の詳細情報) が表示されます。
バーチャル マシン ホストだけでなく、VMDK ファイルが格納されているライブラリ サーバーも指定する必要があります。次のコマンドは、前述のバーチャル マシン ホストのコマンドと似ています。
$library = get-libraryserver –computername
"vmmserver.contoso.com"
$vmhost と同様に、コマンド ラインで「$library」と入力すると、ライブラリ サーバーの情報が表示されます。
最後に、実際にコマンドを入力して V2V 変換を実行します。この操作を実行するために、get-help 関数を指定して new-v2v コマンドを実行し、表示されたヘルプを参照することもできます。V2V 変換を実行するためのコマンドには、VMX や VMDK が格納されているライブラリ サーバー、変換先のホスト、変換後の VM の名前、および変換される VHD ファイルのパスを指定します。
コマンド ラインで行うほとんどの参照は、変換先のホスト (この例では vshost1.contoso.com) を基準としています。たとえば、インストール パスは VSHOST1 をローカルに参照しています。VMX パスは、ライブラリ サーバーを基準としています。この結果、Windows PowerShell のコマンド ラインは次のようになります。
new-v2v –LibraryServer $library –vmxpath
"\\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx"
–vmhost $vmhost -name "DemoV2V"
–path "C:\VHDs"
ご覧のとおり、ここでは、ライブラリ サーバー $library (VMMSERVER) の \\vmmserver.contoso.com\MSCVMMLibrary\VMDKS\ConvertMe.vmx にある VMX や VMDK を変換して変数 $vmhost (VSHOST1) に格納し、VSHOST1 の C:\VHDs に DemoV2V という名前で展開しています。
コマンドを実行したら、必ず、VMM 管理者コンソールの [Jobs] (ジョブ)ウィンドウに戻って進捗状況を確認することをお勧めします。VMX や VMDK が変換され、VSHOST1 にコピーされます。VSHOST1 では、変換後の VHD が DemoV2V として VM の一覧に追加されます。この処理が完全に終了したら、VMM を使用して新しいバーチャル マシンを起動し、結果を確認できます。

まとめ
ご覧になったとおり、System Center Virtual Machine Manager 2007 では、仮想インフラストラクチャ向けのすばらしい新機能が提供されます。P2V 処理と V2V 処理の説明を読んで、Virtual Machine Manager を使用してこれらの処理をどれだけ容易に行うことができるかということがおわかりいただけたらさいわいです。
VMM は、VM の作成、展開、および保守という IT 管理者の作業を簡略化するように設計されています。Virtual Server 2005 を使用している管理者は、System Center Virtual Machine Manager 2007 のリリースに伴い、Virtual Machine Manager を使用したバーチャル マシン ホストの管理について検討することを強くお勧めします。マイクロソフトは、Windows Server 2008 で新しく提供される Windows Server Virtualization のユーザー向けに、System Center Virtual Machine Manager の次期バージョンで Windows Server Virtualization をサポートする予定です。これは、Windows Server 2008 の最終的なリリース後に提供される予定です。
VMM の詳細およびダウンロード可能なデモについては、microsoft.com/SCVMM を参照してください。マイクロソフトのすべての仮想化製品の詳細については、microsoft.com/virtualization を参照してください。

Edwin Yuen は、System Center Virtual Machine Manager の Windows 企業管理部門に所属するテクニカル プロダクト マネージャです。Edwin は、2006 年 7 月の Softricity 社の買収によって、同社からマイクロソフトに移籍しました。また、民間企業と連邦機関の両方で 13 年間技術コンサルティングを担当した経験があり、ジョンズ ホプキンス大学の電気工学士号も取得しています。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 System Center: Data Protection Manager 2007 を使用してバックアップを強化する
System Center Calvin Keaton

Data Protection Manager 2007 を使用してバックアップを強化する
概要:
  • テープ バックアップから脱却する
  • 継続的なデータ保護 (CDP)
  • ディスク ベースのバックアップ
  • DPM を使用したきめ細かな制御

データ保護市場は、最近ルネサンスのような状態になっています。これまではテープ ベースのバックアップ ソリューションと夜間バックアップによる画一的な方法が使用されてきましたが、
さまざまな新しいテクノロジや方法が、比較的短い期間で導入されています。これらの新しいテクノロジには、ディスク ベースのバックアップや継続的なデータ保護 (CDP)、および一見データ暗号化と同じくらい単純なものもあります。これらの新しい方法の中には、近年のディスク記憶装置の価格の低下、ネットワークとプロセッサのパフォーマンスの向上、および新しい規制要件によって、単に提供されているだけでなく必須の方法となっているものもあります。
この分野において、マイクロソフトはプラットフォームやアプリケーション ベースのソリューションを長年手がけてきました。少し例を挙げるだけでも、NTBackup、Exchange Server、SQL ServerTM バックアップ ツールなど、さまざまなものがあります。
System Center Data Protection Manager (DPM) 2006 は、マイクロソフトのスタンドアロン ソフトウェアとしてデータ保護市場に初めて送り込まれた製品でした。DPM 2006 は、初めてのディスク ベースのデータ保護製品であり、ディスク ベースのバックアップを念頭に置いて一から開発されたデータ保護製品の 1 つとして現在も提供されています。その他のほとんどの製品は、ディスクには不向きなテープ ベースの手法を現在も使用しています。
DPM は、System Center 製品ファミリに含まれています。System Center 製品は、複雑な IT インフラストラクチャの日々の管理を容易にし、コスト効率を高めるために、相互に連携して動作するよう設計されています。System Center ソリューションは、Microsoft® Operations Framework (MOF) と情報技術インフラストラクチャ ライブラリ (ITIL) から派生した自動化方法とベスト プラクティスに基づいており、組織のあらゆるレベルで使用できます。
System Center ファミリには、DPM 以外にもさまざまな製品があります。System Center Configuration Manager は、構成の管理機能とソフトウェアの配布機能を提供します。System Center Operations Manager は、積極的なシステムの監視と自動化を提供します。System Center Capacity Planner は、インフラストラクチャを展開する際のキャパシティの計画と what-if 分析を行うために使用できます (詳細については、microsoft.com/systemcenter を参照してください)。
System Center Data Protection Manager 2006 は、ディスク ベースで行うファイル サーバーやプリント サーバーのバックアップ機能のほか、WAN ベースで行うブランチ オフィスのディスク バックアップ機能を提供していました。この機能は、データセンターのファイル サーバーを保護し、ブランチ オフィスにテープ バックアップ ハードウェアを置かなくても済むようにすることを目的としています。ただし、マイクロソフトのアプリケーションがネイティブにサポートされていなかったため、長期的な保管のためにテープ バックアップを作成する場合は、サードパーティの製品を使用する必要がありました。
DPM の新しいバージョンである System Center Data Protection Manager 2007 では、この DPM 2006 を基盤として、ファイル サーバー、プリント サーバー、およびブランチ オフィスのディスクを保護する堅牢な機能が引き続き提供されますが、Exchange、SQL Server、SharePoint® など、業務上重要なマイクロソフトのアプリケーションのサポートや、テープ バックアップのネイティブ サポートも追加されています。新しいバージョンで機能が大幅に変更されることは珍しくありませんが、今回の DPM では特にその傾向が顕著に表れています。この 2 番目のバージョンでは、さまざまな新機能が追加されているだけでなく、既存の機能も大幅に強化されています。この記事では、これらの新機能と機能強化のいくつかについて説明し、この魅力的な新しいリリースを使用してどのような作業を行うことができるかについて大まかに説明します。

アプリケーションとプラットフォームのサポート
多くのバックアップ ソフトウェア ベンダは、アプリケーションのサポートに "ピーナッツ バター" 方式を採用しています。エンジニアリングの投資を多数のアプリケーションに分散し (薄く伸ばし)、できるだけ多くのデータ ソースをサポート (バターが塗られる面をできるだけ広く) しようとしています。このため、多くのアプリケーションのごく基本的なサポートのみが提供されるという結果になっています。マイクロソフトは、限られたサポートを広範囲のアプリケーションやプラットフォームに提供するのではなく、Windows® プラットフォームで動作するいくつかの特定のアプリケーションを保護することに注力しています。これにより、エンジニアリングの投資をこれらのアプリケーションに対して集中的に行うことができるため、他のバックアップ製品では通常見られない機能が含まれた統合型のバックアップおよび復元エクスペリエンスを提供できるようになります。
Microsoft Exchange のサポートは、DPM 2006 のユーザーから最も要望が多かった機能です。これを踏まえて、DPM 2007 では、Exchange Server 2003 と Exchange Server 2007 のサポートが導入されました。保護はストレージ グループ レベルで提供され、個々のストレージ グループが DPM の UI にオブジェクトとして表示されます。また、必要に応じてこれらのオブジェクトを保護グループに追加し、スケジュールとポリシーに基づいたバックアップを行うこともできます。クラスタ化されたストレージ グループは、1 つのオブジェクトとして表示されるため、クラスタの個々のメンバを追跡したり、メンバ間で保護を手動で同期したりする必要がありません。復元は、ストレージ グループ、データベース、またはメールボックス レベルで実行できます。また、自動化機能を使用して細かいレベルでの回復を行うことができます。この機能は標準の Exchange ツールを使用してデータを回復用ストレージ グループに復元した後、標準の Exchange ツールを使用してさらに細かいレベルのオブジェクト (メールボックスなど) を抽出します (図 1 参照)。
図 1 DPM で提供される Exchange のサポート
図 1 DPM で提供される Exchange のサポート
DPM は、他の一部の Exchange バックアップ ソリューションとは異なり、オブジェクトを抽出して復元するときに Exchange ツール以外のツールを使用したり、Exchange データベースをリバース エンジニアリングしたりすることはありません。したがって、DPM ベースのメールボックスの復元は、完全に Exchange によってサポートされています。
DPM 2007 は、Exchange 2007 のクラスタ連続レプリケーション (CCR) クラスタとローカル連続レプリケーション (LCR) クラスタが完全にサポートされる初めての製品です。また、この製品では Exchange 2003 クラスタもサポートされています。
DPM 2007 では、SQL Server 2000 と SQL Server 2005 がサポートされています。バックアップと復元は、どちらもデータベース レベルで実行されます。リダイレクトされる復元や名前を変更する復元がサポートされるだけでなく、クラスタ化されたデータベース、ミラー化されたデータベース、およびログ配布データベースの完全なサポートも実装されています。
Exchange と同様に、クラスタ化されたデータベースは 1 つのオブジェクトとして DPM の UI に表示されるため、クラスタ化された複数のサーバーの保護を個別に構成する必要がありません (図 2 参照)。DPM で提供される SQL Server のサポートを使用することにより、バックエンド データベースとして SQL Server を使用するさまざまなサードパーティ製のアプリケーションを保護することができます。ファイル保護機能が提供されること、および DPM で提供される SQL Server のネイティブ サポートによって SQL Server データベースが保護されることによって、これらのアプリケーションのサポートが実現されます。DPM の柔軟なスケジュール エンジンを使用すると、ファイル バックアップと SQL Server バックアップを同じ保護グループに追加できるため、この 2 つのバックアップを同時に実行し、同じ管理およびスケジュール インターフェイスを使用することができます。
図 2 バックアップのクラスタ化
図 2 バックアップのクラスタ化
コラボレーション ワークロードは SharePoint 2007 を使用して保護されます。また、Windows SharePoint Services (WSS) 3.0 と Microsoft Office SharePoint Server (MOSS) 2007 もサポートされています。ファームが複数のサーバーにまたがっている場合でも、サポートはファーム レベルで提供されます。したがって、たとえば、3 台の Web フロントエンド サーバー、2 台のサイト コレクション サーバー、および 1 台のデータベース サーバーの合計 6 台のサーバーで構成されるファームは、DPM の UI に 1 つのオブジェクトとして表示されるため、1 つのオブジェクトとしてバックアップされます。また、DPM での復元も 1 つのオブジェクトとして実行されます。
DPM では、ファーム全体の復元がサポートされていますが、サイトやサイト コレクション、および個々のドキュメント、リスト、アイテムの復元もサポートされています。もちろん、古いバージョンの SharePoint も DPM の SQL Server 保護機能を使用することによって SQL Server データベースとして保護することができます。
ファイルと印刷のワークロードも DPM 2007 で引き続きサポートされています。ファイルを開く機能のサポートも追加料金なしで提供されます。また、ファイルおよびフォルダの除外機能とシステム状態のバックアップのサポートが追加されています。さらに、ファイルのサポートが強化され、Windows Vista® と Windows XP もサポートされるようになりました。ただし、これらのクライアント オペレーティング システムのサポートは比較的限られており、基本的にはファイル サーバーとして使用されるシステムのサポートが提供されます。DPM のユーザーは、必要に応じて少数のクライアントを保護することができますが、この規模を拡張して多数のデスクトップを保護することは容易ではありません。
DPM では、Exchange Server、SQL Server、SharePoint サーバー、およびファイル サーバーがネイティブにサポートされているため、Windows 環境で発生するワークロードの大半がサポートされます。また、DPM 2007 では、あまり一般的でないワークロードの事前スクリプトと事後スクリプトもサポートされており、バックアップ時に自動的に実行することができます。この機能により、他のさまざまなアプリケーションやワークロードがサポートされます。このサポートは、Exchange、SQL Server、および SharePoint で提供されるサポートに比べるとそれほど密接に統合されていませんが、データ ソースに関しては非常に柔軟なサポートが提供されます。Oracle など、マイクロソフト以外のいくつかの主要製品をサポートする方法については、DPM TechCenter (technet.microsoft.com/dpm) で提供されるホワイト ペーパーに記載される予定です。
DPM 2007 で特に興味を引く革新的な機能の 1 つに、ホスト ベースの仮想サーバーのサポートがあります。ほとんどのバックアップ製品では、仮想サーバーのゲストが個々のサーバーとしてサポートされていますが、1 つのライセンスやエージェントをインストールして、ホスト レベルでこのような保護を提供する製品はほとんどありません。DPM は、再帰的なボリューム シャドウ コピー サービス (VSS) ライタを使用し、特定の仮想サーバーに 1 つのエージェントを展開することによって、その仮想サーバーでホストされているすべてのゲストを保護します。これらの再帰的な VSS ライタは、ゲストにインストールされているアプリケーションやオペレーティング システムの種類にかかわらず、ゲストまたはゲスト上で実行されるアプリケーション内で動作する VSS ライタを呼び出すことができます。これにより、DPM では、製造元を問わず、ゲストとして実行されるすべてのプラットフォームやアプリケーションを保護することができます。このようなホスト ベースの仮想サーバーのバックアップでは、アプリケーションの一貫性が確保されているため、作成された 1 つのバーチャル ハード ディスク (VHD) イメージを必要に応じて既存または新規のホストに復元することができます。
このようなホスト ベースのバックアップ イメージを使用した復元では、ゲストやスタンドアロン サーバーにインストールされている DPM エージェントを使用したバックアップほどのきめ細かさは提供されませんが、仮想化環境への容易なシステムの回復など、効率を高めるその他の機能が提供されます。

速度、可用性、効率
DPM 2007 では、前のバージョンと比較して、内容の面でも種類の面でもアプリケーションのサポートが強化されたことに加え、よりきめ細かな完全バックアップと増分バックアップが可能になりました。DPM 2006 では最短で 1 時間ごとに同期を実行できましたが、新しいバージョンの DPM では、増分バックアップを15 分ごとに、完全バックアップを 1 時間ごとに実行することができます。サービス レベル契約 (SLA) の要件が比較的厳しくない場合は、完全バックアップを 1 週間に 1 回実行すればよいこともあります。このような場合は、比較的重要でないサーバーのバックアップの頻度を少なくして、重要なサーバーがより厳重に保護されるようスケジュールを設定することができます。DPM エージェントは、DPM サーバーとの同期が 15 分ごとに実行される場合でも、次の同期が行われるまで、保護サーバー上の変更を細かく追跡します。
この新しい DPM エージェントは、保護サーバー上で発生した変更をブロック レベルで継続的に追跡します。この動作は、DPM 2007 用に開発されたまったく新しいボリューム フィルタによって実現されます。このフィルタは、ページ プール メモリに格納されているビットマップから構成されており、保護対象のボリュームのブロックごとに 1 ビットが割り当てられています。
ボリュームにブロックが書き込まれるたびに、ビットマップ内のビットが反転します。このプロセスがプロセッサとメモリに与える影響は、通常のウイルス対策フィルタよりも少なく、変更率に応じたディスク領域を用意する必要はありません。実際、このフィルタによる負荷は、変更率に応じて変化することはありません。この点は非常に重要です。通常、ブロック レベルで変更を追跡するほとんどの構成では、プロセッサとメモリのオーバーヘッドが高くなり、変更率に応じて必要なディスク領域も大きく変化します。変更率が高いと影響も大きくなり、場合によってはシステムのディスク領域が不足することもあります。DPM 2007 では、ボリューム フィルタがプロセッサ、メモリ、およびディスクに与える影響は、変更率にかかわらず一定です。変更率が 1% でも 1,000% でも、このフィルタによって発生するオーバーヘッドはほとんどないため、影響はありません。
しかし、データの変更を追跡する機能は、全体からすると 1 つの機能に過ぎません。DPM 2007 は、保護対象のサーバーの VSS サービスも利用することにより、アプリケーションの一貫性が確保された、信頼性の高い回復が可能なバックアップ イメージを作成します。マイクロソフトによって開発された VSS は、Windows XP と Windows Server® 2003 のバックアップ インフラストラクチャを提供し、特定の時点の一貫性があるデータのコピー (シャドウ コピー) を作成するためのメカニズムです。VSS は、ビジネス アプリケーション、ファイル システム サービス、バックアップ アプリケーション、高速回復ソリューション、および記憶域ハードウェアの読み取りと書き込みを調整することで、一貫性のあるシャドウ コピーを生成します。このため、アプリケーションの一貫性が確保されたバックアップを生成するメカニズムとしては、ほぼ間違いなく現在の市場で最も一貫性と信頼性の高いメカニズムであると言えます。共有フォルダのシャドウ コピーなど、Windows Server 2003 のいくつかの機能は VSS を使用しています。
アプリケーションのバックアップに VSS を使用するほとんどの製品は、VSS レプリカを作成し、保護対象のサーバー上に格納した後、これを使用して、変更の追跡や、アプリケーションの一貫性が確保されたバックアップ イメージの作成を行います。残念ながら、保護対象のサーバー上にレプリカが常に格納されていると、アプリケーションがディスクに書き込みを行うたびに、VSS レプリカを最新の状態に保つためにコピーへの書き込みが発生するため、パフォーマンスが大きく低下します。この動作が発生すると、25％ ものプロセッサ オーバーヘッドが発生し、書き込み時間も非常に長くなります。
DPM はボリューム フィルタを使用して変更を追跡するため、VSS レプリカを常に保持しておく必要はありません。DPM は、完全バックアップを実行するときに VSS レプリカを作成しますが、その後はボリューム フィルタ ビットマップを使用して、レプリカ内で変更されたデータのみを識別します。この変更されたデータは DPM サーバーに移動され、このデータを使用して回復ポイントが作成されます。この処理が完了したら、保護されたサーバー上の VSS レプリカは削除され、ボリューム フィルタがリセットされます。その後は、引き続き変更がブロック レベルで追跡されます。この追跡によって発生するオーバーヘッドはほとんどなく、VSS レプリカやそれに関連するリソースを使用する必要もありません。
このソリューションによって、確実に回復ポイントを復元可能なアプリケーション イメージとして機能させることができるため、保護対象のサーバーと DPM サーバーとの間を移動するデータの量を減らすことができます。
DPM 2007 では、完全バックアップ時でも、保護対象のサーバーから DPM サーバーにデータの完全なコピーは渡されません。渡されるのは変更されたデータのみです。したがって、1 日あたりの変更率が 10％ である 100 GB の Exchange ストレージ グループの完全バックアップを毎日実行する場合、バックアップされるデータは 10 GB のみです。
このように完全バックアップのサイズが減少することにより、スナップショットを作成して回復ポイントをキャプチャする際に、DPM サーバーの記憶域が非常に効率的に使用されます。各スナップショットは、前回の完全バックアップを補完する変更されたデータから構成され、完全バックアップが実行されると自動的に作成されます。アプリケーションのスナップショットを作成する際には、途中で作成された増分バックアップも含まれます。
DPM では、増分バックアップは基本的にログ バックアップであるため、アプリケーションの完全バックアップを作成するたびに、変更されたデータが DPM サーバーに渡され、途中で作成されたログ バックアップと統合されて、複数の回復ポイントを含む単一のスナップショットが作成されます。先ほどの毎日の変更率が 10％ である 100 GB の Exchange ストレージ グループの例では、毎日完全バックアップを実行し、15 分ごとに増分バックアップを実行する場合、各スナップショットには 10 GB の変更されたデータと約 5 ～ 10 GB のアプリケーション ログが含まれます。ただし、この 15 ～ 20 GBのスナップショットには、最大 97 個の回復ポイントが含まれていることに注意してください。
完全バックアップは、少なくとも 1 週間に 1 回実行する必要があります。また、作成できるスナップショットの最大数は、アプリケーション サーバーの場合は 512 個、ファイル サーバーの場合は 64 個です。したがって、1 週間に 1 回完全バックアップを実行し、増分バックアップを 15 分ごとに実行する場合、スナップショットごとに 673 個の回復ポイントが作成され、制限いっぱいの 512 個のスナップショットを使用した場合、340,000 個を超える回復ポイントが作成されます。これほど多くの回復ポイントをディスクに格納しておく必要がある状況はあまり考えられませんが、ジョブのスケジュール設定や特定の時点への復旧に関して DPM が提供する柔軟性とスケーラビリティをよく表わしています。
完全バックアップにログ バックアップが含まれるため、DPM は非常に多くの回復ポイントをごくわずかなディスク領域に効率的に格納できます。しかし、この処理では若干のオーバーヘッドが発生します。また、DPM の処理ではデータの重複を回避するためのコンポーネント (ブロック レベルの変更の追跡など) が使用されますが、処理自体の技術に圧縮や単一インスタンス記憶域 (SIS) は使用されていません。技術的にどのようなものを使用していたとしても、DPM は作成された各回復ポイントの格納にわずかな領域しか使用しません。重要なことは、DPM ではこの作業に従来の圧縮、単一インスタンス記憶域、および重複回避機能を使用しないため、DPM サーバーの記憶域に圧縮、SIS、または重複を回避する記憶域プラットフォームが使用される場合、さらに効率の向上が期待できます。

データを失わない回復と CDP
DPM 2007 で変更された機能のうち最も魅力的なものは、データを失わずにマイクロソフトのアプリケーションを回復できる機能でしょう。この動作は、ブロック レベルの変更の追跡と VSS アーキテクチャのほか、保護対象のサーバー上に格納されている既存のアプリケーション ログとの密接な統合によって実現されます。
大まかに言って、現在の市場では 2 種類のデータの保護および回復方法が提供されています。
レプリケーション ベースのソリューション 従来、継続的なデータ保護 (CDP) と考えられているものです。レプリケーション ベースのデータ保護では、保護対象のサーバーで変更が発生するたびに、変更内容がバックアップ サーバーに渡されます。これは、特定の時点へのデータを失わない回復を目的としたディスク ベースのソリューションです。
非常に魅力的ですが、この方法には大きな欠点がいくつかあります。まず、レプリケーション ソリューションにはアプリケーションの状態という概念がなく、アプリケーションの流動的な部分も意識されていません。したがって、バッファをフラッシュしたり、バックアップの進行中にメモリに保持されているか遷移状態にあるデータについて考慮したりすることはありません。つまり、多くの場合、レプリケーション ベースの回復ポイントではアプリケーションの一貫性が確保されていません。回復を実行することはできますが、アプリケーションは実際に使用できる状態には復元されません。この問題は非常によく発生するため、レプリケーション ベースの CDP を提供しているベンダは、現在の回復ポイントがアプリケーションに対して有効でない場合は別の回復ポイントを試すようマニュアルに明記している場合があります。
このようなアプリケーションの一貫性に関する問題だけでなく、レプリケーション ベースの CDP ソリューションは一般的に非常に高価で、ネットワークとプロセッサのオーバーヘッドが大きく、かなり多くの記憶域を必要とします。さらに、展開先のハードウェアのメーカーが限定されている場合もあります。レプリケーション ベースのデータ保護ソリューションは、多くの顧客が必要としている、保管やオフサイトへの格納を目的としたオフサイトのテープ バックアップにも特に適しているとは言えません。
スナップショット ベースのソリューション 従来のテープ バックアップによるデータ保護方法であり、特定の時点のスナップショットを外部メディア上に作成します。このスナップショットを使用して、特定の時点への回復を実行できます。目標回復時点 (RPO) はスナップショットの頻度によって決まるため、1 日に 1 回バックアップを実行する場合は、24 時間分のデータが失われます。スナップショットの利点は、コストが低いこと、管理が容易であること、ネットワークへの影響が限られていること、およびディスクやテープへの保存に適していることです。また、スナップショットが作成される前にアプリケーションを準備するため、アプリケーションの流動的な部分がバックアップ中に失われる危険性が低下し、アプリケーションの一貫性が確保されたイメージを作成しやすくなります。
スナップショットを使用した最新の方法は、CDP ソリューションに類似しています。これらは、スナップショットの作成回数を増やして、RPO が非常に近い時点になるようにするスナップショット ソリューションです。今では、分単位の RPO を提供し、頻繁にスナップショットを作成することで "CDP に類似している" という表現を完全に排除して、自らを CDP 製品と称している製品もあります。ただしそれでも、復元を実行する数分間分のデータは失われます。
DPM 2006 は確実に CDP ソリューションに類似したスナップショット製品でしたが、DPM 2007 は独自の方法で CDP を確保しています。この DPM の新しいバージョンでは、VSS とブロック レベルの変更の追跡テクノロジを使用して最短で 15 分ごとにスナップショットを作成し、保護対象のサーバー上の VSS スナップショットから変更されたデータのみを渡します。したがって、特定の時点の各スナップショットにはブロック レベルの変更しか格納されないため、非常にサイズが小さくなります。これは、本質的に非常に高度なスナップショットの作成方法です。DPM の革新的な新技術は、Exchange、SQL、および SharePoint との密接な統合です。DPM がアプリケーション ログを認識し、回復時にこれらのログをロール フォワードできるほど、密接な統合が実現されています。アプリケーション ログが利用できる限り (ベスト プラクティスに従って別のドライブに保存していれば利用できるはずです)、DPM は最新の時点のスナップショットからこれらのログをロール フォワードして、データが失われない回復を実行できます (図 3 参照)。
図 3 Data Protection Manager の管理コンソールで提供される回復オプション
図 3 Data Protection Manager の管理コンソールで提供される回復オプション
いろいろな意味で、CDP を確保するためのこの複合的な方法は、2 つの方法の最も良いところを組み合わせた方法であると言えます。それぞれのソリューションの欠点をほとんど解消し、アプリケーションの一貫性を確保したり、スナップショット ソリューションで提供される長期間の保管をサポートしたり、レプリケーション製品で提供される、データが失われない回復機能を利用したりすることができます。

ディスク バックアップとテープ バックアップのサポート
DPM 2007 の新機能を説明するうえで欠かせないのが、テープのサポートが追加されたことです。DPM 2006 では、保護対象のサーバーから DPM サーバー上のディスクにデータを移動するディスク間 (D2D) バックアップのみがサポートされていました。DPM 2007 では、ディスクとテープ メディアの両方がサポートされています。したがって、保護対象のサーバーのディスクから DPM サーバーに接続されているディスク (D2D) や DPM サーバーに接続されているテープ (D2T) にデータを移動したり、保護対象のデータを DPM サーバー上のディスクにまず格納した後、テープに移動して長期間保管したりする (D2D2T) ことができます。
DPM 2007 では、さまざまなテープ ライブラリやオートローダのほか、各種テープ メディアがサポートされています。
DPM で提供されるテープのサポートには、追加料金なしで提供されるソフトウェア ベースのテープ メディアの暗号化機能、暗号化キーの基本的な管理機能、テープの保管状況と保管場所の追跡機能など、高度な機能が多数含まれています。

まとめ
この記事では、System Center Data Protection Manger 2007 で提供されるいくつかの新機能と機能強化について説明しました。これらの機能は、マイクロソフトのプラットフォームとアプリケーションに対応した、一貫性と信頼性の高い、管理が容易なデータ保護を提供することを目的としています。これらの機能が追加された System Center Data Protection Manger 2007 により、Windows アプリケーションおよびプラットフォームのデータを保護するための新しい標準が確立されます。
この製品では、この記事で説明した機能だけでなく、他にも多くの機能拡張が提供されます。これには、Windows と統合されたエンド ユーザー回復、柔軟な帯域幅の調整、高度なコマンド ライン インターフェイスなどがあります。Data Protection Manager 2007 Beta 2 をダウンロードし、これらの機能や他の機能が実際にどのように動作するかをご確認ください。System Center ファミリのすべての製品の概要については、microsoft.com/systemcenter を参照してください。このページから、Data Protection Manager を含む、System Center ファミリのすべてのソリューションに関する情報を参照することができます。

Calvin Keaton は、現在 DPM の製品プランナを務めています。前職では、Microsoft IT データ保護サービスを管理していました。Calvin は、マイクロソフト入社前はデータセンターの運用およびハードウェア業界に 6 年間携わっており、Compaq でデータ センター サイト運用チームの管理者、その後は HP サービスの管理者を務めました。


 System Center: オンライン サービスを利用してソフトウェア インベントリを簡素化する
System Center Paul Bourgeau

オンライン サービスを利用してソフトウェア インベントリを簡素化する
概要:
  • オンライン サービスの基礎
  • インベントリ エージェントをセットアップする
  • インベントリ レポートを取得する

CFO から電子メールで "ちょっとした頼み" があると言われたとします。その頼みごととは、社内のコンピュータがすべて記載されたインベントリが必要であるというものでした。コンピュータが設置されている場所と、各コンピュータにインストールされているソフトウェアがわかる
インベントリが必要であるとのことでした。しかも、今週中に必要だというのです。これが必要になる理由としては、次のことが考えられます (1 つまたは複数)。
  • 来年度の予算を立てる時期になり、ソフトウェア ライセンス用の予算をどの程度用意すべきかを知る必要がある。
  • ソフトウェア監査実施の通知を受けたため、特定の製品のライセンスが十分にあり、監査基準を満たしていることを証明する必要がある。
  • CEO から IT 運用費を削減するように言われ、これを実現する 1 つの方法として、使用するアプリケーションの統一を考えている。
このような状況には、どう対処したらよいでしょうか。
IT 資産管理はこの 10 年間で進化を遂げ、現在組織はソフトウェア資産の有効な管理に注意を移しています。この主な理由としては、ソフトウェアへの投資が一時に比べて大幅に増加していることと、注意が必要な法律、セキュリティ、およびポリシーに関する問題が増加していることが挙げられます。規制を遵守していない状態であることが指摘され、規制を遵守するためにかなりの費用や罰金を支払うことになる可能性があることから、正確なソフトウェア資産管理の必要性が増してきています。
大規模な組織では、通常、ソフトウェアを管理するためのリソースが確保されており、そのためのツールも導入されています。多くの場合、これらのツールは大規模な多目的のソリューションであり、ハードウェアとソフトウェアのインベントリを管理するだけでなく、デスクトップへのソフトウェアの配布の管理やパフォーマンスの監視など、他にも運用支援機能が提供されています。では、このようなソリューションを利用できない組織や、このような複雑なソリューションを実装および管理するためのリソースや専門知識がない組織の場合はどうなるでしょうか。
規模の大きい企業と小さい企業の両方のニーズに応えることが、サービスとしてのソフトウェア (SaaS) という概念を支える要素の 1 つです。マイクロソフトの "Software plus Services" 戦略の下、ソフトウェア資産の有効な管理を支援するサービス ベースのソリューションを開発するための取り組みが進められています。最初に誕生したこのようなサービスの 1 つに、Microsoft® Asset Inventory Service があります。このサービスは、ソフトウェア アシュアランスの契約者に、Desktop Optimization Pack for Software Assurance の一部として今年の終わりに提供されます。
Asset Inventory Service (AIS) (図 1 参照) は、容易に展開および使用できるホスト サービスであり、組織内のコンピュータにインストールされているソフトウェアの情報を収集します。この情報はブラウザ ベースのレポートで参照することができます。また、将来のバージョンでは、マイクロソフト ボリューム ライセンス契約の展開状況を分析する機能の提供も計画されています。
図 1 Microsoft Asset Inventory Service
図 1 Microsoft Asset Inventory Service

オンライン サービスの特徴
オンライン ソリューションを採用する理由は何でしょうか。納得できる理由はいくつかあり、更新プログラムや新しいバージョンがすぐに入手できることや、容易に導入できること、展開および管理費用を抑えられることなどが挙げられます。
オンライン サービスは動的です。Web ページと同様、ユーザー エクスペリエンスを強化し、技術の変化にすばやく対応するために、サービス プロバイダによってコンテンツと機能が絶えず更新されます。この結果、かつてないほどのアジリティ (敏捷性) が得られ、より積極的なデスクトップの管理を可能にする最新の機能、ソリューション、および知識をソフトウェア ベンダが提供できるようになります。
オンライン サービスには、どこからでも利用できるというメリットがあります。今日の IT 環境では、ネットワーク リソースに直接接続する、完全にネットワークで結ばれた PC から、インターネットを経由して各地からリソースにアクセスするリモート ユーザーやブランチ オフィスに至るまで、さまざまな状況があります。Web ベースのメール プログラムを使用するとき以外は会社のネットワークにほとんど接続しないモバイル ユーザーのことも考えると、IT 資産の完全なインベントリを作成することは非常に困難です。これは、特にリモートのシナリオやネットワークに接続されていないシナリオがサポートされていないオンプレミス ソリューションなど、従来のインベントリ ツールにとっては大きな課題の 1 つです。
ただし、すべてでなくてもほとんどの PC がインターネットに接続できるのであれば、特別な手段を実装して社内のクライアント/サーバー ソリューションへの接続を確保しなくても、オンライン サービスを使用して PC を管理できます。管理機能を実行するサービスへのアクセスは、セキュリティが確保されたインターネット接続を経由して提供されるため、インターネットにアクセスできる場所であればどこからでも、管理用アカウントを使用してすべての PC を管理できます。
展開は容易であり、オンライン システムにアカウントを作成するだけで運用を開始できます。環境内にサーバーを設置する必要はなく、新しいネットワーク インフラストラクチャやソフトウェアへの投資も必要ありません。つまり、管理面でも財務面でも、投資を抑えることができます。また、運用中のサポートも容易に行うことができます。通常、新バージョンの提供もサービス契約に含まれるため、組織がアップグレード パスの管理に頭を悩ませる必要はありません。

サービスを使用する
オンライン コミュニティを支援する
Asset Inventory Service と System Center Online サービスは、オンライン サービスの進化に影響を与える可能性があるユーザーで構成される、強力なコミュニティの誕生を後押ししています。たとえば、ソフトウェア カタログは、ユーザー コミュニティによる (完全な Wiki 形式の) 情報の提供が考えられる良い例です。また、サービスのユーザーが、意見、修正、ガイダンスなどを提供することもできるでしょう。
いずれはカタログ自体が、エンド ユーザーがソフトウェアの購入を検討するときに参照できる、価値ある情報源となる可能性もあります。まとまった匿名の統計情報をサービス全体で収集し、ソフトウェア製品やハードウェア製品の導入率を特定できるため、このような作業を行うエンド ユーザーにとって有用なデータになります。
また、コミュニティから、特定のビジネス ニーズを満たすためにどの分野を優先すべきかについてのフィードバックが提供されることで、サービスが全体としてどの方向に進むべきかがわかります。

Microsoft System Center Online では、オンライン デスクトップ管理サービスを提供するために、当面だけでなく、将来のサービスでも Asset Inventory Service がサポートされるプラットフォームを増築する予定です。同サービスは、セキュリティ、スケーラビリティ、および信頼性を考慮して設計されています。AIS は完全なホスト ソリューションであり、すべてのサーバーはマイクロソフトのデータセンターに設置されています。ソリューションを展開する場合は、管理対象のインベントリに追加する各クライアント PC に、小型のソフトウェアをインストールする必要があります。
Asset Inventory Service は、Microsoft.com の管理者によって管理されます。このサービスは多機能な Web アプリケーションであり、Web サービスを使用して各顧客のデータのプライバシーとセキュリティを確保し、クライアント アプリケーションと Web アプリケーションを組み合わせて顧客のデータを保存します。顧客のサイトで実行されるエージェントは、ソフトウェア インベントリをマイクロソフトの IIS Web サービスにアップロードします。また、相互認証 SSL によって、顧客のデータ、クライアントとサーバーとの間の通信、SQL Server™ を使用してデータを保存するサイト、および AIS Web サイトが保護されます。
顧客は、認証に Windows Live™ ID アカウントを使用してサービスにログインし、各自のアカウントを管理したり、レポートを参照したりします。顧客の Web サイトでも SSL を使用することによって、顧客のデータと、SQL Server Reporting Services によって生成されたレポートを保護します。SQL Server データベースはミラー化され、Web サイトは負荷分散されるため、高可用性が確保されます。また、インベントリ データは一定の単位で分割されるため、高いスケーラビリティが確保されます。
Asset Inventory Service を利用するには、マイクロソフト ボリューム ライセンス契約の内容に基づいて Microsoft Desktop Optimization Pack のライセンスを購入します。その後、マイクロソフト ボリューム ライセンス サービス サイト (licensing.microsoft.com) で、Asset Inventory Service のライセンス認証を行います。正常に認証を完了して AIS サービスにログインするには、有効な Windows Live ID が必要です。
ライセンス認証中に、契約の管理者が Asset Inventory Service の管理者を指定します。これは AIS の管理者の Windows Live ID を指定することによって行います。AIS の管理者が自分の Windows Live ID を使用して AIS にログインし、AIS のライセンス認証手続きを完了します。完了したら、他のユーザーの Windows Live ID を指定して、それらのユーザーをサービスに追加できます。

インベントリ エージェント
各 PC にインストールされるクライアントは、Windows® インストーラ (MSI) ファイルとしてパッケージ化された、展開しやすい小型のエージェントです。このエージェントのインストーラはダウンロードすることができます。また、クライアントへの展開をオンライン サービスで管理することもできます (図 2 は、管理およびサポート用のインターフェイスを示しています)。このエージェントの動作は Windows Update エージェントと似ており、System Center Online サーバーと定期的に通信します。この動作の目的は、事前に定義されている頻度でインベントリのプロファイルを更新することと、新しいバージョンのエージェントが提供されている場合にエージェントを更新することです。
図 2 アカウントの管理とクライアントへの展開
図 2 アカウントの管理とクライアントへの展開
インベントリの作成はスケジュールに基づいて自動的に実行されるため、ユーザーが操作を行う必要はありません。また、必要に応じて手動でインベントリの作成を開始することもできます。サービスへの初回接続時に、エージェントは公開キー基盤 (PKI) 証明書の資格情報を使用して、顧客の ID をサービスに提供し、エージェントが実行されているコンピュータで使用される一意の ID を生成します。エージェント自体は、スケジュールが設定されている時間にのみ実行され、ユーザーの邪魔になることがないように設計されているため、最小限のリソースを使用してバックグラウンドで実行されます。アップロードされるデータ ファイルのサイズは小さいため、ネットワーク トラフィックが急増することもありません。
インベントリの作成処理自体は少量で効率的です。エージェントはレジストリ エントリ、MSI データベース、およびその他のソースをスキャンしてインストール情報を収集します。これは、コンピュータに格納されている実行可能ファイルのスキャンと解決を行い、ユーザーの生産性を低下させる、従来の管理システムの動作とは異なります。この処理では、項目の識別と分類に役立つメタデータが含まれたフレンドリ名を使用して、ソフトウェア インベントリのデータが返されるため、これらのデータを使用してさまざまなソフトウェア資産管理作業を行うことができます。

Reporting Services
インベントリ用のデータがアップロードされたら、レポートに表示するためにこのデータを識別およびカタログ化する処理が行われます。インベントリ用のデータは、一元管理されているソフトウェア カタログと比較された後、分類されます。これは、このサービスの最も重要な機能の 1 つです。すべての顧客がソフトウェア インベントリ用にアップロードするデータは、一元管理されているソフトウェア カタログに一意の署名を提供します。マイクロソフトの研究チームは、機密データではない未分類のソフトウェア署名を確認し、ソフトウェアのファミリと分類を特定するための構造的な分類方法を使用して、アプリケーションの種類や機能を基に、その署名が表すアプリケーションを分類します。この分類を利用すると、より詳細なレポートを作成できます。たとえば、ウイルス対策アプリケーションのみを確認したい場合など、関心がある特定の種類のソフトウェアにすばやく範囲を絞り込むことができます。
また、ソフトウェアの署名は、レポートに表示するデータの統合にも利用されます。たとえば、発行元の名前には複数の表記が使用されている場合があります。あるアプリケーションでは発行元を Contoso Software と表記し、別のアプリケーションでは Contoso と表記している場合、レポートではこれらが別の組織として表示されます。発行元とアプリケーション名を統合することで、これらの条件を基に正確なレポートを作成し、データを意味のある形で提供する機能が強化されます。
フィルタを適用し、グループ化を行って、目的のデータセットを取得できたら、SQL Server Reporting Services を使用して、CSV ファイル、Microsoft Word 文書、Microsoft Excel® ワークシート、PDF ファイルなど、サポートされているさまざまな形式でレポートの内容をエクスポートできます (図 3 参照)。このため、追加でデータの分析と操作を行ったり、他の企業管理システムへの入力データとして利用したりすることができます。
図 3 インベントリの照会結果の報告
図 3 インベントリの照会結果の報告
将来このサービスでは、マイクロソフト ライセンスの管理を強化し、ユーザーがライセンスに関する処理を格段に行いやすくなる機能を提供する予定です。ユーザーは各自のマイクロソフト ボリューム ライセンス契約のペアをアップロードできるようになります。このペアを使用して、Microsoft Customer License Position Repository から各ユーザーのライセンス情報が取得されます。このライセンス認証資格に関するデータを使用して、ライセンス認証可能なインストール済みのすべてのマイクロソフト ソフトウェアと、対応するライセンス数をまとめた明細が作成されます。
同じくインベントリの作成時に収集される製品識別子を使用して、インストール済みのソフトウェアを入手経路別に分類することもできます。入手経路は、ボリューム ライセンス、小売、および OEM に分類されます。この機能は、Asset Inventory Service の次のバージョンでリリースされる予定です。

今後の展開
Asset Inventory Service は、System Center Online から提供された最初のサービスですが、これで最後というわけではありません。前述のとおり、System Center Online は、長期的な目標として、総合的なデスクトップ管理サービスを完全にオンライン サービスとして提供することを目指しています。
リリースが検討されているサービスとしては、ハードウェアとソフトウェアの管理とインベントリの作成を行う IT 資産管理サービスや、Windows Software Update Services と同じようにインターネット経由でソフトウェアの更新と配布を行うサービス、オンラインとオンプレミス両用のハイブリッド サービスなどがあります。その他にもさまざまなデスクトップ管理サービスを調査し、このようなシナリオに役立つかどうかを検証しています。
Microsoft Asset Inventory Service の詳細については、microsoft.com/windows/products/windowsvista/enterprise/ais.mspx を参照してください。

Paul Bourgeau は、System Center Online チームのプログラム マネージャです。Assetmetrix 社の買収に伴い、マイクロソフトに入社しました。


 グループ ポリシー: グループ ポリシー用の ADM テンプレートと ADMX テンプレートの内部
グループ ポリシー Jeremy Moskowitz

グループ ポリシー用の ADM テンプレートと ADMX テンプレートの内部
概要:
  • グループ ポリシー テンプレートの種類
  • 適切なポリシー キーと不適切なポリシー キー
  • ADM テンプレートを表示する
  • ADM から ADMX に変換する

ADM ファイルに関しては、好き嫌いが分かれます。また、両方の感情を抱いている人もいるかもしれません。というのは、このファイルは必要なものですが、わかりづらいものでもあるからです。そして、一見ますます混乱させるだけとも思える新しい形式の ADMX ファイルが登場しました。このあいまいな題材を解明するときが来たようです。

ADM ファイルが必要な理由
グループ ポリシーでは、広範な領域を扱っています。グループ ポリシー オブジェクト エディタ (GPOE) を詳しく調べると、グループ ポリシーを使用してさまざまな作業を行えることがわかります。たとえば、ソフトウェアの制限のポリシー、グループ ポリシー ソフトウェア インストール、フォルダのリダイレクトなどがあります。そして、そうです。最も頻繁に使用する、管理用テンプレートもあります。この管理用テンプレート ノードは、ユーザー側とコンピュータ側の両方のノードにあります。ご想像のとおり、ユーザーはユーザー側のポリシー設定のみを、コンピュータはコンピュータ側のポリシー設定のみを受け付けます。
けれども、この管理用テンプレートにある不思議なすべての設定は、どこから来ているのでしょうか。新しいアプリケーションが導入されたとき、潜在的に操作できる設定がいくつかあります。ここで活躍するのが、ADM ファイルです。ADM ファイルには、管理者が指定した設定を受け入れる準備が整っているアプリケーションの領域が記載されています。残念ながら、ADM ファイルで処理できるのは、アプリケーション内のレジストリ設定だけなので、このファイルの機能は非常に限定的なものになります。けれども、アプリケーションによっては、.ini ファイル、.js ファイル、.xml ファイル、データベースなど、別の領域にレジストリ設定を保存している場合があります。

既定の ADM ファイル
では、コンピュータの構成ノードとユーザーの構成ノードの下にある管理用テンプレートの既定のポリシー設定は、そもそも、どのようにして設定されるのでしょうか。GPOE のユーザー側またはコンピュータ側のいずれかのノードで、[管理用テンプレート] を右クリックし、[テンプレートの追加と削除] をクリックすると、標準の構成を作成する既定のテンプレートが表示されます (図 1 参照)。
図 1 既定の管理用テンプレート
図 1 既定の管理用テンプレート
既定のテンプレートを構成するファイルには、次のようなものがあります。
  • Conf.adm - NetMeeting® の設定です。
  • Inetres.adm - Internet Explorer® の設定です (接続、ツール バー、ツール バーの設定など)。このファイルには、Internet Explorer の [インターネット オプション] メニューをクリックしたときに利用できるオプションと同じ設定が含まれています。
  • System.adm - オペレーティング システムの変更点と設定です。コンピュータ側とユーザー側の両方のノードにある管理用テンプレートの設定も、その大半がこの ADM テンプレートに含まれています。
  • Wmplayer.adm - Windows Media® Player 9 の設定です。
  • Wuau.adm - クライアントから Windows® Update サーバーや Windows Server® Update Services サーバーへのアクセスを制御します。

新しい ADM テンプレート ファイルを追加する
マイクロソフト製のツールとサードパーティ製のツールを使用して制限を克服する
ADM ファイルと ADMX ファイルは非常に便利です。これらのファイルを使用して、定義ファイルに情報をまとめて、特定のアプリケーションを制御することができます。しかし、ADM ファイルと ADMX ファイルには制限事項があります。具体的な制限事項としては、これらのファイルでは、以下のような処理を行うことができません。
  • これらのファイルでは、HKEY_LOCAL_MACHINE と HKEY_Current_User 以外のレジストリ ハイブにアクセスできません。他のレジストリ ハイブを操作する必要がある場合、その用途に、ADM ファイルと ADMX ファイルを使用することはできません。
  • これらのファイルでは、REG_Binary 値への追加を実行することはできません。
  • これらのファイルを "1 度だけ実行する" という厳密な設定はできません。
  • グループ ポリシーの更新で "常に再適用する" という厳密な設定はできません。
  • ADM ファイルと ADMX ファイルによる不適切なキーへの書き込みはレジストリに残ります。そのため、ユーザーが管理の対象 (SOM) から外れた場合、つまり、GPO が削除された場合も、その値は削除されません。
マイクロソフトと一部のサードパーティでは、このような制限事項に対応するためのソリューションを提供しています。最近、マイクロソフトでは DesktopStandard 社を買収し、商標を変更したバージョンの DesktopStandard Registry Extension がリリースされました。このツールでは、GPOE 内でウィザードのインターフェイスを使用して、対象のコンピュータで管理する必要があるレジストリ値を設定できます。
現在、Registry Extension ツールを含む DesktopStandard PolicyMaker テクノロジは、Group Policy Preferences と改名され、Windows Server 2008 に同梱されています。Group Policy Preferences により、管理者は、通常グループ ポリシーでは構成できないアプリケーションや Windows コンポーネントを構成できるようになります。また、非常に充実した適用規則に基づいて特定のユーザーやコンピュータにグループ ポリシーを適用することができます。Group Policy Preferences は、Windows Server 2008 で、グループ ポリシーの管理コンソールと Advanced Group Policy Management に完全に統合されます。
Group Policy Preferences については、今月号の TechNet Magazine の Derek Melber の記事「Advanced Group Policy Management コンソールの調査」を参照してください。

これは簡単な操作です。まず、使用する ADM テンプレートを入手します。ADM テンプレートは、GPanswers.com からダウンロードすることもできますが (10 数個の興味深いテンプレートをご用意しています)、マイクロソフト Web サイトで提供されている Office 2003 または Office 2007 用の ADM ファイルを利用することもできます。
[管理用テンプレート] を右クリックし、[テンプレートの追加と削除] をクリックするだけで管理用テンプレートに追加できます (図 1 参照)。既定では、システムによるテンプレートの検索は \Windows\inf ディレクトリ内で行われますが、他の場所にテンプレートを置けないというわけではありません。また、ADM テンプレートについては、見落とされがちな点があります。それは、ADM テンプレートが元の保存場所から追加されると、その ADM テンプレートがグループ ポリシー オブジェクト (GPO) 自体の内容に追加されるという点です。
たとえば、この記事では、GPanswers.com にアクセスして nopassport.adm をダウンロードし、このテンプレート ファイルを c:\temp ディレクトリに保存しました。この ADM テンプレートを適用すると、Windows XP を実行しているコンピュータにユーザーが最初にログインしたときに表示される、"Do you want to add your passport" (パスポートを追加しますか) というメッセージが表示されなくなります。
また、Office 2003 用の ADM テンプレートをダウンロードして、c:\temp に保存しました。しかし、これらのファイルは、このディレクトリ内にはとどまりません。図 2 で、nopassport.adm と Word11.adm を追加したことを確認できます。また、これらのファイルが [テンプレートの追加と削除] ウィンドウの既定のテンプレートの一覧に追加されたことも確認できます。
図 2 GPO に追加された ADM ファイル
図 2 GPO に追加された ADM ファイル
ここで、GPO 自体のファイルがある場所 (具体的には、\\domaincontroller\SYSVOL\domainname\Policies\GUID\ADM ディレクトリ) の中を見ると、nopassport.adm ファイルと Word11.adm ファイルが GPO の一部になっていることを確認できます (図 2 参照)。
なぜこれらのテンプレートが GPO に追加されるのでしょうか。これは、後で別の管理コンソールを使用して、この GPO を編集する場合に、ADM ファイルに含まれている設定を確認できるようにするためです。

読み込んだファイルの設定を表示できない理由
追加した ADM ファイルは、表示されることもあれば表示されないこともあります。この現象は、多くの管理者が ADM ファイルを難解なものだと見なす要因となっています。確かに、これは GPanswers.com では、よく寄せられる質問なので、すぐに解決しましょう。
少なくとも、先ほど追加した 2 つのテンプレートは確認できる必要があります (図 3 参照)。つまり、コンピュータの構成ノードの下に (nopassport.adm に対応する) Nuisances と、ユーザーの構成ノードの下に (Word11.adm に対応する) Microsoft Office Word 2003 という 2 つの新しいノードが表示される必要があるということです。Microsoft® Word 2003 の設定を詳しく見ていくと、図 3 に示すように、非常に多数の設定可能な項目が表示されます。
図 3 構成可能なグループ ポリシーの設定
図 3 構成可能なグループ ポリシーの設定
けれども、新しい Nuisances ノードに設定が表示されないのはなぜなのでしょうか。この現象を理解するには、まず、ADM テンプレートに影響を与える "適切なポリシー キー" と "不適切なポリシー キー" の概念を理解する必要があります。

適切なポリシー キーと不適切なポリシー キー
マイクロソフトが提供しているドキュメントには、次の 4 つのレジストリ領域が、レジストリ外でポリシーを作成するための承認された場所として見なされるという記述があります。
  • HKLM\Software\Policies (コンピュータの設定、推奨の場所)
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Policies (コンピュータの設定、利用可能な場所)
  • HKCU\Software\Policies (ユーザーの設定、推奨の場所)
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies (ユーザーの設定、利用可能な場所)
Word 2003 の ADM ファイルに含まれている設定は、これらの適切な場所に書き込まれますが、nopassport.adm の設定は、HKLM\Software\Microsoft\MessengerService\PassportBalloon に書き込まれます。
上記の 4 つの適切なポリシー キーに書き込まれない設定はレジストリに残るので、GPOE では、このような設定に対しては小さなセキュリティ対策を講じています。レジストリに残るというのは、GPO を強制的に削除しても、設定を戻せないということです。たとえば、nopassport.adm ファイルを追加してドメイン内のすべてのコンピュータで "Do you want to add a passport?" (パスポートを追加しますか) というポップアップ バルーンが表示されないように設定したとしましょう。その後、上司から、そのポップアップ バルーンが表示されることが本当に好きだったと言われたとします。このような状況に対処するのは、容易ではありません。というのも、この時点では、基本的に、この設定を明示的に戻すまでは、すべてのコンピュータでは永久に変更した設定が適用されるからです。もちろん、この設定を戻すという目的だけのために新しいカスタムの ADM ファイルを作成することはできます。けれども、それも決して簡単な作業ではありません。
これに対して、通常のポリシー設定には既定値があります。通常のポリシー設定は、GPO を強制的に削除すると、既定値に戻ります。たとえば、組み込みの ADM テンプレートを使用してコントロール パネルへのアクセスを禁止し、後で気が変わった場合、GPO を強制的に削除すれば、ユーザーはコントロール パネルにアクセスできるようになります。これは、いくつかの特殊な例外はありますが、既定の ADM に組み込まれているすべての設定に当てはまります。
繰り返しになりますが、パスポートに関する表示を抑制するカスタムの ADM の場合、そのポリシー設定が適用された場所では、ポリシーを削除する際に、グループ ポリシー エンジンが設定を元に戻すことはできません。そのため、マイクロソフトは、このように削除できないポリシーの設定を既定で表示しないようにすることで、ユーザーが自ら災いを招くことがないように保護しています。

ADM テンプレートを表示する
ADM テンプレートを表示することは、それほど難しいことではありません。エディタの既定の設定により、設定が表示されませんが、これは簡単に修正できます。ユーザー側またはコンピュータ側の [管理用テンプレート] をクリックし、[表示] メニューの [フィルタ] をクリックします。そして、[完全に管理されているポリシー設定のみ表示します] チェック ボックスをオフにします (図 4 参照)。この操作を行うと、[設定] 列に Passport Solicitation というポリシー設定が表示されます (図 4 参照)。
図 4 GPO のフィルタ
図 4 GPO のフィルタ

Windows XP と Windows Vista のエディタの違い
ポリシー設定の微妙な違いにお気づきでしょうか。まず、図 5 のADM ファイルに含まれているポリシー設定のアイコンをご覧ください。次に、図 6 の適切な Policies レジストリ キーに設定が書き込まれない ADM テンプレートのポリシー設定のアイコンをご覧ください。
図 5 ADM ファイルとアイコン
図 5 ADM ファイルとアイコン
図 6 不適切なキーが使用されていることを示すアイコン
図 6 不適切なキーが使用されていることを示すアイコン
この青と赤のアイコンの違いは、どの設定が削除されずに残り、どの設定が適切に削除されるのかを判断するのに役立ちます。けれども、繰り返しになりますが、設定の書き込み先は、ポリシー設定がどこに適用されるのかに依存します。
Windows Vista® で管理コンソールで ADM ファイルを使用する場合、状況は少し異なります。ADM ファイルは、[従来の管理用テンプレート (ADM)] ノードという専用のノードに表示されます (図 7 参照)。赤い点で表示された設定が、ここでは下向きの矢印が付いた紙のアイコンとして表示されます (ただし、編集中の設定には、小さな "進入禁止" のマークが表示されます)。
図 7 従来の管理用テンプレート ノード
図 7 従来の管理用テンプレート ノード
青い点で示されていた設定 (適切なポリシー キーに書き込みを行う設定) は、小さな紙のアイコンとして表示されます (図 8 参照)。
図 8 適切なキーが使用されていることを示す紙のアイコン
図 8 適切なキーが使用されていることを示す紙のアイコン

ADMX に関する混乱
Windows Vista と Windows Server 2003 には新しい組み込みのグループ ポリシーの管理コンソール (GPMC) が同梱されています。そして、この新しい GPMC には、必要に応じて、古い ADM ファイルを取り除き、新しい ADMX ファイルに切り替える新しい機能が備えられています。では、なぜ ADM 形式のファイルを取り除くのでしょうか。
ADM ファイル自体が GPO のグループ ポリシー テンプレート (GPT) の部分 (SYSVOL に存在する部分) に置かれることを思い出してください。このため、新しい GPO を作成するたびに、すべてのドメイン コントローラ (DC) で 4 MB が消費されます。また、別の管理コンソールで GPO を再編集する場合に、GPO の設定が必要になるため、ADM ファイル自体が GPO の GPT 内に置かれるということも思い出してください。ADM ファイルがなければ、GPO に含まれているカスタム設定を編集することはできません。
ADMX 形式のファイルは、このような問題と決別するのに役立ちます。GPO の内部に直接保存しなければならないものがないので、"SYSVOL の膨張" と呼ばれるような状況に陥ることがなくなりました。SYSVOL の膨張とは、多数の ADM ファイルを含む GPO を保存する必要があり、このような GPO をすべての DC にレプリケートする大きな SYSVOL のことです。この状況を回避するため、新しい ADMX の標準では、セントラル ストアを利用できます。セントラル ストアの役目は、新しい ADMX ファイルを置くことができる場所を 1 つ用意して、各 GPO に ADMX ファイルをコピーしないで済むようにすることです。このしくみにより、SYSVOL の膨張から解放されます。セントラル ストアに関するもう 1 つの重要な事柄は、ADMX ファイルの定義が更新された場合、その更新された ADMX ファイルが Windows Vista のすべての管理コンソールで直ちに使用されることです。
特に ADMX ファイルの作成やセントラル ストアの使用方法の詳細など、ADMX ファイルの形式に関する詳細情報を知りたい方のために、2 つのリソースを紹介します。Darren Mar-Elia が、2007 年 2 月号の Technet Magazine (technetmagazine.com/issues/2007/02/Templates) で ADMX ファイル形式の内部とセントラル ストアの簡単な説明に関する有益な記事を掲載しています。また、私の最新の著書である『Group Policy: Management, Troubleshooting, and Security』のダウンロード可能な章を GPanswers.com の Book Resources にご用意しました。
既に説明したように、Windows Vista の管理コンソールを使用した場合も ADM テンプレートは引き続きサポートされますが、セントラル ストアでは ADM ファイルはサポートされません。この点が少しわかりづらいかもしれないので、例を使用して詳しく説明しましょう。
Windows Vista の管理コンソールを使用して GPO を作成し、既定の設定 (コントロール パネルへのアクセスの禁止など) の一部を少し調整したとしましょう。さらに、カスタムの ADM テンプレートを追加する必要があるとします。カスタムの ADM テンプレートを追加したら、GPO の GPT を調査して何が起きているかを確認し、状況をいくらかはっきりさせましょう。
先ほど行った手順を繰り返すと、ADM テンプレートを追加できます。必要な作業は、GPOE を起動し、ユーザー側のノードとコンピュータ側のノードの両方にある [管理用テンプレート] を右クリックし、[テンプレートの追加と削除] をクリックするだけです。追加されたテンプレートは図 9 で確認できます。
図 9 追加されたテンプレートを表示する
図 9 追加されたテンプレートを表示する
この ADM テンプレートに含まれている設定を実際に確認するには、図 4 で示した操作を実行する必要があります。つまり、[表示] メニューの [フィルタ] をクリックし、[完全に管理されているポリシー設定のみ表示します] チェック ボックスをオフにするという操作です。その後、GPOE を閉じて GPMC に戻ります。図 10 は、Windows Vista の管理コンソールを使用して作成した GPO の [詳細] タブを示しています (この GPO には、覚えやすい名前を付けました)。[詳細] タブでは GPO の GUID を確認できます。GUID は、SYSVOL で特定の GPO を探す場合に役立ちます。
図 10 既定の管理用テンプレート
図 10 既定の管理用テンプレート
GPO の GUID を使用して GPO の GPT を見つけたら、GPO の ADM ディレクトリを開いて、図 11 に示すように手動でインポートした ADM テンプレートが 1 つあることを確認できます。これは、Windows Vista コンピュータが ADM に依存しなくなったことの表れです。Windows Vista では ADM がネイティブに使用されないので、GPO 自体には何も追加されません。ただし、先ほど行ったように ADM を手動でインポートすると、以前のバージョンの Windows と同じように ADM が受け付けられます。
図 11 手動でインポートされた ADM ファイル
図 11 手動でインポートされた ADM ファイル
これは、Windows XP や Windows Server 2003 を実行しているコンピュータで作成された図 12 の GPO とは対照的な動作です。Windows Vista より前のバージョンの管理コンソールを使用して GPO を作成すると、先ほど説明したように、基の ADM ファイルが GPO に追加されます。この GPO は、Windows XP の管理コンソールで作成されたことがわかります。それは、Windows Vista で使用する必要のない ADM ファイルが含まれていることから判断できます。
図 12 Windows XP で作成された GPO
図 12 Windows XP で作成された GPO

ADMX Migrator ツールを使用して ADM から ADMX に変換する
これまで説明したように、Windows Vista では、必要に応じて、引き続き ADM ファイルがサポートされますが、Windows XP では ADM ファイルが、Windows Vista では ADMX ファイルが使用されます。ただし、ADM ファイルはセントラル ストアに追加できないので、Windows Vista の管理コンソールでは ADM ファイルを使用することはできません。
セントラル ストアで ADM に含まれている設定を利用するには、ADM ファイルを ADMX ファイルに変換するか、手動で ADM ファイルを ADMX ファイルとして作成し直す必要があります。さいわい、この両方の機能を実行できるダウンロード ツールがあります。ADMX Migrator ツールは go.microsoft.com/fwlink/?LinkId=103774 でダウンロードできます (このツールは ADM-to-ADMX 変換ツールと ADMX 作成ツールの両方から構成されています)。
ADMX Migrator ツールの MSI ファイルは、Windows Server 2003、Windows XP、または Windows Vista にインストールできます。このツールをインストールすると、アプリケーションには C:\Program Files\FullArmor\ADMX Migrator からアクセスできます。実行するコマンド ライン アプリケーションは faAdmxConv.exe と呼ばれているものですが、このアプリケーションのディレクトリは、Windows パスに含まれていないので、このアプリケーションを実行するには、このアプリケーションがあるディレクトリに移動する必要があります。そのため、私自身は、このツールを使用するときに、このディレクトリを Windows パスに追加します。Windows でパスを設定する方法の詳細については、www.computerhope.com/issues/ch000549.htm を参照してください。
通常、私は、C:\ADMtemp などの一時ディレクトリを作成し、そこに変換元となる ADM ファイルをコピーしています。faAdmxConv.exe に対して指定できるパラメータは数多く存在しますが、ADM ファイルを変換する最も簡単な方法は、ADM ファイルと出力ディレクトリの名前を指定することです。変換元となる ADM ファイルを ADMtemp ディレクトリに置き、このパスに faAdmxConv.exe を追加したら、必要な作業は「faAdmxConv nopassport.adm .」を実行するだけです (末尾のドットは、現在のディレクトリが出力ディレクトリであることを示します)。(現在のディレクトリを表す) ドットまたは他の明示的なパスを指定しない場合、出力先はアカウントのプロファイルの一時ディレクトリになります。図 13 に次の 3 つのコマンドの実行結果を示します。
図 13 ADMX Migrator ツール
図 13 ADMX Migrator ツール
  • dir コマンド - ADM ファイルの有無を確認しています。
  • faAdmxConv コマンド - ADM の名前と現在のディレクトリを表す . (ドット) を指定しています。
  • dir コマンド - 出力ファイル nopassport.admx と nopassport.adml を確認しています。
結果ファイルを直接セントラル ストアに置く前に、オフラインで実行しているコンピュータでテストすることをお勧めします。コンピュータをオフラインにしたら、ADMX ファイルを C:\Windows\PolicyDefinitions ディレクトリに、ADML ファイルを言語固有のディレクトリにコピーします。米国の場合、このディレクトリは C:\Windows\PolicyDefinitions\en-us になります。このコピーの手順例を 図 14 に示します。
図 14 セントラル ストアに ADMX ファイルをコピーする
図 14 セントラル ストアに ADMX ファイルをコピーする
ADM-to-ADMX 変換ツールは、最近、バージョン 1.2 に更新されました。このバージョンでは、数多くの変換バグが修正され、変換中に便利な警告メッセージが表示されるようになりました。過去に ADM-to-ADMX 変換ツールを使用して、エラー メッセージを解決できないことが原因で、このツールの使用を諦めた場合は、現在ダウンロード可能なこのツールのバージョン 1.2 を再度試してみることをお勧めします。
ADM ファイルを変換すると、ADMX ファイル (言語非依存) と ADML ファイル (言語固有) という 2 ファイルが作成されます。この時点で、変換後のファイルをセントラル ストアに置いたり、ローカル コンピュータでテストしたりすることができます。ただし、繰り返しになりますが、この ADMX テンプレートに含まれている設定を実際に確認するには、先ほどの図 4 で行った操作を実行する必要があります。つまり、ここでも [表示] メニューの [フィルタ] をクリックし、[完全に管理されているポリシー設定のみ表示します] チェック ボックスをオフにする必要があるということです。これは、この ADMX ファイルに含まれている設定が、既に説明した適切なポリシー キーのいずれにも書き込まれないからです。

環境の整理
ADMX ファイルだけを使用して、セントラル ストアを使用することが理想的な状態であるのは明らかです。けれども、この状態を実現するには、現在使用しているすべての ADM ファイルを ADMX ファイルに変換し、すべての管理コンソールを Windows Vista (または Windows Server 2008) の管理コンソールに変更し、Windows Vista 以前のバージョンのコンピュータで GPO の編集を行わないようにするという公約を打ち出す必要があります。
この 3 つの手順を完了した場合、事実上、ご使用の環境では ADM ファイルが使用されなくなります。この時点では、GPO に含まれる ADM ファイルは、単に DC の SYSVOL の領域を占有しているだけのものになります。ADMX に最適な環境を実現したら、必要に応じて、SYSVOL にある GPO の GPT に含まれる ADM を削除することができます。そうですね、お腹の中の盲腸のように ADM が残っています。ある時点では役割を果たしていましたが、今は、単なる痕跡でしかありません。ADM ファイルは手動で削除することも、スクリプトで削除することもできます。ただし、上記の 3 つの手順が完了していない場合、ADM ファイルを削除すると、深刻な問題が発生する可能性があることに注意してください。そのため、ADM ファイルを削除するのは、ADM ファイルが確実に必要ない場合に限定する必要があります。
ADM、ADMX、および ADML ファイルの詳細については、「グループ ポリシー ADMX ファイルの管理 : ステップ バイ ステップ ガイド」(go.microsoft.com/fwlink/?LinkId=105019) と「ADMX テクノロジの概要」(go.microsoft.com/fwlink/?LinkId=105032) を参照してください。また、GPanswers.com のニュースレター (GPanswers.com/newsletter) とブログ (GPanswers.com/blog) による中間報告のサービスにも、ぜひご登録ください。

Jeremy Moskowitz (グループ ポリシーの MCSE および MVP) は、グループ ポリシーのコミュニティ フォーラム、GPanswers.com を運営しています。また、グループ ポリシーについての一連の集中トレーニング コースも開催しています。最新の著書には『Group Policy: Management, Troubleshooting, and Security』(Sybex、2007 年) があります。Jeremy には www.GPanswers.com (英語のみ) から連絡してください。


 グループ ポリシー: グループ ポリシーのパフォーマンスを最適化する
グループ ポリシー Darren Mar-Elia

グループ ポリシーのパフォーマンスを最適化する
概要:
  • モノリシック GPO と機能別 GPO
  • グループ ポリシー エントリの処理方法
  • GP が変更された場合の動作

よく「パフォーマンスの観点では、サイズの大きい少数の GPO を使用するべきか、サイズの小さい多数の GPO を使用するべきか」という質問を受けます。この記事では、この質問やグループ ポリシーの設計とパフォーマンスに関連するその他のトピックについて取り上げます。ただし、このような包括的な質問にはよくあることですが、
あらかじめ答えをお教えすることができます。それは、「場合によります」というものです。これはいい加減な答えに思われるかもしれませんが、ここでの目的は、グループ ポリシーの処理を支えるメカニズムを説明することです。GPO に取り組み始めたばかりなのか、既存の GPO が数百個適用された環境の最適化を考えているのかにかかわらず、皆さんがグループ ポリシーを設計する際に、適切な情報を基に判断を下すことができるようになることを目的としています。

モノリシック GPO と機能別 GPO
まず、GPO を実装するための 2 つの方法について説明します。"モノリシック" と "機能別" という言葉は、どのように GPO を設計するかを表しています。モノリシック GPO には、さまざまな領域の設定が格納されています。たとえば、モノリシック GPO は、管理用テンプレート、Internet Explorer のメンテナンス、ソフトウェア インストール ポリシーなどからの設定を含みます。つまり、これらすべての設定が 1 つの GPO に格納されています。対照的に、機能別 GPO は通常 1 つのことしか行いません。たとえば、ある機能別 GPO では、ソフトウェアのインストールのみを行ったり、セキュリティ設定を適用したりします。これまで、たった 1 つのポリシー設定のみが格納された機能別 GPO を目にしたこともあります。ただし、おそらくこれはきわめて特殊なケースです。図 1 は、それぞれの方法の長所と短所を示しています。
Figure 1 モノリシック GPO と機能別 GPO の比較 (Close Figure 1)

課題 | モノリシック GPO | 機能別 GPO
委任/分離 | 難しい。各 GPO に複数の領域の設定が格納される場合があるため、委任は設定レベルではなく GPO レベルで行うことしかできません。 | 易しい。各 GPO には 1 つの領域のポリシーのみが格納されるため、たとえばソフトウェアのインストールの GPO を展開の管理者に委任し、セキュリティの GPO をセキュリティ担当者に委任することができます。
管理と複雑さ | 各 GPO にすべての設定が格納されるため、管理は比較的単純かつ容易です。 | GPO が多くなればなるほど、問題を突き止める場合に確認する場所が増え、特定のユーザーやコンピュータに適用されるポリシーの結果セットを特定することが難しくなるため、比較的複雑です。
パフォーマンス | 特定のクライアント側拡張機能に適用される GPO のいずれかが変更されると、すべての拡張機能に適用されるすべての GPO を実行する必要があるため、パフォーマンスが低下する可能性があります。 | 使用される GPO の数と、その変更頻度によって異なります。動的な環境では、モノリシック GPO に比べてパフォーマンスが高くなる可能性があります。
おわかりのように、あらゆる状況でモノリシック GPO と機能別 GPO のどちらが適切な方法であるかを明言することはできません。実際の環境では、おそらく両方が必要になるでしょう。たとえば、ドメイン全体のセキュリティ ポリシーを作成するときは、機能別 GPO の方が適しているかもしれません。セキュリティ設定のみが含まれた 1 つの GPO を用意することで、この GPO の制御をセキュリティ管理者に委任しやすくなり、他のユーザーがこの GPO にアクセスできないようにすることができます。同様に、GP の管理を OU 管理者に委任する場合は、OU ごとにモノリシック GPO を作成することで、各 OU 管理者がそれぞれのポリシー設定をすべて 1 か所から管理できるようになります。これにより、OU 管理者の作業の複雑さを軽減し、特定の OU のユーザーとコンピュータ用に作成する GPO の数を抑えることができます。
このような設計上の方針は、グループ ポリシーの処理のパフォーマンスにどのように影響するのでしょうか。また、パフォーマンスの影響を最小限に抑えることができる GP の設計を賢明に判断するにはどうすればよいでしょうか。グループ ポリシー インフラストラクチャのパフォーマンスを最大限に高めるには、まず、グループ ポリシーの処理の内部動作を理解する必要があります。

グループ ポリシーの処理を理解する
グループ ポリシーの処理は、Windows® および Active Directory® インフラストラクチャのさまざまな機能に関する一連の複雑なやり取りです。大まかには、グループ ポリシーの処理は 2 つに分けることができます。1 つはコアと呼ばれる、グループ ポリシー インフラストラクチャの処理です。このフェーズでは、Windows グループ ポリシー クライアントが最も近いドメイン コントローラに、DC へのリンクの速度、Active Directory 階層内でのこのクライアントの場所 (つまり、このクライアントが属するサイト、ドメイン、および OU)、およびコンピュータまたは現在ログオンしているユーザーに適用される GPO を照会します (この場合、このクライアントは Active Directory ドメインに参加しているサーバーまたはワークステーションであることに注意してください)。GPO の一覧が作成されたら、次のフェーズであるクライアント側拡張機能 (CSE) の処理に移ります。CSE のフェーズでは、登録されている各 CSE が、自身の領域の設定を実装している GPO を処理します。たとえば、レジストリまたは管理用テンプレートの CSE は常に最初に実行され、特定のコンピュータまたはユーザーに適用されるすべての GPO と、レジストリ ポリシーを実装しているすべての GPO を処理します。
この後の箇条書きの部分では、クライアントとドメイン コントローラとの間のネットワーク通信など、グループ ポリシーの処理サイクルで実行される各手順について詳しく説明します。覚えておく必要があることは、グループ ポリシーがコンピュータとユーザーの両方に適用されるということです。したがって、グループ ポリシーをバックグラウンドで更新するときなど、ポリシーが処理されるたびに、以下に示す処理サイクルが、コンピュータと特定のシステムに現在ログオンしているユーザー アカウントの両方に対して繰り返されます。これは、コンピュータとユーザーに適用される一連のポリシーがそれぞれ異なるためです。ポリシーの適用動作が発生すると、実際には Windows はコンピュータとユーザーの処理サイクルを同時に実行します。各サイクルはグループ ポリシー エンジンのプロセス内の別々のスレッドで実行されます (Windows 2000、Windows XP、および Windows Server® 2003 の場合は Winlogon プロセス、Windows Vista® と Windows Server 2008 の場合はグループ ポリシー クライアント サービスです)。
GP の処理は、以下の 6 つの手順から構成されています。
  1. クライアントが、インターネット制御メッセージ プロトコル (ICMP) を使用してサイト内のドメイン コントローラへの低速リンクの検出を実行し、リンクの速度を特定します。Windows Vista では、低速リンクの検出に ICMP ではなくネットワーク位置認識 (NLA) サービスが使用されます。
  2. クライアントは CSE の状態に関する情報をローカル レジストリから読み取り、最後に処理された GPO を特定します。
  3. クライアントが LDAP を使用して、Active Directory 階層内の同じ場所にある各コンテナ オブジェクトの gpLink 属性を検索します。この検索は、OU レベル (入れ子になっているすべての OU を含む)、ドメイン レベル、Active Directory サイト レベルの順に行います。この検索結果から、実行する処理があるかどうかを評価する GPO の一覧を作成します。
  4. 次に、Active Directory 内の各 GPO を検索し、その GPO の処理に必要なアクセス許可がクライアント (ユーザーまたはコンピュータ) に与えられているかどうかを確認します。バージョン番号、SYSVOL に格納されている GPO のグループ ポリシー テンプレート (GPT) 部分へのパス、およびどの CSE が GPO に実装されているかについても評価されます。
  5. 次に、クライアントはサーバー メッセージ ブロック (SMB) プロトコルを使用して GPT の内容を読み取り、gpt.ini ファイルから GPO のバージョン番号を取得します。グループ ポリシー コンテナ (GPC) と GPT のバージョン番号は、前回の処理サイクルから GPO が変更されていないかどうかを確認するために使用される要素の 1 つです。
  6. 各 CSE が、HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions に登録されている順番で実行され、前回の処理サイクルから GPO が変更されている (コア処理中に確認されます) 場合は、その CSE が実装された GPO を処理します。各 CSE は、更新中に可能であれば、ユーザー ポリシーの結果セット (RSOP) のデータも Windows Management Instrumentation (WMI) に記録します。
このプロセスを細かく分析し、パフォーマンスへの影響を確認しましょう。まず気を付ける必要があるのは、フォアグラウンドの処理とバックグラウンドの処理には違いがあるということです。フォアグラウンドの処理は、コンピュータの場合はシステムの再起動中に、ユーザーの場合はログオン中に発生します。バックグラウンドの更新は、ワークステーションとメンバ サーバーの場合は、既定の 90 分に無作為に時間 (最大 30 分) を加算した間隔で発生します。ドメイン コントローラの場合は、既定では 5 分おきにバックグラウンドの更新が発生します。Windows Vista では、NLA ベースの更新が発生する場合もあります。これは、基本的にはバックグラウンド更新イベントであり、ドメイン コントローラにアクセスできなかったこと (バックグラウンド更新が発生したときにクライアントがオフラインであった場合など) が原因でグループ ポリシーの処理が失敗した場合に発生します。なぜこれらの処理を区別することが重要なのでしょうか。主な理由は、特定の CSE (ソフトウェアのインストールやフォルダのリダイレクトを実行する CSE など) がバックグラウンド更新中に実行されないためです。同様に、バックグラウンド更新中は、ログオンとログオフを実行するスクリプトや、起動とシャットダウンを実行するスクリプトも実行されません。
同様に、このプロセスの手順 1. では、低速リンクの検出処理について説明しました。Windows Vista よりも前のバージョンのシステムでは、クライアントが ICMP を使用してドメイン コントローラへの ping を実行することで、そのドメイン コントローラが利用可能であるかどうか、およびリンクの速度を特定します。計算されたリンクの速度が特定のしきい値 (既定では 500 Kb/s) を下回る場合は、リンクが低速であると見なされます。この場合も特定の CSE (ソフトウェアのインストール、フォルダのリダイレクト、Internet Explorer のメンテナンスなど) が実行されません。これらの条件はすべて、パフォーマンスだけでなく、ポリシーが予期されたとおりに適用されるかどうかにも影響する可能性があります。
おそらく、パフォーマンスに最も影響を与えるポリシー処理サイクルの側面は、コンピュータまたはユーザーに適用する GPO が変更されているかどうかを特定するロジックです。グループ ポリシー エンジンには、前回 GP が処理されてからコンピュータまたはユーザーに変更が加えられていない場合は処理を実行しないようにする最適化機能が組み込まれています。言うまでもなく、この機能は、特に変更の少ない GP 環境でクライアントがポリシーを処理する際にかかる時間に大きく影響を与える可能性があります。次は、変更が発生する状況について詳しく説明します。

グループ ポリシーの変更が発生する状況
では、グループ ポリシーの処理が必要になる変更とは、どのような変更なのでしょうか。さまざまな状況がありますが、最もわかりやすいのは、GPO を変更した場合に、その GPO を処理するクライアントが変更を検出し、その GPO を再処理するという状況です。クライアントは、どのようにして GPO が変更されていることを認識するのでしょうか。これは、GPO のバージョン番号を基に、クライアント内で検証されます。
GPO は、Active Directory に格納されている GPC (各ドメイン内の CN=Policies, CN=System コンテナの下) と、Policies フォルダの SYSVOL に格納されている GPT という 2 つの要素から構成されます。この GPO の各要素には、バージョン番号が含まれています。GPC のバージョン番号は GPC オブジェクトの versionNumber 属性に格納されています。また、GPT のバージョン番号は特定の GPT のルートにある gpt.ini ファイル内に格納されています。また、クライアントは、自身が (コンピュータごとおよびユーザーごとに) 処理した GPO のバージョン番号をレジストリ内に記録しています。コンピュータのバージョン情報は各クライアントの HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\History に、ユーザーのバージョン情報は各クライアントの HKLM\Software\Microsoft\Windows\Currentversion\Group Policy\<ユーザーの SID> に格納されています。
グループ ポリシーの処理が発生すると、この 2 つの要素のうちいずれかが、コンピュータまたはユーザーに適用されるすべての GPO のバージョン番号を確認し、レジストリに格納されている、前回のサイクルで処理されたバージョン番号と比較します。現在の GPO のバージョン番号が (大きいか小さいかにかかわらず) 異なっている場合、その GPO は現在の処理サイクル中に処理されます。異なっていない場合は、以下の変更がない限り GPO は処理されません。GPO の再処理条件となるその他の変更を以下に示します。
  • ユーザーまたはコンピュータに適用される GPO の一覧に変更があった (GPO が追加または削除された)
  • ユーザーまたはコンピュータのセキュリティ グループのメンバシップに変更があった
  • GPO にリンクされている WMI フィルタに変更があった (WMI フィルタが追加または削除された)
上記の変更があった場合、クライアントは処理サイクル中にポリシーを再処理します。ただし、この処理では、パフォーマンスに大きな影響を与える可能性がある、いくつかの細かい点に注意する必要があります。特定の CSE に適用される GPO が 10 個のうち 1 つでも変更されれば、その CSE に適用されるすべての GPO を処理する必要があります。処理は CSE 単位で実行されることに注意してください。ただし、CSE は、処理を制御する優先順位に従ってポリシーを処理する必要があります (ローカルの GPO、サイトにリンクされている GPO、ドメインにリンクされている GPO、OU にリンクされている GPO の順)。この要件を踏まえて、たとえば、あるユーザーに適用される GPO が 10 個あり、各 GPO が Active Directory 階層の異なるレベルにリンクされているとします。また、この 10 個の GPO にはそれぞれ、管理用テンプレートのポリシー設定が実装されているとします。ここで、管理者が管理用テンプレートのポリシー設定を新たに追加して、ドメインにリンクされている GPO を変更したとします。その後、コンピュータまたはユーザーがポリシーを処理し、変更された GPO のバージョン番号が前回処理されたときよりも大きくなっていること、つまり GPO を再処理する必要があることを認識します。しかし、GP の処理の優先順位によって決められた順序を維持するために、すべての GPO に適用される管理用テンプレートの設定をすべて処理する必要があります。このように、1 つの GPO を簡単に変更しただけでも、そのクライアントのパフォーマンスに大きく影響する可能性があります。

モノリシック GPO と機能別 GPO のパフォーマンスを比較する
ここまでは処理サイクルについて、およびグループ ポリシー環境への変更が処理に与える影響について説明してきましたが、モノリシック GPO と機能別 GPO について、およびこれらがパフォーマンスに与える影響についての説明に戻りましょう。
モノリシック GPO は、グループ ポリシーのバージョン管理のしくみが原因で、パフォーマンス上の隠れた欠点を抱える可能性があります。この理由は必ずしも明確ではありませんが、グループ ポリシーの処理では、CSE 単位のバージョン管理という概念がないことに対処する必要があります。あるユーザーに適用される GPO が 3 つあるとします。これらはモノリシック GPO で、それぞれ複数のポリシー領域を実装しています。たとえば、各 GPO に、管理用テンプレート ポリシー、ソフトウェアのインストール ポリシー、およびフォルダのリダイレクト ポリシーが実装されているとします。ここで、管理者がこの 3 つの GPO のうちの 1 つで、管理用テンプレート ポリシーに変更を加えたとします。この変更のために、バージョン番号が変更されます。その後、ユーザーがグループ ポリシーを処理すると、管理用テンプレート CSE が起動し、1 つの GPO が変更されていることを検出するため、これら 3 つの GPO が再処理されます。
ソフトウェアのインストール CSE とフォルダのリダイレクト CSE が実行されるときも GPO のバージョン番号が確認され、1 つの GPO でバージョン番号が新しくなっていることが検出されます。ただし、バージョン番号からは GPO のどのポリシー領域が変更されているかわからないため、念のため 3 つの GPO がすべて処理されます。結果として、モノリシック GPO の実装では、あるポリシーの 1 つの領域が変更されると、別の領域でも処理が実行されます。
確かに、ソフトウェアのインストール ポリシーやフォルダのリダイレクト ポリシーの CSE は、たとえば、アプリケーションが既にインストールされていて再インストールされることがない場合、実際には何の処理も実行しない可能性があります。しかし、どの CSE でもこのような状態になる可能性があるため、モノリシック GPO を設計するときは、この点を考慮する必要があります。頻繁に変更されるポリシー領域がある場合は、そのポリシー領域が実装された GPO を他のポリシー領域から分離しておくことを検討してください。
機能別 GPO の場合、パフォーマンスに関する考慮事項はより明確です。ユーザーまたはコンピュータごとに複数の GPO が存在する場合 (通常、機能別 GPO では特定のポリシー設定を実装するためにより多くの GPO が必要になるため)、グループ ポリシーの処理のコア フェーズ中に、これらの GPO を列挙するためにグループ ポリシー エンジンが費やす時間が増加することになります。ただし、次のセクションで説明するように、このことがパフォーマンスに大きく影響するとは限りません。

グループ ポリシーのパフォーマンスを計測する
結局、グループ ポリシー インフラストラクチャのパフォーマンスを適切に判断するには、実際の環境でグループ ポリシーのパフォーマンスを計測する必要があります。グループ ポリシーのパフォーマンスをモデル化または予測することは、特定の処理サイクルに影響する可能性がある要素の多さを考えると、ほぼ不可能です。このため、GP の処理のパフォーマンスに問題があるかどうかを確認する最も良い方法は、実際に計測を行うことです。パフォーマンスが低いと判断できる要因は何でしょうか。システムのユーザー エクスペリエンスにグループ ポリシーの処理が影響する場合、パフォーマンスが低いと言えます。この基準は組織によって異なりますが、重要なのは問題があることを認識することです。
では、特定のグループ ポリシーの処理サイクルにかかった時間はどのように計測するのでしょうか。この場合も、答えは単純ではありません。Windows Vista または Windows Server 2008 を実行している場合は、イベント ビューアの操作ログを利用できます。イベント ビューアで参照できるグループ ポリシーの操作ログは、"アプリケーションとサービス ログ\Microsoft\Windows\GroupPolicy\Operational" の下にあり、各処理フェーズに要した時間も含め、グループ ポリシーの処理サイクルで実行される各手順の詳細な計測情報を提供しています (図 2 参照)。
図 2 ポリシーの処理時間を示すグループ ポリシーの操作ログのイベント
図 2 ポリシーの処理時間を示すグループ ポリシーの操作ログのイベント
ただし、Windows Vista または Windows Server 2008 環境で作業を行っていない場合、ポリシーの処理にかかる時間を計測するメカニズムは、これほど直接的ではありません。この場合は、詳細な userenv ログを有効にし (support.microsoft.com/kb/221833 で公開されているサポート技術情報の記事を参照)、そのファイルに記録されている特定の処理サイクルのタイムスタンプを確認するか、クライアントのレジストリに格納されている、ポリシーの処理の開始時刻と終了時刻を示す値を使用します。コンピュータの場合、これらの値は次の場所に格納されています。
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\Machine\Extension-List\
{00000000-0000-0000-0000-000000000000}
ユーザーの場合、これらの値は次の場所に格納されています。
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Group Policy\State\<SID of User>\Extension-List\
{00000000-0000-0000-0000-000000000000}
これらの値は FILETIME 形式で保存されているため、通常の日付と時刻の形式に変換する必要があります。また、私が作成した無償のユーティリティ GPTime.exe (gpoguy.com/tools.htm#GP_Time_Utility からダウンロードできます) を使用して、同じ情報を取得することもできます。
Windows Vista または Windows Server 2008 環境がなくても、userenv ログを利用できる場合は、各ポリシー処理サイクルに費やされた時間についての有用な情報を得ることができます。図 3 は、グループ ポリシーの処理のコア フェーズ部分を示す userenv ログの一部です。
図 3 userenv ログの一部
図 3 userenv ログの一部
このログ ファイルの各行にタイムスタンプが含まれています。グループ ポリシー処理サイクルのコア部分は、"ProcessGPOs: Starting user Group Policy (Background) processing ..." のようなイベント以降の部分が該当します。処理サイクルの CSE 部分は、"ProcessGPOs: Processing extension Registry" という行以降の部分が該当します。このログと、ログ内のタイムスタンプを使用して、ポリシー サイクルの各部分に要した時間を特定することができます。

大まかなパフォーマンスを把握する
十分に時間をかけて userenv ログ ファイルを確認すると、パターンを見つけられるようになります。ポリシーの処理にかかる時間を予測することはできませんが、特定の処理サイクルのどの部分に時間がかかるかが大まかにわかるようになります。たとえば、ポリシー処理イベント中に、ポリシーの変更が処理され、その変更によって CSE の処理が発生する場合、GP の処理のコア部分にかかる時間は、CSE 部分に比べて、通常かなり短くなります。
これはほとんどのポリシー領域に当てはまります。その理由は、ほとんどの CSE は処理のコア部分よりも時間がかかる作業を実行する必要があるためです。CSE の操作で最も時間がかかるのは Active Directory と SYSVOL の照会です。たとえば、コア処理に必要な時間と、Microsoft® Office のインストールを実行するソフトウェアのインストール CSE の処理に必要な時間は比べ物になりません。ただし、前回のサイクルから変更が発生していない、通常のポリシーのバックグラウンド更新の場合、この処理サイクルのコア部分にかかる時間と CSE 部分にかかる時間はほぼ同じです。例外は、レジストリ ポリシーの処理です。この処理は、特定のユーザーまたはコンピュータに適用するレジストリ ポリシー設定が数十個または数百個ない限り、きわめて短時間で実行されます。
また、使用されていないという理由で、GPO の中でコンピュータまたはユーザーのいずれかを対象としたポリシーを無効にしても、ポリシーの処理のパフォーマンスにはほとんど影響がありません。いずれかを対象としたポリシーが使用されていない場合に発生するオーバーヘッドは、このことを確認するために実行される Active Directory の照会処理のみですが、ポリシーが無効になっていることを確認するには、それらのポリシーを適用するように実装されている CSE があるかどうかを確認するために実行されるものと同じ照会処理を実行する必要があります。一方を対象としたポリシーを無効にしても、影響はほとんどありません。

最適な GP のパフォーマンスを得るための設計に関する推奨事項
これまではグループ ポリシーの処理のパフォーマンスに関するさまざまな要素について説明してきましたが、ここではパフォーマンスに直接影響する可能性がある、設計に関する推奨事項を一部紹介します。まとめると、重要なポイントは次の 4 つです。
  1. GPO を頻繁に変更する場合は、前述のとおり、1 つの CSE を変更しただけですべての CSE の処理に影響が出る可能性があることを考慮してください。これを回避するには、たとえば、レジストリ ポリシーを頻繁に変更する場合は、レジストリ ポリシーを機能別 GPO (レジストリ ポリシーのみを処理する GPO) に実装するとよいでしょう。これにより、変更があっても他の CSE が処理されずに済みます。
  2. GPO の数について考えるときは、ポリシーの処理は変更があった場合のみ実行され、ソフトウェアのインストール、フォルダのリダイレクト、多数のレジストリ ポリシーの処理、サイズの大きなファイルまたはレジストリ ツリーへのアクセス許可の設定など、"負荷の高い" CSE に最も時間がかかることを考慮してください。多くの場合、コア フェーズで処理する GPO の一覧を Active Directory に照会して取得する作業は、処理サイクルの中で最も時間のかからない部分です。したがって、特定のユーザーに適用されるがレジストリ ポリシーをほとんど変更しない、変更頻度の少ない 30 個の GPO は、定期的に負荷の高い CSE を実行する 5 個の GPO よりも処理時間が短くなる可能性があります。これは、後者の GPO は頻繁に変更されるためです。
  3. ポリシーの処理のパフォーマンスが明らかに低下する動作は回避してください。たとえば、GPO が変更されていなくても CSE を強制的に実行するポリシーを設定 ("コンピュータの構成\管理用テンプレート\システム\グループ ポリシー" の下) することができますが、この設定を行うと、どのサイクルでもポリシーの処理かかる時間が長くなります。
  4. Windows XP と Windows Vista の高速ログオンの最適化を無効にした場合のトレードオフを考慮してください (これを行うには、"コンピュータの構成\管理用テンプレート\システム\ログオン\コンピュータの起動およびログオンで常にネットワークを待つ" のポリシーを有効にします)。このポリシーを有効にすると、フォアグラウンド処理が非同期処理から同期処理に切り替わります。つまり、ユーザーがコンピュータとデスクトップを制御できるようになる前に、コンピュータとユーザーのポリシーを実行する必要があります。ただし、ソフトウェアのインストールおよびフォルダのリダイレクト ポリシーを有効にする際に複数回の再起動やログオンが必要になるという問題を回避できるため、便利な機能として使用できる場合もあります。

まとめ
グループ ポリシーの処理のパフォーマンスを正確に求めることはできませんが、大まかな情報を設計プロセスで参考にして、パフォーマンスの問題を緩和することができます。
処理サイクルのしくみと、どの部分に時間がかかるかを理解することは、パフォーマンスの問題を突き止めるうえで非常に役立ちます。Windows Vista または Windows Server 2008 の操作ログ (以前のバージョンの Windows では userenv ログ) を使用すると、処理サイクルの計測情報を取得できます。CSE の処理が流動的であることと、CSE がポリシーの変更を検出する基準を考慮してください。また、変更が多い動的な環境では、モノリシック GPO よりも機能別 GPO の方が適していることも考慮してください。しかし肝心なのは、グループ ポリシーが Windows 環境の管理を支援するためのテクノロジであるということです。ビジネス ニーズを基にグループ ポリシーの設計を決めることが非常に重要です。その逆ではありません。この記事で説明した、パフォーマンスに影響するいくつかの動作を覚えておくことは、この目的を達成するうえで役立つでしょう。

Darren Mar-Elia は Microsoft グループ ポリシーの MVP です。グループ ポリシーに関する人気サイト (www.gpoguy.com) の制作者であり、『Microsoft Windows Group Policy Guide』(Microsoft Press、2005) の共著者でもあります。また、SDM Software Inc. の創立者で CTO を務めています。彼の連絡先は Darren@gpoguy.com (英語のみ) です。


 グループ ポリシー: Advanced Group Policy Management コンソールの調査
グループ ポリシー Derek Melber

Advanced Group Policy Management コンソールの調査
概要:
  • AGPM のインストールとアーキテクチャ
  • GPO のオフライン編集
  • AGPM による変更管理
  • 障害回復

マイクロソフトは、ごく最近、グループ ポリシー オブジェクトを完全に管理できる製品を開発していた DesktopStandard 社を買収しました。私の個人的な意見ですが、Active Directory を導入している企業では、この Advanced Group Policy Management (AGPM) ツールを使用することをお勧めします。
AGPM は、グループ ポリシー オブジェクト (GPO) のオフライン編集、変更管理、ポリシーを更新するワークフロー、委任などの機能を備えています。今月は、このツール内部のしくみを掘り下げて調査し、この驚くほど役立つ製品の詳細をご紹介します。
まず、このツールの背景について少しご説明しましょう。AGPM は、GPOVault という名前のツールでした。マイクロソフトでは、DesktopStandard 社を買収後、このツールを AGPM と改名し、Microsoft® Desktop Optimization Pack (MDOP) に追加収録しました。現在、MDOP は、Windows Vista® デスクトップのライセンスが、マイクロソフト ソフトウェア アシュアランス プログラムでカバーされているユーザーのみに提供されています。
MDOP に収録されているツールを使用した私自身の経験では、MDOP は、ここ最近、マイクロソフトが提供した製品の中で間違いなく最も好印象を受けた製品の 1 つです。MDOP には、5 つのツールが収録されています。各ツールは単独でも優れたツールですが、組み合わせて使用すると、非常に優れた価値のあるツール群になります。MDOP の詳細については、MDOP Web サイト (windowsvista.com/optimizeddesktop) を参照してください。

AGPM のインストールとアーキテクチャ
AGPM のインストールは、軽量で簡単に行えるようにデザインされており、サーバー コンポーネントとクライアント (管理) コンポーネントで構成されています。サーバー コンポーネントは、ドメインのメンバ サーバーにインストールする必要があります。このコンポーネントのインストールにより、Active Directory®、スキーマなど、他のディレクトリ サービスが変更されることはありません。AGPM は、必要に応じて、ドメイン コントローラにインストールすることもできます。
サーバー コンポーネントをインストールすると、ドメイン ベースのサービス アカウントを必要とするサービスがインストールされます。AGPM では、このアカウントを使用して、ユーザーの代わりに、運用環境のグループ ポリシー オブジェクトにアクセスします。また、委任や GPO の初期管理など、AGPM の全設定を制御する AGPM 管理者も必要になります。
クライアント コンポーネントは、一般的な管理作業を行い、Windows Vista を実行しているコンピュータにインストールする必要があります。通常、クライアントは、ネットワークと Active Directory の管理者のデスクトップ コンピュータにインストールすることになります。クライアントをインストールし、AGPM の設定で AGPM サーバーをポイントすると、アーカイブへの接続が確立されます。AGPM クライアントでは、グループ ポリシー管理コンソール (GPMC) のインターフェイスを使用し、Change Control (変更の管理) ノードとして表示されます (図 1 参照)。
図 1 AGPM は、使いやすさを考慮して GPMC に完全に統合されています
図 1 AGPM は、使いやすさを考慮して GPMC に完全に統合されています
AGPM クライアントがアクセスするファイルは、AGPM サーバーに基本的なファイル形式で格納されます。これは、最も簡単にファイルを格納する方法で、AGPM アーカイブ全体のバックアップ作業が簡略化されます。AGPM の多くの機能では、GPMC の組み込みの API を使用しているので、シームレスに統合された状態で製品を使用できます。AGPM では、データベースを使用しません。GPO を 1 つのフォルダに格納し、マニフェストによって、アーカイブ内にあるすべての GPO の親 GPO への関連付けを管理します。このような管理方法により、すべての GPO には一意な GUID が割り当てられますが、運用環境に GPO を移行すると、展開時に正しい GUID が GPO に関連付けられます。

AGPM によるオフライン編集
AGPM の最も基本的な機能は、GPO を運用環境から切り離して、オフライン環境で編集できることです。既定の GPMC を使用して GPO を編集すると、間違った設定を行った場合、その変更が瞬時に運用環境に反映されるため、悲惨な結果をもたらす可能性があるというのは周知の問題です。
APGM では、GPO を制御することによって、GPO の編集をオフラインで行います。制御された GPO (図 2 参照) は、運用環境に影響を与えることなく、オフラインで編集できる GPO です。
図 2 制御された GPO は、AGPM のアーカイブに格納されるのでオフラインで編集できます
図 2 制御された GPO は、AGPM のアーカイブに格納されるのでオフラインで編集できます
GPO の制御は簡単に行えます。[Uncontrolled] (未制御) タブ (図 3 参照) には、AGPM のアーカイブと関連付けられていないすべての GPO が一覧表示されます。このタブにある GPO を右クリックすると、Control (制御) コマンドを含むメニューが表示されます。[Control] (制御) をクリックすると、GPO が運用環境 (システム ボリューム (SYSVOL)、ドメイン コントローラ上の共有) からコピーされ、AGPM のアーカイブに配置されます。複数の GPO を一度に制御することもできます。この操作を行うには、Shift キーまたは Ctrl キーを押しながら、複数の GPO を選択し、制御する GPO を選択したら、右クリックして [Control] (制御) をクリックします。制御された GPO の編集にも、グループ ポリシー オブジェクト エディタ (GPOE) を使用します。これは、AGPM が完全に GPMC に統合されていることを示すものです。
図 3 制御されていない GPO は [Control] (制御) コマンドを使用してアーカイブに配置します
図 3 制御されていない GPO は [Control] (制御) コマンドを使用してアーカイブに配置します

AGPM による管理の委任
今度は、AGPM による委任について説明します。まずは、GPMC を使用して GPO の管理を委任する方法を検証してみましょう。GPMC には、GPO の作成、GPO のリンク、GPO の編集、GPO の管理、GPO の読み取りという、ユーザーに与えられる 5 種類の委任タスクがあります。
これらの委任は、すべて GPMC のインターフェイスから行えます。委任は、GPMC の他のノードと関連付けられている [委任] タブに一覧されているユーザーとグループ単位で制御されます。ここで関心があるのは、新しい GPO を作成したり、既存の GPO を編集および管理したりするタスクの委任です。
GPMC で GPO を作成する場合、その処理は [グループ ポリシー オブジェクト] ノードと関連付けられている [委任] タブで行います (図 4 参照)。AGPM をインストールすると、この GPO を作成できるユーザーとグループの一覧から、すべてのユーザーとグループを削除できるようになります (GPO を作成するために、[委任] タブから、SYSTEM、コンピュータ、またはコンピュータ グループを削除する必要はありません)。GPO の作成は、AGPM サービスを制御しているサービス アカウントによって行われます。このアカウントには、AGPM で Create GPOs and Deploy (GPO の作成と展開) が委任されているすべてのユーザーとグループの代わりに GPO を作成する権限が委任されています。
図 4 GPO の作成は、GPMC の [グループ ポリシー オブジェクト] ノードの [委任] タブにあるアカウントの一覧で制御されています
図 4 GPO の作成は、GPMC の [グループ ポリシー オブジェクト] ノードの [委任] タブにあるアカウントの一覧で制御されています
この GPO を作成する新しい機能により、作業を分担して、運用環境を保護できるようになります。AGPM の環境から運用環境に移行する前に GPO の作成、構成、および検証まで行うのが理想的な工程です。現在、AGPM を使用しない場合に発生している問題のある構成が運用環境に展開されるという事態は極力避けなければなりません。
GPO の編集や管理に関するタスクの委任についても同様です。GPMC では、このような委任も、各 GPO と関連付けられている [委任] タブで構成します (図 5 参照)。
図 5 GPO の編集と管理の委任は各 GPO に個別に関連付けられています
図 5 GPO の編集と管理の委任は各 GPO に個別に関連付けられています
AGPM をインストールしたら、このような委任は、[グループ ポリシー オブジェクト] ノードにある各 GPO から削除する必要があります。この委任を削除すると、すべての管理者は AGPM 以外で GPO を編集することができなくなります。つまり、GPO に関するすべての管理作業が AGPM で行われるようになり、オフライン編集、変更管理、障害回復などの作業を行うことができます。
AGPM 以外で GPO を編集できないように、ユーザーとグループを削除する作業は、手動で行う必要があります。AGPM をインストールして構成しても、運用環境で GPO を編集できないようにユーザーやグループが削除されることはありません。AGPM サービスを制御するサービス アカウントが、ユーザーに代わって AGPM から運用環境の GPO を編集するので、各 GPO の [委任] タブにユーザーやユーザー グループが指定されている必要はありません (この [委任] タブからコンピュータやコンピュータ グループは削除しないでください)。
GPMC で GPO を編集する権限を委任を削除したら、すべての管理者は、GPMC から GPO を編集することができなくなります (図 6 参照)。
図 6 編集の委任が拒否されると、管理者は GPMC から GPO を編集できなくなります
図 6 編集の委任が拒否されると、管理者は GPMC から GPO を編集できなくなります
この構成を完了するには、AGPM を使用して、GPO を編集する必要がある管理者を適切なアクセス制御リスト (ACL) に追加する必要があります。アーカイブにあるすべての GPO を編集する必要がある管理者については、AGPM を使用して、ドメイン レベルの編集の権限が与えられているグループに、その管理者のアカウントを追加する必要があります (図 7 参照)。ある特定の管理者が、AGPM のアーカイブにある、いくつかの GPO だけを編集できるようにするには、GPO ごとに構成を行う必要があります (図 8 参照)。
図 7 [Domain Delegation] (ドメイン レベルの委任) タブでは、アーカイブにあるすべての GPO を編集する権限を構成できます
図 7 [Domain Delegation] (ドメイン レベルの委任) タブでは、アーカイブにあるすべての GPO を編集する権限を構成できます
図 8 各 GPO を編集する権限については、その GPO の ACL で構成する必要があります
図 8 各 GPO を編集する権限については、その GPO の ACL で構成する必要があります

AGPM による GPO の変更管理
AGPM の優れた機能の 1 つは、アーカイブにある GPO の変更内容を追跡できることです。変更の追跡は自動プロセスなので、設定、構成、または管理の必要がありません。GPO を AGPM クライアントのインターフェイスで管理している場合、すべての変更内容の追跡がバックグラウンドで行われます。
これは、既定の GPMC における GPO を管理する方法に対する大きな機能強化です。既定の GPMC には、GPO の変更内容を自動で追跡する機能はおろか、変更内容を追跡する機能自体がありません。このことは、長年にわたり、多くのグループ ポリシー管理者の悩みでしたが、ようやく解決されました。
AGPM の変更管理機能では、GPO に対して行われたすべての重要な変更内容を追跡します。GPO の変更内容以外に、変更管理システムは、監査や全体的な管理の追跡にも役立ちます。変更管理システムでは、GPO の編集や変更が行われるたびに、詳細情報を監視、追跡、および記録します。これには、GPO の変更日時、変更を加えたユーザー、GPO の元の設定、および GPO の設定の変更内容が含まれます。
変更の追跡はシームレスに行われるので、どのような操作が自動追跡機能をトリガするのかを理解することが重要です。AGPM クライアント インターフェイスでは、[Controlled] (制御) タブで GPO を右クリックし、[Check-out] (チェックアウト) をクリックすると、この自動プロセスがトリガされます (図 9 参照)。
図 9 GPO をチェック アウトすると変更内容を追跡する自動プロセスがトリガされます
図 9 GPO をチェック アウトすると変更内容を追跡する自動プロセスがトリガされます
詳細については、この後で説明しますが、GPO を編集するには、この手順が必要です。GPO をチェック アウトすると、何も変更しない状態で、すぐにチェック インしても、この操作のアーカイブが作成されます。GPO は企業に不可欠なものなので、このツールでは、実際に変更されていなくても変更の可能性があるものを追跡します。
AGPM では、GPO の変更内容を、その変更を行った管理者ごとに追跡するメカニズムが必要なので、チェック アウト操作は必ず行う必要があります。2 人の管理者が同時に同じ GPO をチェック アウトすることはできません。AGPM には、管理者がチェック アウトした GPO をチェック インできないという状況に備えて、AGPM 管理者が、その GPO をチェック インできるメカニズムが用意されています。

AGPM による GPO の編集
AGPM クライアントがインストールされていれば、AGPM のアーカイブにアクセスできます。AGPM ツールで編集またはフル コントロールの権限が委任されると、アーカイブに格納されている GPO を編集できるようになります。GPO をチェック アウトしたら、GPO を右クリックし、[Edit] (編集) をクリックすると GPO を編集できるようになります (注 : AGPM のアーカイブに格納されている GPO の一部しか編集できない場合、アーカイブにあるすべての GPO ではなく、一部の GPO に対してしか権限の委任が与えられていない可能性があります)。
マイクロソフトは、DesktopStandard 社の買収により、PolicyMaker (Group Policy Preferences と改名) を手に入れました。この一連のグループ ポリシーの機能は、Windows Server® 2008 に同梱される GPMC で提供されます。Group Policy Preferences を使用すると、通常グループ ポリシーでは構成できないアプリケーションや Windows コンポーネントを構成できるようになります。また、非常に充実した適用規則に基づいて特定のユーザーやコンピュータにグループ ポリシーを適用することができます。Group Policy Preferences は、Windows Server 2008 の GPMC と AGPM と完全に統合されています。

AGPM による GPO の展開
AGPM は、効率とワークフローを重視したデザインになっています。AGPM を使用することで GPO の管理が安定し統制が保たれるので、GPO を編集する権限だけを持ち、運用環境に展開する権限を持たない管理者がいても問題ありません。AGPM では、インターフェイス、ダイアログ ボックス、および作業メカニズムを使用して、このような作業分担を非常にスムーズに行うことができます。たとえば、編集の権限しか持たない管理者が GPO を展開しようとすると、システムによってブロックされます。この際、管理者には、展開の権限が委任されている管理者に問い合わせるように指示するダイアログ ボックスが表示されます。このワークフロー機能では、宛先と CC に設定されている両方の受信者に対して電子メールを送信し、GPO を特殊な状態に移行します。この特殊な状態は、AGPM インターフェイスの [Pending] (保留中) タブで確認できます。このタブの GPO には "Pending Deploy" (展開保留中) というフラグが設定されるため、管理者は各 GPO の状態と各 GPO に対して行われた操作をすぐに把握することができます。
保留中の GPO を展開するのに必要な作業は、展開の権限を委任されている AGPM の管理者が、GPO を右クリックして、[Approve] (承認) をクリックするだけです。展開する必要のある GPO が [Pending] (保留中) タブではなく [Controlled] (制御) タブにある場合、必要な作業は、展開する権限を持っている管理者が、GPO を右クリックして、[Deploy] (展開) をクリックするだけです。展開の権限を持っている管理者が操作を行うと、GPO は瞬時に運用環境に展開されます。

AGPM による GPO の設定レポートと比較
GPMC には、強力な機能を備えた [設定] ダイアログ ボックスがあります (このダイアログ ボックスには、同じ名前のタブからアクセスできます)。このダイアログ ボックスでは、GPO で構成されているすべての設定の完全なビューが提供されます。このビューにより、約 3,000 もあるグループ ポリシーの設定のうち、どの設定が構成されているのかを把握することができます。
AGPM では、変更された GPO のアーカイブが提供されるので、GPMC の [設定] タブでは、変更された GPO で構成されている設定を確認することができません。AGPM のインターフェイスでは、この機能に代わるソリューションと追加機能が用意されています。
GPO の設定を確認する場合は、まず、すべての変更内容の履歴を確認することをお勧めします。履歴を確認するには、AGPM の [Controlled] (制御) タブで GPO をダブルクリックします。次に、GPO の任意のバージョンを右クリックし、[Settings Report] (設定レポート) をクリックします。この操作により、選択したバージョンの GPO で構成されているすべての設定を含むレポートが作成されます。このレポートは、わかりやすい HTML ファイルで作成されますが、XML 形式で作成することもできます。
これも有益な機能ですが、同じ GPO の 2 つの異なるバージョンを比較するという、さらに便利な機能があります。この機能を使用すると、ある 2 つのバージョンの変更履歴を確認したり、同じ GPO のまったく異なる 2 つのバージョンを比較したりすることができます (この機能では、展開保留中の GPO と運用環境で使用している GPO の相違点を確認できるので、展開保留中の GPO がある場合に非常に便利です)。このレポートを表示するには、履歴ビューで 2 つの GPO を強調表示し、どちらか一方を右クリックします。
相違点レポートで使用されている色分けは、変更した GPO を実際に展開する前に、展開保留中の GPO の変更内容を確認する必要がある場合に特に便利です。赤で表示されている設定は、運用環境の GPO から削除されたもので、展開保留中の GPO では利用できないものです。青で表示されている設定は変更されたもの、緑で表示されている設定は、運用環境の GPO にはなく保留中の GPO にしかない新しい設定です。
この AGPM の機能を使用すると、GPO の設定を手動で比較するという面倒で時間のかかる作業を短時間で済ませることができます。また、すべてのバージョンのレポートを作成して印刷することができるので、長期にわたって、GPO の記録を作成するのに最適な方法でもあります。

AGPM による GPO の障害回復
GPO に加えた 1 つの変更が、ネットワーク上の複数のコンピュータに大きな損害を与えることがあります。既定の GPMC を使用しても、このように問題のある構成を修正することはできます。ただし、運用環境の GPO の変更前と変更後の GPO のバックアップを作成するという手動で行わなければならない作業が適切になされていることが条件となります。バックアップが作成されていない場合、この惨状から回復する作業は、想像以上にたいへんなものです。
AGPM を使用すると、このような状況にも簡単に対応できます。AGPM では、GPO のライフ サイクルにおいて、すべての GPO の完全なバックアップが作成されます。つまり、このような問題が発生した場合に必要な作業は、GPO の履歴を表示して、再展開する GPO のバージョンを選択するだけで良いのです。
AGPM を使用すると、グループ ポリシーをシームレスに管理できます。管理者は、長年にわたって、GPO をオフラインで管理する機能を切望していました。AGPM では、この機能を使いやすく洗練された機能として提供しています。また、非常に堅牢な変更管理のソリューションが提供され、変更された GPO の主要な分野を追跡できるだけでなく、GPO の比較や障害回復を簡単に行うことができます。AGPM に組み込まれた委任モデルを使用すると、GPO を編集する際には、すべての管理者が AGPM を使用するようにすることができます。AGPM では、GPO の変更内容を自動バックアップする機能が提供され、運用環境の GPO で発生した障害を取り除くことができます。このサービスでは、非常に多くの機能が提供されるため、この記事ですべてをご紹介することはできません。AGMP のマニュアルでは、テンプレート、ノード リンクの回復、SMTP の構成などに関する詳細情報が提供されていますので、他の機能や詳細については、そちらを参照してください。

Derek Melber は、フリーランスのコンサルタント、トレーナー、および著者です。Active Directory、グループ ポリシー、セキュリティ、デスクトップ管理などに重点を置いた、マイクロソフト テクノロジの教育および普及活動を行っています。定期的に、オンラインで、または書籍として文献を発表しており、『The Microsoft Windows Group Policy Guide』(Microsoft Press、2005 年) など、10 冊以上の技術書を執筆しています。彼の連絡先は derekm@braincore.net (英語のみ) です。


 編集長から: 皮肉家を納得させる
編集長から
皮肉家を納得させる
Joshua Hoffman

私は皮肉家です。 嘘ではありません。一般に、私たちニューヨーカーは信じやすく控えめであるという素朴な性格を持っていることで知られていますが、ときどき冷酷な心がリンカーン トンネルをくぐり抜けてきて、それを台無しにしてしまうことを私は知っています。皮肉家である私は、物事に疑問を持つ傾向があります。私を納得させるのは大変です。
レドモンドの同僚たちは聞きたくないかもしれませんが、マイクロソフトが数年前 System Center ブランドを発表したとき、私は少しひねくれた考えを持ちました。誤解しないでください。私は SMS を非常によく使用しています。以前デスクトップ展開および管理の専門家を務めていたころ、Systems Management Server (Version 2.0 以降ですが) は私にとって非常に重要なツールでした。しかし、System Center ブランドが進化し、製品ラインが強化されるに従って、疑問を持ちやすい私本来の性格が顔を出してきました。
本当にこれは必要だったのだろうか、最終的にユーザーの役に立つのだろうか、製品ラインの多様化が、慣れ親しんだ主要管理製品に悪影響を及ぼさないだろうか、といった疑問が浮かび上がりました。
当初の不安はありましたが、System Center が私を納得させてくれたことは認めざるを得ません。SMS と MOM (現在は Configuration Manger と Operations Manager として知られています) は世界に通用する管理製品へと進化し、リリースごとに強力な (驚かされることもある) 新機能が追加されています。また、新製品が追加されたことで既存の製品の価値が低下することもなく、逆に大きく増幅しました。
最近の記事では、新しい Configuration Manager 製品や Operations Manager 製品だけでなく、System Center 製品 (Capacity Planner、Desired Configuration Monitor、Essentials など) 向けの初期に発表されたその他のアドオンをいくつか紹介しました。ご覧いただければわかりますが、今月の記事では非常に強力な新しい追加機能がいくつか紹介されています。
まず、Edwin Yuen が、仮想化インフラストラクチャの集中管理や移行を妨げる厄介な問題の解決を行い、古いハードウェアを新しいバーチャル マシンに統合できるようにするために、Virtual Machine Manager 2007 がどのように役立つかについて説明します。Calvin Keaton は、Data Protection Manager の新しいバージョンについて説明します。このバージョンでは、標準的なユーザー データ (ドキュメントなど) だけでなく、Exchange Server に格納されている重要な情報などの企業データも対象とする強力なディスク ベースのバックアップ ソリューションが提供されます。最後は Paul Bourgeau が、初めてのホストされた System Center ソリューションである Asset Inventory Service を紹介します。
System Center 製品の新しい追加機能に関する皆さんの意見をお聞かせください。私の連絡先は tnmag@microsoft.com (英語のみ) です。 —Joshua Hoffman

次のマイクロソフト技術支援スタッフに心より感謝します。Karandeep Anand、Joseph Dadzie、Ray Hayes、KC Lemson、Bill Scheidel、Jeffrey Snover、Mike Stephens、Kevin Sullivan、Jim Truher、Winni Verhoef。


 レター: 読者の皆さんからの声
レター
読者の皆さんからの声

VMRCplus の問題
2007 年 10 月号の「ユーティリティ スポットライト」(technetmagazine.com/issues/2007/10/UtilitySpotlight) の説明に従って、VMRCplus をダウンロードしましたが、リモート コンピュータに接続しようとすると RPC エラーが発生します。Virtual Server の管理インターフェイスが Web ベースなので、このアプリケーションでも、単に既存の Web テクノロジの操作性を向上しただけの Web インターフェイスが使用されていると考えていました。しかし、残念ながら使用されているのは COM API でした。
- blogs.technet.com/tnmag への投稿より

VMRCPlus では Virtual Server に付属する VMRC のリモート コントロール クライアント (Web インターフェイスではなく実際のクライアント アプリケーション) と同じネットワーク パスが使用されます。つまり、以下のポートにアクセスできる必要があります。
  • ポート 5900 (VMRC サーバーの既定のポート)
  • ポート 1024 (管理 Web サイトの既定のポート)
  • ポート 137 とポート 138 (Kerberos V5 のチケット保証機関の TCP ポートとユーザー データグラム プロトコル (UDP) ポート)
  • ポート 135 (RPC エンドポイント マッパーで使用されるポート)
詳細については、microsoft.com/technet/prodtechnol/virtualserver/2005/proddocs/vs_operate_using_VMRC_manageVMs.mspx を参照してください。

Windows PE を使用する
「Windows PE の概要」(2006 年 9 月号、technetmagazine.com/issues/2006/09/WindowsPE) を読みました。Windows® PE を、ネットワークをサポートする VMWare ワークステーション環境で実行しようとしているのですが、Windows PE で NIC ドライバを使用してネットワークにアクセスすることができません。Windows PE イメージを含む ISO ファイルを使用して VMWare から起動しています。VMWare は起動してコマンド コンソールが表示されますが、「ipconfig」と入力しても IP アドレスが表示されません。また、DHCP サーバーから割り当てられたアドレスも解決されません。
- John C

VMWare でインストールされる既定の NIC が、(Windows PE 2.0 の基盤である) Windows Vista® でサポートされていないことが問題の原因です。この問題を解決するには、バーチャル マシン構成ファイル (VMX ファイル) で、以下のように他の種類の NIC を指定する必要があります。
ethernet0.virtualDev = "e1000"
この作業は、メモ帳などのテキスト エディタで VMX ファイルを編集するなど、手動で行う必要があります。GUI で編集することはできません。上記のように変更すると、既存の仮想化された組み込み NIC が、Windows Vista でサポートされている Intel の 1 GB の NIC に置き換えられます。この変更を行うと、ネットワーク ドライバを追加する必要がなくなるというのが最大のメリットです。

SQL Server クエリのパフォーマンスを最適化する
「SQL Server クエリのパフォーマンスを最適化する」(2007 年 11 月号、technetmagazine.com/issues/2007/11/SQLQuery) では、コストが最も高い 20 個のクエリを特定する SQL Server™ 2005 用の例が紹介されていました。しかし、このクエリは SQL Server 2000 では実行できませんでした。旧バージョンで実行できる例を教えていただけないでしょうか。
- Arun N

残念ながら、SQL Server 2000 でこの情報を取得する方法はありません。SQL Server 2000 では、プロシージャ キャッシュ内のクエリに関して、このような情報を収集して公開する機能がありません。このような情報は、SQL Server 2005 で導入された新しい動的な管理ビューでのみ使用できます。

MIISWorkflow アプリケーションを実行できない
「シングル ステップのプロビジョニング ワークフローを構築する」(2007 年 5 月号、technetmagazine.com/issues/2007/05/Workflow) を読み、この記事について、いくつか質問があります。MIISWorkflow アプリケーションはサポートされているのでしょうか。また、.NET Framework 2.0 と互換性はあるのでしょうか。Visual Studio® の外部でアプリケーションを開こうとすると、"サービスは利用できません" というエラーが発生します。デバッグ モードでは問題なく実行できましたが、Visual Studio を終了してアプリケーションを直接開こうとすると、エラーが発生します。アプリケーション プールが停止したり、"サービスは利用できません" というエラーが発生したりする原因を教えていただけないでしょうか。
- Cliff C

MIISWorkflow アプリケーションは公式にサポートされたマイクロソフト製品ではなく、説明を行うために提供しているサンプル コードです。
TechNet フォーラムの ID 管理のサイト (forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=540&SiteID=17) は、ID 管理に関する問題を話し合うのに最適です。このフォーラムでは、コミュニティの専門家やマイクロソフト製品グループのメンバからアドバイスを受けることができ、このような問題に対する直接的なサポートを受けることができます。


 ツールボックス: IT プロフェッショナル向けの新製品
ツールボックス
IT プロフェッショナル向けの新製品
Greg Steen

Windows PowerShell を使いこなす
PowerGUI
powergui.org
まだ Windows PowerShellTM を使用したことがなくても、近いうちに使用することになるでしょう。Windows PowerShell は、Windows Server® の世界では主要な管理ツールになりつつあります。初心者にとっては、Exchange Server 2007 をスクリプトで管理するための基本ツールとなっています。
Windows PowerShell をそのままの形で最大限活用するには、かなりの量の構文、コマンドレット、および一般的な構造を覚える必要があります。もちろん、それだけの時間 (や精神力) はないと思います。しかし、スクリプトを管理するための一元的かつグラフィカルな管理コンソールがあったとしたらどうでしょう。また、カスタマイズ可能なテンプレート、IntelliSense® のような編集機能、およびスクリプトを共有するためのコミュニティがユーザー インターフェイスで提供されたとしたら、魅力的に感じるのではないでしょうか。このような環境があれば、必要な作業のスクリプトをすばやく作成してそれらの保存場所を把握しておき、いつでも機能を再利用および参照することができます。
ご心配なく、これは冷やかしではありません。この Windows PowerShell 用の GUI 環境は、Quest Software が開発したフリーウェア製品の PowerGUI によって提供されます。このコラムの執筆時点ではまだベータ版ですが、このアプリケーションでは、Microsoft® 管理コンソール (MMC) スナップインの強化版と言うこともできる、使いやすく拡張可能な管理用 GUI が提供されます。
この GUI 内では、提供されているスクリプトや自分でカスタマイズしたスクリプトをダブルクリックして実行し、返されたデータセットを表形式で表示することができます。このデータに列フィルタや値フィルタを適用して、必要な情報を取り出すことができます。また、特定のニーズに合わせて独自の列を追加し、計算された値や独自の結果を提供することもできます。
この GUI から、Windows PowerShell プロンプトや、このアプリケーションに組み込まれているスクリプト エディタを起動することができます。このスクリプト エディタでは IntelliSense のような基本的な環境が提供され、利用可能なコマンドレットの構文のほか、検索と置換、印刷、切り取り、コピー、貼り付けなど、標準のファイル機能や編集機能が提供されます。また、ステップにブックマークを設定することもできます。
さらに PowerGUI には、データセットに適用できる多数のカスタマイズおよび拡張可能なアクションが用意されています。たとえば、ローカル システム サービス用のスクリプトを使用すると、指定したサービスの開始、停止、一時停止、およびプロパティの設定を行うことができます。もう 1 つの便利な機能として、スクリプト間のリンクを追加する機能が挙げられます。これを利用すると、共通の要素でスクリプトをつないで、必要な情報を取得できます。たとえば、特定のグループに属するユーザーの一覧を取得して、それらのユーザーのホーム ディレクトリに格納されているデータの量を表示するスクリプトにこの一覧をリンクさせることができます。PowerGUI には、上記の機能のほか、データを XML、CSV、HTML、およびクリップボードに書き出すことができるレポートおよび校閲用の一般的なアクション スクリプトもいくつか組み込まれています。
ユーザー独自のスクリプトを追加するか、提供されているテンプレートの 1 つをカスタマイズして、スクリプトの個々のアクションと共通のアクションを拡張することもできます。表示されるスクリプトのプロパティ ウィンドウを使用して、スクリプトを編集したり、単にスクリプトの動作を確認したりすることができます。
もう 1 つの価値ある機能は、PowerGUI Web サイト コミュニティのライブラリです。ユーザーはこのライブラリを利用して、システム管理作業に役立つスクリプトを共有およびダウンロードすることができます。このライブラリでは、Active Directory® の管理、Exchange Server の管理、Microsoft Operations Manager の作業、Windows Server の一般的な作業などを行うためのスクリプトやアクションが公開されています。PowerGUI は、Windows PowerShell と連動する GUI ベースの拡張可能な管理ツールを提供するという目標に向け、堅調なスタートを切っています。

価格 : 無償
グラフィカルな UI から容易に使用できる Windows PowerShell
グラフィカルな UI から容易に使用できる Windows PowerShell

環境に配慮して製品を導入する
電子製品環境評価ツール
epeat.net
環境のことを考える際は、コンピュータのライフサイクル全体を通してかかるコストを考慮する必要があります。つまり、コンピュータの製造時、使用時、廃棄時にかかるエネルギー全体を考慮する必要があるということです (使用されている原料や発生したごみなどについては言うまでもありません)。この 3 つの工程全体で費やされるコストは、実に驚異的です (環境上のコストと費用的なコストの概要については、technetmagazine.com/issues/2007/10/Green で公開されている、TechNet Magazine 2007 年 10 月号で Dave Ohara が執筆した記事に記載されていますので、そちらを参照してください)。
さいわい、運用中のインフラストラクチャが費用と環境に与える影響を認識している個人や企業は増加しています。その結果、省エネルギー型の製品が求められるようになってきました。企業の IT プロフェッショナルがこの問題に対処する際に役立つツールが、Green Electronics Council (greenelectronicscouncil.org ) から提供されています。
EPEAT (Electronic Product Environmental Assessment Tool の略) と呼ばれるこのツールは、51 個の環境基準 (そのうち 23 個は必須、28 個は任意) に従って電子製品を評価します。その評価を基に、製品はブロンズ (最低限必要な基準を満たしている)、シルバー (必須基準のほか、任意基準の 50％ 以上を満たしている)、またはゴールド (必須基準のほか、任意基準の 75％ 以上を満たしている) に分類されます。
基準の内容は、製造時に使用する原料から、使用中および廃棄の管理時に消費する電力に至るまで、製品のライフサイクル全体にわたっています。この標準の必須基準は、主に製品が与える影響を明らかにすることを目的としており、製品に使用されているリサイクル プラスチックの量、製品に含まれている特別な処理が必要な材料、製品の梱包に使用されているリサイクル原料の量などが定められています (現在、EPEAT の基準を満たす製品として登録されているすべての製品は ENERGYSTAR 3.0 標準に適合しており、2008 年 1 月末までに、これらすべての製品が新たに策定された ENERGYSTAR 4.0 標準に適合する予定です)。
さらに、製品の認定を受けるには、製品本体とその充電可能バッテリ (該当する場合) の "引き取り" サービスを提供する必要があります。他に興味深い要件としては、3 年間の保証またはサービス契約の有無があります。これにより、製品の寿命が延び、全体的な入れ替え率が低下すると理論上は考えられています。
任意基準には、特定の重金属 (カドミウムなど) を排除すること、モジュラーの設計、メーカーの環境への取り組みやポリシーを第三者機関が認定していること、さまざまなリサイクル率 (%) などがあります。
現在対象になっている製品カテゴリは、デスクトップ、統合システム、モニタ、およびノートブックの 4 つです。製品カテゴリは今後も拡大する予定で、2009 年にはサーバー向けの標準が追加される予定です。
また、ほとんどの大手メーカーがこの取り組みに参加しています。この動向は、2007 年 1 月に出された大統領令 13423 号に後押しされています。この大統領令では、連邦政府機関が電子製品を購入する場合に上記で説明した要件を満たすためには、その要件の 95％ 以上を電子製品環境評価ツール (EPEAT) の基準に適合する製品として登録済みの電子製品で満たす必要があることが規定されています (whitehouse.gov/news/releases/2007/01/20070124-2.html 参照)。
このため、まだ自分の購買行動が環境に与える影響に注意を向けていないのであれば、次の電子製品購入時に環境 (と費用) に優しくなれるよう、EPEAT 評価ツールについて調べてみてください。

価格 : 無償
ハードウェアの購入が環境に与える影響を評価する EPEAT

ブック レビュー
Windows Vista Administrator’s Pocket Consultant
microsoft.com/MSPress/books/9588.aspx
Windows Vista® を組織内に展開する準備を進めているのであれば、William Stanek が執筆した『Windows Vista Administrator's Pocket Consultant』(Microsoft Press、2006 年) を活用すると、新しい機能をすぐに使いこなせるようになるでしょう。Administrator's Pocket Consultant シリーズのその他の書籍を読まれたことがある場合は、本書でもお馴染みの構成が使用され、同シリーズの他の書籍と同様に詳しい内容になっていることがわかると思います。すべてが網羅されているわけではありませんが、機能、特定の管理作業の実行、および動作のしくみに関する再確認事項の概要が、幅広い範囲にわたってわかりやすく説明されています。内容は、一般のエンド ユーザーではなく、完全にシステム管理者向けです。
本書では、まず、自動または対話形式のインストール作業で自由に使用できるユーティリティの簡単な説明と共に、Windows Preinstallation Environment 2.0 を紹介しています。次に、Windows Vista システムの管理に関するトピックに移り、msconfig などのツールを使用してインストールのトラブルシューティングや調整を行う方法や、フォルダまたはファイルを以前の状態に復元できる "以前のバージョン" などの新機能について説明しています。また、対象のシステムで使用されているハードウェアやデバイスの管理に役立つツールも紹介しています。
次に本書では、インターフェイスとデスクトップをカスタマイズしてエンド ユーザーに合った Windows® エクスペリエンスを提供する方法を説明しています。これらの方法には、スクリーン セーバーのリソース使用率を抑える方法、スタートアップ プログラムや [スタート] メニューに表示されるプログラムを調整する方法、Windows サイド バーを構成する方法などがあります。また、個人用ツール バーを作成して、エンド ユーザーがタスク バーから共有フォルダや共有ファイルにすばやくアクセスできるようにする方法についても説明しています。
Windows Vista のプログラムと機能のインストールと保守に関するセクションでは、ソフトウェア エクスプローラなどのツールについて説明しています。ソフトウェア エクスプローラを使用すると、システムのスタートアップ プログラム、現在実行されているプログラム、Winsock サービス プロバイダ、およびネットワークに接続されているプログラムを一目で確認できます。続いて、ユーザー、プロファイル、モビリティの問題、およびコンピュータとユーザーのポリシーの管理について説明した後、ディスク管理、ファイルのセキュリティ、およびリソースの共有について取り上げています。具体的には、ユーザーの作成方法、グループ ポリシーを使用した Windows ログオンの管理、パスワードで保護されたリソースにユーザーがアクセスしやすくなる Key Ring エントリの作成方法などを説明しています。
モビリティに関するセクションでは、新しい代替ネットワーク構成によって、どのように "職場" 構成と "外出時" 構成の両方を指定できるようになるかを説明しています。この 2 つのモードは簡単に切り替えられます。
「Managing File Security and Resource Sharing」(ファイルのセキュリティとリソースの共有を管理する) の章では、NTFS ファイルおよびフォルダのアクセス許可を構成する方法と、Windows Vista の特別なアクセス許可のしくみ (および制御方法) に関する基本的な説明を記載しています。また、共有リソースの作成方法、共有リソースに接続する方法、および共有リソースへの接続を維持する方法についても説明しています。
ディスク管理については、ディスク クォータの構成に関する基本的な説明を記載しており、ディスク クォータを作成、表示、更新、および削除する方法だけでなく、これらの設定をインポートまたはエクスポートして再利用する方法についても説明しています。
IPv4 と IPv6 の両方に対応している Windows Vista のネットワーク スタックのしくみについては、かなり詳しく説明されています。本書では、実際の環境に合わせてネットワーク アダプタを構成する方法についても説明しています。
最後は、ユーザーに最高のエクスペリエンスを提供できるように Windows Vista を最適化する方法に関するセクションと、一般的なトラブルシューティング手法に関する短い説明が記載された章で終わっています。ここでは、リモート アシスタンスをセットアップする方法、ディスク チェックとデフラグを定期的に実行してシステムの正常性を維持する方法、およびバックアップを作成する方法について説明しています。全体的に見て、本書は Windows Vista の管理に役立つ、わかりやすいクイック リファレンスと言えます。

価格 : 29.99 ドル (直販)

Web サイトを監視する
Pingdom.com
pingdom.com
これは、以前から言っていることですが、いくら強調しても足りません。システム管理を積極的に行っていれば、ストレスが軽減され、恥ずかしい思い (上司に電子メールで「サイトが停止していることを知っていたか」と聞かれるなど) をしないで済むようになるということです。
これには優れたネットワーク監視ツールが欠かせません。全員ではなくてもほとんどの皆さんが、おそらく既に、社内ネットワーク監視サーバーのようなものを導入していると思います。しかし、インターネット経由で提供されるサービスの可用性を世界中で確保する必要がある国際的な組織の場合はどうでしょうか。
アプリケーション サービス プロバイダ (ASP) の Pingdom.com は、簡単でありながら有効な自動監視サービスを提供しています。この ASP のサーバーは、1 つの外部サービス モニタに依存するのではなく、世界各地の複数の場所に設置されているため、実際にユーザーが経験している状況をはるかに正確に把握できます。
このサービスを利用するには、アカウントを作成して地域情報を設定します。各自のニーズに沿って、タイム ゾーン、国、日付の形式、および数値の形式を定義します。次に連絡先情報を設定します。名前、SMS 電話番号、および通知を受信する電子メール アドレスを指定します。その後、監視チェックを作成します。名前、チェックの頻度、指定した頻度で実行する監視チェックの種類、チェック結果の通知の種類、通知先、および間隔を定義します。
既定のアカウント パッケージでは、チェック頻度が 1 ～ 60 分の範囲で設定されていますが、監視しているサービスの要件に応じて調整できます。通知は、電子メールまたは SMS を使用して、指定した連絡先に送付することができます。また、何回サービスの ping が失敗したら通知を送信するか、およびその状態が何回連続して発生したら再び通知を送信するか (最大 4 回まで) を定義できます。また、サービスが復旧したら通知を送信するように設定することもできます。この機能は、Web サイトや Web サービスの保守にかかった時間を確認するのに非常に役立ちます。保守と言えば、予定されていた作業中に誤ってエラーが報告されないように、チェックを一時的または完全に停止することもできます。
このサービスでは、HTTP センサ、TCP ポート センサ、ping センサ、UDP センサという 4 種類の基本チェックが提供されます。HTTP センサでは、URL または IP アドレス、SSL を使用して要求を送信するかどうか、ポート、基本認証用のユーザー名とパスワード、コンテンツを許可または拒否するための基本的なチェック文字列などを設定できます。TCP ポート センサでは、チェックするサービスのポートと IP アドレスまたはドメインを定義できます。ping センサでは、ICMP を使用してチェックするサービスのポートと IP アドレスまたはドメインを設定できます。UDP センサは、IP アドレスまたはドメイン、ポート、指定した IP アドレスまたはドメインとポートの組み合わせに送信する文字列、および予期される応答文字列によって定義されます。これらのチェックにより、世界各地の複数の場所にある Web サイト、FTP サーバー、SMTP サーバーなどの可用性を確認できます。
また、履歴データの視覚化に役立つレポートもいくつか提供されています。これらのレポートを使用すると、指定した月の稼働率や、その期間の平均応答時間などを確認できます。実行されたチェックごとに、タイムスタンプ、状態、応答時間、およびチェックを実行したサーバーに関する情報を詳しく確認することもできます。また、通知については、指定した期間内でいつ、何回、だれに、どのような方法で送信されたかを確認できます。これらのレポートを公開して、組織の他のメンバがサービスの統計情報を参照できるようにすることもできます。この情報の照会に使用できる Web サービス API も提供されているため、カスタマイズした NOC がある場合は、現在のダッシュボード ビューに Pingdom.com を統合できます。

価格 : 1 か月 9.95 ドル
世界規模の視野で Web サービスを監視する Pingdom.com
世界規模の視野で Web サービスを監視する Pingdom.com

Greg Steen は技術プロフェッショナルであり、企業家でもあります。また、新製品のファンとも言えます。より簡単な操作、品質保証、および開発に役立つ IT プロフェッショナルのための新しいツールを日夜追い求めています。


 Exchange Queue &amp; A: 音声プロンプトの追加、PBX の選択など
Exchange Queue & A
音声プロンプトの追加、PBX の選択など
Seema Rahman

質問 - Exchange ユニファイド メッセージングでは高可用性やクラスタ化が提供されないと聞きましたが、それは本当ですか。
回答 - ユニファイド メッセージングは、クラスタやネットワーク負荷分散の構成でサポートされませんが、特定のゲートウェイから高可用性ソリューションを実現することができます。重要なのは、トラフィックをラウンド ロビンする複数のユニファイド メッセージング サーバーを指定することです。また、ゲートウェイに高度なルーティング機能が備わっていれば、特定のトラフィックが特定のユニファイド メッセージング サーバーにルーティングされるようにすることができます。たとえば、サブスクライバ アクセス用のユニファイド メッセージング サーバーを 1 台、自動応答の呼び出し用に別のユニファイド メッセージング サーバーを 1 台指定できます。このような構成により、環境のインフラストラクチャと傾向に基づいてユニファイド メッセージング トラフィックのバランスを保つことができます。

質問 - Exchange ユニファイド メッセージングを使用して、外部に公開している会社の電話番号に対して音声プロンプトを設定することはできますか。
回答 - はい、できます。同様に自動応答も設定できます。この機能の構成方法に関する詳細な手順については、「カスタム オーディオ プロンプトの管理」(technet.microsoft.com/aa998818) を参照してください。

質問 - 現在使用している構内交換機 (PBX) が Exchange ユニファイド メッセージングと互換性があるかどうかを確認する方法はありますか。
回答 - マイクロソフトでは、テストを行い、Exchange ユニファイド メッセージングでの使用を推奨しているゲートウェイがあります。こうしたゲートウェイを提供するベンダでは、そのベンダのゲートウェイと連携する PBX の一覧を提供しています。ご使用中の PBX がいずれかのベンダが提供する PBX の一覧に含まれている場合、その PBX は Exchange ユニファイド メッセージングとの互換性があります。
サポートされるゲートウェイの一覧と関連情報については、「Exchange Server 2007 のテレフォニー アドバイザ」(microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx) を参照してください。

質問 - Exchange ユニファイド メッセージングを使用するために、電話システムに何か特別なハードウェアを追加する必要はありますか。
回答 - Exchange ユニファイド メッセージング サーバーは、ボイスメール プロバイダとして機能します。ただし、ご使用中のテレフォニー システムと連携させるために、新しいハードウェアが必要になる場合があります。
サポートされる IP-PBX を使用している場合、追加のハードウェアは必要ありません。ただし、ユニファイド メッセージングと連携させるために、IP-PBX で一部の設定の構成が必要になることがあります。
サポート対象外の IP-PBX を使用している場合は、まず、そのハードウェアが、サポートされているゲートウェイのいずれかとの互換性があるかどうかを確認する必要があります。また、サポートされる VoIP ゲートウェイも必要になります。
サポートされるハードウェア (IP-PBX とゲートウェイ) の一覧については、microsoft.com/technet/prodtechnol/exchange/telephony-advisor.mspx の情報を参照してください。この一覧は、マイクロソフトで新しいハードウェアが認定されるたびに更新されるため、定期的に確認することをお勧めします。また、お住まいの地域のユニファイド メッセージング スペシャリストに相談して、ご使用中の環境のハードウェア要件を確認することもできます。

質問 - ユニファイド メッセージングでは FAX はどのようにサポートされるのでしょうか。
回答 - 現在、ユニファイド メッセージングでは、着信 FAX 機能が提供されます。この機能により、ユニファイド メッセージングに対応しているユーザーの内線宛てに送信された FAX は、FAX メッセージが TIFF 形式で添付された電子メール メッセージとして、ユーザーの受信トレイに配信されます。詳しい概要については、technet.microsoft.com/ bb232022 を参照してください。

質問 - Nortel CS1000 IP/PBX を所有していて、Exchange Server 2007 のユニファイド メッセージングを使用したいと思っています。ただ、これら 2 つのシステムを連動させる方法がわかりません。Nortel CS1000 IP/PBX はゲートウェイとして使用できますか。それとも、Intel 社および AudioCodes 社のハードウェアのみがゲートウェイとしてサポートされますか。また、Exchange システムは CS1000 サーバーで認証を行う必要があります。
回答 - IP/PBX 対応のファームウェア バージョン 5.0 を実行している場合、Nortel CS1000 は IP/PBX としてサポートされます。それを機能させるための追加のハードウェアは必要ありません。IP-PBX の構成に関する注意事項については、Nortel 社の Web サイト (support.nortel.com/go/main.jsp?cscat=docdetail&id=626197&poid=14261) を参照してください。また、サポートされるゲートウェイ、PBX、およびサポートされるファームウェアのバージョンについては、microsoft.com/technet/prodtechnol/exchange/pbx-partners.mspx を参照してください。

Seema Rahman はマイクロソフトに勤務し始めて 6 年になります。サポート エスカレーション エンジニアとして、ユーザーが Exchange Server に関する複雑な問題を解決できるように支援しています。Seema は、特に、Exchange 2007 Beta チームで活躍しました。そのとき、彼女が担当していたのはユニファイド メッセージングです。


 ユーティリティ スポットライト: Windows Easy Transfer Companion
ユーティリティ スポットライト
Windows Easy Transfer Companion
Lance Whitney
この記事は、Windows Easy Transfer Companion のプレリリース版を基にしています。ここに記載されているすべての情報は、変更される場合があります。

そろそろ、 古い Windows® XP コンピュータを使用しているユーザーを新しい Windows Vista® コンピュータに移行する時期に来ていることでしょう。移行における最大の課題は、ユーザーのアプリケーションを新しいコンピュータに再インストールして、それらのアプリケーションが問題なく動作することを確認する作業です。マイクロソフトが無償で提供しているツールを使用すると、このような再インストール作業を行わずに済ませることができます。Windows Easy Transfer Companion (WETC) を使用すると、重要なソフトウェア プログラムを Windows XP から Windows Vista にコピーできます。
現在ベータ版が提供されている WETC は、Windows Vista に用意されている Windows 転送ツール ウィザードとは異なります。Windows 転送ツール ウィザードではデータ ファイル、プログラム設定、ユーザー プロファイルがコピーされますが、WETC では、対象が Windows XP SP2 から Windows Vista へのコピーに限定されるものの、アプリケーション全体がコピーされます。この転送処理は、管理者アカウントを使用して実行する必要があります。
WETC は、コピー元とコピー先の両方のコンピュータにインストールします。コンピュータは、ネットワーク経由または USB 転送ツール ケーブルを介して通信できます。転送ツール ケーブルのドライバは Windows Vista に含まれています。Windows XP については、製品 CD からドライバをインストールする必要があります。
WETC では、カテゴリ別に分類された転送可能なアプリケーションの一覧が表示されます
ケーブルを接続したら、Windows XP コンピュータで WETC を起動します。WETC では、ハード ドライブをスキャンし、基本的なシステム情報を収集し、インストールされているすべてのプログラムを分析します。この処理が完了したら、Windows Vista コンピュータで WETC を実行します。WETC は Windows XP コンピュータと通信し、検出されたすべてのアプリケーションを次の 3 つのカテゴリに分類した状態で一覧表示します (上記のスナップショット参照)。
  1. Programs that transfer well (問題なく転送されるプログラム) - 問題なく転送され、Windows Vista コンピュータで動作するソフトウェアです。
  2. Programs that transfer with possible limitations (なんらかの制限を伴う可能性はあるが転送できるプログラム) - 転送はできますが、適切に動作しない可能性があるソフトウェアです。
  3. Programs that will not be transferred (転送されないプログラム) - Windows Vista では動作しないため、転送対象に含められないソフトウェアです。
正常に転送できないプログラムについては、WETC によってそれぞれ簡単な理由が提示されます。通常、アプリケーションがコピーされない原因としては、インストーラ情報やその他の重要なデータが不足している、Windows Vista と互換性がない、または既に Windows Vista コンピュータに存在していることなどがあります。また、WETC では、ウイルス対策ソフトウェアやシステム ユーティリティなどの特定の種類のアプリケーションはコピーしません。さらに、Microsoft .NET などの OS のフレームワークも転送されません。そのため、このようなソフトウェアは、これらを必要とするアプリケーションをコピーする前に、Windows Vista にインストールしておく必要があります。
プログラムの一覧で、コピーするプログラムのチェック ボックスをオンにします。ヘルプ画面では、コピーするプログラムを決めるのに役立つ情報や問題の解決方法を入手できます。また、転送されるプログラムと転送されないプログラムが一覧表示された転送前のレポートを保存できます。
転送処理を進めると、各プログラムの関連データがコピーされます。転送処理が完了すると、コピーが完了したプログラムとエラーが発生したかどうかを示す状態メッセージが表示されます。詳細な情報が記載された転送後のレポートも保存できます。WETC を終了したら、Windows Vista コンピュータを再起動してログインし、転送されたプログラムを実行して、問題なく動作することを確認します。
問題がある場合は、Windows Vista の WETC Programs フォルダにある Resources ツールへのショートカットを使用します。Resources ツールには Undo (元に戻す) 機能があり、この機能を使用して Windows Vista コンピュータにコピーされたすべてのアプリケーションを削除できます。ただし、この情報の有効期限は 3 日間です。Windows Easy Transfer Companion の詳細と最新版のダウンロードについては、support.microsoft.com/kb/931696 を参照してください。

Lance Whitney は、IT コンサルタントであり、トレーナーであり、テクニカル ライターでもあります。Windows のワークステーションおよびサーバーをカスタマイズすることに数えきれないほどの時間を費やしてきました。元々はジャーナリストでしたが、15 年前、IT 業界への転向を実現しました。


 The Cable Guy: Windows Server 2008 における DNS の機能拡張
The Cable Guy
Windows Server 2008 における DNS の機能拡張
Joseph Davies
この記事は、Windows Server 2008 のプレリリース版に基づいています。記載されている内容は変更されることがあります。

マイクロソフトでは、Windows NT 4.0 以降の Windows サーバー製品にドメイン ネーム システム (DNS) サーバー サービスを同梱しています。DNS とは DNS ドメイン名とさまざまな種類のデータ ( IP アドレスなど) へのマッピングを含む階層型の分散型データベースです。
Windows Server 2008 では、DNS サーバー サービスに新しくバックグラウンド ゾーンの読み込み、IPv6 サポートの強化、読み取り専用ドメイン コントローラ (RODC) のサポート、グローバルな単一ラベル名をホストする機能が追加されました。

バックグラウンド ゾーンの読み込み
Windows Server® 2008 の DNS サーバー サービスでは、バックグラウンド ゾーンの読み込みを実装することで、データの取得が迅速化されます。これまで、Windows Server 2003 では、Active Directory® に膨大な数のレコードを保持するゾーンがある組織では、DNS サーバー サービスを再起動すると Active Directory から DNS データを取得するのに、最大 1 時間、もしくはそれ以上の待ち時間が発生していました。この待ち時間の間、DNS サーバーでは、ホストしているゾーンのいずれに対する DNS クライアントの要求も処理することができませんでした。
この問題に対処するため、Windows Server 2008 の DNS サーバー サービスでは、サービスの再起動後に、Active Directory からゾーンのデータをバックグラウンドで取得することで、他のゾーンのデータの要求に対応できるようになりました。DNS サーバー サービスでは、サービスが開始されると、Active Directory に格納されたゾーンを読み込む 1 つ以上の実行スレッドを作成します。Active Directory ベースの各ゾーンのデータを読み込む個別のスレッドがあるため、DNS サーバー サービスは、ゾーンの読み込み中でも、他の要求に対応することができます。DNS クライアントから読み込みが完了しているゾーンのデータが要求された場合、DNS サーバーでは、その要求に適切に対応できます。また、読み込み中のゾーンのデータが要求された場合、要求されているデータを Active Directory から取得します。
このゾーンの読み込み中に特定のデータを Active Directory から取得することができる機能は、ゾーンのデータをファイルに格納する場合にはないメリットがあります (具体的には、DNS サーバー サービスでは、要求にすぐに対応できるというメリットがあります)。ゾーンのデータがファイルに格納される場合、DNS サーバー サービスでは、データが見つかるまで順番にファイルを読み取っていかなくてはなりません。

IPv6 サポートの強化
IPv6 については、以前のコラムでも取り上げてきましたが、これは新しいインターネットの標準プロトコル群です。IPv6 は、アドレスの不足、セキュリティ、自動構成、拡張の必要性などの現在のバージョン (IPv4) が抱える多くの問題に対処するようにデザインされました。
IPv6 における変更点の 1 つとしては、IPv4 のアドレスが 32 ビットしかないのに対して、IPv6 のアドレスは 128 ビット長であることです。IPv6 のアドレスはコロン区切りの 16 進数を使用した形式で表されます。16 進数の各桁は IPv6 アドレスの 4 ビットです。完全な IPv6 アドレスは、8 つのブロックで構成された 32 桁の 16 進数で、各ブロックはコロンで区切られています。たとえば、完全な IPv6 アドレスは FD91:2ADD:715A:2111:DD48:AB34:D07C:3914 のような形式になります。
IPv6 アドレスの順方向の名前解決では、AAAA レコード ("クワッド エイ" と読みます) として知られている IPv6 ホスト DNS レコードを使用します。IPv6 では、逆引き名前解決に IP6.ARPA ドメインを使用し、IPv6 アドレスの 32 桁の各 16 進数の数字は、逆の順序で逆引きドメイン階層の個別のレベルを構成します。たとえば、FD91:2ADD:715A:2111:DD48:AB34:D07C:3914 というアドレスの逆引き参照ドメイン名は、4.1.9.3.C.7.0.D.4.3.B.A.8.4.D.D.1.1.1.2.A.5.1.7.D.D.A.2.1.9.D.F.IP6.ARPA となります。
Windows Server 2003 の DNS サーバー サービスでは、IPv6 の順方向の名前解決と逆引き名前解決をサポートしていますが、このサポートは完全には統合されていません。たとえば、Windows Server 2003 の DNS マネージャ スナップインで、IPv6 のアドレス レコード (前述の AAAA レコード) を作成するには、ゾーン名を右クリックし、[その他の新しいレコード] をクリックして、リソース レコードの種類として [IPv6 ホスト (AAAA)] をダブルクリックします。Windows Server 2008 の DNS マネージャ スナップインで AAAA レコードを追加するには、ゾーン名を右クリックし、[新しいホスト (A または AAAA)] をクリックします。[新しいホスト] ダイアログ ボックスでは IPv4 または IPv6 のアドレスを入力できます。図 1 に例を示します。
図 1 [新しいホスト] ダイアログ ボックス
図 1 [新しいホスト] ダイアログ ボックス
IPv6 サポートの強化の一環として、逆引き IPv6 ゾーンが導入されました。Windows Server 2003 の DNS マネージャ スナップインで逆引き参照ゾーンを作成するには、新しいゾーン ウィザードの逆引き参照ゾーン名のページで、逆引き参照ゾーンの名前を手動で入力する必要があります。DNS 逆引きゾーン名は 1.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa のようになります (IPv6 サブネットのプレフィックス 2001:db8:0:1::/64 の完全な表記は 2001:0db8:0000:0001::/64 となります)。
Windows Server 2008 では、DNS マネージャ スナップインの IPv6 逆引きゾーンが完全に新しいゾーン ウィザードに統合されています。このウィザードには IPv4 逆引き参照ゾーンまたは IPv6 逆引き参照ゾーンを選択する新しいページが用意されています。IPv6 逆引き参照ゾーンでは、IPv6 サブネット プレフィックスを入力すると、ウィザードによりゾーンが自動的に作成されます。図 2 に例を示します。
図 2 IPv6 逆引き参照ゾーンの名前を付ける
図 2 IPv6 逆引き参照ゾーンの名前を付ける
もう 1 つの逆引き参照ゾーンの機能拡張としては、DNS マネージャ スナップインの IPv6 ポインタ (PTR) レコードの表示方法が挙げられます。図 3 は、Windows Server 2003 の DNS マネージャ スナップインで PTR レコードが表示される状態を示しています。
図 3 Windows Server 2003 における IPv6 の PTR レコード
図 3 Windows Server 2003 における IPv6 の PTR レコード
この状態は IPv6 逆引き参照ドメイン名の DNS 名前空間の構造を正確に反映していますが、IPv6 アドレスの PTR レコードを管理する作業は困難になります。図 4 は、Windows Server 2008 の DNS マネージャ スナップインで PTR レコードが表示される状態を示しています。
図 4 Windows Server 2008 における IPv6 の PTR レコード
図 4 Windows Server 2008 における IPv6 の PTR レコード
Windows Server 2003 の DNS サーバー サービスでは IPv6 の操作がサポートされますが、dnscmd /config /EnableIPv6 1 コマンドを使用して手動で有効にする必要があります。これに対して、Windows Server 2008 では、IPv6 の操作が既定でサポートされます。Dnscmd.exe コマンド ライン ツールは、コマンド ライン オプションで IPv6 アドレスを受け付けるように更新されています。また、DNS サーバー サービスでは、再帰的クエリを IPv6 専用サーバーに送信できるようになり、サーバー フォワーダのリストには IPv4 と IPv6 両方のアドレスを含められるようになりました。
IPv6 と Windows® でのサポートの詳細については、microsoft.com/ipv6 を参照してください。

読み取り専用ドメイン コントローラのサポート
Windows Server 2008 では、RODC という新しい種類のドメイン コントローラが導入されました。RODC は、Active Directory 情報の読み取り専用のコピーを保持しており、Active Directory の機能を使用することはできますが、直接構成することはできません。RODC は攻撃を受けにくいという特性があるため、ドメイン コントローラの物理的なセキュリティを確保できない場所や、ネットワーク上に有害なホストが存在する可能性がある場所にも配置することができます。
RODC の導入に伴い、Windows Server 2008 の DNS サーバー サービスでは、新しい読み取り専用のプライマリ ゾーンの種類がサポートされます。RODC コンピュータでは、ドメイン パーティション、ForestDNSZones、DomainDNSZones など、DNS が使用するアプリケーション ディレクトリ パーティションのすべての完全な読み取り専用のコピーをレプリケートします。これにより RODC で実行されている DNS サーバー サービスでは、RODC ではないドメイン コントローラのディレクトリ パーティションに格納されている任意の DNS ゾーンの完全な読み取り専用のコピーにアクセスすることができます。RODC では、読み取り専用のプライマリ ゾーンの内容を参照できますが、変更することはできません。ゾーンの内容は RODC ではないドメイン コントローラで変更する必要があります。

GlobalNames ゾーン
GlobalNames ゾーンによる名前解決
GlobalNames ゾーンの展開後に、Windows Vista ベースの DNS クライアントが単一ラベル名を解決しようすると、単一ラベル名にプライマリ DNS サフィックスを追加して、名前の照会要求を DNS サーバーに送信します。
名前が見つからない場合、DNS クライアントは、DNS サフィックス検索一覧が構成されていれば、この一覧について単一ラベル名とサフィックスを組み合わせた名前の照会要求を追加で送信します。これらの方法で名前が解決されない場合、クライアントは単一ラベル名による名前解決を要求します。
DNS サーバーは GlobalNames ゾーンで単一ラベル名を検索します。このゾーンに名前があれば、DNS サーバーから DNS クライアントに解決された IPv4 アドレスまたは FQDN が送信されます。このゾーンに名前がなければ、DNS クライアント コンピュータでは、名前を NetBIOS 名に変換し、WINS などの NetBIOS 名の名前解決技術を使用します。GlobalNames ゾーンで単一ラベル名の解決を有効にするために、DNS クライアント サービスを変更する必要はありません。

Windows Server 2008 と Windows Vista® では NetBIOS over TCP/IP (NetBT) プロトコルがサポートされます。NetBT では、セッション層の NetBIOS アプリケーションの識別に NetBIOS 名を使用します。現在提供されているバージョンの Windows では、名前解決に Windows Sockets ベースのネットワーク アプリケーションと DNS が使用されるので、WINS による NetBIOS 名前解決は必要ではありません。しかし、多くのマイクロソフト ユーザーは、古い NetBT アプリケーションをサポートしたり、組織内で単一ラベル名の名前解決を提供したりするために、ネットワークに WINS を展開しています。通常、単一ラベル名では、電子メール サーバー、中央 Web サーバー、基幹業務アプリケーション用のサーバーなど、組織において重要で名前が知れ渡っていて広く使われているサーバーを参照します。
DNS のみが使用されている組織で、このような単一ラベル名を解決できるようにするには、Windows ベースの DNS クライアントが、それぞれに割り当てられている DNS ドメイン サフィックスやサフィックス検索一覧に関係なく名前を解決できるように、組織内にある複数の DNS ドメインに A レコードを追加することが必要になる場合があります。
たとえば、contoso.com という組織に central.contoso.com ドメインのメンバである CWEB という名前の中央 Web サーバーが設置されているとします。DNS クライアントに wcoast.contoso.com、central.contoso.com、または ecoast.contoso.com という DNS ドメイン サフィックスを割り当てられる場合、CWEB サーバーの単一ラベル名を実装するには、ネットワーク管理者は cweb.wcoast.contoso.com と cweb.ecoast.contoso.com の両方に 2 つの A レコードを追加で作成する必要があります。ただし、単一ラベル名の名前解決のために手動で作成した A レコードは IPv4 アドレスの割り当ての変更や新しい名前に合わせてメンテナンスが必要であることを忘れないでください。
contoso.com で既に古い NetBT アプリケーションに対して WINS を使用している場合、ネットワーク管理者は 1 つの WINS 静的レコードを WINS インフラストラクチャに追加することで、CWEB サーバーの単一ラベル名の名前解決を実装できます。IPv4 アドレスが変更された場合、変更する必要があるのは、1 つの WINS の静的レコードだけです。単一ラベル名は DNS よりも WINS での管理の方が容易なので、多くの Windows ベースのネットワークでは単一ラベル名に WINS の静的レコードが使用されています。
WINS の静的レコードと同じくらい管理が簡単な、DNS での単一ラベル名の名前解決を提供するために、Windows Server 2008 の DNS サーバー サービスでは単一ラベル名を格納する GlobalNames と呼ばれる新しいゾーンがサポートされます。通常、このゾーンのレプリケーション スコープはフォレストです。このスコープにより、Active Directory フォレスト全体にわたって単一ラベル名解決を提供できます。また、GlobalNames ゾーンの場所を公開するのにサービスの場所 (SRV) リソース レコードを使用している場合、GlobalNames ゾーンでは、複数のフォレストを含む組織全体にわたって単一ラベル名の解決をサポートできます。
GlobalNames ゾーンは、WINS とは異なり、通常、IT 部門が管理している組織の主要かつ重要なサーバーなど、特定の限られたホスト名の単一ラベル名の解決を提供することを目的としています。GlobalNames ゾーンは、IPv4 アドレスが変更される可能性のあるデスクトップ コンピュータや他のサーバーの名前の格納先として使用されることは目的としておらず、どのような状況においても DNS の動的な更新はサポートしません。最も一般的な用途は、単一ラベル名を完全修飾ドメイン名 (FQDN) に割り当てるために、エイリアス (CNAME) リソース レコードを保持することです。現在 WINS を使用しているネットワークの GlobalNames ゾーンには、一般的に、WINS で既に静的に構成され、IT で管理されたリソース レコードが含まれています。
GlobalNames ゾーンでは、すべての権限がある DNS サーバーで Windows Server 2008 が実行されている場合にのみ、単一ラベル名の解決を提供します。ただし、どのゾーンに対しても権限のない他の DNS サーバーでは、古いバージョンの Windows や他のオペレーティング システムが実行されていても問題ありません。GlobalNames ゾーンはフォレスト内で一意である必要があります。
パフォーマンスとスケーラビリティを最大限に高めるには、GlobalNames ゾーンを Active Directory と統合し、権限のある各 DNS サーバーは、Active Directory のローカル コピーを使用して構成することをお勧めします。これは複数のフォレストへの GlobalNames ゾーンの配置をサポートするために必要な構成です。
Windows における DNS のサポートと GlobalNames ゾーンの展開に関する詳細については、マイクロソフトの DNS Web サイト (microsoft.com/dns) を参照してください。

Joseph Davies は、マイクロソフトのテクニカル ライターとして Windows ネットワークのトピックに関する講義および執筆を 1992 年から行っています。Microsoft Press から 5 冊の書籍を上梓しており、月間の TechNet Cable Guy コラムの執筆者でもあります。


 Windows PowerShell: 悪意のあるコードを回避する
Windows PowerShell
悪意のあるコードを回避する
Don Jones

思い出してみてください。Windows Vista がまだベータ版だったころ、新しいコマンド ライン シェルのごく初期のバージョンであったコードネーム "Monad" に関するうわさが飛び交っていました (言うまでもなく、このコマンド ライン シェルは後に Windows PowerShell として知られることになります)。その当時、主要メディアによって "初めての Windows Vista ウイルス" に関する多くの報道がなされました。
実際のところ、その "ウイルス" は、"Monad" を標的とした概念実証型のマルウェア スクリプトでした。そのスクリプトを実行するには、"Monad" 自体に特別な構成を行う必要がありました。つまり、既定の構成では実行されなかったということです。また、このような報道がなされる前に、マイクロソフトは Windows Vista® に "Monad" が同梱されないことを既に発表していました。要するに、この一連の事態は (少なくとも、ほぼ) 空騒ぎだったというわけです。
しかし、Windows PowerShellTM の人気は上昇しており、既に 100 万回以上ダウンロードされています。これは、Windows PowerShell を使用して悪意のあるスクリプトが作成される可能性が高まったとも言えます。Windows PowerShell で損害を与える可能性があるスクリプトを記述できるということは既知の事実であり、Windows PowerShell、cmd.exe、VBScript など、すべての管理ツールは悪意のある攻撃に使用される可能性があります。このため、特定の PS1 ファイルが安全であると決めつけることはできません。
幸運にも、Windows PowerShell はスクリプトを実行しないように既定で構成されているため、ユーザーによる操作がなければ、悪意のあるスクリプトは実行されません。今月の記事では、この状況がどのようにして発生することが予想されるかについて説明します。この記事は Windows PowerShell の印象を悪くすることを目的としているわけではありません。マイクロソフトは、多くの危険性が回避されるすばらしいスクリプト シェルを設計したと思います。しかし、今回の内容は、この予想される攻撃を回避するための準備という目的のためだけでも論じる価値があります。

既定で安全
Windows PowerShell が、マイクロソフトが有名な Trustworthy Computing (信頼できるコンピューティング) 構想を発表した後に初めて設計した言語であるということは注目に値します。セキュリティの第一人者である Michael Howard (『Writing Secure Code』の筆者) は、Windows PowerShell チームの "セキュリティ アドバイザ" としての役割を果たしました。彼の支援によって、可能な限り安全なコードが記述されていること、そしてこれが最も重要ですが、シェルの既定の構成が安全であることが保証されました。
まず、セキュリティに関する Windows PowerShell の初期設定を簡単に見ていきましょう。このシェルの既定の設定では、拡張子 PS1 のファイルをダブルクリックしても、そのファイルは実行されません。この拡張子はメモ帳に関連付けられています。実は、このシェルの既定の設定でどのスクリプトも実行されない理由は、実行ポリシーと呼ばれる組み込みの機能が動作するためです。実行ポリシーには、スクリプトの実行条件が記述されています。既定では、この実行ポリシーは Restricted に設定されており、どのスクリプトも実行されません。シェルは対話形式でのみ使用できます。実行ポリシーは、Set-ExecutionPolicy コマンドレットやマイクロソフトから提供されている管理用テンプレート (ADM ファイル) を使用して変更できます (この ADM ファイルは go.microsoft.com/fwlink/?LinkId=102940 からダウンロードできます)。図 1 は、設定可能な実行ポリシーを示しています。
図 1 安全な実行ポリシーの選択
図 1 安全な実行ポリシーの選択
実行ポリシーの例外はごくわずかです。具体的には、実行ポリシーが Restricted に設定されている場合でも、マイクロソフトから提供され、シェルと共にインストールされるいくつかの特定の XML ファイルは、シェルによるインポートを許可されます。これらのファイルは、Microsoft® .NET Framework の型の拡張や、ほとんどの .NET オブジェクト型に使用されるレイアウトの既定の書式設定などの特定の機能を提供するために使用されます。このため、これらのファイルはシェルの起動時に必ず読み込まれる必要があります。
これらのファイルには実行可能コードが含まれている可能性があり、実際に含まれていますが、マイクロソフトによってデジタル署名されています。ファイルが改ざんされると、この署名は無効になり、シェルの起動時にファイルがインポートされなくなります。この設計によって、悪意のあるコードを挿入しようとするマルウェアから、これらの XML ファイルを強力に保護できます。
もちろん、実行ポリシーを Restricted のままにしておくと、独自に作成した Windows PowerShell プロファイル スクリプトも起動時に実行されません。既定では、Windows PowerShell によってプロファイル スクリプトは作成されませんが、4 つの特定の場所から特定の名前を持つファイルが検索されます。ファイルが検出された場合、Windows PowerShell の起動時に毎回それらのファイルの実行が試行されます (Windows PowerShell と共にインストールされるドキュメントには、プロファイル スクリプトの検索に使用されるフォルダ名とファイル名が詳しく記載されています)。このプロファイルは、これから説明する攻撃にとって重要な役割を果たします。

実行ポリシーを変更する
今月のコマンドレット
Set-AuthenticodeSignature に関連するコマンドレットとして、Get-AuthenticodeSignature があります。このコマンドレットは、デジタル署名されたスクリプトを調べて、署名の詳細情報を提供します。特定のファイルを指定するだけで、ファイルが署名されているかどうかだけでなく、署名が破損しているかどうか、どの証明書がファイルの署名に使用されたかなどの情報を確認できます。このコマンドレットには、Windows PowerShell スクリプトだけでなく、次のような署名付きの実行可能ファイルも指定できます。
PS C:\Program Files\Microsoft Office\Office12>
Get-AuthenticodeSignature excel.exe | Format-List *
このコマンドを実行すると、上記のファイルが Microsoft Corp. によって Microsoft Code Signing CA から発行された証明書を使用して署名されていることがわかります。
コマンドの結果

ここで強調したいのは、既定の状態では、Windows PowerShell でコードを実行することは (不可能ではありませんが) 非常に難しいということです。もちろん、これには悪意のあるコードも含まれます。コードを実行するには、悪意のあるスクリプトも実行できる状態に実行ポリシーを変更する必要があります。もちろんこのコラムの目的は、Windows PowerShell のセキュリティ ホールに警鐘を鳴らすことではなく、システムのセキュリティを強化するためのベスト プラクティスを紹介することです。
最も制限が弱い実行ポリシーは Unrestricted です。この実行ポリシーでは、すべてのスクリプトが何の疑いも持たれずに制約なしで実行されます。これは、皆さんがこれまで経験してきた、VBScript ファイルとバッチ ファイルによって攻撃されるシナリオと実質的に同じ状態です。シェルの実行ポリシーを Unrestricted に設定するということは、悪意のあるスクリプトで攻撃して損害を与えてほしいと言っているようなものです。Unrestricted に設定して、スクリプトによる攻撃を受けてしまった場合は、Unrestricted に設定した正当な理由を用意し、ウイルスによって環境が破壊された状況を説明するときに、自分が下した判断について白状する覚悟をしておきましょう。
とは言うものの、Unrestricted に設定されている場合でも、Windows PowerShell はインターネットからダウンロードされたスクリプトの検出を試行し、それらを実行する前に警告を表示します。しかし、実行ポリシーを Unrestricted に設定することはやはり良い考えではありません。

スクリプトに署名する
スクリプトを実行できる最も安全な実行ポリシーは、AllSigned です。この設定は、名前が示すとおり、信頼された証明書を使用して作成された破損していないデジタル証明書 (どんな証明書でもよいというわけではありません) で署名されたスクリプトのみを実行します。スクリプトに署名するには、クラス 3 のデジタル証明書、もっと具体的に言うと Microsoft Authenticode コード署名証明書が必要です。これらの証明書は、企業に内部公開キー基盤 (PKI) が実装されている場合は、そこから入手できます。また、CyberTrust、Thawte、VeriSign など、証明書を販売する証明機関 (CA) から購入することもできます。
スクリプトへの署名に使用できる証明書がコンピュータにインストールされているかどうかを確認するには、次のコマンドレットを実行します。
Get-ChildItem CERT: -recurse –codeSigningCert
証明書を Windows® コンピュータにインストールしたら、Set-AuthenticodeSignature コマンドレットを使用してデジタル証明書を作成および適用します。この証明書は、外見上は意味のない一連のコメント行としてスクリプトの末尾に記述されます。一部のスクリプト エディタでは、スクリプトを保存したときに自動的に署名する機能など、スクリプト ファイルに署名を適用する便利なオプションが提供されている場合もあります。
AllSigned は、運用環境での使用に最適な実行ポリシーです。この実行ポリシーによって悪意のあるスクリプトの実行を完全に回避できるわけではありませんが、悪意のあるスクリプトが確実に署名されるため、スクリプトの作成者を確認できます (信頼できる CA のみを信頼するように Windows コンピュータが構成されていることを前提としていますが、コラムの内容から少しそれるため、これに関する説明は割愛します)。興味深いことに、Windows Script Host (WSH) 5.6 以降の TrustPolicy を設定して、同じようにデジタル署名を要求することもできますが、実際にこの設定を使用している管理者にはほとんど出会ったことがありません。
では、ここまで説明した内容を簡単にまとめてみましょう。実行ポリシーを Restricted に設定すると、悪意のあるスクリプトの攻撃を受けずに済みますが、有用なスクリプトを実行することもできません。実行ポリシーを AllSigned に設定すると、シェルでは署名されたスクリプトのみが実行されます。悪意のあるスクリプトの作成者が、身元を突き止めることができる検証済みの身分証明をスクリプトに含めることはほとんどないため、この設定は非常に安全です。一方、Unrestricted は非常に安全性が低い設定です。この設定を使用した場合、最終的に悪意のあるスクリプトの攻撃を受ける可能性があります (Unrestricted は安全ではありませんが何かを偽った設定ではなく、おそらく何の目的もなく使用されることはないため、特定の脆弱性であるとは考えていません)。

裏口から忍び込む
実行ポリシーには、RemoteSigned というもう 1 つの設定があります。これは最近ほとんどの管理者が使用している設定だと思います。理由は単純であり、Unrestricted よりも安全で、AllSigned よりも厄介な設定ではないためです。RemoteSigned では、ローカル スクリプトに署名が要求されません。このため、ローカル ドライブ上にある PS1 ファイルは、署名されていなくても実行されます。リモート スクリプトは署名されていなければ実行されません。主なリモート スクリプトには、Internet Explorer® や Outlook® (これらのアプリケーションはダウンロードされたファイルを特別なフラグでマークします) を使用してインターネットからダウンロードされたスクリプトなどがあります。
しかし、RemoteSigned を設定した場合、安全であるという誤った認識が生まれる可能性があります。まず、特別なフラグを適用せずにリモート スクリプトをダウンロードすることは簡単です。たとえば、マイクロソフト製以外のブラウザ、およびマイクロソフト製以外のほとんどの電子メール クライアントではこのフラグが設定されません。注意する必要があるのは、このフラグが設定されていない場合、ダウンロードされたスクリプトは Windows PowerShell によってローカル スクリプトと見なされ、署名されていなくても実行されるということです。それでもまだ、これが深刻な脆弱性であるとは考えられません。スクリプトを実行するには、そのスクリプトを実際にダウンロードし、Windows PowerShell を起動して手動で実行する必要があるためです。だれかをだましてこれらの手順をすべて実行させるのは困難であり、管理者 (通常はネットワーク上で Windows PowerShell をインストールしている唯一のユーザー) が自ら実行するはずもありません。
ただし、RemoteSigned にはマルウェアが忍び込むことができる "裏口" があります。Windows PowerShell プロファイル スクリプトのことを覚えているでしょうか。これらのスクリプトが (自分で作成したかマルウェアによって作成されたかにかかわらず) 存在する場合、Windows PowerShell が起動するたびに実行されます。また、RemoteSigned 実行ポリシーでは、ローカルのプロファイル スクリプトに署名が要求されません。
このシナリオを次に示します。
  1. マルウェアがシステムに侵入し、シェル用のプロファイル スクリプトを作成するか、既存のプロファイル スクリプトに悪意のあるコードを挿入します。通常、マルウェアはログオン ユーザー アカウントを使用して実行されます。一般的に、このアカウントにはプロファイル スクリプトを変更するためのアクセス許可が与えられています。
  2. プロファイル スクリプトが作成されたか、悪意のあるコードが含まれるように変更されたことに気付かないまま、ユーザーが Windows PowerShell を起動します。コードが実行され、システムは攻撃を受けます。常に管理者の資格情報を使用して Windows PowerShell を起動している場合、被害の規模は大きくなりますが、Windows PowerShell を使用してなんらかの操作を実行するには必ず管理者特権が必要であるため、通常はこの規模の被害を受けます。
RemoteSigned 実行ポリシーが設定されている場合、上記のようにプロファイルを利用すれば、悪意のあるコードを含むどのようなコードでも、ユーザーが気付かないうちに実行することができます。

プロファイルを保護する
プロファイルを保護するには、AllSigned 実行ポリシーを使用するしかありません。AllSigned では、プロファイル スクリプトもデジタル署名されている必要があります。デジタル署名されていない場合、それらのスクリプトは Windows PowerShell の起動時に実行されません。プロファイル スクリプトが署名されていて、悪意のある変更が加えられた場合、デジタル署名も破損するため、プロファイル スクリプトは実行されません。この問題は Windows PowerShell の起動時に通知されます。スクリプトを実行する必要がある運用環境では、AllSigned のみが安全な実行ポリシーの設定であることは間違いありません。
別の方法もありますが、より複雑で信頼性も低下します。この方法では、Windows PowerShell が検索する 4 つのファイルそれぞれに対して、空のプロファイル スクリプト ファイルを作成します。新しいユーザー アカウント (ここではプロファイル編集者と呼びます) を使用してこれらのファイルを作成し、プロファイル編集者アカウントのみがファイルを変更できるように、ファイルの NTFS アクセス許可を設定します。他のアカウントには読み取り専用アクセス許可を与えます。
プロファイルを編集するとき以外は、プロファイル編集者アカウントでログオンしないようにしてください。この方法を使用すると、通常のユーザー アカウントはプロファイル スクリプトを変更できなくなります。また、通常のアカウントでログオンしたときにマルウェアが実行されても、プロファイル スクリプトは変更されません。では、プロファイル編集者としてログオンしたときにマルウェアが実行されたらどうなるでしょうか。いずれにしろ、プロファイル編集者としてログオンしたときはプロファイルを編集するため、プロファイルが変更されていれば気付くはずです。
すべてのユーザー用のプロファイル スクリプトを作成し、上記で説明したような厳密なアクセス許可で制御することによって、セキュリティを強化することもできます。このスクリプトには、Get-AuthenticodeSignature コマンドレットを使用するコードを記述し、シェルが検索するその他のプロファイル上のデジタル署名が確認されるようにします。これにより、実質的にはプロファイル スクリプトに署名が要求され、他のスクリプトには署名が要求されないことになります。
しかし、より徹底的にプロファイルを保護するには AllSigned 実行ポリシーが適しています。ネットワークに接続されているすべてのコンピュータには、可能であればグループ ポリシーを使用して Restricted 実行ポリシーを適用することをお勧めします。この設定はローカルの設定よりも優先されるため、ドメインに新しいコンピュータを追加した場合、そのコンピュータでスクリプトの実行が拒否されるように自動的に設定することができます。スクリプトの実行を許可する必要があるコンピュータには、AllSigned 実行ポリシーを設定する別のグループ ポリシーを適用します。すべてのスクリプトにデジタル署名する必要はありますが、身元を確認できる開発者が作成した信頼できるスクリプトのみが環境内で実行されるため、攻撃について心配する必要はなくなります。

Don Jones は SAPIEN Technologies のリード スクリプト グルであり、『Windows PowerShell: TFM』(SAPIEN Press、2007年) の共著者でもあります。連絡先については、www.ScriptingAnswers.com にアクセスしてください。


 Hey, Scripting Guy!: 正規表現で間違いをなくす
Hey, Scripting Guy!
正規表現で間違いをなくす
Microsoft Scripting Guys
この記事で使用しているコードのダウンロード: HeyScriptingGuy2008_01.exe (150KB)

だれでも 間違えることはあります (えっ、Scripting Guys チームが結成されたのは間違いではなかったとお思いですか)。しかし、間違えることにプラスの面があるとすれば、それは、えーと、なんでしょう。間違いには、常にそこから学ぶことができるというプラスの面があります、なんて言うと思いましたか。まさか、とんでもありません。間違いから学ぶことができるのは、そもそも間違えない方がはるかに良かったということだけです。
注 : すみません、今日は Microsoft Bob に関する冗談はありません。以前、Microsoft Bob をからかうという間違いを犯しましたが、この件については、確かに間違いから学んだことがありました。Microsoft Bob のことになると、私たちは口を閉ざすようになりました。
正直なところ、Scripting Guys は、間違えることに関するプラスの面が思い当たりません。だからこそ、できるだけ間違いを犯さないことに専心しているのです (実は、間違いを最小限にとどめる唯一の方法は、実際に行う作業の数を最小限にとどめることです。それはまた別問題ですが)。
自分たちが、自らの間違いを最小限に抑えようとする点には何の問題もありません。しかし、共同作業者の間違いが減らなければ、あまり意味がありません (既に述べましたが、Microsoft Bob に関する冗談ではありません)。たとえば、データベース プログラムや Active Directory® に対するフロントエンド アプリケーションを作成したことがあれば (多くの方が経験していると思いますが)、ここで言わんとしていることはおわかりでしょう。フロントエンドのデータ入力プログラムの機能は、ユーザーがデータを入力することです。
たとえば、名前を入力するときに、Ken のように最初の文字を大文字に、残りすべての文字を小文字にする必要があるとします。この場合、ユーザーが名前を「KEN」と入力するとどうなるでしょうか。また、日付を 01/23/2007 という形式で入力する必要があるとします。この場合、ユーザーが日付を「January 23, 2007」と入力するとどうなるでしょうか。だんだん、わかってきていただけたと思います。既に述べたように、フロントエンドのデータ入力プログラムの機能は、ユーザーがデータを入力することです。そして、いやが応でも、データ入力を行うユーザーは間違いを犯します。もちろん、ユーザーが間違いを犯さないようにサポートする手段を講じていれば話は別ですが。

データが有効であることを確認する
競技会の閉幕に向けて
Scripting Guys が 1 年で最も楽しみにしているイベントが何だかご存知でしょうか。昨年か一昨年の 2 月にスクリプト センターにアクセスしたことがある方は、そのイベントが Winter Scripting Games であると推測されるかもしれません。でも、違います。Scripting Guys が楽しみにしているのは、2 週間にわたるノンストップの感動と興奮の後、その年の Scripting Games 競技会が成功に終わったことの満悦感に浸る瞬間とその後 1 か月にわたる活動休止期間です。
というわけで、1 年で最もお気に入りのイベントである Scripting Games の閉幕に向けて、2008 Winter Scripting Games を開催します。2008 年 2 月 15 日から 3 月 3 日までスクリプト センターで開催される、現存する最も優れたスクリプト競技会にご参加ください。2 週間以上にわたり、スクリプトのおもしろさを体感できます。
Scripting Games に参加すると、スクリプト作成スキルをテストして、さらに向上させることができます。Scripting Guys は、今年の競技会閉幕後の活動休止期間をさらに数日間増やすため、競技会を昨年よりも一層大きくし、より良いものにしています。今年も、競技会では、初心者と上級者という 2 つの部門を用意しています。ですから、まったくのスクリプト初心者でも、ベテラン (年齢不問) でも、またはその中間に位置するユーザーでも、だれでもこの競技会にご参加いただけます。
さて、今年の競技会で変わったことはというと、スクリプト言語をもう 1 つ追加しました。参加できる競技は、VBScript、Windows PowerShell、または新登場の Perl です (Perl 自体は新しい言語ではなく、この競技会に初めて追加されるということです)。おそらくさらにおもしろくなると思いますが、この補足記事は、競技会の何か月も前にまとめる必要があるので、実際どうなるかわかりません。最新情報については、スクリプト センターにアクセスしてください。
気になる方のために言っておくと、賞品が用意されます。それが何かというと、おっと、ここではびっくりする楽しみを奪わないでおきましょう。スクリプト センターにアクセスして調べてください。microsoft.com/technet/scriptcenter/funzone/games/default.mspx です。

おそらく、多くの方は、既にデータ入力の基本的な検証は行っているでしょう。そして、多くの場合、この単純なデータ入力の検証で問題ありません。文字列値 strName に含まれる文字が 20 文字以下であることを確認する必要がある場合には、次の簡単なコード ブロックを使用します。
If Len(strName) > 20 Then
    Wscript.Echo "Invalid name; a " & _
    "name must have 20 or fewer characters."
End If
strName の値が新しい部品番号で、部品番号は、4 桁の数字の後に 2 つの大文字のという指定のパターン (1234AB など) と一致する必要があるとします。シンプルな VBScript を使用して、strName の値が部品番号の指定のパターンに従っていることを検証できるでしょうか。はい、できます。ただし、まじめな話、その方法はお勧めしません。代わりに、正規表現の使用をお勧めします。

値に数字のみが含まれることを確認する
正規表現は 1950 年代に開発されたもので、当初は、数学的表記の形式として説明されました。1960 年代に入ると、この数学的モデルは、テキスト ファイル内の文字パターンの検索方法として QED テキスト エディタに組み込まれました。その後しばらくして...。何か言いましたか。おや、どうやら、正規表現の歴史にだれもが興味をそそられるわけではないようですね。わかりました。そうであれば、具体例をお見せしましょう。
変数 (ここでは strSearchString 変数) に数字のみが含まれるようにする必要がある場合には、図 1 に示すようなスクリプトを使用します。
Figure 1 数字だけが入力されるようにするスクリプト (Close Figure 1)
Set objRegEx = _
  CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\D"

strSearchString = "353627"

Set colMatches = _
  objRegEx.Execute(strSearchString)

If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
ご覧のとおり、このスクリプトでは、まず VBScript.RegExp オブジェクトのインスタンスを作成します。このオブジェクトにより、ご想像のとおり、スクリプトで正規表現を使用できるようになります (本当は、その説明をしたかったのですが、仕方がないですね)。その後、Global および Pattern という、正規表現オブジェクトの 2 つの主なプロパティに値を代入します。
Global プロパティは、スクリプトで、パターンに一致する文字列をすべて照合するのか、それとも単純に初出の文字列を検出したら照合を停止するのかを決定します。一般に、この値は True に設定し、パターンに一致するすべての文字列を検索することをお勧めします (既定値は False です)。多くの場合、パターンに一致するすべての文字列を検出する必要があります。その必要がなくても、最初の 1 つだけを検出することの利点は、途中で検索を停止した場合、最後まで検索を続けるよりもスクリプトの実行速度が速いということだけです。理論的には、良さそうに聞こえます。しかし、通常、検索は非常に短時間で完了するため、実際には大きな違いを感じません。
良いところは、Pattern プロパティでは目的の文字 (および文字の詳細) を指定します。サンプル スクリプトでは、0 から 9 の数字以外の文字を検索しています。そのような文字 (アルファベット、カンマ、ピリオドなど) が検出されると、strSearchString 変数に代入された値が有効ではないことがわかります。正規表現では、数字以外の文字を検索するのに \D という構文を使用します。そのため、Pattern プロパティに値 \D を代入します。
注 : \D が数字以外の文字に一致するということが、どうしてわかったのでしょう。実は、その裏には長い歴史があります。というのも、数年前...。ああ、そうでした。これについては、MSDN® の VBScript ランゲージ リファレンス (msdn2.microsoft.com/1400241x) で調べました。
Global プロパティと Pattern プロパティに値を代入したら、今度は strSearchString 変数に値を代入します。
strSearchString = "353627"
では、この文字列に数字以外の文字があるかどうか、どうしたらわかるのでしょう。答えは簡単です。単純に Execute メソッドを呼び出し、数字以外の文字があるかどうか変数を調査します。
Set colMatches = _
objRegEx.Execute(strSearchString)
Execute メソッドを呼び出すと、検出された一致する文字列 (Pattern のインスタンス) は自動的に Matches コレクションに保存されます (サンプル スクリプトでは、このコレクションに colMatches という名前を付けました)。(ここでは数字以外の文字が含まれていますが) 変数に数字以外の文字が含まれるかどうかを確認するのに必要な作業は、コレクションの Count プロパティ (コレクションの項目数を示す) の値を確認するだけです。
If colMatches.Count > 0 Then
    Wscript.Echo "Invalid: a " & _
      "non-numeric character was found."
Else
    Wscript.Echo "This is a valid entry."
End If
Count プロパティの値が 0 より大きい場合は、変数の値に数字以外の文字が検出されたということになります (変数の値に含まれるすべての文字が数字の場合、コレクションは空となり、Count プロパティの値は 0 となります)。サンプル スクリプトでは、その後、数字以外の文字が検出されたという事実をエコー バックします。実際のスクリプトやデータベースのフロントエンド アプリケーションでは、おそらく同様のメッセージを表示し、ユーザーが再試行できるようにループ処理の先頭に戻るでしょう。この処理については、皆さんにお任せします。何しろ Scripting Guys には、他に気にかけなければならないことがたくさんありますから。
たとえばどんなことがあるかというと、いつか、TechNet Magazine チームのメンバが、私たちが毎月送っている記事を実際に読み始めるかもしれないという心配です。私たちは、むしろ彼らには間違いから学んでほしくありません。
さて、良い質問ですね。IsNumeric 関数を使用して、strSearchString 変数に数字が含まれるかどうかを確認することはできないのでしょうか。もちろんできます。ただし、strSearchString 変数に含まれる数字が任意の数字であることが前提になります。strSearchString 変数の値が正の整数であることが必要な場合には、この関数を使用すると問題になる可能性があります。というのも、IsNumeric 関数では、次のどちらの数字も有効な数字として認識されるからです。
-45
672.69
なぜこれらが有効な数字として認識されるのでしょうか。その理由は、これらは単に正の整数ではないというだけで、有効な数字だからです。しかし、正規表現では、数字以外の文字の負符号 (-) やピリオド (.) を理解するため、これらの数字は無効なエントリとしてマークされます。このコラムを読みながら「このコラムを読む必要があるのだろうか」と思っていた場合は、まさにここにもっともな理由があります。
何か言いましたか。これでは不十分ですって。うわ、今月は手厳しいですね。わかりました。では、正規表現を使用して実行できる別の種類のデータ入力の検証についてご説明しましょう。

値に数字が含まれないことを確認する
変数の値に数字のみが含まれるようにする方法については、既に説明しました。では、反対に、変数の値に数字が含まれないようにするにはどうすれば良いでしょうか。その場合は、次の検索パターンを使用できます。
objRegEx.Pattern = "[0-9]"
上記のコードではどのような処理が行われているのでしょうか。おもしろく不思議な正規表現の世界では、角かっこ記号 ([ と ]) を使用して、一連の文字や (この例のように) 文字の範囲を指定できます。Pattern プロパティに設定されている [0-9] は何を意味するのでしょうか。これは、0 から 9 の範囲内のすべての文字、つまり数値を検索しているという意味になります。偶数のみが必要な場合 (つまり、値に 1、3、5、7、9 が含まれないようにする場合) には、次のパターンを使用します。
objRegEx.Pattern = "[13579]"
ハイフンを使用していないため、検索しているのは文字の範囲ではなく 1、3、5、7、9 という実際の文字を検索しています。
もちろん、パターン [0-9] では数字のみが検索されますが、カンマやピリオドなど、アルファベットでも数字でもない他の文字は検出されません。アルファベット以外の文字を検索するパターンを作成することはできるでしょうか。もちろんできます。正規表現を使用すれば、実質、何でも実行できます。
objRegEx.Pattern = "[^A-Z][^a-z]"
実は、このパターンでは 2 つの条件を組み合わせています。検索しているのは、[^A-Z] と [^a-z] です。おそらくおわかりのように、A-Z は、大文字の A から大文字の Z までという文字の範囲を表しています。では、^ 文字は何を意味するのでしょうか。^ が 1 組の角かっこ内に含まれるとき、この文字は "文字セット内にない文字を検索する" ことを意味します。したがって、[^A-Z] は、"大文字以外の文字を検索する" ことを意味します。一方、[^a-z] は、"小文字以外の文字を検索する" ことを意味します。つまり、このパターンは、大文字でも小文字でもない文字を検索していることを意味します。それには、数字、カンマやピリオド、キーボードに表示されているその他の見慣れない文字などが含まれます。
または、IgnoreCase プロパティを True に設定することもできます。
objRegEx.IgnoreCase = True
これにより、検索では大文字と小文字が区別されなくなります。すると、次のように Pattern プロパティを使用し、(IgnoreCase プロパティと組み合わせることで) 大文字でも小文字でもない文字を検索できます。
objRegEx.Pattern = "[^A-Z]"

部品番号が有効であることを確認する
では、少し高度な処理を実行してみましょう (正規表現を使用すると本当に高度な処理を実行できます。例については、Web サイト regexlib.com を参照してください)。この記事の前半で、次のように述べました。「strName の値が新しい部品番号で、部品番号は、4 桁の数字の後に 2 つの大文字のという指定のパターン (1234AB など) と一致する必要があるとします」と。変数の値がこのパターンと一致することを検証するにはどうすれば良いでしょうか。もちろん、次のように正規表現を使用します。
objRegEx.Pattern = "^\d{4}[A-Z]{2}"
このパターンは何を意味するのでしょうか。偶然の一致ですね。このパターンの意味をちょうど説明しようと思っていたところです。この場合、3 つの検索条件があります。
^\d{4}
\d は、数字 (0 ～ 9 の範囲の文字) を検索していることを意味します。{4} は何を意味するのでしょうか。これは、ちょうど 4 文字 (つまり 4 桁) の文字と一致する必要があることを意味します。したがって、4 つの連続する数字を検索していることになります。
では、^ 文字はどうでしょうか。^ が 1 組の角かっこで囲まれていない場合、この文字は、値が後続のパターンで始まる必要があることを意味します。つまり、AA1234AB は一致する文字列としてマークされません (その理由は、この値は 4 つの連続する数字ではなく AA で始まっているためです)。必要に応じて、$ 文字を使用し、文字列の最後に一致するパターンが発生する必要があることを示すこともできます。ただし、それは必要ありません (少なくともこの例では、という話ですが)。
[A-Z]{2}
既におわかりでしょうが、[A-Z] コンポーネントは大文字を意味します。では、{2} はどうでしょうか。そのとおりです。4 桁の数字の後に 2 つの大文字があることが必要です。
簡単ですね。ところで、ここでは、Count プロパティが 0 の場合は無効な値が検出されたことになります。その理由は、今回検索しているのは、文字列を無効にする 1 つの文字ではなく、パターンと完全に一致する文字列を検索しているからです。一致する文字列が検出されない場合、無効な値があることを意味します。また、コレクションの Count プロパティが 0 であることも意味します。
注 : その他に役立つのは、{3,} と {3,7} という 2 つの構文です。{3,} は、少なくとも 3 つの連続する文字 (または式) が必要であることを意味します。ただし、最小値は 3 ですが、最大値はありません。\d{3,} は、123、1234、123456789 に一致します。{3,7} は、3 つ以上、かつ 7 つ以下の連続する文字 (または式) が必要であることを意味します。したがって 123456 は一致する文字列と見なされますが、(7 つを超える連続する数字が含まれる) 123456789 という文字列は不一致と見なされます。
もう 1 つ役に立つパターンをご紹介しましょう。4 桁の数字、US というアルファベットの文字、最後の 2 文字 (アルファベットや数字などの任意の文字) と続く部品番号があるとします。このパターンに一致する文字列を検出する 1 つの方法を次に示します。
objRegEx.Pattern = "^\d{4}US.."
ご覧のとおり、このパターンは 4 桁の数字 (\d) で始まり、その後に US という文字が続く必要があります (US という文字のみで、それ以外の文字は一致する文字列とは見なされません)。US という文字列の後に、なんらかの文字が 2 文字必要です。正規表現では任意の文字をどのように示すのでしょうか。ちょっと待ってください、この方法はわかります。待ってください、わかりました。任意の 1 つの文字は、ピリオド (.) によって示されます。必然的に、2 つの文字は 2 つのピリオドによって示すことができます。
..
これは簡単でしたね。では、少し高度な処理を見てみましょう。部品番号の真ん中にある 2 つの文字が、部品が製造された国を示すとします。製造工場が米国、英国、スペインにある場合、US、UK、ES という 2 文字のコードはいずれも有効であることになります。正規表現で複数の選択肢を指定するには、一体どうすれば良いでしょうか。
次のスクリプトはどうでしょう。
objRegEx.Pattern = "^\d{4}(US|UK|ES).."
ここで重要なのは、(US|UK|ES) という部分です。3 つの許容される値 (US、UK、および ES) をかっこ内に配置し、各値をパイプ (|) 文字で区切っています。これが、正規表現で複数の選択肢を指定する方法です。
でもちょっと待ってください。角かっこ内には複数の選択肢を配置できると言いませんでしたか。それが [13579] で説明していた目的ではありませんでしたか。はい、そうです。ただし、ここで選択肢となるのは 1 つの文字です。[13579] という構文は常に 1、3、5、7、および 9 と解釈されます。135 や 79 を選択肢として使用するには、(135|79) という構文を使用する必要があります。また、次のように、かっこを使用して、検索する 1 つの単語を指定することもできます。
objRegEx.Pattern = "(scripting)"
また、かっこは省略することもできます。
objRegEx.Pattern = "scripting"
注 : そうですね、これは便利ですね。ですが、検索用語の一部としてかっこを含める必要がある場合にはどうすれば良いでしょうか。つまり、(scripting) という文字列を検索する場合にはどうでしょう。右かっこも左かっこも正規表現では予約文字であるため、各文字の前に \ を付ける必要があります。つまり、次のようになります。
objRegEx.Pattern = "\(scripting\)"

表現の自由
今月は、これで終わりです。正規表現についてさらに詳しく知りたい場合は、Web キャスト「システム管理者の文字列理論 : 正規表現の概要」(microsoft.com/technet/scriptcenter/webcasts/archive.mspx) を参照してください。そして、正規表現を習得および使用し始めるときには、次の Sophia Loren の不朽の言葉を肝に銘じておいてください。「間違いとは、豊かな人生を送るために支払わなければいけない税金のようなものである。」
すばらしい。私たち Scripting Guys は、思ったよりもずっと豊かな人生を送ってきたんですね。

Dr. Scripto のスクリプト パズル
パズルを解くスキルだけでなく、スクリプト作成スキルもテストする月に一度の課題です。

2008 年 1 月 : 名詞を探し出す
Dr. Scripto は、今月は、Windows PowerShell を使用することにしました。もちろん、コマンドレットなしで Windows PowerShell を使用することはできません。とはいえ、正しく使用していればの話ですが (Dr. Scripto はどんなことでも常に正しく行います)。Dr. Scripto は、このパズルのグリッドにいくつかのコマンドレットを配置しました。皆さんの課題は、それらを見つけることです。
さて、正直に言うと、正式なコマンドレットの名称を使用したら、このパズルの難易度はもう少し高くなるでしょう。コマンドレットは動詞と名詞を組み合わせた形式であるので、Get- や Set- などで始まるものが何十種類もあります。そのため、コマンドレットの動詞部分 (およびハイフン) を省き、名詞部分のみを残しました (ただ、ヒントをお教えすると、動詞部分はすべて Get- でした)。
今月の課題は、コマンドレットの名詞を探し出すことです。パズルに隠されている名詞の一覧は以下のとおりです (Scripting Guys は本当に寛大ですよね)。各語は、右から左へ、上から下へ、またその逆方向と縦横無尽に配置されていますが、斜めには配置されていません。例として最初の単語 (Location) をお知らせしておきます。では、頑張ってください。

名詞の一覧
Alias
ChildItem
Credential
Date
EventLog
ExecutionPolicy
Location
Member
PSSnapin
TraceSource
Unique
Variable
WMIObject

Dr. Scripto のスクリプト パズル
解答 : 名詞を探し出す (2008 年 1 月)

Microsoft Scripting Guys は、マイクロソフトの仕事をしています、というよりもマイクロソフトにより雇われています。野球をプレイしたり監督したり観戦したり (または他のさまざまな活動を) しているのでない限り、彼らは TechNet スクリプト センターを運営しています。詳細については、www.scriptingguys.com を参照してください。


 セキュリティ ウォッチ: 島巡り : 魅惑的なベンダの配布物
セキュリティ ウォッチ
島巡り : 魅惑的なベンダの配布物
Jesper M. Johansson

島巡り (脆弱なリンクを介してネットワークに侵入し、そのネットワーク内にあるシステムを移動して回る) という技術は何年も前から存在します。しかし、この技術は新しい特性を取り入れ続けています。現在、IT 環境ではセキュリティへの関心が高くなっているので、ユーザーが最も脆弱なリンクになっています。悪意のあるユーザーは、
自分たちの利益のために、この脆弱性を利用する方法を探し出します (フィッシングやその他の形式のソーシャル エンジニアリングについて考えてみてください)。この炭素とケイ素のように相性の良い組み合わせは、ネットワークに致命的な影響を与えることがあります。
人的要因を利用する方法の中で、私が最も気に入っているものの 1 つは、Secure Network Technologies の Steve Stasiukonis がある顧客のために行った浸透テストです。彼は、この顧客の駐車場に、トロイの木馬がインストールされた USB フラッシュ ドライブを置いておきました。従業員は、出勤したとき、駐車場に無料の USB フラッシュ ドライブが置いてあるのを見つけて興奮しました。そして、この USB ドライブを積極的に手に取って、最初に目に付いたコンピュータに接続しました。つまり自分たちのワークステーションに接続したのです。
おそらく、従業員の中には、この USB ドライブを無視する賢明な人もいて、一部の USB ドライブは破棄されたかもしれません。しかし、1 人の従業員が 1 つの USB ドライブをコンピュータに接続すると、そのコンピュータはウイルスに感染し、ネットワークへの入り口を提供することになります。もちろん、これは Stasiukonis がテストとして行ったことですが、この技術は、犯罪者が実際に大規模な企業ネットワークに侵入するために使用したものです。
最近は、USB フラッシュ ドライブが至るところにあります。大半のカンファレンスでは、ベンダが、キャンディのように USB フラッシュ ドライブを配っています。このようなドライブの容量は大きくないかもしれませんが、ネットワーク全体を乗っ取るのに大きな記憶域は必要ありません。この 2 部構成のシリーズでは、この類の攻撃を調査して、リスクを軽減する方法を説明します。今月の記事では、USB フラッシュ ドライブを使用してできることと、USB フラッシュ ドライブを制御するためにできることについて説明します。来月号の TechNet Magazine では、ネットワーク上の 1 つのシステムまたは一部のシステムに対して行われる攻撃を阻止する方法について説明します。
攻撃の技術的な詳細は、実はとても単純です。すべての発端は、ウイルスに感染した USB フラッシュ ドライブが 1 台のコンピュータに接続されることです。それから何が起こるかは、そのドライブが持っている破壊力と、もちろんそのユーザーがどれほど騙されやすいかによって異なります。

原因
演壇に無人のラップトップがありました。講演者はプレゼンテーションを開始する前に、聴衆の機嫌を取ることに気を取られています。ラップトップ自体はロックされていましたが、それはほとんど意味がありませんでした。攻撃者は演壇に登り、話し手が戻ってくるのを待っていることを装って、その場に少しそこにとどまりました。このような演壇ではコンピュータのような見苦しいものを隠すように作られているため、USB ポートや攻撃者の手の動きは見えません。USB フラッシュ ドライブがコンピュータに接続されると、攻撃はほんの数秒で完了します。
このテーマには、ある明らかなバリエーションがあります。たとえば、私が毎週のようにプレゼンテーションをしながら世界中を旅していたときのことです。私がプレゼンテーションを終えると、ほぼ毎回、数人の参加者が私のスライドを欲しがります。私はいつも名刺を渡して、電子メール メッセージを送るようにお願いしています。このような参加者が私に対して USB フラッシュ ドライブを差し出したときに、なぜ私は電子メールの送付を求めたのでしょうか。それは、USB Hacksaw、USB Switchblade などのツールについて知っていたからです (このようなツールをご存知ない場合は、wiki.hak5.org を参照してください)。
基本的に、このようなツールを使用すると、ほぼだれでも容易に USB ポートを保護していないコンピュータに攻撃を仕掛けることができます。たとえば、Switchblade では次のような情報をダンプできます。
  • システム情報
  • すべてのネットワーク サービス
  • リッスンしているポートの一覧
  • コンピュータにインストールされているマイクロソフト製品のすべてのプロダクト キー
  • ローカルのパスワード データベース
  • コンピュータで使用されているあらゆるワイヤレス ネットワークのパスワード
  • 現在のログオン ユーザーがコンピュータに保存しているすべてのネットワーク パスワード
  • Internet Explorer®、メッセンジャー、Firefox、および電子メールのパスワード
  • ローカル セキュリティ機関 (LSA) の機密情報 (ここには、すべてのサービス アカウントのパスワードがクリア テキストで含まれています)
  • インストールされている修正プログラムの一覧
  • 最近の閲覧の履歴
これらのすべての情報は、フラッシュ ドライブのログ ファイルに格納され、この処理は約 45 秒で完了します。
Hacksaw は、Switchblade が少し変更されたものです。このツールは、すべての USB フラッシュ ドライブの挿入イベントを監視するトロイの木馬をコンピュータにインストールします。その後、コンピュータに接続されたすべてのフラッシュ ドライブから、すべてのドキュメントを電子メールで攻撃者に送信します。
ここで紹介したツールでは、U3 (u3.com) が使用されています。これは、フラッシュ ドライブを使用してユーザーがプログラムを持ち歩けるようにデザインされた技術です。簡単に言うと、U3 対応のフラッシュ ドライブは偽装をします。フラッシュ ドライブが搭載された USB ハブで、そこに CD が挿入されていると OS に伝えるのです。既定では、Windows Vista® より前の Windows® のバージョンでは、USB ドライブではなく CD に収録されている autorun.inf ファイルで指定されたプログラムが自動的に実行されます。偽装することで、U3 対応の USB フラッシュ ドライブは、OS を騙して U3 ランチャーというソフトを自動実行させます。その結果、U3 ランチャーはプログラムを起動し、メニューを表示し、ユーザーがコンピュータに対して行えるほとんどの操作を実行することができます。
このような攻撃ツールで行っているのは、U3 ランチャーを攻撃を仕掛けるコードに置き換えるだけです。フラッシュ ドライブが Windows XP システムに接続されるとすぐ、攻撃ツールが自動的に実行されます。Windows Vista では、自動再生を決定する流れは異なります。自動再生が実際に有効なのは、CD などのリムーバブル デバイスです。つまり、デバイスが接続されたときに、なんらかの操作が発生するということです。既定では、[自動再生] ダイアログ ボックス (図 1 参照) が表示されます。
図 1 画像を含むリムーバブル ドライブを接続すると、既定の [自動再生] ダイアログ ボックスが表示される
図 1 画像を含むリムーバブル ドライブを接続すると、既定の [自動再生] ダイアログ ボックスが表示される
図 1 のダイアログには、[ピクチャに対しては常に次の操作を行う] チェック ボックスがあります。このチェック ボックスにより自動再生のオプションが設定されます。この設定は、コントロール パネルで構成できます (図 2 参照)。
図 2 Windows Vista での自動再生の構成
図 2 Windows Vista での自動再生の構成
自動再生の構成で特に興味深いのは、"ソフトウェアとゲーム" です。その名前のとおり、リムーバブル ディスクには、特定のプログラムの実行を指定する autorun.inf ファイルがあります。"ソフトウェアとゲーム" に関連する設定 (図 2 参照) は、次のレジストリ キーに格納されています。
Hive:    HKEY_CURRENT_USER
Key:    \Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\
UserChosenExecuteHandlers\AutorunINFLegacyArrival
Value: (Default)
Data:
MSAutoRun – automatically executes the program specified in the autorun.inf file

MSPromptEachTime – prompts the user, using strings specified in the autorun.inf file, if available
この設定の変更には管理者権限が必要ないので、ユーザーは、この設定を好きなように構成できます。それには、従業員が駐車場で見つけたドライブにインストールされていて、自動的に実行されるマルウェアも含まれます。実際、[自動再生] ダイアログ ボックスで適当なチェック ボックスをオンにするとマルウェアが自動的に実行されます。

ネットワークで自動再生を管理する
管理者として、ネットワーク全体の自動再生を管理できる方法はいくつかあります。まず、自動再生が有効なドライブの種類を制御する NoDriveTypeAutoRun の設定を変更することによって、ユーザーがリムーバブル メディアや CD の自動再生を有効にできなくすることが可能です。Windows XP は、NoDriveTypeAutoRun が 0x95 に設定された状態で出荷されています。この設定により、不明なドライブの種類、ネットワーク ドライブ、およびリムーバブル デバイスの自動再生が無効になっています。Windows XP SP2 以降では、既定で NoDriveTypeAutoRun の設定が 0x91 になっています。この設定により、リムーバブル記憶装置の自動再生が有効になります。グループ ポリシーを使用している場合は、"ユーザーの構成\管理用テンプレート\Windows コンポーネント\自動再生のポリシー" にある設定で NoDriveTypeAutoRun の設定を管理できます。"自動再生機能をオフにする" の設定を有効にし、[CD-ROM とリムーバブル ドライブ] を選択すると、これらの種類のドライブで自動再生が無効になります。
この設定により、[自動再生] ダイアログ ボックス (図 1) は表示されなくなります。実際、ユーザーがドライブを挿入しても何も起こりません。ただし、これは理想的な解決策ではない場合があります。というのも、ドライブ上にある必要な情報にアクセスする方法がわからないユーザーを混乱させるおそれがあるからです。
実際に必要なのは、自動再生されるコンテンツの種類を制御することでしょう。Windows Vista では、自動的に実行されるソフトウェアについて 2 段階の制御が用意されているので、このような制御もある程度は可能です。グループ ポリシーには、autorun.inf ファイルを使用したソフトウェアの自動再生だけを無効にし、それ以外の Windows Vista の自動再生の動作は変更しない別の制御が用意されています (図 3 参照)。
図 3 グループ ポリシーを使用して autorun.inf ファイルを無効にする
図 3 グループ ポリシーを使用して autorun.inf ファイルを無効にする
自動再生に関する決定の流れは少し複雑なので、最もわかりやすいと思われるフローチャートを使用して説明しましょう。図 4 は、リムーバブル メディアにあるファイルを自動的に実行するかどうかを判断する場合に使用される決定の流れを表しています。
図 4 自動再生の決定の流れ
図 4 自動再生の決定の流れ

その他の原因
もちろん、ここで紹介したものは、USB フラッシュ ドライブを使用してコンピュータに進入する場合に利用されるツールの一部に過ぎません。このシナリオには、あらゆる種類のツールを加えることができます。たとえば、現在ログオンしているユーザーの Windows NT® のパスワード ハッシュをダンプするツールなどがあります (microsoft.com/technet/community/columns/secmgmt/sm1005.mspx を参照してください)。
多くの USB コントローラの実態は、ダイレクト メモリ アクセス (DMA) デバイスです。つまり、USB コントローラは、オペレーティング システムを経由しないで、直接コンピュータのメモリの読み取りと書き込みができるということです。OS を経由しないということは、OS で提供されるセキュリティ制御が回避されるということになります。つまり、ハードウェアに対して、完全かつ自由にアクセスできるようになります。これにより、OS によって実装されるデバイス制御の効果が完全になくなります。現在、この技術を使用しているハッキング ツールがあるかどうかは知りませんが、「この技術は使用されたことがない」ということに関しては非常に疑問視しています。
ユーザーとリムーバブル デバイスの組み合わせを悪用する別の方法は、単にユーザーに魅力的なオプションを提示することです。たとえば、何人のユーザーが図 5 のようなダイアログ ボックスをクリックするでしょうか。全員でなくても、多くのユーザーがクリックするでしょう。重要なのは、ユーザーが無視できないような魅力的なダイアログ ボックスを作るのはとても簡単な作業だということです。
図 5 何人のユーザーがこのダイアログ ボックスの犠牲になるのでしょうか
図 5 何人のユーザーがこのダイアログ ボックスの犠牲になるのでしょうか

デバイスをブロックする
Windows Vista では、デバイスのインストールを管理する新しい一連のポリシーが導入されました (図 6 参照)。この図にあるように、ドライバによってリムーバブル デバイスであることが示されている場合、管理者はすべての新しいリムーバブル デバイスのインストールをブロックすることができます。ただし、ドライバによってリムーバブル ディスクではないことが示されているデバイスについては、このポリシーは無効になります。したがって、カスタム ドライバを使用すると、このポリシーを迂回することができます。
図 6 Windows Vista のデバイスのインストール ポリシー
図 6 Windows Vista のデバイスのインストール ポリシー
さらに細かく制御するために、管理者は、特定のデバイス セットアップ クラスに適用されるポリシーを使用することができます。ただし、このような細かい制御を行うには、ブロック (または許可) する特定のデバイス クラスの GUID を把握している必要があり、この方法による管理は比較的難しくなります。

重要なのは最小限の特権
ここでは DMA のシナリオは除外しますが、この記事で説明した攻撃が成功するかどうか、また対処方法がうまく機能するかどうかは、コンピュータを使用するユーザーの特権に左右されます。コンピュータを使用しているユーザーが標準ユーザーである場合、攻撃による被害の範囲は限られます。そのユーザーが所持しているデータやアクセスできるデータは盗まれてしまいますが、ネットワーク全体に影響する可能性は低いでしょう。
しかし、攻撃されたユーザーが管理者の場合、その被害の範囲は深刻なものになります。最悪のシナリオは、ユーザーがドメイン管理者である場合です。この場合、ネットワーク全体を乗っ取るのは非常に簡単なことです。たとえば、攻撃者はメモリからユーザーのパスワード ハッシュを抽出できます。システムでは、ユーザーに代わってネットワーク リソースに透過的にアクセスできるように、ログオン時に LSA プロセスの領域にハッシュをキャッシュします。管理者特権を手にした攻撃者は、このハッシュを抽出および使用してネットワーク内のすべてのネットワーク リソースにアクセスできます。つまり、ユーザーがドメイン管理者の場合、ドメイン全体が危険にさらされることになります。
このことは、依存関係のトピックを思い起こさせます。この記事では、ワークステーション上の特定の攻撃について概説しました。ただし、まだ、どのような種類の攻撃がネットワーク規模の被害をもたらすのかについては説明していません。来月は、依存関係の概念や、それが環境全体に対して持つ意味を説明します。そして、さらに重要なことですが、その依存関係を強固なものにするための対策を紹介します。

Jesper M. Johansson は、ソフトウェアのセキュリティ問題に取り組むセキュリティ エンジニアで、TechNet Magazine の編集にも携わっています。MIS の博士号を持ち、セキュリティの分野で 20 年以上の経験があります。


 デスクトップ ファイル: Windows SteadyState で共有コンピューティングを管理する
デスクトップ ファイル
Windows SteadyState で共有コンピューティングを管理する
Wes Miller

過去 10 年ほどの間にコンピュータ室の近くにいたことのある方なら、共有コンピュータの問題についてはよくご存知でしょう。私が最初にこの問題を経験したのは、大学時代でした。当時、コンピュータ室は (学生 ID があれば) 1 日中利用でき、図書館の中に入ってしまえば事実上やりたい放題でした。
そのころのゲーム好きな学生は、コンピュータ室に来てはゲームを実行するために Windows® や MS-DOS® の重要なファイルを変更したものでした。この結果、コンピュータでゲームを正常に実行できるようになる場合もありましたが、Windows は (たとえ実行できたとしても) 正常に実行できなくなりました。共用コンピュータが、使おうとすること自体が時間の無駄になるほどひどい状態になった経験はだれにでもあるでしょう。
最近、私は休暇でここテキサス州のサウス パドレ島に行きました。私が泊まったホテルの "ゲスト コンピュータ室" には、Windows XP を実行する 3 台のコンピュータがありました。利用者全員が管理者としてこの Windows システムを実行し、さらにこれらのコンピュータにはポリシーが設定されていませんでした。つまり、宿泊者が悪意のあるソフトウェアをインストールしたり、主要なアプリケーションの削除や変更を行ったりしたことで、これらの哀れなコンピュータはどれもひどく痛めつけられたのです。ホテル側はこのような方法で利用されるとは想定していなかったでしょう。実際、大学のコンピュータ室であれホテルであれ、公共の環境にある共用コンピュータは、多くの場合、家庭のコンピュータよりも過酷な状況にさらされています。

問題の解決策
SteadyState を入手して使用する
Windows SteadyState は、http://go.microsoft.com/fwlink/?LinkId=104721 から無償でダウンロードできます。SteadyState の詳細については、microsoft.com/windows/products/winfamily/sharedaccess を参照してください。
Windows SteadyState は、Windows XP を実行できるすべてのシステムで動作します。Shared Computer Toolkit (SCT) からの最大の改善点は、SCT では Windows ディスク保護を使用するために 2 つ目のパーティションが必要であったのに対し、SteadyState では不要になったことです。
次の表に、SteadyState の大まかなシステム要件を示します。SteadyState では Windows XP のすべてのバージョンがサポートされていますが、NTFS 形式のファイル システムが必須です。現時点では、SteadyState は Windows Vista® では動作しません。

構成要素 | 要件
プロセッサ | 300 MHz 以上 (最小 233 MHz)
メモリ | 128 MB 以上の RAM (最小要件は 64 MB ですが、パフォーマンスと一部の機能が制限される可能性があります)
ハード ディスク | Windows ディスク保護を使用しない場合は 1.5 GB 以上の空き領域、Windows ディスク保護を使用する場合は 4.0 GB 以上の空き領域
オペレーティング システム | Windows XP Home Edition、Windows XP Professional、または Windows XP Tablet PC Edition (Windows XP SP2 がインストールされている必要があります)
サポートされているローカライズ版の言語 | 英語、オランダ語、フランス語、イタリア語、日本語、ポルトガル語 (ブラジル)、簡体字中国語、およびスペイン語
ファイル システム | NTFS 形式のファイル システム
アクセス | 管理者レベルのアクセス権

この 1 年間私のコラムをお読みになっている方や、Windows の展開全般に詳しい方なら、"たいした問題じゃないね。システムのイメージを再作成するだけさ" と思われるかもしれません。しかし、実際に作業を行った方はおわかりになると思いますが、この作業は必ずしも簡単とは限りません。イメージを再作成するための大きな赤いボタンを毎日、または毎週クリックする労力はなかなか想像できないものです。
数年前、友人と私はインターネット カフェの開業を検討したことがあります。1995 年当時、これはなかなか独創的な考えでした。最大の懸念事項は、実際にシステムの信頼性と可用性を保証する方法でした。残念ながら、当時の対策はすべてのイメージを再作成することが中心で、他にはそれよりも少し堅牢な解決策があるくらいでした。問題をすぐに解決してくれる、いわゆるプラグ アンド プレイの方法はありませんでした。
問題を整理すると、次の 3 つのことが可能になれば、共用コンピュータのセキュリティを保護できます。
  • ユーザーが管理者以外のアカウントのみを使用するようにします。特に、共用コンピュータにはこのような機能が必要です。
  • システムのセキュリティができる限り強化されるようにポリシーを設定します。これにより、アクセスしてはいけないシステムの領域をユーザーが操作する可能性が低下します。
  • ユーザーによる無作為な変更をロールバックできるようにします。ユーザーは管理者以外のアカウントを使用している場合でも、メニューやお気に入りなどに悪意のある変更を加えることができます。
さいわい、マイクロソフトはこの数年間、まさにこのようなシナリオに役立つように設計されたツールセットの開発に取り組んできました。

SteadyState の歴史
1 年ほど前、マイクロソフトは Windows Shared Computer Toolkit (SCT) をリリースしました。SCT は、Windows Genuine Advantage (正規 Windows 推奨プログラム) で検証されたシステムであれば無償でダウンロードできます。このツールキットは、特に図書館、インターネット カフェ、コンピュータ室などの共有コンピューティング環境を念頭に置いて設計されました。SCT については、TechNet Magazine の 2006 年 7 月号 (technetmagazine.com/issues/2006/07/UtilitySpotlight) でご覧になった方もいらっしゃるでしょう。
2007 年 6 月に、新しいバージョンが Windows SteadyStateTM (microsoft.com/windows/products/winfamily/sharedaccess) と名前を変えてリリースされました。このツールセットは、従来のバージョンから機能が大幅に変更されたことなどを理由に、新しいバージョンでは名前が変更されました。この後で説明するように、SteadyState で行われる作業は以前と同じですが、開発チームは、この最新リリースでは全体的な使いやすさに重点を置きました。その結果、SteadyState は新しいコンソールに密接に統合され、簡単にインストールおよび管理できるようになりました。SteadyState はより強力かつ柔軟になり、主要なコンポーネントの 1 つでは Active Directory® の統合がサポートされています。つまり、いくつかのまったく新しい企業のシナリオにおける柔軟性が向上しました。また、SteadyState では Windows Update の統合もサポートされているため、更新プログラムを適用するために Windows ディスク保護を無効にするタイミングが自動的に認識されます。これにより、SteadyState で管理しているシステムの管理オーバーヘッドが軽減されます。

SteadyState の機能
Windows SteadyState は、4 つの主要なコンポーネントで構成されています。コンピュータの制限機能は、コンピュータごとにセキュリティ オプションと構成オプションを制限します。Windows ディスク保護は、Windows システム パーティションの変更をキャッシュして元に戻すことを可能にします。ユーザー アカウント マネージャは、ユーザーの作成、編集、インポート、またはエクスポートを行います。最後に、ユーザーの制限と設定機能は、ユーザーごとにセキュリティ オプションと構成オプションを制限します。
Shared Computing Toolkit から強化された機能の 1 つが、ユーザー向けのヘルプであることにはすぐお気付きになるでしょう。スタートアップ ガイドは、SteadyState の初期設定を行う際に役立ちます。SteadyState では、4 つの主要な作業が提供されます (上記の主要な機能が反映されています)。これらの作業について、以下で詳しく説明します。
  • コンピュータの制限の設定 (コンピュータの制限)。
  • ソフトウェア更新のスケジュール (SteadyState が自動的に Windows Update を適用するかどうかを指定できます。Windows ディスク保護の動作を自動的に調整したり、いくつかの重要なウイルス対策プログラムの定義ファイルを更新したりすることもできるため、この設定を有効にすることをお勧めします)。
  • ハード ディスクの保護 (Windows ディスク保護)。
  • 新しいユーザーの追加 (ユーザー アカウント マネージャ)。
ユーザーの追加を行った後、ユーザーの制限と設定の機能を使用して、ユーザーごとに構成オプションを設定できます。

コンピュータとユーザーの制限と設定
Windows グループ ポリシーに詳しい方は、SteadyState のコンピュータの制限の設定機能とユーザーの制限と設定機能について簡単に理解していただけると思います。SteadyState の管理者は、Windows XP Home Edition で使用できないグループ ポリシー オブジェクト エディタ (GPEdit.msc) を使用する必要はありません (SteadyState は Home Edition 上でもサポートされています)。SteadyState では、共有コンピューティングのシナリオでよく使用される、主要なセキュリティ オプションおよび構成オプションが提供されます。
図 1 は、コンピュータの制限の設定機能の構成画面を示しています。これらの設定はすべて、コンピュータ全体に適用される一般的な設定です。これらの設定は、主にシステムのセキュリティ リスクを最小限に抑えることを目的としています。また、USB ドライブへのアクセスに関する設定は、システムからデータが削除される可能性を最小限に抑えることを目的としています (ユーザーごとの設定では、一部、またはすべてのドライブへの読み取りアクセスをブロックできます)。
図 1 SteadyState のコンピュータの制限機能
図 1 SteadyState のコンピュータの制限機能
SteadyState が構成された実際の Windows インストールを実行している間のみ、USB の設定が有効になることに注意してください。オフライン攻撃からコンピュータを保護するために、USB デバイスまたは CD-ROM デバイスからの起動をブロックし、BIOS 自体もパスワードで保護されるように BIOS を適切に構成する必要があります。
もちろん、これは完璧な対策ではありません。「セキュリティに関する 10 の鉄則」(microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx) の第 3 条にもあるように、悪意のあるユーザーがあなたのコンピュータに物理的に無制限にアクセスできるとしたら、それはもうあなたのコンピュータとは言えません。多くの場合、専門家が十分な時間をかけて適切なツールを使用すれば、BIOS のパスワードは迂回できます。

Windows ディスク保護
Windows XP Embedded を CD-ROM から使用したことがあるか、Windows PE 2.0 を使用したことがある場合、これから説明する内容に聞き覚えがあることでしょう。その理由は、これらに共通の歴史があるためです。Windows ディスク保護では、Windows システム パーティションを完全に "元に戻す" ことができます。これは、システム パーティションに加えられたすべての変更を同じパーティションのキャッシュに保存することによって実現されます。このコンポーネントは、ユーザーがシステムの使用中に加えた変更を元に戻すことができるため、SteadyState の重要な側面であると言えます。
Windows ディスク保護は、主に、一定の時間が経過した後、システムを (予定外の再起動後や予定した間隔で) 初めて展開したときの状態にすばやくロールバックする必要がある場合に役立ちます。Windows ディスク保護では、ダイアログ ボックスで設定できる次の 4 種類のモードが提供されます (図 2 参照)。
図 2 Windows ディスク保護の構成
図 2 Windows ディスク保護の構成
[オフ] Windows ディスク保護が完全に無効になり、すべての変更が通常どおりディスクに書き込まれます。
[オン] および [再起動時にすべての変更を削除する] Windows ディスク保護が有効になり、コンピュータを再起動するたびにすべての変更が破棄されます。つまり、システムはこのオプションをオンにして保存したときとまったく同じ状態に戻ります。
[オン] および [一時的に変更を保持する] 前のオプションとほぼ同じですが、次の再起動時ではなく指定した日時に変更が破棄されます。日単位または週単位で変更を破棄する場合はこのオプションをオンにします。
[オン] および [すべての変更を永続的に保持する] このオプションの概念は [オフ] と紛らわしいですが、一時的なモードであるという点が異なります。たとえば、アプリケーションの更新プログラムの適用、新しいアプリケーションのインストール、またはシステムの構成を行う必要がある場合、このモードを使用できます。通常、このモードが選択された状態を長期間継続することはありません。
これらのモードの切り替えを Windows ディスク保護に反映するには、コンピュータを再起動する必要があります。

ソフトウェア更新のスケジュール
ソフトウェア更新のスケジュールは、SteadyState に Windows ディスク保護のオンとオフを自動的に切り替える機能を提供するという点で便利な設定です。SteadyState で更新プログラムの適用を管理するように設定すると、更新プログラムの実行中は変更を保持するように Windows ディスク保護が設定され、更新が完了すると Windows ディスク保護は更新前のモードに戻ります。管理作業を 1 つ減らすことができるため、この設定を強くお勧めします。
ソフトウェア更新機能でサポートされているセキュリティ ソフトウェアは、Computer Associates eTrust 7.0、McAfee VirusScan、Windows Defender、および TrendMicro 7.0 です。

ユーザー アカウント マネージャ
[新しいユーザーの追加] を使用すると、システムの新しいユーザーを構成できます。図 3 は、新しいユーザーの構成に使用できるオプションを示しています。具体的には、ユーザー名、パスワード、そのユーザーを表す画像、およびユーザー プロファイルの場所を指定します。ユーザーを作成したら、これらのローカル アカウントごとに制限と設定を構成できます。この機能の優れた点は、システムにアカウントを追加して構成した後、必要に応じて (またはアーカイブ用に) そのユーザー プロファイルをエクスポートして別のシステムにインポートできるところです。
図 3 ユーザー アカウントの追加
図 3 ユーザー アカウントの追加
ユーザー アカウント マネージャの便利な点は、[ユーザーの場所] ボックス (図 3 参照) を使用して、ユーザー プロファイルをプライマリ パーティション以外のパーティションに作成できるところです。通常、セットアップ中に unattend.txt ファイルを使用して手動で別の Documents and Settings の場所を指定しない限り、プロファイルは Windows パーティション上に作成されます。この SteadyState の機能は特に有用です。Windows ディスク保護が有効になっていると Windows システム パーティションに加えられた変更が破棄されるためです。Windows ディスク保護キャッシュの内容が消去された後もユーザーのプロファイルの整合性を維持する必要がある場合は、ユーザー アカウント マネージャを使用してユーザーを作成するときに、そのユーザーのプロファイルが別のローカル パーティションに保存されるように指定します。
この処理のしくみを確認するには、コンピュータを再起動して Windows ディスク保護キャッシュの内容を消去し、更新プログラムを適用してから再びコンピュータを再起動して Windows ディスク保護をリセットします。SteadyState は、Windows Update の更新プログラムを適用するだけでなく、サポートされているいくつかの一般的なウイルス対策アプリケーションの定義ファイルを更新します (補足記事「SteadyState を入手して使用する」を参照してください)。ウイルス対策アプリケーションがサポートされていない場合や、他の更新機能を実行する必要がある場合は、手動で更新を行うことができます。手動で更新する場合は、Windows ディスク保護を無効にしてください。無効にしなかった場合、定義ファイルの更新内容は失われます。

ユーザーの制限と設定
ユーザーを選択すると、ユーザーの制限が 4 つに分類されて表示されます。この分類はグループ ポリシーの設定から派生しているため、おそらくよくご存知でしょう。
[全般] タブの設定は、ユーザー プロファイルと強制的なログオフの構成を制御します。ここでは、プロファイルのロック、ログオフされるまでの使用時間やアイドル時間などを設定できます。
[Windows の制限] タブの設定 (図 4 参照) は、Windows 固有の構成項目を制御します。たとえば、スタート メニューのコンポーネントやエクスプローラの機能など、Windows のユーザー インターフェイス項目にアクセスできないように設定することができます。ドライブ文字を指定して特定のドライブへのアクセスをブロックする機能や、CD-ROM への書き込みを無効にする機能もあります。
図 4 Windows 固有のユーザーの制限
図 4 Windows 固有のユーザーの制限
[機能の制限] タブ (図 5 参照) では、ほとんどの Internet Explorer® の機能へのアクセスをきめ細かく制御できます。Internet Explorer のホーム ページを設定したり、Microsoft® Office の機能をある程度 (主に Visual Basic® for Applications (VBA) スクリプトの実行) 制限したりすることができます。
図 5 機能の制限
図 5 機能の制限
[ブロックするプログラム] タブの設定 (図 6 参照) は、特定のアプリケーションの実行を制御します。基本的には、ブラックリストを作成します。いくつかの一般的なアプリケーションの実行を制限することができますが、他のアプリケーションを追加することもできます。これらの項目はパスの定義に基づいてブロックされます。ユーザーがアプリケーションをシステムの他の場所に移動できる場合、このパスの規則は適用されなくなります。しかし、ファイルとディレクトリに ACL やその他の方法を使用してシステムへのアクセスを正しく制限することで、ユーザーが簡単にアプリケーションを移動できないようにすることができます。
図 6 プログラムの実行のブロック
図 6 プログラムの実行のブロック
SteadyState のもう 1 つの重要な新機能は、Windows の制限と機能の制限の両方の制限レベルが指定された構成済みのテンプレートに基づいています。このテンプレートを使用すると、必要な機能の制限レベルに応じて、基準を満たした構成を簡単に使用できます。もちろん、カスタム テンプレートを作成することもできます。

SteadyState の制限
SteadyState は、組織の共有コンピューティング システムを安定させるための非常に有用なツールです。市販のツールとしては、良いツールと言えます。無償のツールとしては、申し分のないツールです。しかし、万能のツールではありません。
共有コンピューティング システムは、攻撃や意図的でない誤用の被害を受けやすいシステムです。アクセスする必要のない情報から、これらのシステムを隔離する必要があります。SteadyState にはアプリケーションへのアクセスをブロックする機能もありますが、この設定はソフトウェアの制限のポリシーを使用して適用されます。数年前に Mark Russinovich が指摘したように、抜け目ないユーザーであれば、一見無害ながら、制限付きユーザーでもソフトウェアの制限のポリシーによる制限を受けずに実行できるアプリケーションを作成できます (blogs.technet.com/markrussinovich/archive/2005/12/12/circumventing-group-policy-as-a-limited-user.aspx を参照してください)。すべてのデバイスとインターネット アクセスをブロックしていない場合は、この脆弱性に注意する必要があります。常に第 3 条を忘れないでください。
当然ですが、SteadyState は、適切に構成された共有コンピューティング システムの 1 つの構成要素にすぎません。Windows Update で定期的に更新プログラムを適用し、Windows ファイアウォール (または別のファイアウォール) を適切に構成することが重要です。また、コンピュータの潜在的なリスクの分析結果に応じて、ウイルス対策、スパイウェア対策、およびその他のセキュリティ対策プログラムをインストールして構成する必要があります。同様に、コンピュータへのアクセスを制御します。制御できない場合は、コンピュータが表示できる項目を制御します。さらに、機密データはローカルに保存しないようにします。
最後に、プラットフォームを検証する際、SteadyState (使用する予定がない場合を除いて、Windows ディスク保護を有効にします) と、システムで実行するその他のソフトウェアをすべてテストするようにしてください。これらのソフトウェアと SteadyState を同時に実行しても最適に動作するかどうかを確認することができます。

SteadyState のサポート
私が確認した SteadyState に関するユーザーのフィードバックは、非常に肯定的でした。これまでのところ、ユーザーを追加する順番に関する問題など、何件かの小さな問題を耳にしています。この問題の多くは、他のヒントやテクニックと共に、非常に活発な Windows SteadyState コミュニティ (forums.microsoft.com/windowstoolsandutilities) で取り上げられています。SteadyState のアプリケーションとドキュメントでも、このコミュニティへの便利なリンクが提供されています。
また、SteadyState を使い始める前に、SteadyState ハンドブック (go.microsoft.com/fwlink/?LinkId=104722) にも目を通されることをお勧めします。このハンドブックでは、適切に SteadyState を使用するためのたくさんのヒントやテクニックが紹介されています。

まとめ
SteadyState では、アクセスを制御する必要があるすべての Windows XP システムに使用できる優れた機能がまとめて提供されます。そのうえ、SteadyState は無償で入手できます。Windows ディスク保護機能が劇的に改善され、ユーザー インターフェイスが強化されたことで、展開作業と共有アクセス システムの全体的な管理作業が簡略化されました。
SteadyState は、コンピュータ室のシステム、訪問者や従業員向けの共有アクセス キオスク、トレーニング ルームなど、あらゆる共有コンピューティングのニーズに対応しており、より簡単にシステムを稼動させ、維持するのに役立ちます。SteadyState を使用すると、システムを回復させるためだけに毎週イメージを再作成する必要がなくなります。これは大きな進歩だと私は考えています。

Wes Miller は、テキサス州オースティンにある Initiate Systems 社 (InitiateSystems.com) のテクニカル プロダクト マネージャです。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラム マネージャとして働いていました。Wes の連絡先は、technet@getwired.com (英語のみ) です。


 フィールド ノート: 1 日で最も重要な作業
フィールド ノート
1 日で最も重要な作業
Eric N. Bush

ビル・ゲイツは、 年に 2 回、「考える週」と称して休暇を取ります。そして、この間は、人との接触、電話、電子メールを絶ち、読みものに没頭します。マイクロソフトと世界中のテクノロジの状況について、じっくり考えます。マイクロソフトや他の企業が取り組みんでいるものごとを理解して、より戦略的に前進するための方法を思案します。彼は、よく考えることと、計画を立てることの重要性を理解しています。
私たちは、日々、考えたり、構想を練ったり、問題を解決したり、作業に優先順位を付けたり、目標を設定したり、空想にふけったりする時間を確保することでメリットを得られます。この作業は、毎日同じ時間と場所で行い、その間は他のものとの接触を避けるようにします。この際、最も重要な作業は、その日に行う作業の計画を立てて、優先順位を付けることです。管理する立場にある場合は、他の人の作業の計画を立てたり、作業の優先順位を付けることに、1 日の大半を費やしていることでしょう。
社内ネットワークの管理、ミッションクリティカルなデータベースの管理、エンタープライズ インフォメーション システムのデザインや管理などでは、その作業内容に関係なく、重要な作業の進捗を止めてしまう問題が日常的に発生します。そのため 1 日の作業が終わったときに、作業が予定より進んでいるのか、それとも遅れているのかを把握することができません。
IT プロフェッショナルに必要なことは、予防策を講じ、手際の良い用意周到な状態を維持して、IT にかかわる緊急事態に対応できるようになることです。計画を立てることによって、受身ではなく主体的に行動できるようになります。そして、このような変化をもたらすには、じっくり考えたり、計画を立てたり、優先順位を付けたりする作業が必要となります。このような作業を行うことで、"進行中"、"至急"、"作業予定" という 3 つのカテゴリに分類された作業リストを管理して、毎日、このリストを確認してから作業に取り掛かることができるようになります。このリストを使用すると、危機的な状況が発生するのを回避するソリューションの作成時間を確保できます。
進行中リストにある作業には、すぐに取り掛かることが重要です。このリストにある重要な作業は、日々、進めることが必要不可欠です。企業とグループにとって重要な目標を最初に実現します。このような目標に直接影響しない作業は、リスト内の優先順位を下げます。管理する立場にある場合は、すべての従業員が優先度の高い項目に対して歩調を揃えるのに役立つプロセスを導入します。
通常、至急リストと作業予定リストは、会社の時間とお金を節約し、競争力を高めるのに役立つ戦略的な計画を立てるためのものです。このような作業を特定したら、時間をかけながら入念に追求し、その優先度が高まった時点で、進行中リストに移動します。
このような優先順位を付けたリストを作成しても、何かを達成したことにはならないという点を忘れないでください。次に、リストにある作業を遂行する際のヒントをご紹介します。
  • まず、簡単かつ迅速に片付けられる作業に着手します。
  • 次に、あまり好きではない作業に着手します。
  • 最後に、楽しくてやりがいのある作業に着手します。
  • 関連性の低い作業間での切り替えは避けます。可能な限り、関連性のある作業をまとめて行うようにします。
  • ただし、ある作業で行き詰った場合は、その作業を遂行できるようになるまで、次の作業を進めます。
  • 自分が担当する意味がないと思う作業は他の人にお願いするか、作業を断ります。または、代案を出します。
  • 自分にとって一番効率の良い時間帯を見極めます。この時間帯は、重要な作業をする時間として確保します。
自分の時間を有効に計画する方法を理解することは、仕事で最高の結果を出すのに役立ちます。計画を立てずに人生を漠然と過ごしている人は、その行き着く先に、心の底から満足することはありません。というのも、そのような人は、そもそも自分がどのようなところを目指しているのかを把握していないからです。

Eric N. Bush は、Microsoft Engineering Excellence グループのソフトウェア開発担当者です。社内コンサルタントおよびインストラクタとして、ヒューマン スキル、プロセス、およびテクノロジの分野における技術力と組織力の強化を推進しています。連絡先は ericbush@microsoft.com (英語のみ) です。


 Windows 秘話: 二度としないように言ってください
Windows 秘話
二度としないように言ってください
Raymond Chen

かつて、 オペレーティング システムの Windows® 95 シリーズ向けに開発された "自動スキップ ドライバ" というツールがありました。皆さんはまずそのツールのぎこちない名前に反応し、さらに ASD という文字が異なるものを意味するようになったのではないかという疑いすら持ったかもしれません。そして皆さんは間違っていませんでした。
Windows 95 は、プラグ アンド プレイに対応していない多くのデバイスに対処する必要がありました。これは、当時のシステムの圧倒的多数が、プラグ アンド プレイの仕様が発表される前から存在していたためです。適切なプラグ アンド プレイ デバイスが登場するまで、ハードウェアの検出は非常に恐ろしい作業でした。
たとえば、モデムを検出する場合は、何十個ものモデム レジスタの値を照会するクエリを発行していました。非常に定評のある基本的なモデム コマンド セットも提供されていましたが、コマンド言語の細部の実装には大きなばらつきがありました。通信を行うプログラムにとって、当然このばらつきはもどかしい問題でした。理由は、モデムのさまざまなモデル用に特殊なコードを追加して、個々の実装に適合させる必要があったためです。しかし、偶然にもこのばらつきが Windows にメリットをもたらしました。各モデムの動作が微妙に異なったため、Windows はそれらの細部を調査し、各モデムの動作を既知のモデムとそれらの応答が記録されたテーブルと比較することができました。
Windows 95 チームに所属していたあるメンバの仕事は、人類が知っているすべてのモデムと言ってもいいくらいのさまざまなモデムのインストール、モデムの性能を試す小規模なプログラムの実行、細部の調査、およびそれぞれの調査結果の収集を行い、あらゆるモデムのデータが格納されたモデム データベースを構築できるようにすることでした。まだ Windows 95 が実行されているコンピュータにアクセスできる場合、Windows\Inf ディレクトリを覗いて、名前が MDM で始まるこれらのファイルを確認することができます。モデムに関するデバイス情報ファイルのサイズは、1 MB を超えていました。1 人の人生における数年が 1 MB の判読不可能な 16 進数に費やされたと言ってもいいでしょう。
すべてのモデムの動作は大まかな部分ではほぼ同じであったため、モデムの検出作業は非常に安全でした。つまり、すべての楽しみは細部にありました。より恐ろしいのは、I/O ポートを使用するデバイスでした。たとえば、Windows 95 コンフィグレーション マネージャのビデオ カード検出モジュールは、特定のビデオ カードがインストールされているかどうかを検出するために、注意深く選択された値を特定の I/O ポートから送信し、そのデバイスからの応答を待機していました。デバイスが正しく応答した場合は、目的のデバイスが検出されたと判断します。正しく応答しなかった場合は、次のビデオ カード モデルに移ります。
もちろん、その I/O ポートにインストールされているデバイスがコンフィグレーション マネージャによってテストされているビデオ カードではなかった場合、無意味な値が送信されたことにデバイスが腹を立てることがありました。この場合、デバイスの気の短さにもよりますが、デバイスのハングやコンピュータの再起動が発生しました。これはコンフィグレーション マネージャにとって幸先の良い話ではありませんでした。このため、ASD として知られるモジュールが開発されました。
このように大惨事を引き起こす可能性があるハードウェアのテストを行う前に、コンフィグレーション マネージャは、簡単に言えば "何てことだ、私は危険な操作 X を実行しようとしている" ファイルを作成しました。これは、昔のアクション映画の主役が悪者との死を覚悟した戦いに出る前に恋人に残していった、"私が死んでしまったら開けてほしい" 封筒のコンピュータ版です。
実際、危険な操作 X を実行した場合、クラッシュやハング、または再起動が発生した後、システムの起動時にこの魔法のファイルが検出され、"封筒が開かれます"。そして、コンピュータのクラッシュを引き起こしたのが危険な操作 X であることが通知されます。システムはデバイス X の検出を試行する操作が大惨事を引き起こすという結論を下し、二度とその操作を実行してはいけないと認識します。
この動作を行うモジュールの名前は ASD でした。"何か危険な操作を試みる (Attempting Something Dangerous)" の略です。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍 (Addison-Wesley、2007 年) で、Windows の歴史と Win32 プログラミングについて扱っています。彼は、やけどすることのないよう慎重にこの分野に取り組んでいます。