 TechNet Magazine July 2007

TechNet Magazine July 2007

通信: Exchange Server 2007 のデータ保護と障害回復

Exchange Server 2007 には、高可用性と障害回復をサポートするための多数のオプションが含まれています。Exchange によって提供されるこれらのオプションについて学習することにより、組織にとって理想的な障害回復ソリューションを計画できます。

Lee Benjamin 通信: Windows Mobile 6 を使用してセキュリティを強化する

Smartphone や PDA では、社外からネットワークにアクセスできますが、ネットワークを新たな脆弱性にさらしてしまう可能性もあります。ここでは、Windows Mobile 6 と Exchange Server で会社のモバイル デバイスとインフラストラクチャを保護する方法を紹介します。

Matt Fontaine 通信: パブリック フォルダの強力な代替手段

MOSS 2007 は、Exchange Server のパブリック フォルダよりも、はるかに強力なデータ共有ソリューションを提供し、機能の拡張と、より簡単な管理を実現します。この記事では、SharePoint Server を使用して、予定表、連絡先、およびドキュメントを共有する方法を紹介します。

Alan Maddison 通信: スマート カードを使用した Outlook Web Access へのログオン

セキュリティ チェーンにおいて最も攻撃を受けやすいリンクの 1 つは、脆弱で改ざんされやすいパスワードに関係しています。スマート カードの 2 要素認証を実装することで、モバイル ユーザーの電子メール セキュリティをどのように向上できるかについて説明します。

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Windows の管理: Windows Vista の ActiveX インストーラ サービス

アプリケーションの互換性を制限することなく、悪意のある ActiveX コントロールからデスクトップのセキュリティを保護するにはどうすればよいでしょう。この記事では、ActiveX コントロールの管理方法を刷新してこの問題に対処する、Windows Vista の ActiveX インストーラ サービス (AxIS) について説明します。

Rob Campbell and Joel Yoker 編集者から: 第 6 レベル

Joshua Trupin ツールボックス: IT プロのための新製品

Greg Steen SQL に関する Q&A: クラスタリングの詳細、不可解なハング、SA アカウントなど

Edited by Nancy Michell ユーティリティ スポットライト: SMSMap

Jeff Tondt 動作メカニズム: RPC エラーのトラブルシューティング

Zubair Alexander The Cable Guy: VPN 接続を経由した IPv6 トラフィック

Joseph Davies Windows PowerShell: パイプラインについての再考

Don Jones Hey, Scripting Guy!: 人生と同じで、スクリプトでも見た目は重要

The Microsoft Scripting Guys Exchange Queue & A: エッジ トランスポート サーバーの役割とハブ トランスポート サーバーの役割、仮想コンピュータなど

KC Lemson and Nino Bilic セキュリティ ウォッチ: ACL 管理用ツール

Jesper M. Johansson デスクトップ ファイル: Microsoft Desktop Optimization Pack

Wes Miller Windows 秘話: セーフ モードの治癒力

Raymond Chen


 通信: Exchange Server 2007 のデータ保護と障害回復
通信 Lee Benjamin

Exchange Server 2007 のデータ保護と障害回復
概要:
  • 基本的なバックアップと復元
  • データの継続性
  • レプリケーション テクノロジ
  • 代替ソリューション

Microsoft Exchange Server は、バックアップを考慮して設計されました。組織はメッセージング データをバックアップするだけでなく、それらの情報を復元できる必要があります。このようなニーズに応えるために、マイクロソフトはあらゆるデータ保護オプションを構築しました。
これには、従来の低コストのバックアップと復元に関するソリューション、運用の継続性を提供するソリューション、および最高レベルの可用性と障害回復を提供する、真のビジネスの継続性を実現するためのソリューションがあります。この記事では、これらのソリューションについて説明します。これらのソリューションについて学習することにより、どのようにして、組織に最も適した Exchange の回復ソリューションを実装すればよいかを判断できるようになります。

レベル 1 : 基本的なバックアップと復元
Exchange ファイルのバックアップは、Exchange データベースをオフラインにした後に実行できますが、Exchange の実行中でもバックアップを実行することができます。実際に、多くの場合、後者のほうが Exchange のバックアップ方法としては推奨されます。しかし、Exchange はただのファイルの集合ではありません。Exchange は、大きなデータベース ファイルやトランザクション ログが格納されるインフォメーション ストアです。Exchange に送信されたメッセージは、すぐにトランザクション ログに記録され、システムに空きサイクルができたとき (通常は数ミリ秒後) にデータベースにコピーされます。Exchange は、情報を可能な限りすばやくディスクに書き込むことにより、非常に高いレベルの回復性を提供します。Exchange の復元にとって重要なことは、データベース ファイルとトランザクション ログの両方が使用できる状態になっていることです。システムがダウンした場合、Exchange の情報を最新の状態に復元するには、以前のバックアップと、そのバックアップを作成した後に発生したすべてのトランザクションが必要です。Exchange は、必要に応じて、復元されたデータベースにトランザクションを自動的に再生します。
バックアップ プログラムから Exchange データベース内の情報にアクセスするには、Extensible Storage Engine (ESE) バックアップ API を使用するか、後で説明する新しい VSS を使用します。Exchange は、ESE バックアップが開始された時点で、Exchange データベースへのすべての書き込みを一時的に中断します。ESE は、Exchange データベースを一時的に読み取り専用モードに設定して、完全バックアップにコピーできるようにするだけでなく、一時データベースを使用して、バックアップ中に発生した新しいトランザクションを保持します。バックアップが完了したら、ESE は Exchange データベースを通常の読み取り/書き込みモードに戻し、一時データベースに蓄積されたトランザクションを適用します。バックアップ処理が成功した場合、古いトランザクション ログの削除も実行されます。
このバックアップ処理は単純で、真夜中にバックアップが実行されているときにログオンしたユーザーでさえ、この処理を意識することはありませんが、ESE を使用した処理は非常に長い時間がかかる場合があります。この主な原因は、Exchange データベースのサイズが、数 GB から、管理可能な 30 ～ 50 GB、さらには 100 GB にまで増加する場合があることです。この大きさまで増加すると、標準のテクノロジでは、一晩中かけてもバックアップを完了することはほぼ不可能です。NTBackup.exe を使用して実行できる操作を大まかに把握するには、図 1 を参照してください。
図 1 NTBackup ユーティリティの使用
図 1 NTBackup ユーティリティの使用

Exchange のベスト プラクティス
一般的なハードウェア障害とシステム障害からの回復をすばやく行うには、毎晩 Exchange の完全バックアップを実行する必要があります。Exchange サーバーがローカル ディスクを使用するときのパフォーマンスと回復性を強化するには、別々の RAID アレイに Exchange データベースと Exchange トランザクション ログを格納することが重要です。これにより、RAID アレイ コントローラで障害が発生した場合や、RAID アレイ内の複数のディスクで障害が発生して、残りのディスクではストライプ化されたデータを再構築できなくなった場合でも、Exchange を回復できるようになります。トランザクション ログが消失した場合でも、他のドライブに最新の Exchange データベースが格納されているため、新しいトランザクション ログを使用して通常の運用を継続できます。データベース ドライブが使用できなくなった場合、Exchange を回復するには、前日の夜に作成した Exchange データベースの完全バックアップを復元した後、それ以降に記録されたトランザクション ログを適用して最新の状態に戻します。
各 Exchange データベースのサイズを制限して、適度な時間でバックアップ (もっと重要なのは復元) できるようにしておく必要があります。ほとんどの組織では、データベースのサイズを 30 ～ 50 GB に保持しておけば問題ありません。データベースがこれ以上のサイズになったら、復元しやすいように複数のデータベースに分割することをお勧めします。

バックアップと復元の連続性
データベースとトランザクション ログの配置は、バックアップのパフォーマンスだけでなく、回復速度のためにも非常に重要です。今日では、すべてのサーバーが、さまざまなレベルのディスク ドライブの冗長性 (RAID と呼ばれます) をサポートしています。基本的に、RAID を使用するとディスク ドライブに障害が発生してもシステムはクラッシュしませんが、ディスクが置換および再構築されるまで、システムのパフォーマンスは低下します。この間、アレイ コントローラは残りのディスクからデータをすぐに再構築して、各ディスクへのアクセス要求に応答する必要があります。メールボックス サーバーのストレージの設計の詳細については、マイクロソフト IT ショウケースの「64 ビット プラットフォームで Exchange Server 2007 を使用する」を参照してください。
Exchange の基本的な特徴は、単一インスタンスのデータベース設計です。つまり、Exchange データベース内には、特定のメッセージのコピーが 1 つしか格納されず、添付ファイル (存在する場合) も 1 つしか格納されないということです。メッセージが同一のインフォメーション ストア上の複数の受信者に送信された場合、オブジェクト (メッセージ、添付ファイル) への追加のポインタが作成されますが、オブジェクト自体は複製されません。これにより、配信効率が向上するだけでなく、Exchange によって使用されるディスクおよびテープの領域を削減できます。
Exchange はデータベース全体を復元することはできますが、個々のメールボックス、フォルダ、またはメッセージを復元するには、まずテープ全体を復元する必要があります。当然、ユーザーはよりきめ細かな制御機能が提供されることを望みました。テープに 1 つのインスタンスしか格納されていない場合、この作業は非常に困難です。バックアップ ベンダは、"ブリック レベルのバックアップ" (個人的にはお勧めしません) を使用することでこのニーズに応えました。バックアップ製品は、認可された ESE バックアップ API を使用して Exchange データベースの完全バックアップを作成した後、各メールボックスをバックアップ テープに追加します。バックアップ API を使用しても個々のメールボックスからはデータを取得できないため、MAPI が使用されます。この結果、すべてのメッセージと添付ファイルを複製することになるため、バックアップ テープのサイズは非常に大きくなります。
マイクロソフトは、この問題を部分的に解決する拡張機能を開発しました。たとえば、ユーザーによって削除されたアイテムを管理用のごみ箱 (または Dumpster) 内にしばらくの間保持しておいて、必要になったときに使用できるようにします。また、予備のサーバーを Exchange 回復用フォレストとして用意する必要がなくなります。回復用ストレージ グループを使用すると、管理者はテープから復元したデータベースを部分的にマウントし、メールボックス レベルまでのデータをコピーまたはマージすることができます。

習うより慣れよ
多くの組織は、実行するバックアップと復元のレベルにかかわらず、バックアップ メディアと復元手順を定期的にテストする必要があることを、身をもって知っています。多くの管理者は、障害が発生して初めて、用意したバックアップ テクノロジと復元手順が実際に機能するかどうかを把握します。テストの最適なタイミングは、新しいサーバーを構築および構成した次の日です。つまり、Exchange 組織の一部として稼動しているが、まだわずかなユーザーしか管理していないうちにテストするということです。このタイミングで、Exchange の完全バックアップ、ドライブの通常バックアップ、およびシステム状態のキャプチャを実行する必要があります。キャプチャされたシステム状態には、システム ディスク上の重要なファイル、および IIS メタベース (Exchange のルーティング構成が保持されています) が含まれています。その後、単純に新しいサーバーを再フォーマットしてもう一度構成し、最初にサーバーを構築したときに書き留めたメモの内容を更新します。システム状態から設定を復元できるようにしておくことも大事ですが、手動でシステムの構成設定を再実装する際に参照できるドキュメントも作成しておく必要があります。
障害に備えたこのような準備作業を行うことにより、実際に障害が発生したときに回復にかかる時間が大幅に短縮されます。この準備作業は定期的に行ってください。また、作業中に、オフサイトからテープの内容を復元するのにかかる時間を計測してください。多くの場合、無限にも感じられるこの復元時間を経験した管理者は、オフサイトのテープ ストレージを引き続き最終手段として使用する一方で、ディスクからディスクへのバックアップを、バックアップおよび復元戦略の中心にすることはできないかと真剣に考え始めます。

テープ バックアップの問題
テープからの復元は、非常に時間がかかります。Exchange は組織に欠かせない存在になったため、ユーザーと管理者は Exchange を常に使用できることが当たり前だと思っています。このため、深刻な問題が発生した場合、ほとんどの組織は不意をつかれた状態になります。75 GB のデータベースをテープから復元するので 8 時間待ってほしいと言われたら、だれでも驚きます。しかも、これにはオフサイトのストレージ設備からテープを搬送したり、オペレーティング システムを再インストールしたりする時間は含まれていません。
さらに、テープからデータベースの内容を正確に取得できるかどうかという問題もあります。Exchange が初めてリリースされてから 10 年の間に、ディスク ストレージ ネットワークと広域ネットワークにかかるコストは大幅に低下しました。このため多くの組織は、その分のコストを、より高速なバックアップ方法と復元方法に投資することができます。そのような組織では、Exchange インフラストラクチャの運用の継続性と障害回復を提供するテクノロジを活用することもできます。

レベル 2 : 運用の継続性
運用の継続性に関するソリューションとは、できるだけ短い時間で回復を完了し、予期しないダウンタイムを最小限に抑えるための一連の処理とテクノロジです。運用の継続性に関するソリューションを使用すると、ローカル レベルの回復に関しては、テープに比べて目標回復時間 (RTO) と目標回復ポイント (RPO) が改善されます。このソリューションは、オンサイトへのテープの搬送が必要な事態を可能な限り回避することを目的としています。図 2 は、運用の継続性に関するソリューションを、バックアップと復元に関するソリューション、および障害回復 (DR) に関するソリューションと比較しています。
図 2 回復に関するグラフ
図 2 回復に関するグラフ
この図は、回復と可用性に関するグラフを示しています。左下のほうが低速でコストがかからず、右上のほうが高速でコストがかかります。運用の継続性に関するソリューションと障害回復に関するソリューションの間には、意図的にあいまいな境界を設定しました。
このグラフを使用して、各ソリューションのコスト、回復までの時間、および可用性のトレードオフを大まかに把握することができます。この記事では、意図的に、ローカルの継続性に関する処理と、障害回復を明確に区別しています。DR は常にリモート ソリューションとして考えられ、オフサイトにデータを格納することを主な目的としています。DR では、距離という問題が加わるため、通常はさらにコストがかかりますが、致命的な障害が発生した後でも業務を続行することができます。これについては、後で詳しく説明します。

これまでに開発された方法
インフラストラクチャにおける Exchange の重要性が増し、Exchange データベースに格納されるデータが増加するにしたがって、バックアップと復元にかかる時間を短縮する必要性が明確になりました。いくつかの大規模な組織は、マイクロソフトと協力して、機能の部分的な復元を強化する方法を開発しました。この方法を使用すると、見かけ上は障害が発生していないかのように、組織は新しい電子メールを外部に送信できます。つまり、課題となったのは見かけです。
この Exchange の "ダイヤル トーン" 復元を実装するには、まず新しい空のデータベースを、破損したデータベースの代わりに用意します。次に、Exchange と Active Directory® が適切な権限を使用して新しいメールボックスを作成することにより、ユーザーが電子メールを送受信できるようになります。バックアップ テープが手元に到着し、データの回復が完了したら、そのデータを管理用にマウントします。その後、Exchange 管理者は復元されたメールボックスをダイヤル トーン メールボックスにマージします。メールボックスには、必要に応じて優先順位を付けることができます。機能は強化されましたが、この処理は複雑であり、時間がかかりました。この処理が開発された当初は EXMERGE が使用されていましたが、その後、回復用ストレージ グループに適合するように変更が加えられました。ダイヤル トーン回復のシナリオの後にデータの完全な復元を実行する場合、厄介で複雑な作業 (ストレージ グループが 50 個までサポートされる Exchange 2007 ではさらにたいへんになります) が必要になります。ダイヤル トーン回復のシナリオの実装を検討する際は、作業量に見合ったメリットが得られるかどうかを考慮するようにしてください。

ボリューム シャドウ コピー サービス
より安価なディスクを活用し、運用環境の Exchange サーバーで発生するプロセッサのオーバーヘッドを軽減するために、Microsoft® Windows Server® 2003 と Exchange 用の新しいバックアップ API が開発されました。ボリューム シャドウ コピー サービス (VSS) は、ある時点の一貫性のあるデータのコピーを作成することを目的として開発されました。これらのスナップショットは、変更されたデータのみが順次格納された、Exchange データの読み取り専用の簡易コピーです。通常、これらのコピーは、十分なディスクの空き領域を持つ別のサーバー上か、ストレージ エリア ネットワーク (SAN) 上に作成されます。複数のスナップショットを作成し、テープにバックアップすることもできます。これにより、バックアップ ソフトウェアやテープへのコピーのオーバーヘッドが原因で、運用環境の Exchange サーバーのパフォーマンスが低下することもなくなります。
Exchange のデータ保護に VSS を使用すると、いくつかのメリットがあります。まず、テープへのバックアップ操作によって Exchange サーバーにかかっていたパフォーマンスの負荷がなくなります。テープへのバックアップも依然として必要ですが、Exchange データのコピーを使用できるため、ユーザーのパフォーマンスには影響を与えません。また、一晩に 1 回を超える頻度でスナップショットを作成できるようになります。さらに、複数のスナップショットを作成し、セカンダリ サーバーやその他のローカル ストレージ上に格納できます。
VSS のスナップショット機能を使用するサードパーティ製品は、非常に多く市販されています。単に Exchange データベースのバックアップと復元に必要な時間を短縮する製品もあれば、ネイティブの Exchange よりもきめ細かな回復機能 (メールボックス レベルまで回復可能) を新たに提供する製品もあります。このような製品で使用されているブリック レベルのバックアップを好むユーザーはいませんが、特定のフォルダ、さらには特定のメッセージを復元する機能が必要とされていることは確かです。

レプリケーション テクノロジ
レプリケーション ベンダが提供する製品には、ソフトウェアを介した Exchange のフェールオーバーを実行するものもあります。これらの製品は、スタンバイ Exchange サーバーを稼動させてから、すべてのユーザーのメールボックスが移動されたことを Active Directory に通知します。この動作を実現する方法は 2 つあり、どちらの方法でも Exchange 環境と Windows 環境をカスタマイズする必要があります。1 つ目は、DNS に若干変更を加え、障害が発生したサーバーの名前と IP アドレスをスタンバイ サーバーが引き継ぐようにする方法です。この方法を使用すると、クライアント ワークステーションでの作業が容易になるというメリットがあります。これは、障害の発生後も、使用中のサーバーとして Outlook® が認識するコンピュータが変わらないためです。
2 つ目は、データベースのコピーを保持しているが、どのコピーもマウントされていないスタンバイ Exchange サーバーを使用する方法です。障害が発生したら、スタンバイ サーバーは、すべてのユーザーのメールボックスがそのスタンバイ サーバーに移動されたことを Active Directory に通知します。その後、スクリプトを実行するか、グループ ポリシーを配布することによって、異なるメール サーバーにメールボックスが移動されたことをクライアントに通知します。Outlook 2007 は Active Directory に対応しており、これらのマッピングを自動的に検出するため、処理が容易になります。

MSCS を使用したローカル クラスタ
Microsoft Cluster Services (MSCS) は、可用性グラフの上位に位置するソリューションです。Exchange はクラスタに対応したアプリケーションです。クラスタでは、複数のコンピュータ間で情報を共有し、1 つのコンピュータで障害が発生しても、他のコンピュータが処理を引き継ぎます。今日使用されている Exchange クラスタのほとんどは 2 ノードまたは 4 ノードですが、実際に使用できるクラスタは最大 8 ノードです。1 つのノードは常にパッシブ ノードとして指定されます。このノードは、Windows Server が実行され、Exchange Server がインストールされた状態で稼動していますが、アクティブなメールボックスは存在しません。Exchange 2003 では、2 ノードのアクティブ/アクティブ クラスタがサポートされていましたが、パフォーマンスが低下するため、Exchange 2007 ではサポートされません。
Exchange 2003 クラスタの配置と同様、パッシブ ノードが含まれた Exchange 2007 クラスタは、引き続き単一の共有ストレージ アレイを使用できます。通常、クラスタ用の品質を備えたストレージ アレイでは、さまざまな障害に対処できる多数の冗長性機能が提供されますが、データのコピーは 1 つしか提供されないため、脆弱性は残ります。このため、これらのクラスタはシングル コピー クラスタ (SCC) と呼ばれ、新たなデータ保護ソリューションを提供する Exchange 2007 のマルチ コピー クラスタ (MCC) と区別されます。MCC については、後ほど障害回復と共に詳しく説明します。

ローカル連続レプリケーション
Exchange 2007 の新機能であるローカル連続レプリケーション (LCR) を使用すると、同一のサーバー内で Exchange データベースとトランザクション ログの 2 番目のコピーを管理する方法が強化されます。この機能により、1 つの RAID アレイに Exchange データベースを格納し、もう 1 つの RAID アレイにトランザクション ログを格納するというベスト プラクティスに冗長性が追加されます。LCR を使用すると、データベースのプライマリ コピーが格納された RAID アレイにログのセカンダリ コピーを格納してから、ログのプライマリ コピーが格納された RAID アレイにデータベースのセカンダリ コピーを格納できます (図 3 を参照)。RAID コントローラまたは RAID アレイで障害が発生しても、もう 1 つの RAID アレイに格納されているデータベースとトランザクション ログを使用できます。このため、障害が発生した RAID アレイを再構築するまでの間、若干不安は残り、パフォーマンスも低下しますが、運用は継続できます。
図 3 LCR の構成
図 3 LCR の構成
LCR はローカルの運用の継続性に関するソリューションであり、バックアップ ソリューションではないため、完全バックアップに関する戦略も必要です。また、LCR を使用すると、サーバー上にデータベースとトランザクション ログのコピーを 2 つずつ作成することになるため、パフォーマンスが低下します。さらに、LCR では、Exchange 2007 の実装の制限により、ストレージ グループあたり 1 つのデータベース、および組織あたり 1 つのパブリック フォルダしかサポートされないため、中規模以上の組織には適していません。
LCR による回復を使用したフェールオーバーは瞬時に完了するわけではなく、経験豊富な IT プロフェッショナルがスクリプトを実行して、Exchange を回復させる必要があります。これを行うには、Exchange 管理シェル コマンドを Exchange 管理コンソールの外部で実行する必要があります。
Exchange Server 2003 Enterprise Edition で実行できる Exchange データベースは最大 20 個 (4 個のストレージ グループでそれぞれ最大 5 個のデータベースを保持できます) ですが、Exchange 2007 Enterprise Edition では、最大 50 個のストレージ グループがサポートされ、グループごとに独自のデータベースを保持できます。また、トランザクション ログ ファイルのサイズは、Exchange 2003 では 5 MB でしたが、Exchange 2007 では 1 MB に減少しました。これらの変更は、LCR のサポートと、この後説明するクラスタ連続レプリケーション (CCR) のサポートを目的としています。
小規模および中規模の組織は、LCR を使用して、運用している Exchange のデータ保護を強化できます。LCR の実装は簡単ですが、手動による作業も必要です。LCR は、同一サーバーのローカル ディスクに対するソリューションであるため、運用の継続性という点では最初の一歩にすぎません。LCR を使用すると、RAID アレイと RAID コントローラの障害に対する保護を提供できますが、複数のディスクが同時にクラッシュしたり、RAID コントローラで障害が発生したりすることは比較的まれです。多くの場合、障害が発生するとサーバー全体が機能しなくなるため、もう一段階上のレベルの保護を Exchange で提供する必要があります。

サードパーティのローカル オフホスト レプリケーション
サードパーティ ベンダは、Exchange の回復機能を強化するために、Exchange のログ ファイルを使用する "オフホスト" レプリケーションによって、別のコンピュータに Exchange データベースのスタンバイ コピーを格納する製品を開発しました。これらのデータ保護またはアーカイブ ソリューションは、Exchange の ESE 完全バックアップを実行して別のコンピュータにバックアップ ファイルを格納し、Exchange がトランザクション ログを閉じた直後に、それらのトランザクション ログをプルします。これらのトランザクションは Exchange データベースのコピーに挿入されるため、常に最新の状態が維持されます。既に説明したように、これらのトランザクション ログは比較的小さい (Exchange 2003 では 5 MB、Exchange 2007 では 1 MB) ため、完全バックアップが完了した後、これらのログ ファイルを Exchange サーバーからオフホスト サーバーにコピーするときには、オーバーヘッドはほとんど発生しません。

レベル 3 : 障害回復と高可用性
障害回復とは、主要なデータ センターが使用できなくなった場合に、再び使用できる状態に戻して実行する機能を指します。今日では電子メール機能と予定表機能は多くの組織の生命線となっているため、障害が発生した場合に、Exchange を効率的に回復させることが重要です。
オフサイトに格納された従来のテープ バックアップも障害回復ソリューションの 1 つと考えることができますが、火事や洪水によってデータ センター全体が破壊されてしまった場合、大量のテープ バックアップの価値はほとんどなくなります。障害回復を実現するには、データを別の場所に移動するだけでなく、アプリケーションを再び使用できる状態に戻して実行するためのテクノロジや処理も準備する必要があります。障害回復の効果を上げるには、プライマリ システムとセカンダリ システムを、ある程度離れた別々の場所に配置する必要があります。これらの場所間の距離は、懸念している障害の規模によって異なります。火事を懸念している場合は、構内の別の建物であれば、十分に離れていると言えます。しかし、電車や飛行機に関連する基幹施設で障害が発生した場合、影響は数 km を超える範囲に及ぶ可能性があります。多くの障害は、広範囲で発生します。たとえば、洪水、大雪、地震、停電などがあります。また、通信に固有の障害が発生する可能性もあります。バックホー (切削機) による電線の切断によって ISP に接続できなくなる、サービス拒否攻撃を受ける、インターネット DoS 攻撃 (通常は商用ネットワークを対象としています) を受けるなど、さまざまな障害が考えられます。
実際的に考えると、組織が既に複数の場所に IT スタッフを配置している場合、考慮している障害の種類にもよりますが、いずれかの場所は、リモート運用の継続性に関する基準を満たしている可能性があります。自社の施設とスタッフを使用した方が、障害回復業者と契約したり、新しい場所を賃借するよりも、はるかにコストを節約できます。
突き詰めれば、障害回復は人々の認識にも関連してきます。つまり、事業活動が継続していることを顧客に信用してもらうことが大事です。顧客は特定の都市や地域で災害が発生したことは理解していますが、数日か 1 週間以内に再びオンラインに復帰しなければ、顧客と仕入れ先は最悪の事態を考える可能性があります。これが原因で衰退した企業は数多く存在します。顧客に対しては、運用環境が回復に向かっていることを示し、営業が継続されていることを信用してもらう必要があります。適切な回復時期に対する考え方は、顧客によって異なります。当然のことながら、顧客はオフィス家具の購入先よりも、金融サービス企業の営業が早く再開されることの方を望んでいます。

障害回復に関する要求
障害発生後に Exchange を再びオンラインにできるようにするには、セカンダリ サイトに Exchange データをレプリケートすること、稼動に必要な Exchange データをウォーム Exchange サーバーに提供できるレプリケーション テクノロジを使用すること、およびメールボックスが移動したことを Outlook クライアントに通知することが必要です。
Exchange は、レプリケーション (特に長距離のレプリケーション) が難しいアプリケーションです。トランザクション データベースの信頼性を維持するには、書き込みの順序がきわめて重要です。さらに問題は複雑になりますが、Exchange は、サーバー間ですべてのトランザクションとシステム情報をやりとりする際に、トランスポート プロトコルとして SMTP を使用します。SMTP は帯域幅を集中的に使用するプロトコルとして知られています。また、Exchange クラスタを使用する場合、500 ミリ秒ごとにシステム間でハートビートを送信し合う必要があります。セカンダリ ノードがハートビートを受信しなかった場合、フェールオーバーが開始されることがあります。
このような問題への対処方法の複雑さが、マイクロソフトが Exchange 2007 でこの分野に足を踏み入れた理由かもしれません。これまでは、サードパーティによって、ホスト ベースまたはアレイ ベースのレプリケーションを使用して Exchange データをレプリケートするソリューションが開発されてきました。
ベンダは、ノードをさまざまな場所に分散させることによってクラスタを拡張できることを認識しました。このようなクラスタをストレッチ クラスタといいます。今日、ストレッチ クラスタの最も一般的な実装方法は、サードパーティ製の汎用レプリケーション製品や、Exchange ノードの伸張に特化した製品を使用した方法です。MSCS を使用してもストレッチ クラスタを実装できますが、WAN を経由したサブネットの要件を満たすことが大きな課題となります。また、クラスタを構築したり、複雑な作業を行って、リモート データ センターへ信頼性の高い高帯域幅接続を提供したりする必要があるため、障害回復システムの構築、保守、および定期的なテストを行うために必要なコストとスタッフの数は当然増加します。

クラスタ連続レプリケーション
マイクロソフトは、Exchange 2007 のクラスタ連続レプリケーションによって、クラスタのサポートを強化しています。CCR で実装される機能の考え方は LCR と同じですが、Exchange データベースとトランザクション ログの 2 つのコピーを 2 つのクラスタ ノードで保持することによって、LCR よりも効果を高めています。障害回復に関するソリューションには、プライマリ システムとセカンダリ システムの地理的な分散も含まれますが、マイクロソフトのマルチ コピー クラスタ (MCC) は、ストレッチ クラスタがサポートされる Windows Server 2008 (以前はコードネーム "Longhorn") がリリースされるまでは、長い距離にまたがって構成することはできません。
複数の MCC ノードにデータの別々のコピーを配置できるテクノロジは、マジョリティ ノード セット (MNS) と呼ばれます。MNS では、どのノードがデータの最新のコピーを保持するかを、複数のノードによる選択プロセスによって決定します。障害が発生した場合、残りのノードが新たにこの選択プロセスを実行して、新しいプライマリ処理/データ サーバーとして役割を引き継ぐノードを決定します。CCR では、この技術的な民主主義がサポートされるため、各ノードで最新のデータベースが保持されます。CCR を使用できる Exchange 2007 クラスタは 2 ノードのみに制限されます。
通常、大規模な企業の Exchange サーバーは、そのサーバー上にローカル システム ディスクを構成し、SCSI、ファイバ、または iSCSI ディスク アレイを使用する SAN 経由で Exchange データベースに接続します。MCC/MNS クラスタを使用する場合、おもしろい疑問が浮かびます。それは、ハイエンドの Exchange ストレージがノードごとにローカル RAID アレイを使用するという方法に回帰するのかどうかということです。MNS クラスタの目的がノードごとに別々のストレージを保有することだとしたら、主な目的が共通のストレージを提供することである SAN に各ノードを接続することに意味があるのでしょうか。
中立的な MCC/MNS クラスタのシナリオでは、プライマリ ノードのストレージが SAN 上に配置され、セカンダリ ノードがローカル ディスク上または低コストの iSCSI SAN 上に配置されます。SAN インフラストラクチャが実装されていない場所では、このセカンダリ ノードはプライマリ データ センターに対してリモートになります。
この疑問の答えにかかわらず、MNS と CCR を使用する MCC により、複数のコンピュータのフェールオーバーが可能になり、データが別々のストレージにレプリケートされるため、冗長性と可用性が強化されます。ただし、Windows Server 2008 がリリースされるまでは、単一のデータ センター内でしかこの機能を使用することはできません。Windows Server 2008 はネイティブでストレッチ クラスタをサポートしているため、MNS クラスタ内のノード間の距離は制限されません (ノード間のネットワーク待ち時間が 500 ミリ秒未満である場合)。それまでは (それ以降も)、ストレッチ クラスタに必要な地理的な分散によって、効果的な障害回復ソリューションを提供するという点では、サードパーティ製のクラスタ テクノロジがマイクロソフトの MNS と CCR を上回る可能性があります。
クラスタは、障害回復ソリューションとして非常に高い効果があります。また、CCR は、Exchange の高可用性を実現するための機能として位置付けることができます。これらを組み合わせて使用すると、より多くの経費やスタッフが必要になりますが、単一のマイクロソフト環境を運用する顧客にとっては、最上級のソリューションとなることが保証されます。

リモート運用の継続性に関するサードパーティ製のソリューション
マイクロソフト ソリューションとサードパーティの拡張機能を組み合わせて使用できるようになれば、最も高い回復性が実現されることは間違いありません。たとえば、数秒以内の自動フェールオーバーなどが実現されるでしょう。しかし、すべての企業がそこまで高いレベルの可用性とビジネスの継続性を必要としているわけではなく、それらの実現に必要な何千万円もの費用を投資する余裕もありません。多くの企業は、Exchange を数分以内に完全に復元できる信頼性の高いソリューションを使用すれば、十分な運用の継続性を提供できます。
たとえば、Mimosa Systems, Inc. は、単一のデータ センターの運用の継続性を拡張して、リモートの継続性を実現しました。Mimosa の DR では、リモート コンピュータに Exchange のコピーを格納し、プライマリ Exchange サーバーから提供されたトランザクション ログを使用して最新の状態に保ち、常にこの最新のコピーをスタンバイ Exchange サーバーで使用できるようにします。リモート Exchange サーバーでは、標準のサーバー ハードウェアを使用します。また、単一のデータ センターを実装する場合と同様に、ウォームアップされた状態に保ち、障害が発生したときに常にアクティブにできるようにしておきます。障害が発生した場合、リモート サイトのオペレータはフェールオーバーを開始し、スタンバイ データベース ファイルのマウントや、メールボックスと Outlook プロファイルの再マッピングなどを実行します。このようなサードパーティ製のソリューションは、サポート技術情報の記事「Exchange データベースの内容を変更または抽出するサードパーティ製品に関するマイクロソフトのサポート ポリシー」に記載されているサポート制限の対象になるため、注意が必要です。

まとめ
Exchange のデータ保護ソリューションは、コストと効果に基づいて 3 つのレベルに分けられたテクノロジと処理として提供されます。必要な Exchange のデータ保護レベルを決定する際は、関係者が許容できるダウンタイムの長さを考慮する必要があります。パフォーマンスを強化し、回復を高速化するには、その度合いに応じたコストがかかります。効果の高いソリューションは、何千万円という費用がかかります。最高レベルの可用性は実現できなくても、それに近い可用性を実現できる手ごろな価格のソリューションもあります。組織にとって本当に必要なレベルのソリューションを選択するようにしてください。
Exchange 2007 Service Pack 1
現在テスト段階の Exchange 2007 Service Pack 1 (SP1) には、OWA の機能拡張や、新しくコンソールに追加された GUI 機能など、管理者が求めていた機能が多数含まれる予定です。
特に回復ソリューションを計画する管理者にとっては興味深いと思いますが、Exchange 2007 SP1 には、LCR と CCR を補完するための 3 番目の可用性ソリューションが追加されます。このソリューションは、セカンダリ連続レプリケーション (SCR) といいます。これは中立的なソリューションであり、完全な "高可用性" を実現することで発生する複雑さをなくし、回復性を重点的に強化します。
SCR を使用すると、通常メールボックスが配置されている Exchange サーバーとは異なる Exchange サーバーに、Exchange データベースとトランザクション ログをレプリケートすることができます。SCR では、ローカルとリモートの両方、およびスタンバイ Exchange サーバーとクラスタの両方をレプリケート先として使用できます。ただし SCR では、どちらの場所にもクラスタを構成する必要はありません。SCR は、スタンバイ環境をレプリケート先とし、フェールオーバーを手動で行うという点で、CCR と異なります。また、SCR でも、最初に大きいコピー (基本的には完全バックアップ) をネットワーク経由でレプリケートする必要があることに注意してください。この大規模なレプリケーションはときどき必要になるため、CCR とサードパーティ製のソリューションを使用する場合と同様に、ネットワークへの影響を考慮する必要があります。SCR と CCR、および同等以上の機能を提供するアドオン製品を有効に利用できると思います。

Lee Benjaminは ExchangeGuy Consulting Services を経営しています。彼は顧客の声を直接聞き、Microsoft パートナーへのアドバイスを行っています。Lee は、世界最大規模の Exchange ユーザー グループである ExchangeServerBoston の会長であり、BostonUserGroups の取締役でもあります。また、Exchange の MVP にしてマイクロソフト認定トレーナーでもあり、業界のカンファレンスでの講演もよく行っています。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 通信: Windows Mobile 6 を使用してセキュリティを強化する
通信 Matt Fontaine

Windows Mobile 6 を使用してセキュリティを強化する
概要:
  • デバイス上のセキュリティ
  • Exchange Server のセキュリティ
  • ネットワーク セキュリティ

モバイル デバイスを使用すると世界各地にいる従業員の生産性が向上します。というのも、オフィスから離れた場所にいても、会社の情報にアクセスして接続を維持できるためです。
生産性が向上するのは事実です。モバイル デバイスの電源を入れて、仕事に取りかかるだけでよいのです。
その陰には、仮想オフィスの安全性と安定性を確保するという困難な作業に立ち向かっている IT プロフェッショナルがいます。IT プロフェッショナルの視点から見ると、どのモバイル デバイスでもネットワーク セキュリティの漏洩やデータ盗難といったマイナス面があります。モバイル デバイスの展開を構築する際によりセキュリティで保護されたものにすることは重要ですが、シームレスで直感的なユーザー エクスペリエンスを提供することともバランスを取る必要があります。
Microsoft® Windows Mobile® 6 とその前身である Messaging and Security Feature Pack (MSFP) が適用された Windows Mobile 5.0 には、企業インフラストラクチャをセキュリティで保護するための多くの機能が含まれていて、ユーザーは難しい操作や手間のかかる操作を最低限だけ行えば済みます。メッセージング プラットフォームとして Microsoft Exchange Server を使用すると、使用できるセキュリティ オプションがさらに多くなります。この記事では、会社のモバイル デバイスを保護するための基盤として、Windows Mobile、Exchange Server、およびネットワーク セキュリティのベスト プラクティスを使用する方法について説明します。

モバイル通信アーキテクチャ
モバイル展開を計画またはアップグレードするときには、考慮すべき 3 つの層があります。それらは、デバイス、メッセージ サーバー、およびネットワークです (図 1 参照)。デバイス レベルの主要な課題には、デバイスに対して承認されたアクセスのみを許可することと、デバイス上に許可されていないアプリケーションをインストールしないことが含まれます。Windows Mobile では、PIN 認証とパスワード保護、デバイスのタイムアウト ロック、デバイスのメモリが失われたか盗まれた場合にローカルまたはリモートのいずれかでメモリの "ワイプ" または消去を行う機能を使用して、デバイス自体に対する承認されていないアクセスを防ぐことができます。通信チャネルおよびリムーバブル記憶域のデータの暗号化がサポートされています。ウイルスやスパイウェアなどの許可されていないアプリケーションのインストールや、デバイスの重要な部分へのアクセスを防ぐことも重要です。管理の役割定義、アプリケーションのアクセス層、コード署名の設定、セキュリティ設定、およびセキュリティ証明書を組み合わせると、デバイスレベルの保護を実現するのに役立ちます。
図 1 モバイル通信の層
図 1 モバイル通信の層
次のセキュリティ層は、Service Pack 2 (SP2) を適用した Exchange Server 2003 や Exchange Server 2007 などのメッセージング サーバーです。この層には、メッセージ セキュリティ (デバイス間でメッセージを安全に転送するために使用されるテクノロジ) および Exchange ActiveSync® 経由で行うメッセージ サーバーとモバイル デバイス間のやり取りが含まれます。Windows Mobile デバイスの使用時に Exchange Server は必須ではありませんが、Exchange を使用すると、コスト、スケーラビリティ、パフォーマンス、管理においてメリットがあります。
デバイスレベルとメッセージング サーバーのセキュリティに対して優れた方法を使用することは重要ですが、ネットワーク層を保護することも重要です。ベスト プラクティスに従って企業ネットワークを構成し、強力なセキュリティ プロトコルを実装することで、1 つ以上のモバイル デバイスが侵害された場合でもネットワークが損害を受けないようにすることができます。

デバイス上のセキュリティ ポリシー
セキュリティ侵害からの保護で最も重要なのは、Windows Mobile 搭載デバイス自体です。Windows Mobile オペレーティング システムには、認証、メモリ カードの暗号化、仮想プライベート ネットワーク (VPN)、Wi-Fi の暗号化、および Secure Sockets Layer (SSL) の各サービスをサポートする、デバイスレベルのさまざまなセキュリティ サービスが用意されています。デバイスレベルのセキュリティには、デバイスおよびデバイス データへのアクセス権を持っているユーザーの管理、デバイス上で実行できるアプリケーションの制御、およびデバイス間でデータを転送する方法の確立が含まれます。通常、管理者は MSFP が適用された Windows Mobile 5.0 と、Windows Mobile 6 の両方のセキュリティ ポリシーを非常に柔軟に設定して適用できます。
ユーザー アクセスは PIN 認証またはパスワード認証を使用して管理されます。デバイスは非アクティブな状態が一定期間続いた後や電源がオフになった後に自動的にロックするように設定できます。ロックされたデバイスを再び使用するには、ユーザーはデバイスのロックを解除する必要があります (図 2 参照)。ユーザー アクセス制御は具体的には、セキュリティ ポリシーを使用して設定します。セキュリティ ポリシーは、管理者のセキュリティ上の役割によって変わります。
図 2 パスワード ポリシーの設定
図 2 パスワード ポリシーの設定
セキュリティ ポリシーではモバイル デバイスのセキュリティをグローバルなレベルで定義します (図 3 参照)。どのユーザーがセキュリティ ポリシーを設定および変更できるのかは、セキュリティ上の役割によって決まります。Manager (管理者) の役割は通常、モバイル オペレータ用に予約されていて、セキュリティ ポリシーの設定を完全に制御できます。Enterprise (エンタープライズ) の役割は、Exchange 管理者が構成した一部のデバイス ポリシーを管理するために Exchange で使用されます。デバイスの提供元との契約によっては、会社のセキュリティ ポリシーをカスタマイズできる場合があります。
Figure 3 モバイル デバイスのセキュリティ ポリシー (Close Figure 3)

ポリシー モバイル デバイス
デバイスへの不正な侵入をブロックする

MSFP を適用した Windows Mobile 5.0

ユーザーが毎回デバイスで認証を行って、デバイスのロックを解除するか、ユーザーがデスクトップで PIN を入力できるようにする必要があることを指定します。
既定の役割 : Manager (管理者)、Enterprise (エンタープライズ)。

Windows Mobile 6

ユーザー アクセス許可を付与または拒否して、リムーバブル記憶域メディアのモバイル暗号化設定を変更します。
既定の役割 : Manager (管理者)、Enterprise (エンタープライズ)。
デバイス ロックがアクティブな場合に、ユーザーがデバイスへの接続時にデバイスに対して認証する必要があるかどうかを指定します。既定の役割 : Manager (管理者)、Enterprise (エンタープライズ)。
デバイスの盗難または紛失時に重要なデータを保護する

MSFP を適用した Windows Mobile 5.0

ユーザーは毎回デバイスで認証を行って、デバイスのロックを解除するか、ユーザーがデスクトップで PIN を入力できるようにする必要があることを指定します。
既定の役割 : Manager (管理者)、Enterprise (エンタープライズ)。

MSFP を適用した Windows Mobile 5.0 および Windows Mobile 6

デバイスでパスワードを構成する必要があるかどうかを指定します。ローカルとリモートのデバイス ワイプ設定を構成します。
既定の役割 : Manager (管理者)、Enterprise (エンタープライズ)。
Windows Mobile で使用されるカスタマイズ可能な認証方法は、ローカル認証サブシステム (LASS) と連動するローカル認証プラグイン (LAP) によって制御されます。このテクノロジを使用すると、Exchange Server がデバイス構成をより細かなレベルで制御できます。たとえば、パスワードの長さや複雑さの要件を適用したり、単純な PIN 認証を有効にしたりします。
Windows Mobile 6 には Exchange Server 2007 を使用して構成される LAP 機能の拡張セットが用意されています。PIN パターンの認識 ("1111" や "1234" などの単純なパターンの使用を拒否するなど) を有効にしたり、パスワードや PIN の有効期限を構成したり、ユーザーが特定の条件に基づいて PIN のリセットを要求できるようにしたり、PIN やパスワードの履歴を保持しておいて、ユーザーが新しい PIN またはパスワードを作成するよう要求されたときに古い PIN やパスワードを再利用するのを防いだりすることができます。

デバイス上のデータを保護する
正しくない PIN またはパスワードが管理者によって設定された制限回数を超えて入力された場合、ローカル デバイス ワイプ機能によってデバイスがハード リセットされ、ユーザー認証の資格情報を含むデバイス メモリが消去されます。この制限は Exchange Server のセキュリティ ポリシーの一部として設定されます。正しくないエントリが 2 回入力されるたびに、デバイスはユーザーに、続行するには構造化されたキー文字列を入力するよう指示します (図 4 参照)。これにより、キーがランダムに押されても、デバイスが誤ってワイプされるのを防ぐことができます。Windows Mobile 6 と Exchange Server 2007 を使用していれば、メモリ カードをリモートからワイプすることも可能です。
図 4 PIN とパスワードの使用を適用
図 4 PIN とパスワードの使用を適用
会社の重要なデータが保存されている 2 GB のメモリ カードをタクシーの中に忘れてきた場合、デバイスのロックダウンは役に立ちません。さいわい、Windows Mobile 6 を使用してこの問題に対処することもできます。Windows Mobile 6 を使用すると、メモリ カードのデータを暗号化して、メモリ カードに書き込んだデバイスだけがそのデータを読み取れるようにすることができます。Windows Mobile 6 のその他多数の拡張されたセキュリティ機能と同様に、Exchange Server 2007 を使用してモバイルでこのセキュリティ機能を提供することもできます。メモリ カードの暗号化は、ユーザーがほとんど意識することなく処理されます。Exchange Server 2007 では、ユーザーがメモリ カードの暗号化設定を変更できるようにするかどうかを管理者が選択できます。
アプリケーションを Windows Mobile デバイス上で実行できるかどうかは、Privileged (特権)、Normal (標準)、および Blocked (ブロック済み) という 3 レベルのアクセス許可に基づきます。Privileged (特権) レベルのアプリケーション (特権のある証明書ストアの証明書で署名されたもの) は、レジストリとシステム ファイルに書き込むことができ、証明書をインストールすることもできます。デスクトップ PC やサーバーと同様に、オペレーティング システム環境を変更できるアプリケーションほど、その環境が脅威にさらされるリスクが高くなります。一般的には、Privileged (特権) アクセスを持つアプリケーションの数を減らすことが推奨されます。多くのアプリケーション (特権のない証明書ストアの証明書で署名されているアプリケーションや、ユーザーが実行に同意した未署名のアプリケーション) は Normal (標準) レベルでのみ実行する必要があります。Normal (標準) レベルでは、アプリケーションを実行することはできますが、システム ファイルにアクセスすることはできません。Blocked (ブロック済み) アプリケーションは言うまでもなく、ブロックされています。不適切な設定やユーザー操作が原因で実行できません。
デバイスでは 1 層または 2 層のセキュリティ アクセスを構成できます。1 層のアクセス構成では、未署名のアプリケーションは Privileged (特権) アクセスを使用して実行されるか、ブロックされていて単に実行できないかのいずれかになります。2 層のアクセス構成の場合、ポリシーが正常に確認されるか、ユーザーがアプリケーションの実行を許可すれば、未署名のアプリケーションが Normal (標準) レベルで実行されます。デバイス設定によって異なりますが、ユーザーには未署名のアプリケーションを実行するかどうかを確認するメッセージが表示されます。
デジタル証明書 (個人、デバイス、およびアプリケーションの認証に最もよく使用される形式の 1 つ) は、デバイス レベル、サーバー レベル、およびネットワーク レベルでの Windows Mobile セキュリティの重要な部分です。Windows Mobile オペレーティング システムでは、複数の種類の証明書がデバイス上のさまざまな証明書ストアに格納されます。アプリケーションに関しては、どのアプリケーションをインストールして実行できるかは証明書によって決まります。Windows Mobile 実装のデバイスで、ユーザーによる確認を必要とせずにアプリケーションを実行するには、実行するアプリケーションが、Microsoft Mobile2Mobile プログラムによって承認されていることを示す証明書で署名されている必要があります。アプリケーションに付与されるアクセス許可レベルは、アプリケーションに関連付けられている証明書によって異なります。
ネットワーク認証の場合、各モバイル デバイスに、証明機関 (CA) から発行された多数の信頼されている商用目的のルート証明書が含まれています (図 5 参照)。メッセージング サーバー (Exchange Server など) では、デバイスのルート証明書の信頼性を確認してから、そのデバイスとの SSL 接続を確立します。会社がカスタム証明書を使用していると、購入した Windows Mobile 搭載デバイスにそれらの証明書をインストールすることができる場合や、新しい証明書を作成する必要のある場合があります。この機能については、この記事の「ネットワーク セキュリティ」で説明します。
図 5 デジタル証明書の管理
図 5 デジタル証明書の管理
ActiveSync と Internet Explorer® Mobile では、SSL を使用して、デバイスと会社の Web サーバー間でのデータ転送をセキュリティで保護することができます。このことは、Microsoft Exchange データの同期、デバイスの構成、アプリケーションのダウンロードのどれを目的として接続が確立されている場合でも当てはまります。SSL では、128 ビットの RC4 暗号または 3DES 暗号を使用して通信チャネルを暗号化するので、外部からデータを読み取ることはできません。また、Windows Mobile は VPN もサポートしています。VPN は、パケットの暗号化を使用して、インターネット経由でサーバーにアクセスしているときに専用回線と同様のセキュリティを提供します。

Exchange Server のセキュリティ
Windows Mobile 搭載デバイスで Exchange Server が機能している必要はありませんが、2 つのシステムは密接に連携して、堅牢なエンド ツー エンドのメッセージングと生産性を備えたソリューションを提供するように設計されています。MSFP を適用した Windows Mobile 5.0 のリリース以降、ActiveSync は Windows Mobile デバイス設定のリモート管理を行えるように拡張されました。ActiveSync には、多くの Windows Mobile デバイス間のグローバルなセキュリティ設定を反映および適用するために、使いやすいうえに強力な手段が用意されています。
ActiveSync は IIS (Microsoft Windows Server 2003 のアプリケーションまたは Web サーバー コンポーネント) 上で動作します。IIS は、ActiveSync 自体をネットワーク経由で侵入してくる攻撃から保護するのに役立つ、組み込みのセキュリティを提供しています。Microsoft Office Outlook® Web Access (OWA) も IIS をベースにしているため、ActiveSync と OWA の両方に同一のセキュリティ証明書を使用できます。
ActiveSync を使用してエンタープライズ ポリシーを反映する場合、そのポリシーは次回デバイスと Exchange Server が同期されるときにデバイスに配信されます。ユーザーはその変更を受け入れる必要があります。そうしないと、サーバーに接続することを許可されません。大半のネットワークは、洗練されたセキュリティ ポリシーを受け入れることができないレガシ ハードウェアを含め、さまざまなデバイスに対応します。必要に応じて、レガシ ハードウェアなどの特定のデバイスをセキュリティ ポリシーの要件から除外して、それらのデバイスが引き続き接続できるようにすることが可能です。
Exchange Server 2003 SP2 と Exchange Server 2007 のセキュリティ ポリシー制御機能は少し異なります。Exchange Server 2003 SP2 では、パスワードの最低文字数を 4 ～ 18 文字に指定して、パスワードに数字と文字の両方を含めるように要求し、非アクティブな期間がどれくらい続いたらデバイス ロックを発生させるのかを設定できます。このバージョンの Exchange Server では、セキュリティ設定をデバイスにプッシュする頻度を設定したり、レガシ デバイスに対する前述の例外を許可することもできます。
Exchange Server 2007 リリースでは、ActiveSync モバイル デバイスの管理機能が拡張されていて、Exchange Server 2003 SP2 のすべての機能だけでなく、次の機能も含まれています。
  • 単純なパスワード ("1234" や "1111" など) を許可または拒否する
  • 添付ファイルのダウンロードを有効または無効にする
  • メモリ カードの暗号化を要求する
  • 添付ファイルの最大サイズを設定する
  • ユーザーが OWA 経由でデバイス パスワードを回復できるようにする
  • 汎用名前付け規則 (UNC) ファイルと Microsoft Windows SharePoint® Services (WSS) ファイルへのアクセスを有効にする
Exchange Server 2007 では、IT プロフェッショナルは、各ユーザーまたはデバイスに合わせてポリシーをカスタマイズしたり、ユーザー グループ用のポリシーを管理したり、特定のユーザーをセキュリティ ポリシーから完全に除外したりする作業が柔軟に行えます。

リモート アクセス ワイプ
前述のローカル デバイス ワイプに加えて、Exchange Server 2003 SP2、Exchange Server 2007、または OWA を使用すると Windows Mobile 搭載デバイスをリモートからワイプできます。同期時に実行されるリモート ワイプは、ActiveSync セキュリティ ポリシーを使用していない場合でも実行できます。リモート ワイプのハード リセットはデバイスから停止できません。データ、設定、およびセキュリティ キーは、ゼロが繰り返されると上書きされます。これにより、コア オペレーティング システムに含まれていないデータを回復するのが非常に困難になります。

ネットワーク セキュリティ
ネットワーク セキュリティは、モバイル セキュリティにとって、デバイス コンポーネントやメッセージング サーバー コンポーネントと同じくらい重要です。また、制御の中で最も明確であるモバイル インフラストラクチャの一部でもあります。1 つ以上のモバイル デバイスが侵害された場合でも、ベスト プラクティスに従って企業ネットワークを構成し、適切なセキュリティ プロトコルを実装することで、ネットワークが損害を受けないようにするのに役立ちます。
Windows Mobile はさまざまなネットワークの種類と適切に連携します。標準のインターネット セキュリティ プロトコルとファイアウォールを使用して、パフォーマンス、安定性、およびセキュリティのニーズに応じたソリューションを設計できます。
企業ネットワーク内にメッセージング サーバーが存在する場合、それらのメッセージング サーバーはインターネットと企業サーバー間のバッファとしての役割を果たすエッジ ファイアウォールを使用して保護できます。Microsoft Internet Security and Acceleration (ISA) Server 2004 または ISA Server 2006 は、両方ともこの目的に特化して設計された機能が備わっているので、すべての着信パケットを調査して、パケットの識別情報を特定してから Exchange サーバーに渡し、その後でインターネットを経由してクライアントに送信情報を返送します。
ISA Server を構成するには、SSL 暗号化を有効にし、Exchange Server トラフィック用の SSL Web リスニング ポートとしてポート 443 を指定する必要があります。このようにリスニング ポートを 1 つのポートに限定することによって、インターネットに対するリスクを最小限に抑えることができます。また、すべてのクライアントで、ActiveSync 経由の接続を行う前に、SSL リンクを確立する必要があります。
ISA Server は OWA のような Web アプリケーションのユーザーを事前認証して、未認証のユーザーがアプリケーション サーバーにアクセスするのを防ぐことができます。ISA Server 2006 は、Windows Mobile 搭載デバイスの SSL 終了ポイントとして機能することによって、ISA Server 2004 の SSL ブリッジ モデルを強化しています。これにより、ISA Server 2006 に依存してトラフィックを送受信するのではなく、Windows Mobile 搭載デバイスを Exchange サーバーで認証できます。このとき、Exchange サーバーと直接接続する必要はありません。また、ISA Server 2006 の推奨の場所が境界ネットワーク内なので、パブリック インターネット クラウドと Exchange Server フロント エンド間に新たな層のセキュリティが許可されます。

認証
基本的な認証方法は 2 つあり、基本認証と証明書ベースの認証のいずれかを選択できます。基本認証は標準であるユーザー名と対応するパスワード、つまり Windows Mobile クライアントと Exchange フロントエンド サーバー間の SSL ベースの接続を参照します。Exchange Server は認証する前にデバイス上の一致するルート証明書を検索するため、基本認証では証明書が必要です。Windows Mobile および IIS では、SSL に関連付けられたさまざまな暗号化方式を使用できます。
証明書ベースの認証は、MSFP を適用した Windows Mobile 5.0 と Windows Mobile 6 の両方で使用でき、SSL 基本認証ではなくトランスポート層セキュリティ (TLS) を使用します。TLS では、ルート証明書だけでなく、各ユーザーがパブリック キーと秘密キーを含む証明書を持っている必要があります。TLS はパスワードではなく暗号化キー (最大 2,048 ビット) を使用するため、このプロトコルでは強力な認証が提供されます。
Windows Mobile 6 で Desktop Enroll (デスクトップ登録) を使用してユーザー証明書を登録するには、証明書登録サーバーと同じドメインにあるデスクトップとデバイスをドッキングする必要があります。ユーザーはパスワードやスマート カードを始めとする方法を使用して登録を認証してから、デバイスをデスクトップ PC に接続します。その後、ユーザーはデスクトップから証明書システムにアクセスし、モバイル デバイスに証明書をインストールします。Desktop Enroll (デスクトップ登録) は、証明書の更新や、ActiveSync 認証証明書、SSL/TLS 認証証明書、802.1x Wi-Fi 証明書、または S/MIME デジタル署名証明書の配布など、Windows Mobile のさまざまなセキュリティ上の目的に役立ちます。
SSL などのセキュリティ プロトコルは、転送中のメッセージ データを保護しますが、Windows Mobile デバイスまたは Exchange サーバーに格納されたデータは暗号化しません。S/MIME は、お馴染みの MIME 電子メール標準というセキュリティ保護形式で、デジタル署名付きの電子メールや暗号化された電子メールをサポートします。これにより、SSL トランスポート層の暗号化の上に追加の保護層が提供されます。

まとめ
ソリューションを構成する多くの層のそれぞれに注目して、十分にセキュリティで保護されたインフラストラクチャを作成します。Windows Mobile、Exchange Server、およびマイクロソフトのネットワーク セキュリティ製品 (ISA Server など) は連携するので、モバイル インフラストラクチャを管理する際の負担が大幅に軽減されます。これにより、IT 部門の作業はいくらか楽になります。IT 部門はモバイル デバイスで生じたセキュリティ問題から生産性に焦点を移すことで、もっと多くのことを実現できます。

この記事の作成を支援してくださった Kathy Esser 氏、Katharine Holdsworth 氏、Sarah Norton 氏、および Chip Vollers 氏にお礼申し上げます。

Matt Fontaine は BuzzBee Company のテクノロジ ライタです。


 通信: パブリック フォルダの強力な代替手段
通信 Alan Maddison

パブリック フォルダの強力な代替手段
概要:
  • 予定表と連絡先を共有する
  • ブログと Wiki を使用してコミュニケーションを図る
  • ドキュメントを共有および管理する

パブリック フォルダは、Microsoft Exchange Server の最初のバージョンで導入された機能であり、当初の目的は、ドキュメントの共有、配布リストのアーカイブ、カスタム アプリケーションの開発を実現する基本的なプラットフォームを提供するということでした。しかし、当初から、
管理者は、管理作業に悪戦苦闘し、パブリック フォルダを使用することは、多くの Exchange 環境において非常に複雑な作業でした。Exchange Server 2007 では、パブリック フォルダの管理作業が大幅に向上しましたが、依然として問題があります。パブリック フォルダは、企業が今日必要としている強力なコラボレーションとドキュメントの管理を実現するプラットフォームを提供しません。
マイクロソフトは、パブリック フォルダのサポートを Exchange Server 2007 で終了する可能性があることを表明しました。現在、パブリック フォルダは完全にサポートされており、Exchange Server 2007 のリリース後 10 年間は完全なサポートが提供されますが、これはパブリック フォルダの代替手段を検討するよい機会です。
さいわい、マイクロソフトでは、Microsoft® Office SharePoint® Server (MOSS) 2007 のリリースにより、強力なオプションを提供しました。MOSS 2007 は、パブリック フォルダで提供される機能の代替として使用できるプラットフォームを IT 管理者や企業に提供します。この記事では、MOSS が Exchange Server のパブリック フォルダよりも豊富な機能を提供する堅牢かつ強力なフレームワークであることを説明します。特に、予定表、連絡先、ドキュメントの共有など、パブリック フォルダの主な用途に SharePoint Server を使用することに重点を置いて説明します。
クライアントを更新するまでは、パブリック フォルダを継続して使用する必要があることに注意してください。Microsoft Outlook® クライアント (Outlook 97 から Outlook 2003 まで) では、オフライン アドレス帳、組織フォーム ライブラリ、空き時間情報の参照などにパブリック フォルダが必要です。Outlook 2007 と Exchange Server 2007 への移行が完了したら、準備が整い次第、パブリック フォルダの使用を完全に中止することができます。

SharePoint Server の予定表
予定表の共有は、パブリック フォルダの一般的な用途です。パブリック フォルダを使用している予定表の代わりに SharePoint Server の予定表を使用するのは簡単な作業です。SharePoint サイトの既定のインストールには 1 つの予定表が含まれていますが、組織のニーズに対応するには複数の予定表を作成する必要があります。これを説明するために、人事部用の共有の予定表を作成する方法を紹介します。まず、[すべてのサイト コンテンツの表示] を選択します。通常、このオプションは SharePoint サイトの左上に表示されます (図 1 参照)。
図 1 新しいサイト コンテンツを作成する
図 1 新しいサイト コンテンツを作成する
[すべてのサイト コンテンツの表示] を選択したら、[作成] ボタンをクリックします (このボタンも図 1 に表示されています)。作成ページが読み込まれると、既定のコンテンツ タイプのオプションが表示されます (図 2 参照)。予定表を作成するには、[リスト] の [予定表] を選択します。[名前] ボックスと [説明] ボックスに情報を設定し、予定表をクイック リンク セクションに含めるかどうかを選択します。
図 2 作成ページには多数の既定のオプションが表示される
図 2 作成ページには多数の既定のオプションが表示される
これで、予定表が作成されました。ユーザーは SharePoint サイトを使用するか、または Outlook から直接、共有の予定表を参照できます。Outlook から共有の予定表を参照するのに必要な作業は、Web ブラウザを使用して予定表に接続し、[操作] メニューの [Outlook に接続] をクリックするだけです。
初めて接続するときには、セキュリティ警告が表示されます。これは、ユーザーが既知の信頼できるソースにのみ接続するようにするためのものです。[はい] をクリックすると、予定表は Outlook に接続されます。図 3 は既定のビューです。既定のビューには、SharePoint の予定表と Outlook の予定表が並んだ状態で表示されます。
図 3 SharePoint の予定表と Outlook の予定表が並んだ状態で表示される
図 3 SharePoint の予定表と Outlook の予定表が並んだ状態で表示される
予定表が Outlook に接続されると、双方向の同期が行われます。Outlook で入力されたイベントは SharePoint と同期され、予定表を参照するユーザーには更新されたエントリが表示されます。また、SharePoint Server で SMTP のサポートを有効にしている場合は、イベントを直接予定表に電子メールで送信し、SharePoint Server でそれらのエントリを追加することができます。

SharePoint Server の連絡先
多くの組織では、パブリック フォルダを利用する共有連絡先も使用されています。SharePoint Server では、連絡先についても、連絡先リストを簡単に作成および管理できるようにする、より堅牢な代替機能を提供します。同じ例を使用して、人事部用の共有連絡先リストを作成する方法を紹介します。
ここでも、[すべてのサイト コンテンツの表示] を選択し、[作成] ボタンをクリックします。[通信] の [連絡先] を選択します。名前、説明、およびクイック リンクの構成情報を指定する画面が表示されます (図 4 参照)。この情報を設定して [作成] ボタンをクリックすると、新しい連絡先リストが作成されます。
図 4 名前、説明、およびクリック リンクの構成を指定する
図 4 名前、説明、およびクリック リンクの構成を指定する

ユーザー コミュニケーション
SharePoint Server を使用してディスカッション掲示板 (ディスカッション リスト) を作成することもできます。予定表や連絡先と同様、作成手順は非常に簡単です。[すべてのサイト コンテンツの表示] を選択し、[作成] ボタンをクリックして、[通信] の [ディスカッション掲示板] を選択します。これまでと同様に、名前、説明、およびクイック リンクの構成情報を指定して、[作成] ボタンをクリックします。図 5 に、いくつかのサンプル投稿があるディスカッション掲示板を示します。
図 5 いくつかの投稿のあるサンプルのディスカッション掲示板
図 5 いくつかの投稿のあるサンプルのディスカッション掲示板
SharePoint Server では、ディスカッション掲示板以外に、ブログと Wiki という 2 つの一般的なコミュニケーション ツールがサポートされるようになりました。ブログと Wiki は SharePoint Server 2007 の新機能であり、パブリック フォルダでは利用できません。これらのツールは、機能セットに魅力的で有益なグループ作業の機能を提供します。
ブログは、対話的なフォーラムであり、ブログの作成者は、Web サイトに投稿することで自分の見解やアイディアを簡単に掲示できます。一般的に、ブログの投稿内容は、ブログにアクセスした人が興味のある投稿内容を検索しやすくするために分類されます。また、ブログの読者は、ブログ作成者のコメントに対して応答のコメントを投稿することができます。たとえば、企業では、経営幹部のブログを設けることができます。このようなブログは、従業員とのコミュニケーションを図る有益なツールとしての役割を果たし、スタッフ メンバがアイディアを共有する手段を提供し、あらゆるレベルでのコミュニケーションを円滑に行うことを可能にします。
SharePoint Server では簡単にブログを作成できます。まず、[すべてのサイト コンテンツの表示] を選択し、[作成] ボタンをクリックして、[Web ページ] の [サイトとワークスペース] をクリックします。この操作により、[新しい SharePoint サイト] ページが表示されます。このページでは、サイトのタイトル、名前、および URL を指定します。次に、サイトで使用するテンプレートを選択します。ここでは、ブログのテンプレートを選択します。最後の 3 つの構成オプションは、アクセス許可、ナビゲーション、およびサイト ディレクトリの一覧です。必要なすべてのオプションを設定したら、[作成] ボタンをクリックします。[作成] ボタンをクリックすると、トップレベル サイト内にサブサイトが作成され、サブサイト内にブログ機能を提供するライブラリとリストが作成されます。この処理が完了すると、新しいブログが表示されます。
Wiki は、グループ作業を促進することを目的にデザインされたツールです。ユーザーは、サイト コンテンツを追加、削除、編集したり、ページを相互にリンクしたりすることができます。Wiki を作成する最も簡単な方法は、[すべてのサイト コンテンツの表示] を選択し、[作成] リンクをクリックして、[Wiki ページ ライブラリ] を選択することです ([Wiki ページ ライブラリ] は [ライブラリ] にあります)。名前、説明、ナビゲーションなどの必要な構成フィールドに情報を設定したら、[作成] ボタンをクリックします。これで Wiki が作成されます。SharePoint Server で Wiki を使用する方法の詳細については、TechNet Magazine 2007 年 1 月号の記事「作業上での Wiki の使用」を参照してください。

SharePoint ライブラリ
パブリック フォルダは、ユーザーが簡単にアクセスしてドキュメントを共有できる集中管理された場所を提供するドキュメント リポジトリとしての役割を果たしています。Exchange Server の管理者たちは、年月を経て、この使用方法がパブリック フォルダを扱いにくいものにした主要な原因の 1 つであるという結論にたどり着きました。このパブリック フォルダの用途は、パブリック フォルダのデータベースに関連する Exchange Server の I/O を増加させるだけでなく、Exchange Server インフラストラクチャ全体のレプリケーションにも影響を与えます。SharePoint ライブラリは、Exchange およびそのリソースへの要求を解放するための優れたオプションを提供します。
SharePoint ライブラリは、SharePoint サイト内にある場所であり、ユーザーは、ここにファイルを格納して管理することができます。SharePoint ライブラリには、画像、Wiki ページ、フォーム、およびドキュメントなど複数の種類があります。パブリック フォルダの代替として最適なのは、ドキュメント ライブラリです。ドキュメント ライブラリは、SharePoint サイト内でのドキュメントの格納、管理、および作成をサポートします。
ドキュメント ライブラリには、さまざまな種類のファイルを格納できますが、セキュリティ上の理由により、既定では、実行可能ファイルやスクリプトなど、特定種類のファイルの格納は制限されています。ただし、この制限は、SharePoint サーバーの全体管理サイトの [サーバー構成の管理] セクションで変更できます。
MOSS の既定のインストールには、カスタマイズできるドキュメント ライブラリが含まれています。ほとんどの組織では、さまざまな事業単位をサポートするのに複数のライブラリを作成する必要があります。SharePoint に付属するツールを使用すると、この作業は簡単にできます。たとえば、人事部用のドキュメント ライブラリを展開するには、[すべてのサイト コンテンツの表示] を選択し、[作成] をクリックし、[ドキュメント ライブラリ] を選択します ([ドキュメント ライブラリ] は [ライブラリ] にあります)。次のページには、構成する必要がある多数の設定が表示されます。ライブラリの名前と説明、ライブラリをクイック リンク セクションに含めるかどうか、バージョン管理を有効にするかどうか、ライブラリで直接作成された新しいドキュメントの既定の形式などを指定します。
特に注意する必要があるのは、ドキュメントのバージョン履歴のオプションです。既定では、このオプションは、無効に設定されています。ただし、バージョン管理は、多くの環境で有益かつ適切なオプションです。この機能は、ドキュメントの履歴を格納するだけでなく、いつ、だれが変更したのかということも追跡し、以前のバージョンを参照したり、復元したりする機能も提供します。
図 6 は、新しく作成されたドキュメント ライブラリにいくつかのドキュメントがアップロードされた状態を示します。ドキュメント ライブラリを作成したら、Microsoft Outlook とエクスプローラから、このリポジトリを使用できるようにすることができます。Outlook は、ドキュメント ライブラリのコンテンツをオフラインで利用することを可能にし、ネットワークにアクセスできないユーザーに読み取り専用のコピーを提供します。エクスプローラによるアクセスでは、マイ ネットワークを利用します。ドキュメント ライブラリの URL を入力することで、ユーザーにアクセスを提供できます。大規模な環境では、このようなネットワーク プレースの展開にグループ ポリシーを使用することを検討してみてください。
図 6 アップロードされたドキュメントを含むドキュメント ライブラリ
図 6 アップロードされたドキュメントを含むドキュメント ライブラリ

高度な設定
SharePoint Server は、パブリック フォルダよりもはるかに優れた機能セットを提供します。SharePoint Server では、パブリック フォルダで提供される一般的な機能以外に、一般的な用途を拡張する強力な機能を提供します。このような拡張機能には、次のようなものがあります。
  • バージョン履歴
  • 承認の制御
  • チェックアウトの手続き
  • ワークフローの制御
  • ドキュメントの保持期間ポリシー
  • 監査
  • RSS
このような機能は、エンタープライズ コンテンツ管理プラットフォームには必要不可欠であり、SharePoint では管理者が簡単に使用できる堅牢なフレームワークを提供します。この拡張機能は、予定表、タスク、ディスカッション掲示板、ドキュメント ライブラリなど、多くの SharePoint Server 機能で有効にできます。
拡張機能を構成するには、[設定] メニューをクリックし、設定オプションを選択します。たとえば、[ドキュメント ライブラリの設定] をクリックします (図 7 参照)。このオプションを選択すると、設定ページが表示されます。このページでは、利用できるすべての構成オプションとユーザー設定オプションが表示されます。たとえば、[全般設定] の [バージョン設定] では、バージョン履歴を構成できます。
図 7 設定オプションを選択して強化機能を構成する
図 7 設定オプションを選択して強化機能を構成する
既に説明したように、この機能は、いつ、だれが変更したのかなど、ドキュメントの変更に関する記録を提供し、ユーザーは必要に応じて以前のバージョンを参照したり、復元したりすることができます。また、SharePoint Server で格納するバージョンの数を制御することもできます。この制限に達すると、アイテムは SharePoint Server のごみ箱に入れられることなく完全に削除されます。
バージョン設定セクションでは、コンテンツの承認やチェックアウトの要件を構成できます。コンテンツの承認を有効にすると、送信されたアイテムは、承認されるまで他のユーザーが利用することはできません。承認されていないアイテムは承認待ちの状態になります。チェックアウト プロセスでは、複数のユーザーが同時に 1 つのファイルを操作することを禁止することでコンテンツの制御機能を提供しています。
ワークフローは、パブリック フォルダにない SharePoint Server が提供する有益な機能の一例です。基本的に、ワークフローは、企業運営の合理化を図るのに役立つ業務プロセスの構造化されたアプローチを提供します。SharePoint で実装されるワークフローは、指定のプロセスを介してドキュメントの移動を自動化する、事前に定義された一連のタスクです。プロセスは、各ステップが次のステップに進む前に完了する必要のある反復的なプロセスにしたり、特定のタスクをいつでも完了できる並列的なプロセスにすることができます。SharePoint Server には、次の既定のワークフローが用意されています。
  • 承認
  • フィードバックの収集
  • 署名の収集
  • 廃棄承認
情報管理ポリシーは、法規制や業務上の要件に準拠するのに使用できます。ポリシーは、ドキュメントの管理に関する一連の規則で構成されています。SharePoint Server では、独自の規則もサポートしますが、次の既定の規則が用意されています。
  • 監査
  • 有効期限
  • ラベル
  • バーコード
監査は、サイトの設定で定義した一連の操作に基づいてイベントをログに記録します。ドキュメントを開く、アイテムやそのプロパティのダウンロードと参照、ドキュメントの編集、ドキュメントのチェックアウトとチェックイン、アイテムの移動とコピー、アイテムの削除と復元などのような操作を追跡できます。
コンテンツの有効期限により、組織で施行しているデータの保持期間に関するポリシーに準拠して、コンテンツを削除できます。このコンテンツの期日には、特定の日時を指定したり、特定のイベント (ドキュメントの作成など) が発生してからの期間を指定したりすることができます。
ラベルは、印刷機能と組み合わせて使用して、印刷物にテキストを追加します。実際、このポリシーは、さまざまな用途に使用できます。たとえば、法務部による規定に準拠するために、人事部で共有しているドキュメント ライブラリにあるすべてのドキュメントについて、機密情報である通知を含めることを条件付けることができます。
バーコードは、オンライン ドキュメントと印刷したドキュメントの両方について、正式な追跡方法を提供します。SharePoint が、すべてのドキュメントに一意の ID を作成するので、ユーザーはバーコードの画像をドキュメントに挿入できます。
SharePoint Server が提供するもう 1 つの重要な強化機能は、RSS フィードとの統合です。予定表、連絡先、ドキュメント ライブラリ、およびディスカッション掲示板では、ユーザーがサブスクライブできる RSS フィードが提供されます。ユーザーは自動的に配信される更新情報を受け取って、日々の役割を把握することができます。RSS フィードの受信に必要なのは Outlook 2007 などの RSS リーダーだけです。

まとめ
Microsoft Office SharePoint Server 2007 は、エンタープライズ クラスの機能を提供し、Exchange Server のパブリック フォルダに代わる強力な機能を提供します。堅牢な管理フレームワークにより、予定表、連絡先、およびドキュメントを共有するためのソリューションを簡単に実装できます。また、ディスカッション フォーラム、ブログ、Wiki など、さまざまなコミュニケーションの場を設けることができます。

Alan Maddisonは、MTI Technology Corporation でマイクロソフト テクノロジの導入支援を担当しているシニア コンサルタントです。主な担当分野は、Active Directory、Exchange Server、および仮想化です。


 通信: スマート カードを使用した Outlook Web Access へのログオン
通信 Victor Akinnagbe and Ted Dressel and Jason Opdycke

スマート カードを使用した Outlook Web Access へのログオン
概要:
  • 2 要素認証
  • Kerberos の制約付き委任
  • ISA Server と Exchange の構成

モバイル機器を使用する従業員は、IT 組織にとって独特なセキュリティ上の課題をもたらします。リモート ユーザーは、データや電子メールなどのサービスに、セキュリティが確保された方法でアクセスする必要があります。しかし、残念ながら実態としては、
セキュリティ チェーンにおいて最も攻撃を受けやすいリンクは、脆弱なパスワード、(キー ロガーなどの) マルウェア、組織内部のリソースにアクセスしているリモート コンピュータ上のウイルスなどに関係しています。
こうしたモバイル環境のセキュリティを強化する 1 つの方法は、攻撃を受けやすいリンクの 1 つである、パスワードを削除することです (認証にパスワードを使用しないでアカウントにアクセスを許可するという考えは、不安かもしれませんが)。パスワードに関連する問題を解消するための主要な技法を 2 要素認証と呼びます (または多要素認証と呼ぶこともあります)。2 要素認証では、アクセスを許可する際にパスワードという 1 つの方法だけに依存するのではなく、ユーザー名とパスワードを組み合わせたり、スマート カードなどの物理デバイスを使用したり、指紋などのバイオメトリクス ID を使用するなど、追加の認証手法の使用が求められます。
リモート ユーザーがいる場合は、通常、ファイアウォールの一部を開放し、企業ネットワークへのリモート アクセスを許可する必要があります。標準のファイアウォールでは、社内ネットワークと社外ネットワークの間のネットワークレベルを分離することで、基本的なリスクを緩和しています (図 1 参照)。セキュリティを強化する場合は、単純にポートを閉じ、社内ネットワーク上のデバイスとの通信が必要になったときに、適切な場所にポートを転送します。これらの技術を使用することで、実質的にネットワークレベルが保護されますが、攻撃はますます巧妙化してきているため、現状は複数層でのネットワーク セキュリティが必要になってきます。
図 1 標準ファイアウォールとブロックまたは転送されるポート
図 1 標準ファイアウォールとブロックまたは転送されるポート
モバイル機器を使用する従業員が最も多く使用する一般的な企業サービスは電子メールとメッセージングです。そのため、セキュリティを確保するために Exchange インフラストラクチャを構成することが今までになく重要となってきます。電子メールへのアクセス方法として Outlook® Web Access (OWA) を使用することは、モバイル ユーザーにセキュリティが確保されたサービスを提供するための 1 つの方法です。もう 1 つの重要な方法は、スマート カードを使用してよりセキュリティの高い 2 要素認証を OWA で提供することです。この記事では、スマート カードに対応したユーザー独自の OWA を展開する際に、知っておく必要がある構成とセットアップの問題について詳しく説明します。

ファイアウォールを上回る利点
Microsoft® Internet Security and Acceleration (ISA) Server 2006 をネットワークに導入することにより、セキュリティがより確保される方法で、ネットワークをリモート ユーザーに開放する作業を簡素化できます。ISA Server 2006 には、スマート カード対応の仮想プライベート ネットワーク (VPN)、Active Directory® に対するライトウェイト ディレクトリ アクセス プロトコル (LDAP) 認証、Kerberos の制約付き委任などのセキュリティが強化された機能が含まれています。ISA Server は、従来のファイアウォールの考え方とは多少異なります。ISA Server は、標準ファイアウォール ハードウェアの代用として、また標準ファイアウォール ハードウェアと連携してネットワーク層で機能するだけでなく、従来のファイアウォールではサポートされていなかったアプリケーション フィルタなどの追加セキュリティ機能を提供することによって、複数層のセキュリティを提供します。ホストしている特定の Web サイトに対して HTTP POST メソッドを使用しない場合、SMTP メッセージが Exchange サーバーに到着する前に、メッセージを RFC に準拠させる場合、または暗号化された SSL (Secure Sockets Layer) HTTP パケットがネットワークに着信する前にパケットを検査したい場合などにISA Server を使用して、これらの作業すべてを管理し、さらにクリーンで、フィルタ処理されたトラフィックのみを DMZ や社内ネットワークに転送することができます。
SSL セッションは標準のファイアウォールにとっては厄介です。パケットがファイアウォールを通過する際、それらのパケットは暗号化されたままです (これは SSL が正常に機能していることを意味します)。そのため、OWA などのアプリケーションが、SSL を使用してハードウェアまたはソフトウェア ファイアウォール経由で公開される場合、標準のファイアウォールで、実際にステートフル パケット インスペクション以外に適用できる検査はありません。単純にポートを開いて転送するだけでは、相当な範囲が攻撃にさらされてしまうことになります。エッジでは実際の検査は行われていないので、未検査の認証されていないパケットが社内ネットワークにルーティングされることになります。
ISA Server 2006 は、HTTP クライアント向けの SSL エンドポイントとして機能し、認証済みのトラフィックのみが、公開された Exchange サーバーに到達することを保証します。ISA Server では SSL ブリッジという有用な機能をサポートしています。通常、パケットは、標準の SSL セッション経由で ISA Server と通信しているクライアントによって暗号化されます。ISA Server は SSL ブリッジを使用して、SSL 暗号化をローカルで解除し、すぐにその暗号化が解除されたパケットを検査します。次に、(必要に応じて) Active Directory に対してユーザーを認証し、SSL を使用してパケットを再暗号化してから、暗号化したパケットを適切な Exchange サーバーに転送します （図 2 参照)。SSL ブリッジではこの技法を使用して、アプリケーションを認識しないファイアウォールに送信される、暗号化された BLOB データにしか見えない SSL セッション内に潜む攻撃を緩和します。
図 2 ISA Server によるトラフィックのアプリケーション層ビュー
図 2 ISA Server によるトラフィックのアプリケーション層ビュー
Kerberos の制約付き委任について話をする際には、サーバーに到着する事前認証済みのトラフィックが重要なポイントになります。標準ファイアウォールでは、ポートが単純に Exchange サーバーに転送され、悪意のある可能性があるユーザーに対し、フロントエンド サーバー自体が認証作業を実行します。ISA Server では、認証が必要な場合に、直接 Active Directory にアクセスして、そのユーザーに代わって資格情報を要求できます。ユーザーが正しく認証されると、ISA Server から Exchange フロントエンド サーバーにメッセージが転送されます。これにより、フロントエンド サーバーではランダムで未知のユーザー要求を認証する必要がなくなるため、バックエン サーバーへの要求を単にプロキシするためだけにフロントエンド サーバーを使用できるようになります。また、ISA Server 2006 では、Kerberos の制約付き委任を使用して、Windows SharePoint Services や Exchange ActiveSync などのテクノロジに証明書ベースでアクセスすることもできます。
Exchange Server 2003 では、OWA ログイン用に、フロントエンド サーバーとバックエンド サーバー間での Kerberos ベースの認証がサポートされていました (クライアント トラフィックの保護には IPsec を使用していることと思います)。Exchange Server では、クラスタ化されたメールボックス サーバーに対する Kerberos 認証もサポートされています。

スマート カード認証を有効にする
これまで、OWA 向けにスマート カード ベースの認証を実装することは困難でした。しかし、ISA Server 2006 で使用可能になった Kerberos の制約付き委任機能を基にソリューションが開発されました。このソリューションでは、証明書を使用してユーザーから資格情報を送信することで、OWA に対して正しく認証を行うことができます。Kerberos の制約付き委任は、制約のない委任に使用していた Windows® 2000 でサポートされている Kerberos 委任を上回る優れた機能強化です。Kerberos の制約機能により、さらにセキュリティが確保され、偽装を利用した巧妙な攻撃による潜在的なリスクを軽減します。
スマート カード対応のシナリオでは、ユーザーは社外ネットワークからキー配布センター (KDC) にルーティング可能な方法でアクセスできないので、ISA Server 2006 が Active Directory にアクセスしてユーザーを認証します。ISA Server は、Active Directory 証明書ユーザー マッピングに従ってユーザーを認証した後、ユーザー プリンシパル名 (UPN) に基づいてそれぞれの Kerberos チケットを取得します。この場合、ISA Server は、Kerberos の制約付き委任機能を、アプリケーション レベルのフィルタリングとリバース プロキシ サービス経由で Exchange フロントエンド サーバーに提供します。リバース プロキシを経由しないで委任が試行された場合、脆弱性に対するリスクが増加し、ネットワークまたは Active Directory ドメインの完全性に影響することがあります。
Exchange Server 2003 と Exchange Server 2007 はどちらも、基本認証と統合認証を許可します。ただし、Exchange Server 2003 で OWA に対するスマート カード ベースの認証が正常に機能するには、ソフトウェア更新プログラムを適用する必要があります (詳細については、「Outlook Web Access に対するスマート カード認証をサポートする Exchange Server 2003 の新機能について」を参照してください)。Windows Server® 2003 ネイティブ機能モードのドメインを用意し、関連するすべての Exchange Server 2003 サーバーに SP2 以降を適用する必要があります。また、OWA サイトのリバース プロキシとして機能する ISA Server 2006 サーバーが必要です。
ソフトウェア更新プログラムをインストールして、ISA サーバーと Exchange サーバーを構成すると、ユーザーはスマート カードを使用して OWA セッションを認証できるようになります。図 3 に、スマート カード認証に必要なイベント フローを示します。まず、ユーザーが Internet Explorer® で OWA サイトを開きます (1)。実際には、ユーザーが接続しているのは ISA Server で、OWA セッションを開始するために、ユーザー名とパスワードの代わりに証明書が求められます。適切な証明書はスマート カードに保存されているため、PIN が必要です。
図 3 スマート カードによる OWA の認証
図 3 スマート カードによる OWA の認証
証明書の検証 (2) は、ISA Server とその他のインストール済みソフトウェアの構成に応じて、証明書失効リスト (CRL) またはオンライン証明書状態プロトコル (OCSP) 要求を経由して処理されます。ISA Server は、 ユーザーの資格情報を確認するようにドメイン コントローラ (DC) に要求します。この要求に失敗すると、ISA Server はユーザーに対してエラー ページを表示し、要求は Exchange フロントエンド サーバーには到達しません。
資格情報が確認されると Kerberos チケットが生成され、統合認証を使用して Exchange フロントエンド サーバーに要求が渡されます (3)。Exchange フロントエンド サーバーが要求を受け取ると、Kerberos チケットを検証して、ユーザーのバックエンド メールボックス サーバーを検索します (4)。
フロントエンド サーバーは、適切なバックエンド サーバーの Kerberos チケットを Kerberos の制約付き委任を使用して要求し、統合認証を使用してバックエンド サーバーにメールボックス要求をプロキシします (5)。要求がバックエンド サーバーで処理され (6)、メールボックス データが Exchange フロントエンド サーバーに返されます (7)。OWA ページの HTML データが ISA Server に渡され (8)、その後、クライアント コンピュータに渡されます (9)。

Exchange 環境の構成
前述のサポート技術情報の資料には、Exchange Server 2003 のソフトウェア更新プログラムの説明、および ISA Server 2006 と Exchange Server 2003 を使用して Kerberos の制約付き委任を有効にするプロセスに役立つ情報が記載されています。
このソフトウェア更新プログラムによって有効になる主な機能は、Exchange フロントエンド サーバーからそれぞれのバックエンド サーバーまでの Kerberos の制約付き委任のプロセスの自動化です。ISA Server は Exchange 組織の一部ではないので、この更新プログラムを適用しても、ISA Server からフロントエンド サーバーまでの Kerberos の制約付き委任のプロセスは自動化されません。各 ISA Server インスタンスから各 Exchange フロントエンド サーバーまでの委任プロセスは、手動で有効にする必要があります。
このソフトウェア更新プログラムを適用すると、Exchange システム マネージャに新しいタブが追加され、Exchange フロントエンド サーバーを KCD-FE として指定できるようになります (図 4 参照)。また、それぞれの Exchange バックエンド サーバーの委任タブでそのサーバーを設定できるようになります。
図 4 Kerberos の制約付き委任を有効にする
図 4 Kerberos の制約付き委任を有効にする
新しい UI では、図 5 に示すように、msDS-AllowedToDelegateTo (A2D2) 属性の設定に使用する資格情報を、管理グループのプロパティで指定することもできます。この属性が、Kerberos の制約付き委任を担当します。
図 5 委任を制御するアカウントの設定
図 5 委任を制御するアカウントの設定
最小特権の原則に関しては、標準ユーザー アカウントを使用し、グループ ポリシー オブジェクト (GPO) 経由でユーザーとコンピュータに委任する権限を標準ユーザー アカウントに許可することができます。アカウントにこの権限を昇格したアクセス許可を与えると、各管理グループの Kerberos の制約付き委任プロセスを自動化するサービス アカウントとしてこのアカウントを使用できます。
悪意のあるユーザーに Kerberos の制約付き委任サービス アカウントを知られないようにするために、適切な措置を講じてください。そのアカウントがドメイン管理者でなくても、そのアカウントへのアクセスにより、Kerberos 委任を利用した巧妙な攻撃につながる可能性があります。このアカウントを使用すると新たに Kerberos の関連付けを確立できるため、十分に注意して使用してください。アカウントのセキュリティと完全性を確保するために、必要な予防措置を講じてください。たとえば、長くて複雑なパスワードを使用することや、監査を増やすこと、またはアカウントを無効にする技術などが必要です。
また、この Exchange ソフトウェア更新プログラムでは、統合認証に関連する非常に重要な変更が ESM インターフェイスに加えられます。以前、Exchange Server 2003 では、サーバーをフロントエンド サーバーとして指定した場合に、HTTP 仮想ディレクトリ (HTTP 仮想サーバーの下) の統合 Windows 認証を有効にするオプションを使用できませんでした (図 6 参照)。
図 6a 更新プログラムにより統合認証が有効になる
図 6a 更新プログラムにより統合認証が有効になる
図 6b 更新プログラムにより統合認証が有効になる
図 6b 更新プログラムにより統合認証が有効になる
プロキシ サーバーによって NTLM セッションが中断されたり、Kerberos 認証を使用するユーザーは Active Directory に接続する必要があったり、インターネット ユーザーは通常ドメインに所属していなかったりなどの技術上の問題により、統合認証が Exchange フロントエンド サーバーでサポートされていなかったため、このオプションを使用できませんでした。前述のサポート技術情報の資料で説明されている更新プログラムを適用すると、こうした制限が取り除かれます。更新プログラムをインストールすると、単に仮想ディレクトリに移動し、ユーザー資格情報を確認するためのメカニズムとして、統合 Windows 認証のチェック ボックスをオンにすることができるようになります。このチェック ボックスをオンにすると、msexchAuthenticationFlags という属性が、Active Directory の仮想ディレクトリ オブジェクトに設定されます (Microsoft 管理コンソールの Adsiedit.msc スナップインを使用して確認できます)。
OWA を使用してメールを確認するユーザーは、使用している Exchange バックエンドサーバーの名前を把握できます。また、企業ネットワークにログオンしている間は統合認証を使用して Exchange バックエンド サーバーに接続できます。統合認証とのユーザー エクペリエンスの違いは、ネットワークにログオンしているため、Internet Explorer によって Web サイトに対して自動的に認証が行われているので、ユーザー名とパスワードの入力を求められない点です。このことは、企業ネットワーク上のユーザーにとっては好都合ですが、社外ユーザー (OWA ユーザーは通常社外ユーザーです) はネットワーク外部から Exchange フロントエンド サーバーにアクセスするとき、通常はドメインにログオンしません (このプロセスは、サポート技術情報の資料「[INFO] IIS におけるブラウザ クライアントの認証方法」で詳しく説明されています)。
Exchange Server では、この更新プログラムにより、[委任] タブが、Active Directory のサービス プリンシパル名 (SPN) 属性ではなく A2D2 属性を使用するように設定されます。Adsiedit.msc を使用して Exchange コンピュータ オブジェクトを確認すると、2 つの属性に気付きます。Kerberos の制約付き委任リストである A2D2 属性と、Kerberos ロケータおよびアカウント指定ポイントとして機能する SPN 属性です。両方の属性が連携して Kerberos の制約付き委任が行われるのは事実ですが、グラフィカル インターフェイスを使用してA2D2 属性のみを変更してください。
Windows では、組み込みの HOST SPN をエイリアスとして使用して、他のサービスを検索できます。つまり、setspn.exe を Kerberos の制約付き委任に使用しなくても、Exchange フロントエンドからバックエンドへの委任が機能します (SPN 属性リストで HTTP/Servername を明示的に指定すると、このソリューションは機能しますが、管理者の設定ミスによるエラーが発生しやすくなるため、このソリューションは Kerberos の制約付き委任を機能させるための要件にはなっていません)。Kerberos の制約付き委任では、Active Directory の A2D2 属性が検索されます。この属性が設定されていない場合 (または間違った SPN 値に設定されている場合)、Kerberos の制約付き委任はそれぞれのサーバー間で機能しません。ただし、Exchangeh クラスタ上では、フロントエンド サーバーの A2D2 属性がクラスタ ノード コンピュータ アカウントを指してさえいれば正しく機能します。
前述のように、Exchange 2003 サーバーを含む Windows Server 2003 ドメインは、Windows Server 2003 ネイティブ機能モードになっている必要があります。Kerberos の制約付き委任は、ドメインの機能レベルが満たされない限り使用できません。ドメインが混合モードの状態で前述のソフトウェア更新プログラムをインストールすると、更新プログラムは正常に機能するように見えますが、実際には SPN の登録に失敗します。Kerberos の制約付き委任もドメイン レベルの機能であり、フォレスト レベルの機能ではありません。つまり、Exchange Server 2003 の場合、ISA Server、Exchange フロントエンド サーバー、および Exchange バックエンド サーバーは、同じドメインのメンバである必要があります (ただし、異なるドメインのユーザーでも Kerberos の制約付き委任に対する認証は可能です)。ISA Server インスタンスがドメインのメンバでない場合、または異なるドメインのメンバである場合は、このソリューションの一部としては機能しません。

OWA サイトの構成
IIS Admin は OWA に関する認証の変更には使用しないでください。IIS で実行される OWA が他の Web サイトのようにメタベースの変更に応答したとしても、Exchange の Directory Services to Metabase (DS2MB) プロセスに多少問題が生じます。DS2MB プロセスは、変更を Active Directory から IIS メタベースに一方向のプロセスでレプリケートします。これにより、IIS に対して直接加えられたすべての変更が上書きされます。このプロセスの影響により、管理者が直接 IIS メタベースに変更 (統合認証の設定など) を加えた場合に、そのソリューションが成功したように見えますが、次回の DS2MB レプリケーション サイクルが始まると問題が発生します。
ESM によって直接 Active Directory に対する編集が行われ、変更が IIS メタベースにレプリケートされるため、HTTP 仮想ディレクトリの統合 Windows 認証を有効にするオプションが ESM で使用できるようになりました。システム アテンダント サービスを停止すると DS2MB プロセスも停止し、IIS メタベースに変更を加えてもその変更が上書きされないようにすることができますが、この方法はお勧めしません。システム アテンダントの次回起動時に、システム アテンダントから Active Directory に変更がポーリングされるので、このソリューションは自動的に無効になります。
[委任] タブには、[Kerberos のみを使う] と [任意の認証プロトコルを使う] というオプションが表示されます。ここで説明しているソリューションでは、Kerberos の制約付き委任を使用しているので、単純に考えると [Kerberos のみを使う] を選択すればよいことになりますが、IT の状況はさまざまで、共通の論理は当てはまりません。そのため、[任意の認証プロトコルを使う] を選択します (図 7 参照)。これは、要求は Kerberos 要求としてではなく、Active Directory アカウントにマップされた対応する証明書を備えた HTTP 要求として着信するためです。
図 7 スマート カードの正しい認証設定
図 7 スマート カードの正しい認証設定
この場合、ISA Server は SSL 経由で ユーザー PKI 証明書を要求します。着信要求は Kerberos チケットではないため、Kerberos の制約付き委任が正常に機能するには、遷移が行われる必要があります。そのため、[Kerberos のみを使う] を指定すると、ISA Server で通信のチェーンが途切れます。ただし、Exchange フロントエンド サーバーは ISA Server から Kerberos チケットのみを受信するため、Exchange のフロントエンド サーバーからバックエンド サーバーへの委任では [Kerberos のみを使う] オプションが機能します。
仮想ディレクトリ \Exchange と \Public のみが、プライベート ユーザー情報とパブリック フォルダ情報を含む場所です。Exchange の SSL 構成は、Kerberos の制約付き委任または 2 要素認証にとって新たに必要になるものではなく、基本認証の資格情報を使用する標準の SSL 対応の OWA から持ち越されます。不適切な SSL を使用すると OWA だけではなく、ESM にも問題が発生する原因にもなるので、ドキュメントに記載された方法に従って OWA で SSL を有効にしてください。

構成のその他の詳細
このソリューションを実装する場合、最初に標準の方法で ISA Server と Exchange を展開する方がより簡単です。すべての設定が構成済みの完全な Kerberos の制約付き委任ソリューションを展開しないでください (ISA Server をまだ展開していない場合に特にこのことが当てはまります)。このような展開では、トラブルシューティング プロセスが複雑になり、プロセスの手順が失敗します。ISA Server と Exchange を標準の方法 (ユーザー名とパスワードを使用しますが、フォームベースの認証は使用しません) で展開する方がはるかに容易であり、インストールが正常に機能し、Kerberos の制約付き委任と証明書認証への遷移が確実になります。
通常、スマート カード対応の OWA にはフォームベースの認証を使用できません。フォーム ベースの認証は、ユーザーが、標準の Outlook フォーム経由で送信するユーザー名とパスワードを所持していることを示します。しかし、スマート カード ベースの 2 要素認証では、ユーザーはスマート カードのみを所持し、パスワードは所持しません。そのため、フォームベースの認証には、認証用の証明書のみを授受する方法がありません。認証チェーンのどこか (たとえば、ISA Server の背後のフロントエンド サーバー上) でフォームベースの承認を使用すると、スマート カード対応の OWA 構成は機能しません。フォーム ベースの認証を有効にすると、Exchange 仮想ディレクトリが強制的に基本認証に設定されるため、IIS メタベースも同様に基本認証に設定されます。
ユーザー名およびパスワードと、スマート カードの両方を混在使用するユーザーが存在する場合は、ISA Web リスナでフォールバック認証を有効にできます。この場合、証明書ベースの資格情報を求められた後にユーザーが Esc キーを押すと、Exchange サーバー上の ISA Server の背後で統合認証を有効にしている場合でも、標準のユーザー名とパスワードの資格情報の入力が求められます。さらに、ISA Server は、フォームベースの認証機能とほぼ同じ方法で SSL セッションをタイムアウトできます。

まとめ
OWA の認証でスマート カードがサポートされることは、Exchange Server 2003 と Exchange Server 2007 の両方にとって歓迎すべき機能追加です。証明書を使用して OWA にログオンする機能により、ユーザーは長くて複雑なパスワードを覚えることに悩む必要がなくなり、管理者は、キー ロガーや、侵害されたシステムからユーザー証明書を盗聴できるその他の形式のマルウェアに対して有効な手段を持つことになります。詳細については、「詳細情報」を参照してください。
スマート カードによる 2 要素認証用に ISA Server を適切に構成すると、公開された OWA アプリケーションに対してアプリケーション レベルのフィルタ処理を実行することにより、全体のセキュリティがさらに向上します。また、ISA Server 2006 には簡単な公開ウィザードを使用して Exchange Server 2003 と Exchange Server 2007 の両方を公開する組み込みサポートが用意されているため、組織が Exchange Server 2007 に移行する際にも健全な投資といえます。
詳細情報
  • Outlook Web Access for Exchange Server 2003 の "安全な HTML" フィルタ機能によって削除されるファイルを共有する方法
  • Kerberos 委任のトラブルシューティング
  • メタベース更新サービス
  • ISA Server 2006 での認証
  • Kerberos プロトコル遷移と制約付き委任
  • TechNet Webcast: スマート カードを使用した多要素認証の実装

Victor Akinnagbeは、ワシントン D.C. の Microsoft に勤務するプレミア フィールド エンジニアです。主な担当分野は、セキュリティ、インフラストラクチャ、およびメッセージングです。
Ted Dresselは、ワシントン D.C. の Microsoft に勤務するコンサルタントです。主な担当分野は、セキュリティおよびインフラストラクチャです。
Jason Opdyckeは、シャーロットの Microsoft に勤務するプレミア フィールド エンジニアです。主な担当分野は、セキュリティおよびインフラストラクチャです。


 Windows の管理: Windows Vista の ActiveX インストーラ サービス
Windows の管理 Rob Campbell and Joel Yoker

Windows Vista の ActiveX インストーラ サービス
概要:
  • ActiveX コントロールに関する一般的な課題
  • ActiveX コントロールのインストール方法
  • 危険なアクセス許可
  • Windows Vista でのより安全な処理

いつも決まってそうなのですが、セキュリティを大幅に強化するには、自由や柔軟性をある程度犠牲にしなければなりません。お使いの環境が多くの組織と同様なら、セキュリティが確保されたコンピューティング環境をエンド ユーザーに提供するために、デスクトップ オペレーティング システムを強化したいという非常に強い要望を
お持ちでしょう。通常、IT 管理者は、デスクトップのセキュリティを確保するという課題に取り組む場合、セキュリティ ポリシー設定、ユーザーのアクセス許可、ファイルとレジストリのアクセス制御リスト (ACL)、およびシステム サービスの制限を組み合わせて利用します。
セキュリティが確保されたデスクトップ環境を構築する上での一般的な問題の 1 つが、お使いの環境でアプリケーションの互換性を適切なレベルに保ったまま、悪意のある ActiveX® コントロールに関連する脅威を軽減するにはどうすればよいかということです。これは何年もの間、デスクトップ オペレーティング システムに関する課題でした。さいわい、Windows Vista™ で導入された ActiveX インストーラ サービス (AxIS) が、企業環境での ActiveX コントロールの管理固有の問題に対処します。AxIS には、標準ユーザー (通常、ActiveX コントロールのインストールを許可されていません) が承認済み Web サイトから ActiveX コントロールをインストールするための、簡単で管理しやすい方法が用意されています。AxIS はグループ ポリシーで制御されるため、IT 管理者は、ユーザーのアクセス許可に関係なく、ユーザーがインストールできるコントロールを決定できます。
この記事では、ActiveX コントロールに関連する管理上の課題、以前のバージョンの Windows® ではこうした課題への対処がどのように行われていたか、および Windows Vista の AxIS ではどのようにして独自の効率的な ActiveX コントロールのインストールの管理方法を提供するかについて説明します。

ActiveX コントロールとは
ActiveX コントロールは、ユーザーが Internet Explorer® 経由でインストールし実行する、実行可能なコード (通常、キャビネット ファイルにパッケージ化された OCX ファイル) です。Web 開発者は、標準の HTML や単純なスクリプトでは簡単に実現できない機能を Web アプリケーションに追加するために、ActiveX コントロールを作成します。
ActiveX コントロールの重要な特性は、"ダウンロードして実行する" という単純な展開モデルにあります。ActiveX コントロールのインストールと実行は、HTML オブジェクト タグで行われます。このタグには CODEBASE という属性があり、ユーザーのコンピュータにコントロールがまだインストールされていない場合に、(URL を使用して) Internet Explorer にコントロールの取得先を通知します。これにより、関連するインストール パッケージがダウンロードされ、オブジェクトの信頼性検証が行われ、ユーザーにインストールの許可を問い合わせるメッセージが Internet Explorer の情報バーに表示されます (図 1 参照)。インストール時に、表示中のページによってコントロールが登録され実行されます。いったんインストールされれば、すべての標準ユーザーがこのコントロールを実行できるようになります。この、配布と実行の単純なメカニズムにより、開発者には Web アプリケーションのユーザーにコンポーネントを配布する簡単な方法が提供されます。この配布方法の問題点は、インストールを完了するには管理者特権が必要になるため、標準ユーザーが ActiveX コントロールを直接インストールすることができない点にあります。
図 1 ActiveX コントロールのインストールについての情報バー
図 1 ActiveX コントロールのインストールについての情報バー
Internet Explorer 4.0 で ActiveX コントロールが初めて導入されたときは、インターネットは今よりずっと友好的な場所だと考えられていました。現在では、Web 経由で配布される実行可能なコードが深刻な脅威を意味するようになってきました。そのため、Windows では、ローカル管理者権限のあるユーザーのみが、しかも、ポリシー設定に従ってインストールが承認されている場合にだけ、ActiveX コントロールをインストールできるようにしています。管理者がいったん ActiveX コントロールをインストールすれば、システムのすべてのユーザーがそれを実行できます。この動作は、Windows のファイルとレジストリの ACL のセットによって容易になります。これにより、標準ユーザーによる ActiveX コントロールのインストールは防止されますが、ActiveX コントロールをインストールするローカル管理者と (既定のアクセス許可を変更した) 標準ユーザーへのリスクは軽減されません。
Windows の既定の保護 (管理者特権のあるユーザーだけにインストールの実行を許可する) は、個人レベルでは ActiveX コントロールに対処されますが、大規模組織全体で ActiveX コントロールを管理する方法には対応していません。企業環境での一般的な課題は、信頼されていない外部コントロールによってもたらされる潜在的脅威を軽減しながら、IT 組織が信頼している ActiveX コントロールの使用を許可するには、どうすればよいかということです。結局、特定の ActiveX コントロールをインストールするかどうかの決定は、良くも悪くも、多くの場合、権限に応じて個々のユーザーに一任されてしまいます。脅威に対抗するために、すべての ActiveX コントロールをブロックする組織もあれば、エンド ユーザーによるインストールを許可し、すべてのマルウェアのインストールを管理しようとする組織もあります。
悪意のあるコントロールのインストールを防ぐには、標準ユーザーの権限の制限を徹底し、必要なコントロールを IT 管理者がデスクトップ プラットフォームにすべてプレインストールしておくという方法もあります。この方法は、使用する ActiveX コントロールが変更されることが本質的に比較的少なく、定期的なリリース プロセスとデスクトップ更新の併用によって変更が管理される場合、または組織で Systems Management Server などのソフトウェア配布メカニズムを使用している場合に効果があります。しかし、継続的な管理、社内アプリケーション開発者の刻々と変化するニーズ、外部コントロールへの依存などが、引き続き、こうしたアプローチの課題として残るでしょう。
ユーザーに管理者特権があると問題は異なってきます。こうしたユーザーによる承認されていないコントロールのインストールを防止することが必要になります。このような場合、ユーザーには管理者特権があるため、エンド ユーザーに ActiveX コントロールをインストールする権限があると考えられます (エンド ユーザーをローカル管理者として運用する方法は、組織に高いリスクが生じる可能性があるため、ほとんどの企業環境にはお勧めしません)。
1 つの解決策は、承認済みコントロールをホストするインターネット コンポーネント ダウンロード サーバーを社内に用意することです。この解決策では、クライアントのレジストリ内の CodeBaseSearchPath 文字列を変更する必要があります。要求された HTML ページ内に CODEBASE 属性を含むオブジェクト タグが見つかると、通常、Windows クライアントは CodeBaseSearchPath データで指定された場所にリダイレクトされます。既定では、このレジストリ文字列には、CODEBASE キーワードと、ActiveX コントロール ギャラリーのインターネット URL を含みます。インターネット コンポーネント ダウンロード サーバーを実装するには、CodeBaseSearchPath 内の既定のデータを、組織が承認済みコントロールをホストする社内サーバーの URL に置き換える必要があります。前のアプローチと同様、この解決策でも継続的な管理が必要であり、ActiveX コントロール用に社内サーバーをホストするという、コストがかかる複雑な作業が必要になります。
他にも、Internet Explorer ゾーンの URLAction を変更する、管理者が承認済みコントロールをグループ ポリシーで指定する、すべてのコントロールのインストールをファイアウォール ルールによって境界でブロックするなどの解決策もあります。しかし、おわかりのように、これらすべての方法にはそれぞれ問題があり、多くは柔軟性に欠けるため、やがて廃止されます。さらに悪いことに、これらの解決策の中には、ユーザーに管理者権限が必要なものもあります。結局、こうした解決策では、ActiveX コントロールの発行元、呼び出し元などを制御する (またはブロックする) など、問題の一部に対処しようとしていますが、管理者権限のないユーザーが ActiveX コントロールをインストールできないという根本的な問題は軽減されません。

AxIS で可能な作業
企業管理者は Windows Vista の AxIS を使用して、ユーザーを既定のファイル システム設定を持つ標準ユーザーとして実行させることで、強力なセキュリティ体制を維持したまま ActiveX コントロールを管理することができます。AxIS には、ActiveX コントロールの信頼できる発行元を構成するためのグループ ポリシー オプション、およびこれらの信頼できる発行元から標準ユーザーに代わってコントロールをインストールする仲介プロセスがあります。主なメリットは、管理制御を一元的に行うと同時に、管理以外のセキュリティ体制をユーザーのワークステーションでメンテナンスできることです。AxIS では、ActiveX コントロールの信頼できる発行元 (通常、インターネットまたはイントラネットの URL) の特定は IT 管理者が行います。オブジェクト タグから Internet Explorer にコントロールの実行指示が出ると、AxIS によって次の手順が実行されます。
  1. コントロールがインストールされているかどうかチェックします。インストールされていなければ、使用前にインストールする必要があります。
  2. コントロールが信頼できる発行元からのものかどうか確認するために、AxIS のポリシー設定をチェックします。特定チェックで、オブジェクト タグの CODEBASE 属性で指定された URL のホスト名を、ポリシーで指定された信頼できる場所の一覧と照合します。
  3. ユーザーに代わって、コントロールのダウンロードとインストールを行います。
発行元 URL のホスト名が AxIS のポリシー設定の一覧にない場合は、通常のユーザー アカウント制御 (UAC) プロンプトが起動され、インストールを完了するために管理者権限が要求されます。また、AxInstallService をソースとする ID 4097 のイベントがアプリケーション イベント ログに記録され、試行された ActiveX コントロールのインストールの概要とコントロールの具体的なダウンロード パスが示されます。4097 イベントの例を図 2 に示します。企業管理者は、このイベント ログ エントリのデータを使用してグループ ポリシーを変更でき、次にその Web サイトにアクセスする際に AxIS によってコントロールをインストールできるようになります。
図 2 4097 AxInstallService イベント
図 2 4097 AxInstallService イベント
AxIS は、Windows Vista Business、Enterprise、および Ultimate の各 SKU に付属するオプション コンポーネントで、無人オプションまたは [Windows の機能] ダイアログ ボックス (コントロール パネルで、[プログラム]、[プログラムと機能]、[Windows の機能の有効化または無効化] の順にクリック) を使用して有効にすることができます (図 3 参照)。一度有効にすれば、Internet Explorer からコントロールが要求されるたびに上記の手順が実行されます。
図 3 コントロール パネルで AxIS を有効にする
図 3 コントロール パネルで AxIS を有効にする
Windows Vista では、タスクをイベントに添付できるので、管理者は、ActiveX コントロールのインストールがブロックされる際などに AxIS サービスから簡単に通知を受け取ることができます。必ずしも、エンド ユーザーが各自の Web サイトからアクセスしているのと同じ URL ホスト名から ActiveX コントロールがインストールされるとは限らないことに注意が必要です。このため、AxInstallService 4097 (試行されたインストール) イベントによって提供される情報は、コントロールのインストールがどのホストから試みられたかを特定するのに非常に役立つことがあります。
イベントから提供される情報を使用して、グループ ポリシー内の信頼できる場所を構成することができます。ローカル ポリシーまたはグループ ポリシー内の AxIS 設定は、[コンピュータの構成] の設定にあります (図 4 参照)。“ActiveX コントロールの承認されたインストール サイト” のポリシー設定で、信頼できる場所のホスト URL を指定することができます (図 5 参照)。承認されたサイトの設定には、ActiveX コントロールのインストール元となる可能性のある場所、およびインストールの動作という 2 つの情報が必要です。
図 4 グループ ポリシー オブジェクト エディタの設定
図 4 グループ ポリシー オブジェクト エディタの設定
図 5 AxIS によって承認されたインストール サイト
図 5 AxIS によって承認されたインストール サイト
1 つは、前述のように、コントロールの信頼できる場所を示すホスト URL です。従来の解決策では、コントロールの CLSID (開発者がコントロールを改訂すると頻繁に変更されます) を認識している必要がありましたが、AxIS ではこうした解決策とは異なり、信頼できる場所からすべてのコントロールをインストールすることができ、全体的な管理上の負担が軽減されます。もう 1 つの情報は、4 つの値をコンマで区切った文字列で、それぞれの値が ActiveX コントロールのダウンロード エクスペリエンスの動作を指定します。これらの値は、TPSSignedControl、SignedControl、UnsignedControl、ServerCertificatePolicy という 4 つのプロパティを指定します。最初の 2 つのプロパティ (TPSSignedControl と SignedControl) には、0、1、2 のいずれかの値を指定できます。これらの値は、URLAction の設定値と似ています。値が 0 の場合はコントロールのインストールは禁止され、値が 1 の場合はユーザーにインストールの許可を求めるメッセージが表示され、値が 2 の場合はユーザーに代わってコントロールがサイレントにインストールされます。未署名のコントロールはサイレントにインストールできないので、UnsignedControl の値には 0 か 1 しか指定できません。ポリシーが指定されていない場合、既定値の 2、1、0 が使用されます。
最後のプロパティは、署名済みコントロールの証明書の設定を基に、インストールの動作を指定します。ほとんどの SSL サイトと同様、証明書が有効であることを保証するためには、その証明書が一連のセキュリティ テストに合格する必要があります。現実の署名済み ActiveX コントロールの実装では、証明書のプロパティが無効になっていることがあります。管理者は AxIS を構成することで、証明書から提示されることのある無効な情報を URL 単位で軽減することができます。最後のプロパティは、図 6 に示す、値のビットマスクの組み合わせとして表されます。
Figure 6 ServerCertificatePolicy (Close Figure 6)

値 | 定義
0x00001000 | 証明書内の無効な正規名 (CN) を無視します。
0x00000100 | 不明な証明機関を無視します。
0x00002000 | 無効な証明書日付を無視します。
0x00000200 | 誤った証明書の使用法を無視します。
既定の設定は 0 であり、AxIS によってインストールが完了する前に、すべてのセキュリティ チェックに合格する必要があることを意味します。ホストの設定とこれらの 4 つの値の組み合わせは、ポリシー設定で指定されます (図 7 参照)。
図 7 承認された AxIS ホスト URL
図 7 承認された AxIS ホスト URL

まとめ
AxIS を使用すると、管理者特権や複雑な構成なしでユーザーがインストールできる ActiveX コントロールを制御するように、グループ ポリシーを構成できます。このレベルの制御は、以前のバージョンの Windows では困難な場合があり、また従来から使用できる解決策には、多くの場合、深刻な制限や管理オーバーヘッドの増加が伴いました。AxIS では、デスクトップ システムのエンド ユーザーの権限に対して最小特権アプローチをとるためのさらなるツールを組織に提供し、エンド ユーザーに管理者特権が必要ない、標準ユーザー モデルの実装を可能にします。Windows Vista を使用すると、企業環境内で信頼する ActiveX コントロールをエンド ユーザーではなく組織が決定し、選択できることにより、IT 管理者が再び主導権を握ることができます。

Rob Campbell は、マイクロソフトの連邦政府チームのシニア テクニカル スペシャリストです。米国連邦政府の顧客向けにセキュリティ ソリューションを開発し展開することを専門としています。
Joel Yoker は、マイクロソフトの連邦政府チームのシニア コンサルタントです。米国連邦政府の顧客向けにセキュリティ ソリューションを開発し展開することを専門としています。


 編集者から: 第 6 レベル
編集者から
第 6 レベル
Joshua Trupin

ちょっと孤独だなと感じたことはありますか。 オフィスに 1 人で座り込んで、気分がどうしようもなく落ち込み、世の中に自分しかいないのではないかと悩んだことはありませんか。いや、本当にだれもいないのでしょうか。そんなことはないでしょう。特に私のように受信トレイがいつもいっぱいの人は。
それにもかかわらず、私は最近このような辛さを経験し、自分から連絡を取る必要があるのだと決意しました。まずは、多数あるビジネス中心のソーシャル ネットワーク サイトの 1 つにサインアップして、これまでに一緒に仕事をしたことがある人、記事をいただいた人、カンファレンスで話をした人など、出会ったすべての人を追加していきました。1 週間もしないうちに、私のリストに含まれている連絡先は 58 件になりました。すばらしいことです。
しかし、これは第 1 レベルに過ぎませんでした。第 2 レベルは知り合いの知り合いです。知り合いの知り合いを追加したら、友達の人数が 3,500 人を超えました。そして、3,500 件の連絡先の人が各自の連絡先を持っているので、私のリスト内の連絡先は、あっという間に 277,000 件に膨れ上がりました。これは第 3 レベルの連絡先といえます。ここで、Excel ワークシートを使ってすばやく計算してみたところ、1 人あたり平均 50 件の連絡先を持っていることが想定されます。これにより、第 6 レベルの連絡先では 340 億人を超えることがわかります。これは、ケヴィン ベーコン (アメリカの俳優) に勝る顔の広さです。私の知り合いは地球の人口よりも多いということになります。突然、落ち込んだ気分が満たされました。
しかし、このことが新しい問題を引き起こしました。これらすべての人とうまくやっていくにはどうすればいいのでしょうか。どんな意見でもお待ちしています。現在ソーシャル ネットワーク サイトやビジネス ネットワーク サイトを使用していますか。付き合いたい人と避けたい人を区別するにはどうすればよいですか。TechNet Magazine のブログにアクセスして、この重要な問題について皆さんの考えをお聞かせください。
この Web 2.0 ネットワーク全体に皆さんが詳しくなくても、心配はいりません。今月号の TechNet Magazine は、Exchange Server をもっと有効に使用することによって通信を強化するのに役立ちます。組織のメッセージング範囲を広げるために必要な知識が記載されている 5 つの記事が含まれています。
今月号の特集に含まれているトピックの 1 つは、Outlook Web Access でスマート カード認証を使用することです。会社のリソースに対するアクセス権を与える前に物理的な認証形式を要求することをお勧めします。スマート カードを使用すれば、どこからでも認証を行うことができます。また、Exchange Server を使用した障害回復、Exchange Server 2007 のパブリック フォルダを SharePoint に置き換える方法、Windows Mobile 6 を使用してモバイル セキュリティを強化する方法についても見ていきます。もちろん、Exchange Queue & A もあるので、メッセージングに関する情報を入手する場合は、これをお気に入りのコラムにすべきです。おっと、私のネットワークに新たに 3 人がやってきました。「こんにちは」と声をかけるべきでしょうか、それとも寝たふりをすべきでしょうか。
—Joshua Trupin

次のマイクロソフト技術支援スタッフに心より感謝します。Kristian Andaker、Chris Corio、Jim Harrison、Chad Jones、Michael Lee、Shawn McGrath、Michael Murgolo、Eric Perlin、Michelle Rutzer、Gavriella Schuster、Jim Truher


 ツールボックス: IT プロのための新製品
ツールボックス
IT プロのための新製品
Greg Steen

リモート接続を監視する
RecordTS
www.tsfactory.com
ターミナル サーバーやリモート デスクトップ セッションを監視したいと思ったことはありますか。リモート デスクトップ セッションによって Web サイトが削除されたように見えたとき、その前に何が起こったのか知りたくはないですか。ターミナル サーバーにどうしても再現できない問題があるのかもしれないし、知的財産のセキュリティを心配しているのかもしれません。そうではなく、テスト環境に SharePoint® サーバーをどのように構成したかについて簡単なログやプレゼンテーションを作成することが必要になることもあり得るでしょう。このようなシナリオを耳にしたことがあるなら、TSFactory の RecordTS をチェックしてみてください (TSFactory は、ターミナル サービスの Microsoft MVP である Cláudio Rodrigues 氏によって作成されました)。
RecordTS には 2 つのエディション Terminal Server と Remote Desktop があります。自分にふさわしいエディションは、監視する接続の種類によって異なります。製品 Web サイトによると、RecordTS はターミナル サーバーやリモート デスクトップ セッションに対する "セキュリティ カメラ" として機能します。このソフトウェアは、基本的にはターミナル サービスとエンド ユーザー セッション間のプロキシとして機能するため、セッションで行われるすべての動作と操作を記録できます。
インストーラは直感的なウィザードであり、保存されたセッションを格納するデータ ディレクトリを指定します。このアプリケーションでは、MMC スナップイン (サービスの構成に使用)、RecordTS サービス、および記録されたセッションを監視するためのセッション再生ユーティリティがインストールされます。MMC スナップインを開いた後、サービス フォルダを右クリックすると、サービスを実行するポートなどの設定を構成できるプロパティ画面が表示されます (この設定は、ターミナル サービス セッションを非標準のポートに移した場合に役立ちます)。[Storage] (保存場所) タブでは、[Default Storage Folder] (既定の保存フォルダ) にローカル フォルダまたは UNC パスを設定できます。
また、格納されたセッションのディレクトリ構造も構成できます。たとえば、ドメイン、ユーザー、および日時を使用して、保存するデータを編成します。また、ディスク領域が不足した場合の対処方法をサービスに指定できます。おそらくこれがローカル ディスクにセッションを格納する場合の最も重要な設定でしょう。新しい接続を許可せずに現在のセッションを切断したり (セキュリティ意識が高い場合の選択肢)、セッションの記録を無効にしたり (生産性を下げたくない場合に必要なオプション) することができます。
[Security] (セキュリティ) タブでは、既存の証明書を選択するか自己署名入りの証明書を作成して、記録されたすべてのセッションにデジタル署名するかどうかを指定できます。これは、監査または責任の目的でツールを使用する予定がある場合に有効な設定です。[Users] (ユーザー) タブでは、セッションを記録しておく必要のあるユーザーや記録する必要のないユーザーを指定できます。
要するに、RecordTS は、セキュリティや監査のための有益なツールであり、操作方法のプレゼンテーションを記録するなど、その用途は多岐にわたります。このツールは重宝します。

価格 : RecordTS Remote Desktop Edition = 495 ドル～、RecordTS Terminal Services Edition = 995 ドル～

ホストの監視
Advanced Host Monitor
www.ks-soft.net
ミッション クリティカルなインフラストラクチャの運用をサポートする立場になった場合に、なくてはならない安眠剤として、信頼性の高い優れたホスト モニタがあります。単一障害点のない堅牢なハードウェア セットや、安定性と信頼性の高いアプリケーション スタックを持っていても、その予備システムの起動が必要なときに通知してくれるフル機能搭載のホスト モニタが欲しいところです。
KS-Soft 社の Advanced Host Monitor は、58 種類のテスト方法と 30 種類の警告方法が特長です。プロセス情報、ユーザー セッション、平均負荷、メモリなどの項目を確認できます。アプリケーションは、Windows® 固有のテスト、Linux または UNIX のテスト、およびプラットフォームに依存しないチェックを提供します。Linux または UNIX のテストでは、Windows のテストとは異なり、クライアントに Remote Monitoring Agent をインストールする必要があります。
Windows Management Instrumentation (WMI) の監視テストもあります。組み込みの WMI Explorer を使用して適切なクエリを参照できます。WMI Explorer を使用すると、適切な項目に移動してその項目を選択する操作を容易に行えるだけでなく、クエリを実行して必要なデータが表示されることも確認できます。
Advanced Host Monitor には、ODBC クエリ テストなど、データベース関連のテストも多数用意されています。こうしたテストでは、ODBC データ ソースの可用性を確認し、クエリを実行して、その結果を既知の値と照合します。また、ホストの機能を確認し、SQL Server™、MySQL、Oracle、Postgres、Sybase、および Interbase の各データベース サーバーへの着信セッションを許可することもできます。
空き領域、クォータ、フォルダ、またはファイルの可用性と、UNC 共有の可用性を把握するための、ディスクやファイル関連のテストも多数あります。さらに、標準的なネットワーク関連のテストとして、一般的な TCP/UDP チェック、メール テスト (SMTP、POP3、および IMAP 用)、メール中継チェック、HTTP のコンテンツとタイミングのテストなどがあります。また、モニタ テストの依存関係を作成し、チェックを連鎖的に行うこともできます。これは便利なオプションです。テストは、いわゆる定期的なスケジュールと不定期なスケジュールで設定することもできます。これにより、テスト パターンをかなり細かくすることができます。
警告方法には、SMS、ICQ、電子メール、イベント ログ、またはポップアップ ウィンドウにメッセージを送信するというものがあります。また、警告方法によって、サービスの開始や停止、コンピュータの再起動、外部プログラムの実行など、他のイベントをトリガすることもできます。
Advanced Host Monitor の Professional と Enterprise の両エディションには、KS-Soft 社の IP ツールが用意されています。このツールは、TCP/IP 関連の 19 個のネットワーク ユーティリティのセットであり、ポート スキャナやプロトコル スキャナ、SNMP トラップ メッセージを受信して処理できる SNMP トラップ監視機能などが含まれています。さらに、どちらのバージョンにも、ログ分析機能とレポート作成コンポーネントが搭載されているので、履歴監視データから稼働状況レポートを作成したりパフォーマンス分析調査を行ったりすることができます。
インターフェイス自体は、多数のテストの概要を同時に示すのに大変便利です。監視対象ホスト上にある問題を簡単に調べることができます。
価格 : Enterprise Edition = 599 ドル、Professional Edition = 275 ドル

ディスク クリーンアップ
WinDirStat
www.windirstat.info
家やアパートと同様に、ファイルの保存場所は、時間が経つにつれて散らかる傾向にあります。昔は必要だったものでも、今は貴重な場所をふさいでいるだけで不要になったものまで含まれているためです。ちょっとした大掃除でも役に立ちますが、家とは異なり、ディレクトリ ツリー構造では、どこから片付け始めればよいのか、はっきりと目に見える手がかりがありません。さいわいにも、環境内で場所を取っているファイルを確認するのに役立つ、優れた視覚化ツールがあります。
GPL プログラム WinDirStat は、Linux KDE kdirstat から発想を得た Windows ベースのツールで、選択したドライブ上のファイルをさまざまな色の正方形で示します。正方形のサイズはファイルのサイズを表します。これにより、不要な古い ISO ファイルや ZIP ファイルのうち、サイズの大きいものを簡単に見つけることができます。
ローカル ドライブ (または一連のローカル ドライブ) を選択すると、ディレクトリ ツリーがスキャンされ、メモリ内のファイルのマップが作成されます。その後、GUI の下部のペインにマップが視覚的に表示されます。下部のペインで色付きの正方形をクリックすると、Windows エクスプローラに似た上部のペインで、ファイルの場所に移動します。上部のペインには、ファイル サイズや、そのファイルの最終変更日などの属性を含む便利な統計が表示されます。さらに、サブツリーには対象のファイルが占める割合も表示されます。
すばらしいのは、ファイルの種類による色分け表示です。右上で検出されたファイルの種類をクリックすると、下部のペインで、その種類のすべてのファイルが強調表示されます。これは、ユーザーがファイル サーバー上に持っている非表示の MP3 をすべて特定する必要がある場合などに便利です。これらのファイルがパーティション上でどの程度の割合を占めているかを確認することもできます。
価格 : 無料ダウンロード

ブック レビュー
『Enemy at the Water Cooler』
syngress.oreilly.com
ほとんどすべての企業はインターネットへの接続を必要としています。そのため、常に存在する攻撃の危険を認識し、情報インフラストラクチャの "内部" と "外部" を切り分ける接続ポイントを構成しています。ところが、多くの企業は、組織内に存在する、危険性の高い潜在的な脅威を見落としてしまいます。いわゆる内部関係者による脅威の力は、Brian Contos の著書『Enemy at the Water Cooler: Real-Life Stories of Insider Threats and Enterprise Security Management Countermeasures』(2006 年、Syngress) で的確に説明されています。
Contos は、過去の攻撃とその攻撃が関連企業に与えた影響についての実話を提供しています。彼は、セキュリティは、"人間、プロセス、テクノロジが融合したもの" から成る進行中の過程であると主張しています。この書籍では、内部関係者による脅威を軽減するための、エンタープライズ セキュリティ管理 (ESM) ソフトウェア ソリューションの潜在的な力を示しています。
Contos は、ArcSight 社の最高セキュリティ責任者なので、自社の ESM ソフトウェア ソリューションを紹介することに重点を置いていますが、全体的な価値は損なわれていません。この書籍では、技術的な詳細は十分ではありませんが、他の組織がどこで失敗したのかを確認したり、内部攻撃に対するリスクを軽減するために効果的に実装した ESM ソリューションを使用して何ができるのかを把握したりすることで、ご自分の組織のセキュリティ プロセスのどこを強化すべきなのかを詳しく知ることができます。
予備知識の章にある「Cyber Crime and Cyber Criminals 101」では、認識すべきさまざまな攻撃者のタイプと動機の概要が示されています。また、バッファ オーバーフロー、コード パッキング、Warhol 型脅威など、攻撃者が使用する手法の概要も紹介されています。
次の章には、内部関係者が企業に被害を与える方法、リスク管理の概念、および技術的な観点から脅威に対処する方法など、内部関係者による脅威について詳しく説明されています。技術的な観点からは、最小特権、強力な認証、アクセス制御、および障害の検出と管理の概要が示されています。これは、ESM ソフトウェア ソリューションの説明へと続きます。ここでも、ArcSight 社の製品のみを扱う傾向が見られますが、主要な機能の概要はどのシステムにも当てはまります。
この書籍では、業界や環境を代表する多くの事例を紹介しています。その中で、内部関係者によるさまざまな種類の脅威や、その脅威がどのように検出 (場合によっては軽減) されたかを詳しく説明しています。このようなケース スタディにより、独自のビジネス慣行についてのヒントを得られる場合があります。また、ご自身の環境で内部関係者による攻撃のリスクを軽減するためのソリューションを提供できるかもしれません。
価格 : 49.95 ドル

ツールボックスにご意見、ご要望をお送りください。
ここで取り上げてほしいおすすめのツールやユーティリティがございましたら筆者 tntools@microsoft.com まで英語でご連絡ください。

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


 SQL に関する Q&amp;A: クラスタリングの詳細、不可解なハング、SA アカウントなど
SQL に関する Q&A
クラスタリングの詳細、不可解なハング、SA アカウントなど
Nancy Michell

質問 - クラスタリングのしくみについて詳しく理解する必要があります。使用する環境は、SQL Server™ 2005 を実行する 64 ビットの Windows Server® 2003、SQL Server Reporting Services (SSRS) Web ファーム (レポート サーバー スケールアウト展開)、SSRS TempDB カタログ サーバー、およびリンク サーバー経由でサードパーティのデータベースからデータを取得し、そのデータを SSRS 用に保存する SQL Server という構成です。
3 ノード クラスタ (アクティブ/アクティブ/パッシブ) を考えています。ノード 1 はアクティブとし、ここにはサードパーティのデータベースから取得したデータを保存します。ノード 2 もアクティブとし、ここには SSRS カタログを保存します。ノード 3 はパッシブとし、ノード 1 またはノード 2 のいずれかをフェールオーバーします。どうすればよいでしょうか。

回答 - 残念ながら、SQL Server のクラスタリングに関して、アクティブ/アクティブ、およびアクティブ/パッシブという表現に惑わされている人が多すぎます。こうした人々は、SQL のクラスタリングでは、複数のサーバー間での、1 つのデータベースや 1 つの SQL インスタンスの "スケールアウト" がサポートされているだろうと考えています。これは間違いです。SQL Server では、アクティブ/アクティブのデータベースやインスタンスというものは存在しません。"インスタンス" とは、対応するデータベースを保持する SQL Server の 1 つのインストールです。SQL Server インスタンスごとのクラスタリングは、常にアクティブ (1) に対してパッシブ (n) です (n の値は 1 ～ 7 で、使用している SQL Server のバージョンによって異なります)。これが、フェールオーバー クラスタリングと呼ばれる理由です。
このことを理解すれば、フェールオーバー クラスタリングのインスタンスを一連のノードに複数インストールすることを検討できるようになります。たとえば、3 台の物理サーバーがすべて共有ディスクを使用している場合は、既定でアクティブになっているインスタンスをノード 1 に 1 つ保持し、既定でアクティブになっている 2 つ目のインスタンスをノード 2 に 1 つ保持することができ、どちらもノード 3 にフェールオーバーすることができます。各インスタンスは完全に独立しており、データを共有することもなく、アクティブ/アクティブではありません。これらはどちらもアクティブ/パッシブで、どちらも同じフェールオーバー インスタンスを共有します。両方のインスタンスがノード 3 にフェールオーバーされるとすると、長期的な課題は、ノード 3 が負荷に耐えられるかどうかを把握することです。仕様では、フェールオーバーは、等しい処理能力があることが前提です。通常運用での処理ピーク時の負荷に 2 つのノードが必要だとすると、通常は 2 つのノードに割り当てられているピーク時の負荷にノード 3 が耐えられる可能性はあまりありません。
とは言うものの、クラスタを実行できるハードウェアの相対的なコストを考えると、両方のプリンシパル ノードで同時に障害が発生し、全体の負荷が 1 つのノードにかかる可能性が一般的にどの程度重視されるかはわかります。この点を考えると、100% のフェールオーバー能力を手に入れるのではなく、ある程度のリスクを見込むというビジネス上の決断を下すことになるかもしれません。
さいわい、良いニュースがあります。SQL Server 2005 では、高可用性 (HA) を実現する選択肢を数多く提供しており、クラスタよりも迅速にフェールオーバーすることができる方法や、データの重複コピーも可能な方法などがあります (クラスタリングは単一の SAN に依存します)。こうした選択肢には、ミラーリング、ピア ツー ピア レプリケーションなどがあります。このような新しい方法の登場によって、あらゆる種類のニーズを満たす選択肢が大幅に増えました (いくつかの HA 機能を組み合わせることもできます)。
ダウンロード可能になった Microsoft® Cluster Configuration Validation Wizard (ClusPrep) は、以前のハードウェア互換リスト (HCL) テストに代わるものです。HCL テストでは、クラスタリングに "耐えられる" と判断するための構成全体の検証に、数か月かかることもありました。ClusPrep により、DBA がハードウェア検証ツールを使用できるので、認定済みのハードウェアを用意するのにかかる費用と時間が大幅に削減されます。ClusPrep を使用すると、1 つのクラスタ ノード セット内で異種ハードウェアを検証し展開することさえ可能になる場合があります。

質問 - 使用しているコンピュータのうち 1 台で、delete プロシージャを実行すると 12 時間後にハングするようです。ブロックはされていません。最も遅いクエリ プランを確認すると、87,327 秒間実行されているトリガが見つかるので、プロシージャはこのトリガ内でハングしていると思われます。どのステートメントがハングしているかを正確に確認するにはどうしたらよいでしょうか。

回答 - さまざまな理由により、トリガ内のループが終了していない可能性が大いにあります。長時間ハングしており、どのステートメントが実行されているかを確認する必要がある場合は、図 1 のコードを実行してください。このコードを実行すると、現在実行中のステートメントを把握できます。これがおそらくコンピュータでハングが発生する原因となっているステートメントです。
Figure 1 現在実行中のステートメントを検索する (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

質問 - ファイアウォール越しのトランザクション レプリケーションをサポートする必要があります。パブリッシャとディストリビュータはファイアウォールの外側にあり、サブスクライバは内側にあります。サブスクライバは 1433 でリッスンするように設定しています。コンピュータ名は、パブリッシャが PUBMACHINE、ディストリビュータが DISTMACHINE、サブスクライバが SUBMACHINE です。初期スナップショットとプッシュ パブリケーションを成功させるには、どのポートを開く必要がありますか。

回答 - プッシュ サブスクリプションを使用している場合は、ディストリビューション エージェントは、(ファイアウォールの外側にある) ディストリビュータ コンピュータで実行され、スナップショット エージェントによって生成されたスナップショット ファイルにローカルにアクセスできるため、SQL Server ポート (今回の場合は 1433) を開くだけで十分です。しかし、プル サブスクリプションを使用している場合は、サブスクライバ コンピュータで実行されているディストリビューション エージェントは、何らかの方法でファイアウォール越しにスナップショット ファイルにアクセスする必要があります。以下の選択肢を検討することができます。
ファイアウォールの外側にあるファイル共有のスナップショット ファイルに既にアクセスできるとすると、ファイアウォールで Windows® ファイル共有ポートを開いて、ファイアウォールの内側で実行されているディストリビューション エージェントが、外側にあるスナップショット ファイルにアクセスできるようにすることができます (ただし、これによって発生し得る、インフラストラクチャの他の部分へのセキュリティ面での影響に注意してください)。既定のスナップショットの場所としてローカル パスを構成した場合 (SSMS の既定値) は、スナップショット ファイルの取得場所をオーバーライドするために、ディストリビューション エージェントの /AltSnapshotFolder オプションの使用が必要になることがあります。
また、スナップショット ファイルの転送に FTP を使用するようにレプリケーションを構成することもできます (この場合はポート 21 を開く必要があります)。

質問 - SQL Server 2005 で SA アカウントを無効にすると不都合があるかどうか、また SA アカウントを無効にすることによって真のセキュリティ価値がもたらされるかどうかを知りたいと考えています。この問題に関するホワイト ペーパーはありますか。

回答 - 混合モードが有効になっていない場合、SQL Server 2005 を新しくインストールすると、SA アカウントは既定で無効になり、このアカウント用にランダム パスワードが生成されます。自分で無効にすることもできます。これに関するホワイト ペーパーはありませんが、ログインの無効化と名前変更については、ベスト プラクティスのホワイト ペーパーで説明されています。
SA アカウントを不正利用しようとする試みを防ぐために、名前を変更することもできます。無効にしたアカウントを有効にする場合、そのアカウントに新しいパスワードを設定する必要があることを覚えておいてください。
これによって真のセキュリティがもたらされるかどうかという質問の答えとしては、アカウントを無効にすることによってセキュリティが向上するのは、アカウントが無効になっている間はパスワードの推測が無意味であるという点を思い出してください。ハッカーやウイルスが何度試みても、ロックされているアカウントに対するブルート フォース攻撃は成功しません。SA の名前変更や無効化を行うと、接続に SA アカウントを使用しているアプリケーションは機能しなくなります。このようなアプリケーションを見つけて、修正または排除することは、何よりの優先事項と考えてください。既に説明したように、再び有効にするまではそのアカウントをデータベースへの接続に使用できません。また、早い段階で認証プロセスが失敗するため、システムが攻撃を受けた場合でも、攻撃が失敗するまでの被害が少なくて済みます。

質問 - 大規模オンライン トランザクション処理 (OLTP) データベースの 1 つに、データ ファイルの 2 倍のサイズのログ ファイルがあります。ログ ファイルを適切なサイズまで小さくするため、以下のコマンドを使ってみましたが、さらにサイズを小さくする必要があります。
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

回答 - backup database ステートメントを backup log ステートメントに変更してください。または、データベースを単純復旧モードにして、shrinkfile ステートメントを発行することもできます。ログの圧縮が完了したら、データベースを以前の復旧モデルの設定に戻し、データベースをバックアップします。それでも圧縮されなかったら、開いているトランザクションがないことを確認します (dbcc opentran を使用します)。詳細については、サポート技術情報の資料 (support.microsoft.com/kb/907511) を参照してください。

質問 - SQL Server エージェントの定期ジョブの実行中にフェールオーバーが発生した場合、フェールオーバー後にそのジョブはどうなりますか。手動でジョブを再開する必要はありますか。

回答 - はい。他のプロセスを用意していない場合は、手動で開始する必要があります。手動でジョブを再開する必要をなくすために、ジョブの完了時にテーブルを更新するスクリプトを記述できます。値が 1 の場合は、ジョブの実行が完了しています。その他の値の場合は、ジョブの実行が完了しておらず、後で 2 つ目のジョブが開始コマンドを発行することを示します。したがって、ジョブの実行中にフェールオーバーが発生した場合、そのジョブを再実行する必要がありますが、このスクリプトを記述することにより、翌営業日までに絶対に完了している必要のある、夜中に実行される重大なジョブに関する懸念をある程度軽減することができます。
ヒント : アップグレードと DBCC UPDATEUSAGE
SQL Server 2000 から SQL Server 2005 にアップグレードする予定はありますか。
その場合、データベースのアップグレード直後に DBCC UPDATEUSAGE を実行してください。
DBCC UPDATEUSAGE を実行すると、カタログ ビュー内のページ数と行数の誤りが報告および修正されます。このような誤りがあると、sp_spaceused システム ストアド プロシージャから間違った使用領域レポートが返される場合があるので、このような誤りは修正する必要があります。SQL Server 2005 では、これらの値が常に正しく保たれるので、これらのデータベースでは間違った数になることはありません。ただし、SQL Server 2005 にアップグレードしたデータベースには無効な数が含まれている場合があるため、アップグレード後に DBCC UPDATEUSAGE を実行する必要があります。
ここで、DBCC UPDATEUSAGE の動作について説明します。DBCC UPDATEUSAGE を実行すると、テーブル内またはインデックス内のパーティションごとに、行数、使用ページ数、予約ページ数、リーフ ページ数、およびデータ ページ数が修正されます。システム テーブルに誤りがなければ、データは返されません。誤りが検出および修正され、かつ、WITH NO_INFOMSGS を使用しなかった場合、システム テーブル内の更新された行と列が返されます。
DBCC UPDATEUSAGE は、使用領域カウンタの同期にも使用することができます。DBCC UPDATEUSAGE は、大規模テーブルやデータベースに対して実行すると少し時間がかかる場合があるので、通常、sp_spaceused から間違った値が返されている疑いがある場合のみに使用します。sp_spaceused にオプション パラメータを指定して、テーブルやインデックスの領域情報を返す前に DBCC UPDATEUSAGE を実行することもできます。
SQL Server 2005 では DBCC CHECKDB が強化されており、ページ数や行数が負になるタイミングを検出します。負の値が検出されると、警告と、問題に対処するために DBCC UPDATEUSAGE を実行するよう勧めるメッセージが出力されます。データベースを SQL Server 2005 にアップグレードしたことによりこの問題が発生したように見えますが、無効な数がアップグレードを行う前から存在していたことは確かです。
例として、現在のデータベース内の全オブジェクトのページ数か行数、またはその両方を更新する方法を示します。以下のコマンドでは、データベース名に 0 を指定しています。このコマンドを実行すると、現在のデータベースに関して更新された情報がレポートされます。
DBCC UPDATEUSAGE (0);
GO
たとえば AdventureWorks について、ページ数か行数またはその両方を更新し、さらに、情報メッセージを表示しないようにするには、以下のコマンドを実行します。このコマンドでは、データベース名として AdventureWorks を指定し、すべての情報メッセージを表示しないようにしています。
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
詳細については、SQL Server Books Online で「DBCC UpdateUsage」を検索してください。

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 ユーティリティ スポットライト: SMSMap
ユーティリティ スポットライト
SMSMap
Jeff Tondt
この記事で使用しているコードのダウンロード: UtilitySpotlight2007_07.exe (2477KB)

百聞は一見にしかず。この有名なことわざは、複雑な物語もたった 1 枚の絵で伝えることができるとか、1 枚の絵が大量の文章より強い影響力を持つといったことを表しています。また、このことわざは、ビジュアル化 (視覚化) の目標を的確に捉えています。ビジュアル化により、大量のデータがすばやく吸収される必要があります。
私のような System Management Server (SMS) マニアにとって、SMS の全体階層を 1 枚の図で見ると、インフラストラクチャのレイアウトの理解に役立ちます。おそらく、SMS の移行計画を管理する場合、移行前後の状態を示すためにこのような図を使用している方もいるでしょう。特定のトラブルシューティングを行う場合、解決方法を見つける際にこのような図が非常に役立つこともあります。少なくとも、他人から支援を受ける場合には役に立ちます。もちろん、責任ある SMS 管理者であれば、さまざまな理由からシステム階層を文書化することは必要です。

図を入手する
このような図を自分自身で描けないということではありません。確かに、袖をまくり、手作業で SMS 階層を描き、サイト設定を手書きで文書化することはできます。Microsoft® Operations Manager (MOM) を使用して SMS サーバーを監視しているなら、MOM を使用して階層図を作成できます。ただし、MOM は作図には不向きであり、サイト設定が文書化されるわけではありません。他の方法や手軽なツールがあるかもしれませんが、十分に満足のいく図を作成でき、サイト設定の文書化に役立つものはこれまで見たことがありません。少なくとも、私にとっては満足のいくものはありませんでした。
そこで、自作することにしました。このようにして SMSMap 1.0 が生まれました。SMSMap は、SMS SDK の SMS マネージ ライブラリを使用して、COM 経由で Microsoft Visio® の自動化を行う Visual Basic® .NET アプリケーションです。このユーティリティは、対象の SMS サイト サーバーに照会し、視覚に訴える Visio 図面を作成して、サイト設定を XML ファイルにエクスポートします。サイト設定を文書化する際に XML を選択したのは、互換性に最も優れているためです。他の SMS サーバーに関連付けられた物理的なサーバーだけではなく SMS の役割も示すようにしました。そのため、Visio レイヤをいろいろと操作して、SMS 階層を複数の視点から考察することができます。
図 1 放射型図表
図 1 放射型図表
現在、このユーティリティでは 6 つの形式の Visio 図面を選択できます。たとえば、図 1 では、非常に単純な SMS 階層が放射型図表を使用して示されていますが、図 2 では、同じ階層がフロー チャート形式を使用して示されています。このユーティリティは、これよりはるかに大規模な階層でもまったく正常に機能しますが、ここでは簡単な階層にとどめておきます。
図 2 フロー チャート形式
図 2 フロー チャート形式
いつか SMSMap の機能を強化し、すべてのサイト設定を文書化できるようにするつもりです。現時点では、SMS サイトの役割とすべての境界のみが文書化されます。もっと多くのサイト設定を XML ファイルにエクスポートできるようにするのは簡単です。

SMSMap を使用する
SMSMap のソース コードとインストール ファイルは、TechNet Magazine Web サイト から入手できます。SMSMap のインストールは SMSMapSetup.msi を実行するだけであり、表示される指示に従えばインストールできます。SMSMap では Visio を使用するので、Visio も忘れずにインストールしておく必要があります。SMSMap をインストールしたら、C:\Program Files\Microsoft\smsmap\smsmap.exe を実行します (既定以外の場所にインストールした場合は、このパスも異なります)。
SMSMap はどのコンピュータからでも実行できます。つまり、サイト サーバーから SMSMap を実行する必要はありません (おそらく、SMS サイト サーバーには Visio がインストールされていません)。クエリを最初に実行する SMS サイト サーバー名を入力します。この SMS サイト サーバー名は、階層全体についてのクエリを実行する場合はセントラル サイトにすることもできますが、子プライマリ サイト サーバーにもできます。この例では、子プライマリ サイトから下の階層のみを取得します。次に、SMS に対してクエリを実行できるアクセス許可を持つアカウントを、ドメイン\ユーザー名形式で入力し、次にそのアカウントのパスワードを入力します (このパスワードは表示されないため、この作業は人前でもできます)。
6 個のオプション ボタンを使用してレイアウトを選択できます。また、SMS の役割を図に示すかどうかも選択できます。これらのチェック ボックスは、[Options (オプション)] タブにあります。[Draw (描画)] をクリックすると、ユーティリティが開始されます。最初に、Visio を使用できるかどうかを確認します。次に、指定した SMS プライマリ サイト サーバーに対してクエリが実行され、Visio 図面にオブジェクトが追加されます。SMSMap からオブジェクトが無造作に出力されている間の Visio 図面は見づらいですが、実行終了時に、最初に指定した形式に編集されます。
詳しい説明
ここまでは、SMSMap を使用して SMS 階層を文書化する理由と方法について見てきました。開発者としての頭脳を働かせたい人のために、ここからは SMSMap のしくみについて詳しく見ていきましょう。
SMSMap では、Managed SMS Site Server Interfaces を使用して SMS 情報を収集し、Visio プライマリ相互運用機能アセンブリを使用して必要な図形をレイアウトする Visio 図面を生成しています。SMS 2003 SDK Version 3.1 には、最新リリースの Managed SMS Site Server Interfaces が含まれています。このマネージ インターフェイスのセットを使用して、Microsoft .NET Framework 対応の言語またはアプリケーションを通じて SMS サイト サーバーに接続することや SMS サイト サーバーを構成することができます。
これらのインターフェイスでは、System.Management 名前空間を使用して Windows® Management Instrumentation (WMI) 経由で SMS プロバイダと通信します。これらのインターフェイスを使用するには .NET 互換の言語 (C#、Visual Basic .NET など) を使用してアプリケーションを開発し、SMS SDK で提供される .NET アセンブリ、Microsoft.SystemsManagementServer.Automation.dll を参照する必要があります。
.NET Management クラスは、WMI オブジェクト モデルの多く特異性を整理して、一貫性のあるオブジェクト指向モデルを提供します。WMI 接続、オブジェクトの列挙、メソッドの実行、オブジェクトの削除、オブジェクトの取得、イベントのキャプチャなどの基本的な作業は、この .NET Management クラスを使用してすべて実現できます。

Visio プライマリ相互運用機能アセンブリ
プライマリ相互運用機能アセンブリを使用すると、Visio などの COM アプリケーションをマネージ コードを使用してプログラムから制御できます。Visio プライマリ相互運用機能アセンブリを使用すると、Visio の機能をマネージ アプリケーションに統合し、拡張することができます。
既に .NET Framework をコンピュータにインストールしていれば、その後の Visio のインストール時に、インストーラによって Visio プライマリ相互運用機能アセンブリがコンピュータのグローバル アセンブリ キャッシュ (GAC) に追加されます。Visio プライマリ相互運用機能アセンブリへの参照は、マネージ アプリケーションから追加できます。
プロジェクトに参照を追加すると、Visio オブジェクトをマネージ アプリケーションから操作できるようになります。Visio のオブジェクト モデルは広範にわたっており、一連のクラス、インターフェイス、および列挙値が用意されているため、プログラムから作図できます。

プログラム フロー
ここまでは、Visio と SMS の主要コンポーネントのインターフェイスについて説明してきました。次は SMSMap 自体の処理の流れについて説明します。
マネージ インターフェイスを使用する際の最初の手順は、SMS プロバイダへの接続です。これは、SMSProvider クラスの新規インスタンスを作成することによって実現できます。このクラス内部では、指定されたサイト サーバーの SMS プロバイダを検索し、既存の一連の資格情報を使用して SMS プロバイダに接続します。SMS プロバイダがローカル コンピュータに存在する場合は、SMS プロバイダへの接続時に、指定された資格情報の代わりに現在ログインしているユーザーの資格情報が使用されます。SMSMap を SMS サーバーで実行することもできますが、Visio がインストールされた別のワークステーションで SMSMap を実行することをお勧めします。大半の SMS サイト サーバーには Visio がインストールされていないことが明白だからです。
SMS サイト上のデータに SMSProvider クラス経由でアクセスする場合のセキュリティ権限は、SMS 管理コンソールを使用しているときと同様に扱われます。つまり、たとえば、SMSProvider を使用してサイト サーバーの設定を構成する場合、管理コンソールを使用している場合と同様の権限のセットが、プロバイダに接続するアカウントにも必要です。
SMSProvider クラスには GetSiteSettings メソッドが用意されており、このメソッドを使用して、現在のサイト (プロバイダが所属するサイト) のサイト設定、または特定のサイト コード備えた任意のサイトのサイト設定を取得できます。SMSMap から対象のサイト サーバーのプロバイダへの接続方法を図 3 のコードに示します。ユーザーの資格情報は、Domain\User 形式で渡します。"." を使用して、現在のコンピュータを示すこともできます。図 3 には、結果を UI に表示するのに役立つコードや、ログに記録するコードも示しています。
Figure 3 GetSiteSettings のコード (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
次の手順では、図 4 に示すように、対象サイト サーバーの SMS 情報の収集と記録用の XML ファイルをセットアップします。
Figure 4 XML ファイルの作成 (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
次に、図 5 に示すように、対象サイトを Visio 図面に描画し、UI を更新し、ログを出力する必要があります。
Figure 5 Visio でのサイトの描画 (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
対象サイトの下位階層全体に対して実行するには、SMS に対するクエリの実行と Visio での描画を行う上記の基本コードと同じコードを実行します。これは Level という再帰的に呼び出される関数で、この関数を使用すれば、どのような規模の階層でもすべての子サイトに対してクエリが実行されるようになります。Level は、SMS サイト情報を収集し、収集したサイトの子サイトごとに、その情報を XML、UI、およびログに記録します。最後に、SMSMap の起動時に選択した形式を使用して、Visio 図面の書式を設定する方法を図 6 に示します。その後、XML ファイルとログ ファイルを閉じます。
Figure 6 仕上げ (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

まだ始まったばかり
もちろん、これは第一歩にすぎず、多くの機能強化の可能性があります。デバイス管理ポイントについては、SDK に記載がないようなので調査が必要です。サイトを完全に文書化するには、その他の多数のサイト設定を追加することになります。大小の階層の見栄えをよくする場合は、Visio のレイアウト設定を広範にわたって追加する作業が必要になります。効果的な図面を作成しようとすると、それぞれのレイアウトに独自の難しさがあります。もちろん、System Center Configuration Manager 2007 のサポートを追加することは、次の手順として非常に重要です。しかし、この SMSMap の最初のバージョンでも、SMS 管理者が全体像を把握し、Visio のレイヤとわかりやすさを利用して、いくつかの仮説を試みるのに役立ちます。
ソース コードをダウンロードすれば、独自のニーズを満たすように SMSMap を拡張できます。SMSMap は、Visio 2003 をインストールした Windows XP SP2、および Visio 2007 をインストールした Windows Vista™ Enterprise でテスト済みです。SMSMap の機能強化に関するご提案は、jeff.tondt@microsoft.com 宛てに電子メール (英語のみ) をお送りください。

Jeff Tondt は Microsoft Consulting Services のシニア コンサルタント II です。得意分野は、システム管理、自動化、修正プログラム管理です。SMS に関する業務を専門にしています。連絡先は、jeff.tondt@microsoft.com (英語のみ) です。


 動作メカニズム: RPC エラーのトラブルシューティング
動作メカニズム
RPC エラーのトラブルシューティング
Zubair Alexander

長年、Windows サーバー プラットフォームに携わっていれば、一度ならずリモート プロシージャ コール (RPC) エラーを目にしたことがあるはずです。このエラーは、RPC サーバーが使用できないことや、使用できるエンドポイントがなくなったことを知らせたり、その他何らかの不可解な警告を提示したりします。こうしたメッセージによって混乱が生じたら、この記事をお読みください。ここでは、
いくつか共通するエラー、表示された RPC エラーの特定に使用できるさまざまな技法、および特定の問題を解決するいくつかの解決策について説明します。ただし、特定の RPC エラーや解決方法についてお話しする前に、RPC 用語の基礎知識を身に付けておきましょう。

RPC について
RPC とは、クライアントとサーバーの相互通信に使用されるプロセス間通信 (IPC) 方法の 1 つです。簡単に言えば、プログラム (通常はクライアント コンピュータ上のプログラム) からサーバー コンピュータ上のプログラムを実行する場合に RPC が使用されます。たとえば、Microsoft® Outlook® クライアントは、RPC を使用して Microsoft Exchange Server と通信します。クライアント コンピュータは、特定の引数を指定してサーバーにメッセージを送信します。サーバーは、プログラムの実行結果を含むメッセージをクライアントに返します。
このプロセスに不可欠なのがエンドポイントです。エンドポイントとは、クライアント要求を受信するためにサーバーが監視する、コンピュータ上の名前、ポート、またはポートのグループです。さらに具体的に言うと、エンドポイントは、RPC に使用されるサーバー プロセスのネットワーク固有のアドレスです。
RPC サブシステムの一部であるエンドポイント マッパーは、クライアント要求に応答して動的なエンドポイントの解決を担当します。エンドポイント マッパーは、状況によっては、エンドポイントの動的サーバー割り当ても担当します。
RPC のもう 1 つの重要なコンポーネントは、ロケータ サービスです。このコンポーネントは、ネットワーク上の RPC サービスと RPC サーバーの一覧を管理します。Windows® クライアントは、サーバー メッセージ ブロック (SMB) ポート (TCP 139 と 445) 経由でドメイン コントローラに接続し、ロケータ サービスを使用して RPC サービスまたは RPC サーバーを検索します。
大部分の組み込み Windows サービスは、RPC を使用して相互に通信します。たとえば、証明書サービス、DCOM、FRS、MSMQ、MAPI、Active Directory® のレプリケーション サービスなどは、通信に RPC を使用します。そのため、ネットワーク上で RPC サービスが適切に機能していないと、多くの通信エラーが発生する可能性があります。

RPC エラー
では、RPC サービスが失敗したときに発生する可能性があるエラーをいくつか考えましょう (この一覧は完全なものではありません)。
ファイル レプリケーション サービス (FRS) が失敗すると、作業中に "RPC が使用できない" という世にも恐ろしいエラーが発生することがあります。ドライブを割り当てようとすると、"アクセス拒否" というエラーが発生することがあります。Active Directory ユーザーとコンピュータを使用しているときは、"指定されたドメインがないか、またはアクセスできません。" というエラーが表示され、ドメインにログオンすると、"プライマリ ドメイン内にこのシステムのコンピュータ アカウントがないか、アカウントのパスワードが間違っているため、このドメインにログオンできません。" というエラーが表示されることがあります。
Microsoft Outlook クライアントが Exchange Server と通信すると、RPC のエラーにより、"ログオン情報が正しくありません。" や "Outlook がログオンできませんでした。" など、誤解を招くエラーがクライアントに表示されることもあります。
RPC サービスが使用できないと、こうしたエラー以外に、他の問題が発生することもあります。たとえば、マイ ネットワークでドメインを参照できなかったり、グループ ポリシー スナップインを開けなかったりします。
これらは、必要な RPC が使用できないために発生する問題例の一部にすぎません。これ以外にも非常に多くの事例があり、RPC の問題は必ずリモート プロセスとかかわっているため、トラブルの根本原因となる場合があります。では、このようなエラーをどのようにすれば確実に認識できるでしょうか。さらに重要なことは、どのようにすれば正確なエラーを見つけ出すことができるでしょうか。方法を探してみましょう。

トラブルシューティング
RPC サービスで問題が発生していると考えられる場合、その問題の診断に使用できるツールがいくつかあります。
1 つが Repadmin ツールです。このツールは、通常、Active Directory のレプリケーションの問題の監視とトラブルシューティングに使用しますが、RPC エンドポイント マッパーの問題のトラブルシューティングにも使用できます。このツールを実行するには、コマンド プロンプトで「repadmin /bind」と入力します。RPC に問題があれば、"エンドポイント マッパーから使用できるエンドポイントはこれ以上ありません。" などのメッセージが表示されます。これが、問題が RPC に関連していることを示す最初の手掛かりです。
もう 1 つは、ドメイン コントローラ診断ツール (DCDiag) を使用する方法です。このツールは、ドメイン コントローラの問題を診断するためのコマンド ライン プログラムです。エラー "ステータス 1722: RPC サーバーを利用できません。" が表示された場合は RPC の問題が発生していますが、これは、ドメイン コントローラ診断ツールで偶然発見されたにすぎません。
Ntdsutil を使用しているとき、サーバーへの接続時に RPC エラーが発生することがあります。このツールは、Active Directory の管理に使用するコマンド ライン ツールであり、さまざまなメンテナンス作業を実行します。このような場合多くは、"エンドポイント マッパーから使用できるエンドポイントはこれ以上ありません。" など、一般的なエラーのいずれかが表示されます。これも、RPC サーバーで問題が発生していることを示す手掛かりになります。RPC に問題が発生すると、ドメイン コントローラ上のグループ ポリシー オブジェクトの一貫性を確認する Gpotool ツールでも同様のエラーが示されます。
Dcpromo ツールを使用して、Windows 2000 Server や Windows Server® 2003 のサーバーをドメイン コントローラに昇格したときに生成される Dcpromo.log からも、RPC の問題がわかります。たとえば、昇格に失敗した場合には、このログを調べます。このログは %windir%\debug フォルダにあります。出力されたエラーでは、"ディレクトリ サービスがパーティションのレプリケートに失敗した"、または "オブジェクトの作成に失敗した" といったことを示します。メッセージの末尾にはエラー コードがあります。以下に、Dcpromo.log に出力されることがあるエラー メッセージの例を示します。

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
エラー コード 1722 に注目します。このエラー コードはメッセージ内に 4 回出現し、RPC サーバーが使用できないことを示しています。図 1 にエラー コードの一部とその説明を示しますが、msdn2.microsoft.com/ms681386 でより多くのエラー コードと説明を確認できます。
Figure 1 エラー コードとその説明 (Close Figure 1)

エラー コード | 説明
58 | 指定されたサーバーは、要求された操作を実行できません。
1721 | リソースが不足しているため、この操作を完了できません。
1722 | RPC サーバーを利用できません。
1723 | RPC サーバーが非常にビジーであるため、この操作を完了できません。
1727 | リモート プロシージャ コールに失敗し、実行されませんでした。
1753 | エンドポイント マッパーから使用できるエンドポイントはこれ以上ありません。

RPC エラーの解決
ここまで RPC エラーの検出方法をいくつか見てきましたが、ここからは解決策をいくつか見ていきましょう。
マイクロソフトのクライアントは、ポート 135 で RPC エンドポイント マッパーに接続します。次に RPC エンドポイント マッパーからクライアントに、要求したサービスをリッスンするポートを通知します。ポート番号は 1024 ～ 65,535 のいずれかに動的に割り当てられます。エンドポイント マッパーから使用できるエンドポイントがなくなったことを示す 1753 などのエラーが RPC 表示されるときは、RPC エンドポイント マッパーが 1024 以上のポートをサービスに割り当てられなかったことを意味します。このトピックは、この後、もう少し詳しく見ていくことにしましょう。
まず、サーバー上の RPC サービスの状態を確認します。RPC サービスと RPC ロケータ サービスは、サーバーの役割の種類に応じて図 2 に示す状態になります。2 つのサービスのいずれかがこの図と異なる構成であれば、状態を調整し、サーバーを再起動して問題が解決されるかどうかをテストします。
Figure 2 RPC サービスの状態 (Close Figure 2)

サーバーの役割 | RPC サービス | RPC ロケータ サービス
Windows Server 2003—ドメイン コントローラ | 開始、自動 | 停止、手動
Windows Server 2003—メンバ サーバー | 開始、自動 | 停止、手動
Windows Server 2003—スタンドアロン サーバー | 開始、自動 | 停止、手動
Windows 2000 Server—ドメイン コントローラ | 開始、自動 | 停止、自動
Windows 2000 Server —メンバ サーバー | 開始、自動 | 開始、手動
Windows 2000 Server—スタンドアロン サーバー | 開始、自動 | 停止、手動
接続の問題が発生しているサーバーに、クライアントから正常に ping を実行できることを確認します。たとえば、IP アドレスが 192.168.1.200 の DC1 というサーバーへの接続に関して問題が発生しているとすると、コマンド プロンプトから次のコマンドを使用して、DNS によってホスト DC1 に正常に解決されることを確認します。
Ping –a 192.168.1.200
-a スイッチは、ホスト名ではなく IP アドレスと共に使用してください。
すべてが正常に機能する場合、図 3 のような ping 応答が DC1 から返されます。ping を実行すると、単に IP アドレス 192.168.1.200 に解決されるのではなく、ホスト名 dc1.contoso.com にも解決されることに注目してください。これにより、DNS 名前解決が正しく機能し、期待どおりにホスト dc1.contoso.com に正確に解決されることが確認されます。
Figure 3 Ping 応答 (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
また、Windows XP クライアントまたは Windows 2000 クライアントでは、図 4 の右側のウィンドウからわかるように、レジストリに少なくとも 4 つの ClientProtocols が含まれます。
図 4 レジストリに表示される RPC ClientProtocols
図 4 レジストリに表示される RPC ClientProtocols
不足しているエントリがあれば、図 4 に示した名前とデータの種類で新しい文字列値を追加します。既定では、ncacn_nb_tcp という 5 番目のエントリが存在します。このエントリは、NetBIOS over TCP をエンドポイントのプロトコル ファミリとして識別するために使用されます。構成によっては、ClientProtocols にエントリが存在しない場合がありますが、手動で追加して RPC エラーが解決するかどうかを確認できます。
図の左側のウィンドウの Rpc フォルダの下に表示されるキー、つまり、ClientProtocols、NameService、NetBios、および SecurityService を見てください。Internet というキーがあり、そのキーに値が設定されていない場合は、そのキーを削除してコンピュータを再起動します。これが、問題の解決に役立つ場合があります。ただし、Windows レジストリを変更する場合は、常に十分な注意が必要です。
前述のように、RPC では 1024 ～ 65,535 のポートを使用するため、これらのポートがファイアウォールでブロックされないようにする必要があります。ポートが開いていることを確認する最も簡単な方法は、Port Query ツールを使用することです。このツールには、コマンド ライン バージョン (PortQry) と GUI バージョン (PortQueryUI) の 2 つがあります。
PortQry は、Microsoft ダウンロード センターからダウンロードできます。詳細については、「Portqry.exe コマンド ライン ユーティリティの説明」を参照してください。この資料には、PortQry の状態レポートの簡単な説明と、問題の解決に使用するコマンド例が記載されています。GUI バージョンも使用できます。使いやすさは GUI バージョンの方がはるかに優れています。このバージョンは、go.microsoft.com/fwlink/?LinkId=73740 からダウンロードできます。
Port Query を使用する場合、必ず、RPC エラーが発生していないコンピュータと発生しているコンピュータの両方で実行します。たとえば、RPC エンドポイント マッパーによって使用されるポート 135 が開いていることを確認する場合は、コマンド プロンプトで次のように PortQry を使用します。
portqry -n [servername] -e 135
PortQuery と PortQueryUI のどちらを使用しても、以下のような結果が得られます。
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
最後の行に、ポート 135 が開いていることが示されます。ポートが開いていない場合、最終行に NOT LISTENING と示されます。
ポートの範囲の状態を確認するには、ポート番号の範囲を、"135,1024-5000" のようにコンマで区切って入力します。

その他の解決策
ここまでに示したすべての方法を試しても問題が解決しない場合は、他にも試せる方法があります。環境固有の問題に応じて、レジストリの以下のいずれかの変更を試みることができます (ただし、特にレジストリの場合、問題が発生した場合にコンピュータを以前の状態に復元できるように、変更を加える前にシステムをバックアップしておくことが重要です)。
1 つは MaxUserPort を調整する方法です。このキーでは、アプリケーションがシステム上で使用可能なユーザー ポートを要求したときに、TCP から割り当て可能な最大ポート番号を指定します。Windows Server 2003 の既定では、MaxUserPort 値に 5000 が設定されています。つまり、このエントリが存在しない場合も、使用される最大ポート番号は 5000 です。構成によっては、このエントリがレジストリに存在しない場合がありますが、その場合は 図 5 に示す場所にこのエントリを追加できます。
図 5 レジストリの MaxUserPort 設定
図 5 レジストリの MaxUserPort 設定
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
レジストリに変更を加える場合は、発生する可能性がある他の副作用に注意する必要がありますが、それは必ずしも簡単ではありません。このエントリを変更して 50,000 より小さな値を設定すると、Microsoft Exchange Server に影響を及ぼすことがあります。Exchange Server ベスト プラクティス アナライザ (BPA) では、MaxUserPort レジストリ キーの値に 50,000 より小さな値が設定されていることを検出すると、警告が表示されます。マイクロソフトでは、この値を 60,000 に設定することをお勧めします。それ以外の値を設定すると、イベント 9040 など、NSPI (Name Service Provider Interface) プロキシの警告が表示されることがあります。詳細については、マイクロソフトのドキュメント「MaxUserPort 値が小さすぎる」を参照してください。
また、TcpMaxDataRetransmissions も調整できます。TCP パケットでは、受信側から受信確認が返されることを期待します。指定時間内に受信確認が返されない場合は、TcpMaxDataRetransmissions に設定されている回数までパケットが再送されます。このパラメータの既定値は 5 ですが、4 または 3 に設定することもできます。2 以下の値は使用しないでください。
TcpMaxDataRetransmissions レジストリ エントリが存在しない場合、次に示すレジストリの場所に TcpMaxDataRetransmissions レジストリ エントリを追加できます。設定値も示します。
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
TcpMaxDataRetransmissions の詳細については、マイクロソフト サポート技術情報の記事「TCP/IP の再送タイムアウトの最大値を変更する方法」を参照してください。
もう 1 つ試すことができるレジストリ値に、TcpTimedWaitDelay があります。クライアントで使用されるポートが多すぎると、閉じられた接続が TCP/IP から解放される前にポート不足が発生する可能性が高まります。これは、TCP/IP では、2 つの最大セグメント有効期間 (MSL) が経過する (TIME WAIT 状態とも呼ばれます) まで、接続が解放されないことが原因です。さらに、各 MSL が 120 秒と定義されており、TCP/IP では 2 つの MSL が経過するまで接続が解放されないため、閉じられた接続が解放されるまでには、最大で 240 秒 (4 分) かかります。これは、Windows NT® の既知の問題であり、Service Pack で修正されました。その結果、最近ではこの問題が発生する可能性は大幅に低下しました。ただし、マイクロソフトでは、サポート技術情報の記事「RPC エンドポイント マッパーのエラーのトラブルシューティングを行う方法」で説明されているように、RPC エンドポイント マッパー エラーの解決に使用できる解決策の 1 つとしてこの設定を調整することをお勧めします。
TcpTimedWaitDelay は、レジストリの次の場所に追加されています。
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
TcpTimedWaitDelay の詳細については、サポート技術情報の記事「Windows NT クライアントでポートが不足する」を参照してください。この資料では特定の数値を推奨していませんが、TcpTimedWaitDelay を 10 進数で 60 (秒) まで減らすことができます。この値は 16 進数では 3c です。

まとめ
RPC エラーは、ネットワーク上の多くの通信エラーの根本原因になる可能性があります。さいわい、このような特定しにくい問題のトラブルシューティングを行える、独創的な方法がいくつかあります。ここで紹介したツールの一部は組み込みのツールですが、Windows Server Resource Kit から入手できるツールもあります。図 6 に多くのツールを記載しました。これらのツールを使用して、RPC エラーの原因と問題が発生した場所を検出し、ここで示した技法のいずれかを使用して RPC エラーを解決することができます。
Figure 6 RPC トラブルシューティング ツール (Close Figure 6)

ツール | 説明
DCDiag | ドメイン コントローラの状態を分析します。
イベント ビューア | ログに記録されたイベントを表示します。
Gpotool | ポリシーが有効かつ一貫性を保っているかどうかを判断します。
NetDiag | ネットワーク接続をテストするために使用します。
ネットワーク モニタ | ネットワーク トラフィックを監視およびキャプチャします。
Ntdsutil | Active Directory 用の管理機能を提供します。
PortQry、PortQueryUI | TCP/IP 接続のテストに使用します。
Repadmin | Windows DC 間のレプリケーションの問題を診断します。
RPCDump | 通常、ネットワーク モニタと併用します。
RPCPing | RPC 接続を確認するために使用します。

Zubair Alexanderは MCSE、MCT、Microsoft MVP を取得しており、IT トレーニングおよびコンサルティング企業である SeattlePro Enterprises のオーナーです。IT 教育の分野で、著者、大学講師、コンサルタント、ネットワーク エンジニア、講演者、セキュリティ アーキテクト、システム管理者、テクニカル エディタ、トレーナーなどの経験があります。Zubair の連絡先は alexander@techgalaxy.net (英語のみ) です。


 The Cable Guy: VPN 接続を経由した IPv6 トラフィック
The Cable Guy
VPN 接続を経由した IPv6 トラフィック
Joseph Davies

イントラネット上でインターネット プロトコル バージョン 6 (IPv6) が果たす役割の評価と、IPv6 の展開計画を開始する前に、IPv6 トラフィックが、Windows の仮想プライベート ネットワーク (VPN) 接続を経由した場合のサポートについて理解する必要があります。VPN 接続を使用すると、ネットワークを拡張して、インターネットなどのパブリック ネットワークにまたがったリンクを
含めることができます。VPN 接続は、接続しているユーザーの資格情報を検証するための強力な認証プロトコル、およびデータの機密性を提供するための暗号化方法によって保護されます。
Windows® XP と Windows Server® 2003 には IPv6 プロトコル スタックが含まれていますが、多くの主要なサービスとネットワーク コンポーネントでは IPv6 がサポートされていません。Windows Vista™ と Windows Server 2008 (以前のコードネーム "Longhorn" から変更) では、IPv6 のすべての機能がサポートされており、既定で IPv6 がインストールおよび有効化されています。さらに、Windows Vista と Windows Server 2008 に含まれているほとんどすべてのネットワーク アプリケーションおよびネットワーク サービスでは、IPv6 がサポートされています。今月は、インターネット プロトコル バージョン 4 (IPv4) インターネットと IPv6 インターネットにまたがって確立された VPN 接続を経由して送信された IPv6 トラフィックに対する、Windows Vista、Windows Server 2008、Windows XP、および Windows Server 2003 のサポートについて説明します。

IPv4 インターネットを経由した VPN 接続
今日のほとんどのイントラネットでは、IPv4 インターネットを経由して VPN 接続が作成されます。図 1 は、この種類の VPN 接続で使用される Windows ベースのコンポーネントを示しています。これらの構成要素に関する説明を次に示します。
図 1 IPv4 インターネットを経由した VPN 接続で使用される Windows ベースのコンポーネント
図 1 IPv4 インターネットを経由した VPN 接続で使用される Windows ベースのコンポーネント
VPN クライアント VPN サーバーへのリモート アクセス VPN 接続を開始し、イントラネット リソースと通信するコンピュータです。リモート アクセス VPN 接続を使用すると、VPN クライアントは、イントラネットに直接接続されているかのようにリソースにアクセスすることができます。VPN クライアントでは、Windows のクライアント バージョンまたはサーバー バージョンを実行できます。
VPN サーバー 試行されるリモート VPN 接続をリッスンし、認証を実行して接続要件を適用し、VPN クライアントとイントラネット リソースとの間でパケットをルーティングするコンピュータです。通常、VPN サーバーでは、ルーティングとリモート アクセスのサービスが含まれた Windows のサーバー バージョンが実行されます。
VPN ルーター サイト間で試行される VPN 接続を開始またはリッスンするコンピュータです。サイト間の VPN 接続は、イントラネット内の 2 つの場所を接続します。VPN ルーターでは、Windows のサーバー バージョンと、ルーティングとリモート アクセス サービスが実行されます。
VPN 接続 VPN プロトコルのカプセル化によって定義された、VPN クライアントと VPN サーバーとの間、または VPN ルーター間の論理リンクです。
IPv6 対応イントラネット IPv6 トラフィックを、IPv4 パケットとしてトンネリングするかネイティブで転送できるイントラネットです。
IPv6/IPv4 ホスト IPv6 トラフィックを、IPv4 パケットとしてトンネリングするかネイティブで送受信するイントラネット ノードです。
Windows ベースの VPN クライアント、VPN サーバー、および VPN ルーターは、Point-to-Point トンネリング プロトコル (PPTP)、インターネット プロトコル セキュリティを使用したレイヤ 2 トンネリング プロトコル (L2TP/IPsec)、および Secure Socket トンネリング プロトコル (SSTP) といった VPN プロトコルを使用して、VPN 接続を経由して送信されたパケットをカプセル化できます。SSTP は、Windows Vista Service Pack 1 (SP1、現在はベータ テスト段階) と Windows Server 2008 のみでサポートされます。
IPv4 インターネットを経由した VPN 接続の場合、IPv6 の送信に使用される方法は 2 つあり、IPv4 パケットとしてトンネリングされた IPv6 パケット (これ以降は IPv6-over-IPv4 トラフィックと呼びます) か、ネイティブ IPv6 トラフィックとして送信されます。
このコラムでは、VPN 接続を経由した IPv6 トラフィックのサポートについて、VPN プロトコルと Windows のバージョンという観点から説明します。リモート アクセス VPN 接続の場合、特定の VPN プロトコルと Windows のバージョンを組み合わせて使用することにより、Windows のリモート アクセス クライアント コンポーネントとリモート アクセス サーバー コンポーネントの両方で、VPN 接続を経由した IPv6 トラフィックをサポートすることができます。

IPv6-over-IPv4 トラフィック
この方法では、リモート アクセス クライアントまたはイントラネット上の IPv6/IPv4 ホストが、IPv4 ヘッダーで IPv6 パケットをカプセル化し、それを IPv4 パケットとして送信します。イントラネットの場合、IntraSite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 移行テクノロジ (RFC 4214) を使用すると、IPv4 のみに対応したイントラネット内の IPv6/IPv4 ノード間で IPv6 トラフィックを送受信できます。ISATAP を使用すると、ネイティブ IPv6 のアドレス指定と転送をサポートするように既存のルーターを構成またはアップグレードすることなく、IPv4 のみに対応したイントラネットで IPv6 接続を確立できます。ISATAP の詳細については、microsoft.com/technet/network/ipv6/ipv6coexist.mspx の「IPv6 移行テクノロジ」を参照してください。
図 2 は、VPN 接続を使用して、IPv4 インターネット経由で IPv4 パケットを送信する場合の一般的な VPN トラフィックのパケット構造を示しています。IPv4 パケットは、VPN プロトコルによって、ヘッダーを付加して (VPN プロトコルの種類によってはトレーラも使用されます) カプセル化されます。カプセル化された IPv4 パケットは、さらに IPv4 ヘッダーでカプセル化されます。これにより、IPv4 インターネットを経由した転送が可能になります。
図 2 VPN 接続を使用して IPv4 インターネット経由で送信される IPv4 パケット
図 2 VPN 接続を使用して IPv4 インターネット経由で送信される IPv4 パケット
IPv6-over-IPv4 トラフィックの場合、VPN 接続を経由して送信される IPv4 パケットのペイロードは IPv6 パケットです。図 3 は、VPN 接続を使用して、IPv4 インターネット経由で IPv6-over-IPv4 パケットを送信する場合の一般的な VPN トラフィックのパケット構造を示しています。
図 3 VPN 接続を使用して IPv4 インターネット経由で送信される IPv6-over-IPv4 パケット
図 3 VPN 接続を使用して IPv4 インターネット経由で送信される IPv6-over-IPv4 パケット
リモート アクセス VPN 接続の場合、IPv4 インターネットを経由した IPv6-over-IPv4 トラフィックは、Windows Vista、Windows Server 2008、Windows XP SP1 以降、および Windows Server 2003 の PPTP と、Windows Vista SP1 と Windows Server 2008 の SSTP でサポートされます。サイト間の VPN 接続の場合は、Windows Server 2008 と Windows Server 2003 の PPTP と L2TP/IPsec でサポートされます。

ネイティブ IPv6 トラフィック
ネイティブ IPv6 トラフィックの場合、VPN クライアント、VPN サーバー、または VPN ルーターは、最初の IPv4 のカプセル化を実行せずに、VPN 接続を経由して IPv6 パケットを送信します。この通信方法は、ネイティブ IPv6 接続がサポートされているイントラネットで使用することができるため、VPN クライアント、VPN サーバー、および VPN ルーターで、RFC 2472 の IPv6 制御プロトコル (IPV6CP) がサポートされている必要があります。このプロトコルでは、IPv6 ノードが Point-to-Point プロトコル (PPP) ベースの接続用の IPv6 構成オプションをネゴシエートする方法が定義されています。Windows Vista と Windows Server 2008 では IPV6CP がサポートされていますが、Windows XP と Windows Server 2003 ではサポートされていません。図 4 は、VPN 接続を使用して、IPv4 インターネット経由でネイティブ IPv6 パケットを送信する場合の一般的な VPN トラフィックのパケット構造を示しています。
図 4 VPN 接続を使用して IPv4 インターネット経由で送信されるネイティブ IPv6 パケット
図 4 VPN 接続を使用して IPv4 インターネット経由で送信されるネイティブ IPv6 パケット
リモート アクセス VPN 接続の場合、IPv4 インターネットを経由したネイティブ IPv6 トラフィックは、Windows Vista と Windows Server 2008 の PPTP と L2TP/IPsec、および Windows Vista SP1 と Windows Server 2008 の SSTP でサポートされます。サイト間の VPN 接続の場合は、Windows Server 2008 の PPTP と L2TP/IPsec でサポートされます。

IPv6 インターネットを経由した VPN 接続
IPv6 インターネットを経由した VPN 接続を確立することもできます。この VPN 接続はまだあまり使用されていませんが、顧客に IPv6 を提供するインターネット サービス プロバイダや、IPv6 インターネット接続をイントラネットのエッジ ネットワークに含める組織が増加するにしたがって普及することが予想されます。
IPv6 インターネットを経由した VPN 接続をサポートするには、使用する VPN プロトコルで IPv6 を経由した接続がサポートされている必要があります。Windows Vista と Windows Server 2008 の L2TP/IPsec VPN プロトコルと SSTP VPN プロトコルでは、IPv6 を経由したリモート アクセス VPN 接続がサポートされています。Windows Server 2008 の L2TP/IPsec では、IPv6 を経由したサイト間の接続がサポートされています。IPv6 インターネットを経由した VPN 接続は、リモート アクセス VPN 接続であるかサイト間の VPN 接続であるかにかかわらず、IPv4 インターネットを経由した VPN 接続と同じコンポーネントを使用します。
IPv6 インターネットを経由した IPv6 パケットの送信方法も 2 つあり、IPv6-over-IPv4 トラフィックかネイティブ IPv6 トラフィックとして送信されます。図 5 は、VPN 接続を使用して、IPv6 インターネット経由で送信される IPv6-over-IPv4 パケットの一般的な構造を示しています。
図 5 VPN 接続を使用して IPv6 インターネット経由で送信される IPv6-over-IPv4 パケット
図 5 VPN 接続を使用して IPv6 インターネット経由で送信される IPv6-over-IPv4 パケット
リモート アクセス VPN 接続の場合、IPv6 インターネットを経由した IPv6-over-IPv4 トラフィックは、Windows Vista と Windows Server 2008 の L2TP/IPsec、および Windows Vista SP1 と Windows Server 2008 の SSTP でサポートされます。サイト間の VPN 接続の場合は、Windows Server 2008 の L2TP/IPsec でサポートされます。IPv4 インターネットを経由した IPv6-over-IPv4 トラフィックの場合と同様に、IPv6 インターネットを経由した IPv6-over-IPv4 トラフィックの場合も、イントラネット上に ISATAP などの IPv6 移行テクノロジを展開する必要があります。
図 6 は、VPN 接続を使用して IPv6 インターネット経由で送信されるネイティブ IPv6 パケットの一般的な構造を示しています。IPv4 インターネットを経由したネイティブ IPv6 トラフィックの場合と同様に、IPv6 インターネットを経由したネイティブ IPv6 トラフィックの場合も、イントラネットで IPV6CP をサポートし、ネイティブ IPv6 接続を展開する必要があります。
図 6 VPN 接続を使用して IPv6 インターネット経由で送信されるネイティブ IPv6 パケット
図 6 VPN 接続を使用して IPv6 インターネット経由で送信されるネイティブ IPv6 パケット
リモート アクセス VPN 接続の場合、IPv6 インターネットを経由したネイティブ IPv6 トラフィックは、Windows Vista と Windows Server 2008 の L2TP/IPsec、および Windows Vista SP1 と Windows Server 2008 の SSTP でサポートされます。サイト間の VPN 接続の場合は、Windows Server 2008 の L2TP/IPsec でサポートされます。

まとめ
図 7 は、VPN 接続を経由して IPv6 トラフィックを送信するための 4 つの方法と、異なる 2 つの種類の VPN 接続に対する Windows のサポートを示しています。簡単に言うと、イントラネット上で ISATAP などの IPv6 移行テクノロジを使用している場合、IPv4 インターネットと IPv6 インターネットのどちらを経由しても、VPN 接続を使用して IPv6-over-IPv4 トラフィックを送信できます。イントラネットでネイティブ IPv6 接続がサポートされている場合、Windows Vista と Windows Server 2008 では、IPv4 インターネットと IPv6 インターネットのどちらを経由しても、VPN 接続を使用してネイティブ IPv6 トラフィックを送信できます。
Figure 7 VPN 接続を経由した IPv6 トラフィックに対する Windows のサポート (Close Figure 7)

IPv6 トラフィックの送信方法 | リモート アクセス VPN 接続 | サイト間の VPN 接続
IPv4 インターネットを経由した IPv6-over-IPv4 トラフィック | Windows Vista、Windows Server 2008、Windows XP SP1 以降、および Windows Server 2003 の PPTP と L2TP/IPsec Windows Vista SP1 と Windows Server 2008 の SSTP | Windows Server 2008 と Windows Server 2003 の PPTP と L2TP/IPsec
IPv4 インターネットを経由したネイティブ IPv6 トラフィック | Windows Vista と Windows Server 2008 の PPTP と L2TP/IPsec Windows Vista SP1 と Windows Server 2008 の SSTP | Windows Server 2008 の PPTP と L2TP/IPsec
IPv6 インターネットを経由した IPv6-over-IPv6 トラフィック | Windows Vista と Windows Server 2008 の L2TP/IPsec Windows Vista SP1 と Windows Server 2008 の SSTP | Windows Server 2008 の L2TP/IPsec
IPv6 インターネットを経由したネイティブ IPv6 トラフィック | Windows Vista と Windows Server 2008 の L2TP/IPsec Windows Vista SP1 と Windows Server 2008 の SSTP | Windows Server 2008 の L2TP/IPsec

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


 Windows PowerShell: パイプラインについての再考
Windows PowerShell
パイプラインについての再考
Don Jones

Windows PowerShell は、UNIX や Linux ベースのオペレーティング システムで数十年使用されているコマンド ライン インターフェイスの概念に基づいていますが、それとは異なる新しくおもしろいものであるということについては、十分に説明しました。けれども、Windows PowerShell という一般的な用語には、その前身も含まれてしまうので、次のようなデメリットがあります。
Windows PowerShell™ の柔軟性や独自性、Windows® 環境での優れた安定性が見落とされがちである
パイプラインは、Windows PowerShell の機能で最も話題に上るものの 1 つですが、残念ながら最も誤解されやすい機能の 1 つでもあります。これは、1970 年初頭に定義された同名の用語に基づいていることが原因です。当時、パイプラインという用語は、まったく別の機能を持った、パフォーマンスの低い機能の名称として使用されていました。

パイプの起源
初めて作成された UNIX シェルの 1 つは Thompson shell です。これは、非常に原始的なものであり、変数のないごく基本的なスクリプト言語の要素を搭載していました。このシェルの本来の目的はプログラムを実行することなので、意図的に質素なデザインが採用されていました。しかし、このシェルは、当時出回っていた他のシェルに改善をもたらした "パイプ" という重要な概念を導入しました。< 記号と > 記号を使用することで、シェルは、入力と出力をコマンド間でリダイレクトできるようになりました。この概念により、ユーザーがコマンドの出力をファイルにリダイレクトできるようになりました。
この構文は、後に、あるコマンドの出力を他のコマンドの入力としてパイプできるように拡張され、長いシーケンスのコマンドを連結して、より複雑なタスクを実行できるようになりました。シェルのバージョン 4 のころには、パイプするために縦線文字 "|" が導入され、パイプ文字として使用されるようになりました。MS-DOS® の初期バージョンでも、このパイプ文字を使用して基本的なパイプ機能が実装されていました。たとえば、ユーザーは、入力コマンドの出力を後続コマンドの入力としてパイプし、長いテキスト ファイルの 1 ページ単位の表示を作成できました。
UNIX Version 6 がリリースされた 1975 年ごろには、Thompson shell の機能は一般的には不十分だと見なされていましたが、パイプの概念は、シェル開発者とシェル ユーザーに浸透し、現在使用されている多くのテクノロジに受け継がれています。

テキストをパイプする
ほぼすべてのシェルには、本質的にテキスト ベースであるという制限があります。UNIX ベースのオペレーティング システムでは、これは制限というよりも、OS 自体のしくみを反映した結果です。UNIX のほぼすべてのリソースは、なんらかのファイルとして表されます。つまり、あるコマンドのテキストを別のコマンドにパイプできることは、大きなメリットと柔軟性をもたらします。
しかし、管理情報については、テキスト ベースであるということは間違いなく足かせになります。たとえば、私が読者の皆さんに Windows コンピュータで実行しているサービスの一覧を提供したら、その一覧の内容を問題なく理解してもらえるでしょう。おそらく、私は、1 列目にサービス名を記入し、2 列目にスタートアップの種類を記入するでしょう。脳は自動的かつ瞬時にテキストを解析 (解釈) するので、この一覧は有益な情報になります。残念ながら、コンピュータは、人間の脳ほど優れていません。コンピュータが、この一覧から有益な情報を得るには、1 列目が 1 ～ 20 文字で構成されていて、2 列目が 22 ～ 40 文字で構成されているなどのような情報をコンピュータに提示する必要があります。
何年もの間、このようなテキスト ファイルの解析を行うには、管理者が複数のコマンドを連結するしかありませんでした。実際、VBScript や Perl などのスクリプト言語では、あるプログラムやコマンドのテキスト出力を受け取って、この出力を後続のタスクで使用できる有益なデータとして解析する必要があるため、スクリプト言語は文字列を操作する言語としては優れています。たとえば、Dir コマンドのテキスト出力を受け取り、その出力からファイル名や日付を解析し、古くて使用していないファイルをアーカイブ用の場所に移動する VBScript ジョブを記述したことがあります。入力データには (一貫性がなく) 常に例外が付き物で、考えられるすべての順列に対応するスクリプトのロジックを作り直す必要があるので、文字列の解析は非常に難解な作業です。
Windows 環境における管理作業のスクリプト化や自動化の手段としてスクリプトを解析するのは、それほど有用ではありません。これは、Windows に格納されている大半のデータの形式が簡単にアクセスできるテキスト形式ではないからです。Windows では、Active Directory®、Windows レジストリ、証明書ストアなど、データ処理を中心とするストアを使用するので、スクリプトの作成者は、ツールを使用して何らかの形式のテキスト出力を生成し、その後、スクリプトを使用して生成したテキストを解析してテキストを操作する必要があります。

使いやすいオブジェクト
Windows ソフトウェアの開発者は、常に物事を改善してきました。初めに、マイクロソフトは、Windows 内部の複雑な処理を使いやすい形式で表すために COM を開発しました。現在、Microsoft® .NET Framework が、このタスクを受け継ぎ、標準化された形式でソフトウェア内部の処理を表しています。
一般的に、COM と .NET はどちらもアイテムをオブジェクトとして公開しています (ソフトウェア開発者は、この単純化について意義を唱えるかもしれませんが、この記事の説明では簡単な表現で差し支えないと判断しました)。これらのオブジェクトは、さまざまな型のメンバを持っています。この記事の説明においては、オブジェクトのプロパティとメソッドが最重要事項です。基本的に、プロパティは、オブジェクトについて説明するか、オブジェクまたはその動作を変更するものです。たとえば、サービス オブジェクトには、サービスの名前を保持するプロパティや、サービスのスタートアップの種類を保持するプロパティがあります。メソッドは、オブジェクトが何らかの処理を行うようにするものです。サービス オブジェクトには、サービスについて行えるさまざまな処理を表す Stop、Start、Pause、Resume などの名前のメソッドを持っていることがあります。
プログラミングやスクリプトの観点から説明すると、オブジェクトのメンバは、ドット形式の表記で表されます。オブジェクトを変数に割当てて、物理的にオブジェクトを操作できるようにすることができます。たとえば、サービスを変数 $service に割当てた場合、$service.Stop という構文を使用してサービスを停止できます。また、$service.Name という構文を使用してサービスの表示名を取得することもできます。

パイプにおけるオブジェクト
Windows は大規模で複雑なオペレーティング システムであり、管理データをテキスト形式で格納しないため、旧式のシェル技法は、管理データの操作には不向きです。たとえば、サービスとそのスタートアップの種類についての整形された一覧を生成する SvcList.exe という名前のコマンドライン ツールがあるとします。数十年前に誕生した MS-DOS シェルの流れを強く受け継いでいる Windows コマンド ライン シェルで、次のようなステートメントを実行したとします。
SvcList.exe | MyScript.vbs
このステートメントは、サービスの一覧を取得して、一覧を VBScript ファイルにパイプします。整形された一覧を解析する VBScript ファイルを記述して、スタートアップの種類が "無効" (Disabled) に設定されているサービスを出力するなど、必要な処理を行う必要があります。この作業には時間がかかります。結局のところ、問題は、SvcList.exe の出力形式が一意で、他のコマンドが簡単に使用できる一般的な形式を使用していないことにあります。
しかし、オブジェクトでは共通の形式を提供できます。それが、Windows PowerShell パイプラインがテキストだけでなく、すべてのオブジェクトで機能する理由です。Get-WMIObject のようなコマンドレットを実行すると、オブジェクトのグループ (プログラマ用語ではコレクション) を作成することになります。各オブジェクトには、プロパティやメソッドが備わっており、開発者はこれを使用してオブジェクトを操作できます。オブジェクトを Where-Object コマンドレットにパイプすると、必要なオブジェクトだけが表示されるようにオブジェクトをフィルタ選択できます。Where-Object はテキストではなくオブジェクトを受け取っているので、テキストを解析する必要はありません。以下に例を示します。
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
短い構文を使用する場合は、次のようにエイリアスを使用できます。
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
ここで興味深いのは、Windows PowerShell がオブジェクトをパイプラインに必ず渡していることです。シェルは、オブジェクトがパイプラインの末尾に到達するまで、組み込みの書式の規則を使用してオブジェクトのテキスト表記を生成しません。たとえば、次の例について考えてみましょう。
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
この 3 つのコマンドレットは、ローカル コンピュータで実行されているすべてのサービスを取得し、ログオンに LocalSystem アカウントを使用していないサービスをフィルタアウトし、残りのサービスを Select-Object コマンドレットに渡します。Select-Object コマンドレットでは、指定した Name プロパティと StartMode プロパティのみを出力します。このコマンドレットの実行の結果は、LocalSystem としてログオンしているサービスの単純なレポートです (このレポートはセキュリティ監査に使用できます)。
すべてのコマンドレットでは、共通のデータ形式 (オブジェクト) が使用されているので、複雑な文字列の解析を行うことなくデータを共有できます。Windows PowerShell にはオブジェクトのテキスト表記を作成する機能が備わっているので、このパイプの最後では、必ず人間が解読できるテキスト出力が提供されます。図 1 に、出力の例を示します。
図 1 オブジェクトを渡す一連のパイプされたコマンドレットによって生成されたテキスト出力
図 1 オブジェクトを渡す一連のパイプされたコマンドレットによって生成されたテキスト出力

パイプの魅力
Windows PowerShell のパイプが優れているのは、Windows PowerShell で扱うものが、すべてプロパティとメソッドを完備したオブジェクトであるからです。技術的には、テキスト ファイルもファイルの各行が一意で独立した文字列オブジェクトとして動作する文字列オブジェクトのコレクションです。たとえば、メモ帳を使用して、C:\Computers.txt という名前のテキスト ファイルを作成します。このファイルにテキストを入力し、Windows PowerShell で次のコマンドを実行します。
Get-Content C:\Computers.txt | Select-Object Length | Format-List
ここでも、次のようにエイリアスを使用して短い構文を使用することができます。
gc C:\Computers.txt | select Length | fl
このコードは、テキスト ファイルの各行の長さを文字単位で提示します。Get-Content がファイルから文字列オブジェクトを取得し、Select-Object が各オブジェクトの Length プロパティを取得し、Format-List が解読可能なテキスト出力を作成します。これは実用的な管理ツールではないかもしれませんが、Windows PowerShell では、テキスト行のように単純なものもオブジェクトであることは十分に実証できたと思います。
オブジェクトをコマンドレット間 (または、コマンドレットとスクリプトとの間) でパイプできることは、非常に強力な "一行スクリプト" を作成できることになります。このような一行スクリプトは、長いパイプラインに割り当てられ、必要なものを提供するように一連のオブジェクトの精度を上げる単純なコマンドレットの文字列です。Windows PowerShell のコマンドレットは、適切なパイプラインに連結することで、スクリプトやプログラムを作成することなく、優れた結果を出すことができます。

次世代の製品をサポートする
今後リリースされるマイクロソフトのサーバー製品が Windows PowerShell に基づいて構築されるという事実は、この機能の拡張を意味します。たとえば、Exchange Server 2007 コンピュータを新たに実装する場合、Windows PowerShell を使用して、すべてのメールボックスを取得し、新しいメール サーバーを配置するオフィスで使用しないメールボックスをフィルタアウトし、該当メールボックスを新しいサーバーに移動することができます。この作業は、スクリプトを作成することなく、1 行のテキストを記述するだけで行えます。Exchange Server 2007 チームは、強力な一行スクリプトの詳細な一覧を公開しました。このページでは、パイプラインの威力とパイプラインを使用して行える管理作業を紹介しています。
Windows PowerShell を使いこなすには、この新しいツールが UNIX の世界で長い歴史を持つ原理と哲学に基づいて構築されてはいるが、Windows の管理に非常に適しているということを理解することが欠かせません。共通の用語があるという理由で、Windows PowerShell が UNIX シェルの単なる Windows 用の模造品であるとは思わないでください。Windows PowerShell には Windows プラットフォームを活用するための斬新な概念が取り入れられており、Windows での物事のやり方と密接に一体化しています。

Don Jones は Windows PowerShell MVP で、『Windows PowerShell 101』(ScriptingTraining.com) の著者でもあります。連絡先は、www.ScriptingAnswers.com (英語のみ) です。


 Hey, Scripting Guy!: 人生と同じで、スクリプトでも見た目は重要
Hey, Scripting Guy!
人生と同じで、スクリプトでも見た目は重要
Microsoft Scripting Guys

何百年、 いや何千年もの間、哲学者や賢人たちは、だれかや何かを判断するときは見た目に惑わされてはいけないと話してきました (念のため、だれかを判断する必要があると言っているのではなく、美しさは、見る人によって異なると言いたいのです)。つまり、本当の美しさは、外見ではなく内面から浮かび上がるもので、自分がどういう人間であるかということのほうが、見た目よりもはるかに重要だと言っているのです。
これについて、Scripting Guys が一言付け加えるとすれば、ナンセンスという言葉でしょう。
そう、ナンセンスです。Scripting Guys は、完璧な世界では見た目で区別されないということをよくわかっています。しかし、私たちは完璧な世界に住んでいるのではありません。もしそうだとしたら、フライド ポテトとホット チョコレート サンデーが 2 つの主要食品群を作り上げているはずです。好むと好まざるとにかかわらず、見た目は重要です。そしてこのことは、当然、スクリプトにも当てはまります。
Scripting Guys は、コマンド ウィンドウで実行している VBScript スクリプトの美しさに感極まって涙を流す人などめったにいないことはわかっています (Scripting Guy の Dean Tsaltas なら感極まって涙を流すかもしれませんが、私たちが考えつく唯一の人物です)。
一方、現在のハイテク世界においては、スクリプト作成者の仕事は、もはやコマンド ウィンドウで実行されるスクリプトを作成することだけではなくなってきていることも事実です。HTML アプリケーション (HTA) の登場により、スクリプト作成者は DHTML の能力を結集して、スクリプト向けの GUI を作成できます。また、こうした HTML の同様のスキルを使用して、Windows Vista™ のガジェットを作成することができます。ガジェットは、ご存知のように、システム管理スクリプトの作成に革命をもたらす可能性を秘めた新たな分野です。ところで、GUI についての話を始めると、うわべだけの美しさについての退屈で古くさい観念は直ちに無意味になります。グラフィカルな環境で実行されるスクリプトでは、関数やパフォーマンスとまったく同様に、見た目が重要です。
ここで問題発生です。私たちはスクリプト作成者にすぎません。グラフィカル ユーザー インターフェイスの作成について知っていることなどあるでしょうか。残念でしたね。
本当にそうでしょうか。そうでもないかもしれませんよ。今、だれか「Scrpting Guys の誠実さには頭が下がる」と言いませんでしたか。
それほどでもありません。また、何か言いましたか。「ほんのちょっと」とか、言ったでしょう。
まあ、どちらでもかまいません。私たちの助けを必要とするかどうかにかかわらず、Scripting Guys はそのためにここにいるのですから。
GUI のすばらしい世界を始めるにあたって、小さくて簡単な HTA の冒頭部分を見てみましょう (HTA の作成に関する詳細については、HTA Developers Center を参照してください)。
図 1 は、おしゃれなデスクトップ情報システムの最初の部分です。ご覧のとおり、かわいい小さなグラフィックを HTA ウィンドウの右上隅に配置することから始めました。HTA の最初の読み込み時に、ログオンしているユーザー名を取得します。次に、そのユーザー名とコンピュータ名をこの画像の上に表示します。他のすばらしい機能については後からこの HTA に追加するつもりですが、「大事なことから先に片付けなさい」とよく言われます。
図 1 とてもかわいい HTA グラフィカル インターフェイスの出発点
図 1 とてもかわいい HTA グラフィカル インターフェイスの出発点
実のところ、だれがそのようなことを言ったのかはよく知りません。おそらく、哲学者の 1 人でしょう。多分ボルテールでしょう。ボルテールが言いそうなことですね。
確かに、これは非常に小さくて簡単なアプリケーションなので、Scripting Guy の Dean ですら、その美しさ (とは言えないかもしれませんが) に感極まって涙を流すことはないかもしれません。しかし、このアプリケーションは便利なデモ ツールとしての役割を果たし、さまざまな状況に応用できる基本概念を備えています。結局、Windows Vista の仰々しいガジェットの多くも、同様の原理に基づいて動作します。つまり、ゲージや文字盤などのおしゃれなグラフィックを表示し、そのグラフィック上にテキストを書き込んでいるだけです。実際には、汎用のグラフィックに動的テキストを重ねているだけなのですが、これによって、使用可能なディスク領域の表示に小さくておしゃれなゲージが備わっているように見えます。
私たちにとってもあまり意味のない真実を皆さんにお伝えすることもないでしょう。しかし、このコラムで取り上げる細かい内容が、わずかながら明確になるはずです。
グラフィックを表示してからそのグラフィック上にテキストを書き込むことができるという考え方には、問題点が 1 つだけあります。実は、この考えでは機能しないのです。基本的な HTML タグを使用すると、見た目は図 2 のようになります。これは期待していた動作とはまったく異なります。「人間は、グラフィック上にテキストを配置することは望み得ない、少なくとも HTA 内からは」と言ったニーチェは、正しかったのかもしれません。
図 2 テキストを重ねる最初の試み
図 2 テキストを重ねる最初の試み
ニーチェは間違っていたかもしれません。今、だれか「どっちでもいいじゃない」と言いましたか。結局のところ、ありきたりな HTML を使用していては目的を果たすことができません。その方法ではまったく機能しないためです。確かに、理論上は、グラフィックを背景とし、表や改行を伴わないスペースなど、こまごまとしたあらゆるテクニックを駆使すれば、画像の上にテキストを重ねることはできます。ただし、正当な理由があって "理論上は" と言っています。最も単純なケースを除いて、この方法では機能しません。
実は、HTA や Windows Vista のガジェットのレイアウトをおしゃれにする、はるかに優れた方法があります。CSS として知られている、カスケード スタイル シートを使う方法です。
CSS は、フォント、余白や配置、色などのドキュメントの表示に関する側面を定義するために使用されます (CSSは、特に Web ページに適用されますが、HTA やガジェットも本質的には Web ページにすぎないので、CSS が同様に適用されます)。CSS を使用してどのようなことが行えるかについて説明を始めるとたいへんなことになるので、詳細については、便利かつ完全な MSDN® の CSS リファレンス ドキュメントを参照してください。ここでは、あるアイテム (テキスト) を他のアイテム (グラフィック) に重ねる機能など、CSS を使用すれば HTA のレイアウトを綿密に制御できる、とだけ言っておきます。
では、その方法すべてを説明しましょう。しかし、説明に入る前に、図 3 の非常に簡単な HTA のコードを見ておきましょう。
Figure 3 スクリプトの最終形 (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
ご覧のとおり、実に単純です。まず、Window_OnLoad サブルーチンがあります。このサブルーチンは、(その名前が示すとおり) HTA が起動または更新されるたびに自動的に実行されます。このサブルーチンについてはすぐに説明します。これ以外に、2 つの HTML 要素、グラフィックと span タグがあります。おわかりのように、次のようなタグでグラフィックを挿入し、align 属性を使用してウィンドウの右側に画像を表示しています。
<img src=”test2.jpg” align=”right”>
では、HTML の span タグについて説明しましょう。
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
よろしいですか。ここで span タグを使用しました。span タグとは何でしょう。そう、span タグの趣旨と目的は、HTA のある領域に名前を付けるだけです。その領域は、HTA ウィンドウ内で "区別" され、プログラムから識別できます (通常、span タグには ID UserData を付与するためです)。span タグを設定すれば、その span タグにテキストや HTML コーディングを割り当てるサブルーチンを記述できます。実際には、行えると言っているだけではなく、今回の HTA でこれを行いました。
しかし、前にも言いましたが、これについては後で説明します。その前に、span タグに追加された次の style パラメータを見ておく必要があります。
style=”position:absolute;left:770px;top:150px”
おわかりのように、このパラメータは、動的テキストをグラフィック上に正しく配置する際に重要な役割を果たします。ここでは実際に、異なる 3 つのスタイル属性を指定しています。
Position span を絶対位置にすることを HTA に指示します。つまり、事実上、この span は常に同じ場所に配置されます。たとえ、今回のように、テキストを別のアイテム (つまり、グラフィックなど) の上に書き込む場合でもです。
Left この属性は、span の位置を単純に HTA ウィンドウの左端からの相対位置として指定します。この例では、左端から 770 ピクセルの位置 (770px) に span を配置しています。
Top この設定は、Left 属性とよく似ています。この設定では、span の位置を HTA ウィンドウの上端からの相対位置として指定します。この例では、HTA ウィンドウの上端から 150 ピクセルの位置 (150px) に span を配置しています。
span の左を 770 ピクセル、上を 150 ピクセルの位置に設定する必要があることはどのようにしてわかったのでしょう。実は、わからなかったのです。そのため、推測しました。つまり、グラフィックをページ上に配置してから、span タグの Left 属性と Top 属性に値を割り当てました。次に、HTA を開いて結果を確認しました。ご想像のとおり、少しずれていたので値を調整して HTA を更新し、再度確認しました。ゴルディロックスのように、適切な値が見つかるまでこの作業を数回繰り返しました。
注 : ゴルディロックスと 3 匹の熊、その熊たちのベッドと椅子、熱すぎるおかゆと冷たすぎるおかゆなどについてはご存知でしょう。ゴルディロックスを偉大な哲学者と考えてよいかどうかはわかりません。しかし、他人の家に侵入し、おかゆを食べ、椅子でくつろぎ、ベッドで寝ていることを考えると、間違いなく彼女は独特の哲学を持っていると言えるでしょう。
いずれにしても、この時点での HTA の見た目を図 4 に示します。確かに芸術作品ではないかもしれません。やはり、ピカソがプログラムを使用してグラフィック上に情報を出力したところを見てみたいものです。
図 4 スタイルの力を見よ
図 4 スタイルの力を見よ
そういえば、どのようにしてプログラムからグラフィック上に情報を出力したのでしょう。そうです、良いお知らせです。お待たせしました。いよいよ、図 5 に示した Window_OnLoad サブルーチンについて説明します。
Figure 5 Window_OnLoad サブルーチン (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” & _
  strUser & “<br>” & strComputer & “</font></p>”
End Sub
このサブルーチンを少し詳しく見てみれば、実はそれほど説明することがないことにお気づきでしょう。ご覧のように、まず、Wscript.Network オブジェクトのインスタンスを作成しています。次に、以下のコード行を使用して、ユーザー名、ドメイン、およびコンピュータ名を取得します。
strUser = objNetwork.UserDomain & “\” & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
もちろん、これが HTA に書き込もうとしていた情報だったのは偶然にすぎません。ここで必要なのは、変数 strUser と strComputer を、簡単な HTML タグと組み合わせ、結果としてできた文字列を span の InnerHTML プロパティに割り当てることだけです。
UserData.InnerHTML = _
  “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” _
  & strUser & “<br>” & strComputer & _
  “</font></p>”
ええ、コードの見た目が煩雑であることはわかります。しかし、実はそれほど悪くはありません。いくつかの項目を組み合わせて 1 つの文字列にしているので、煩雑に見えるだけです。段落の開始タグから始まります。このタグでは、テキストを段落の中央に配置することを指定しています。
“<p align = ‘center’> “
次は、フォントの開始タグです。このタグでは、18 ポイントの白色のテキストを使用することを指定しています。
“<font style=’font-size:18pt;color:white’>”
strUser は、ユーザー名を Domain\UserName の形式で保持する変数です。"<br>" は、改行を挿入します。改行を挿入することで、1 行目にユーザー名、2 行目にコンピュータ名が表示されます。strComputer は、コンピュータ名を保持する変数です。最後に、次に示す、フォントと段落の終了タグをそれぞれ追加しています。
“</font></p>”
詳しく見ていけば、想像とは違って煩雑でもなんでもないことがおわかりでしょう。
ところで、ほとんどの HTML 要素は希望どおりの場所に配置できます。たとえば、ボタンをグラフィックの下部中央に配置するとします。これには、次のコードを HTA コードに追加するだけです。
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
その結果、HTA は図 6 のようになります。
図 6 実にかわいらしいボタン
図 6 実にかわいらしいボタン
こうした簡単なコードでも、ボタンを適切な位置に配置するために試行錯誤する必要がありますが、それほど時間はかからないはずです。実際、計算する気があれば、通常、適切な位置は意外に早く決定できます。各オブジェクト (style パラメータを使用して指定できる対象) の幅と高さ、および HTA ウィンドウの幅と高さがわかっていれば十分です。少なくともこの Scripting Guys のテスト コンピュータでの HTA の既定サイズは、幅約 1020 ピクセル、高さ約 685 ピクセルです (もちろん、状況に応じて結果は異なります)。ともかく、これから始めてその後要件に応じて調整することができます。
CSS の導入部としては明らかに簡単すぎましたが、美しいスクリプトの作成への道に踏み出すことができると思います。哲学者たちはこのような努力を鼻で笑い、スクリプトの真の美しさは外見からではなく内面から浮かび上がるのだと言うかもしれません。しかし、こう考えてみましょう。歴史に残る最も偉大な哲学者はだれでしょう。そうです。プラトン、ソクラテス、アリストテレスたちです。その点を踏まえて、質問します。皆さんは、こうした哲学者たちの写真をこれまでに見たことがあるでしょうか。美しさは重要ではないと言う人々の写真が存在しないという事実は面白くありませんか。それとも奇妙に感じるでしょうか。考えてみてもよいでしょう。

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


 Exchange Queue &amp; A: エッジ トランスポート サーバーの役割とハブ トランスポート サーバーの役割、仮想コンピュータなど
Exchange Queue & A
エッジ トランスポート サーバーの役割とハブ トランスポート サーバーの役割、仮想コンピュータなど
KC Lemson and Nino Bilic

2007 年 5 月号の Exchange Queue & A では、.pst ファイルをネットワーク共有に格納する場合の問題について説明しました。最近 Windows Server パフォーマンス チームによって公開が開始されたブログに、
この話題に関する技術的な説明が詳しく記載されていたため、このページへのリンクを掲載しておきます。では今月の質問に移りましょう。

Q Microsoft Exchange Server 2007 を展開する場合、エッジ トランスポート サーバーの役割を展開する必要はありますか。

A いいえ、Exchange Server 2007 を展開するためにエッジ トランスポート サーバーの役割を展開する必要はありません。1 台のコンピュータを用意し、そのコンピュータでドメインのインターネット電子メールを受け入れるための主要なサーバーの役割 (メールボックス、クライアント アクセス、ハブ トランスポートなど) を実行し、スパム対策プログラムとウイルス対策プログラムを実行すれば、Exchange Server 2007 は展開できます。

Q エッジ トランスポート サーバーの役割とハブ トランスポート サーバーの役割にはどのような違いがありますか。エッジ トランスポート サーバーを展開しなかった場合に使用できない機能について教えてください。

A ハブ トランスポート サーバーの役割は、組織内でメールをルーティングすることと、それらのメッセージにビジネス ポリシーを適用することを主な目的としています。ハブ トランスポート サーバーの役割では、トランスポート ルールはユーザーや配布リストなど、Active Directory® オブジェクトに基づきます。このため、ユーザーのグループに送信されるメッセージに免責事項を追加したり、ジャーナルを作成したりすることもできます。たとえば、DLOfUsersOnLitigationHold に送信されたすべてのメッセージのジャーナルを作成したり、DLOfMembersOfLegalTeam によって送信された電子メールに免責事項を追加したりすることができます。ハブ トランスポート サーバーではスパム対策エージェントを実行できますが、これらは既定では有効になっていないため、サーバーの \scripts ディレクトリにある install-antispamagents スクリプトを手動で実行して、スパム対策エージェントをインストールする必要があります。
エッジ トランスポート サーバーの役割は、組織の内外に電子メールをルーティングし、それらのメッセージに対してメッセージ検疫 (スパム対策、ウイルス対策、コンテンツと添付ファイルのフィルタ処理など) を実行することを主な目的としています。スパム対策機能は、エッジ トランスポート サーバーの役割をインストールすると既定で有効になります。エッジ トランスポート サーバーの役割には、Windows® ドメインに参加させる必要がないという独自の特性があり、Windows ドメインに参加していないスタンドアロンの Windows Server® で実行することができます。また、企業フォレスト内の Exchange 2007 組織の一部として管理することもできます。
この特性は、特に境界ネットワークのサーバーをワークグループに参加させる場合や、境界ネットワーク内のコンピュータ用の別のフォレストを明示的に作成した場合に役立ちます。便利なことに、このような状況でエッジ トランスポート サーバーを展開すると、企業ネットワークとインターネットとの間で送受信されるすべてのメッセージに対して、メッセージ検疫とルーティングを実行できます。それだけでなく、このエッジ トランスポート サーバーは、環境内の他の Exchange 2007 システムと共通した方法で管理できます。
エッジ トランスポート サーバーのトランスポート ルールは、Active Directory オブジェクトではなく SMTP アドレスに基づきます。もちろん、Active Directory 内の配布リストまたはユーザーの SMTP アドレスを使用することができます。エッジ トランスポート サーバーのトランスポート ルールの大部分は、ハブ トランスポート サーバーのトランスポート ルールのサブセットです。例外は、エッジ トランスポート サーバーでのみ使用できる検疫アクションです。
エッジ トランスポート サーバーでは、エージェントを介して、ハブ トランスポート サーバーでは提供されないいくつかの機能を使用することもできます。これらは、添付ファイルの削除機能とアドレス書き換え機能です。添付ファイルの削除は、拡張子が .exe や .com などの、危険性のあるファイルを選択して削除できる機能です。アドレス書き換えエージェントを使用すると、電子メールのヘッダーを書き換えることができます。たとえば、ユーザー アカウントのドメイン アドレスと既定の SMTP プロキシ アドレスが @contoso.com のネットワークからインターネットにメッセージを送信した場合に、受信者にはそのメッセージの送信者が @northwindtraders.com として表示されるようにすることができます。また、エッジ トランスポート サーバーは、ドメインまたはアドレス空間のみに基づいてルーティングを実行するため、Exchange と他の電子メール システムとの間で同一の SMTP アドレス空間を共有する場合、そのルーティングをハブ トランスポート サーバー上で実行するか、エッジ トランスポート サーバー上でアドレス書き換えエージェントを使用して実行することが必要になります。
もう 1 つの重要な考慮事項は、Exchange 2007 サーバーが直接インターネットに接続されているかどうか (ハブ トランスポート サーバーの役割またはエッジ トランスポート サーバーの役割を実行しているかどうか) ということです。つまり、ドメインの MX レコードに基づいたポート 25 への接続が、何らかの形で Exchange 2007 に接続されているかどうかということです。インターネット上には、ドメインの電子メールを受け入れ、その電子メールを企業ネットワーク内の Exchange に渡す、SMTP ゲートウェイ、ウイルス ウォール、またはその他のソリューションが既に構成されていると思います。直接インターネットに接続されるコンピュータに、エッジ トランスポート サーバーまたはハブ トランスポート サーバーを展開すると、Exchange 2007 の最も素晴らしい機能の 1 つを活用することができます。その機能とは、セーフリスト集約です。セーフリスト集約を使用すると、ユーザーによって送信者 (インターネット ニュースレターや小売企業からの電子メールなど) が追加された Microsoft Outlook® のセーフリストを、エッジ トランスポート サーバーまたはハブ トランスポート サーバーの役割が実行されたコンピュータに安全に伝播させることができるため、それらの送信者からのメッセージはコンテンツ フィルタから除外されます。もちろん、同一の電子メールでも、それをスパムと見なすか重要なニュースレターと見なすかはユーザーによって異なるため、セーフリスト集約はユーザーごとに構成できます。セーフリスト集約の詳細なしくみについては、Exchange 2007 のドキュメントを参照してください。
ハブ トランスポート サーバーの役割が実行されたサーバーで、ドメインのインターネット電子メールを受け入れる場合、いくつかのことに注意する必要があります。もちろん、まずは優れたファイアウォールやポート フィルタ ソリューションを使用して、必要なポート (ポート 25 など) への接続のみをサーバーが受け入れるようにする必要があります。また、スパム対策エージェントは既定でインストールおよび有効化されていないため、これらをインストールする必要があります。ハブ トランスポート サーバーは、企業ネットワーク内で最もよく展開されるため、既定では匿名接続を許可していません。このため、ポート 25 の受信コネクタの AnonymousUsers 許可グループを確認する必要があります。また、セーフリスト集約を有効にし、定期的に実行されるようにスケジュールを設定することをお勧めします。これにより、ユーザーが各自のメールボックスのセーフリストを更新すると、それらの安全な送信者からの電子メールがコンテンツ フィルタから除外されます。詳細については、私たちのブログを参照してください。
次のコードは、SafeList.bat というバッチ ファイルを使用して、すべてのサーバー上のすべてのメールボックスを毎日午後 11 時に更新する AT コマンドです。
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
次のコードは、SafeList.bat ファイルの内容を示しています。
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
使用している設定が適切に機能しているかどうかを確認するには、Exchange 2007 のドキュメントを参照してください。

Q Exchange がインストールされた Virtual PC イメージを起動した後、ディレクトリや LDAP サーバーへのアクセスに関する問題が発生し続けています。ポート 389 への telnet 接続は成功し、すべてのサービスが実行されています。なぜこのような問題が発生するのでしょうか。

A 私も昨年の Tech Ed で同じ問題を経験しました。私は職場のコンピュータからラップトップに Virtual PC をコピーし、翌月の Exchange 2007 Beta 2 のリリースと同時に記事を発表する報道陣向けに、デモンストレーションを計画していました。
この製品のデモは何回も経験しており、このビルドが安定していることを知っていたため、あまり入念には準備していませんでした。月曜の朝、最初のミーティングの数時間前に Virtual PC を起動し、準備したビルドがまったくドメイン コントローラにアクセスできないことを知ったときの、額に汗した私の姿を想像できるでしょう。その場に非常に頭の切れる人々がいてくれたおかげで、すぐに問題を解決することができました。
この Tech Ed での大失敗は、処理速度が非常に遅い私のラップトップで Virtual PC を実行したことが原因でした。問題の根本は、DNS と Active Directory の競合状態にありました。イメージ上の DNS サーバーは、Active Directory と統合されるように構成されていましたが、イメージ上でサービスが読み込まれる順序 (それと、繰り返しになりますが、私のラップトップの遅さ) が原因で、DNS サーバーが Active Directory にアクセスしようとするまでに、必要なディレクトリ サービスが開始されませんでした。
この状況は、DC と Exchange が同一のコンピュータ (仮想イメージに限りません) で実行されている場合に発生する可能性があります。特に、さらにパフォーマンスが低下する仮想化環境 (私のラップトップのように処理速度が遅いコンピュータではなおさらです) の方が、発生する可能性は高くなります。
また、Virtual PC イメージを別のコンピュータにコピーしたときにも問題が発生しました。この問題は、特にコピー先のコンピュータが別のネットワーク上にあるときに発生します。この問題が発生した場合は、イメージ内の OS の IP アドレスを確認してください。古いネットワークから割り当てられた古い IP アドレスを使用している可能性があります。IP アドレスを新しいネットワークから取得して更新し、問題が解決されるかどうかを確認してください。
今後このような問題を回避する方法の 1 つとして、ゲスト上の DNS サーバーを Active Directory に統合しないようにし、ホストとゲストの両方に DNS をインストールするという方法があります。この方法では、ゲストが不明なレコードの解決をホストに転送し、ホストが不明なレコードの解決を適切な DNS サーバーに転送するようにします。イメージが起動し、DNS レコードの更新を試行した場合、問題が発生する可能性は低くなります。

Q Exchange 2007 のセットアップは、以前のバージョンの Exchange とはまったく異なっていると思います。このセットアップの動作について教えてください。

A そうですね。Exchange 2007 のセットアップは、非常にさまざまな段階から構成されています。では、セットアップ プロセス全体の動作について大まかに説明しましょう。

まず setup.exe を起動すると、実際のサーバーの役割をインストールするために必要なほとんどの前提条件へのリンクを提供するプロセスが起動します。これらの前提条件をすべてインストールしたら、[Microsoft Exchange のインストール] リンクをクリックできるようになります (図 1 を参照)。
図 1 全般的な要件がすべて満たされたときにクリックできるようになるインストールのリンク
図 1 全般的な要件がすべて満たされたときにクリックできるようになるインストールのリンク
ネットワーク上の別のコンピュータにある setup.exe を実行し、[インストール] リンクをクリックした場合、主要なセットアップ ファイルがローカル コンピュータの %TEMP%\ExchangeServerSetup\ フォルダにコピーされます。その後、セットアップ ウィザードが起動します。
セットアップ ウィザードでは、使用許諾契約書、エラー報告、インストールの種類 (この段階で、インストールするサーバーの役割を選択できます) など、さまざまな選択を行ってセットアップを進めていきます。ウィザード ページの内容は、既に Exchange 組織が存在するかどうか、およびその Exchange 組織 (存在する場合) の状態によって異なります。
インストールの種類を選択したら、セットアップはインストールの前提条件の確認を行います。ここで実行されるプログラムは、Microsoft Exchange Server ベスト プラクティス アナライザ (BPA) に微調整を加えたものであり、既定では、インターネットに接続して必要な XML ファイルの最新バージョンをダウンロードします。このプログラムを実行することにより、前提条件を定期的に更新したり、製品のリリース後に Exchange チームによって確認された問題に対処したりすることができます。前提条件の確認が完了したら、結果を確認し、セットアップ プロセスを続行します。問題が検出された場合は、セットアップ プロセスを続行する前に、それらの問題を解決することが必要になる場合があります。サーバーで前提条件の確認が失敗しても、多くの場合、再度確認を実行できます。
前提条件の確認段階を通過したら、[インストール] ボタンをクリックし、前の段階で選択した役割のインストールを開始できます。選択した役割のファイルのみが、コピーおよびインストールされます。
セットアップの最後には、Exchange 管理コンソールが起動されます。また、利用可能な Exchange 2007 の更新プログラムが適用されます。

KC Lemsonは、Exchange Server のユーザー エクスペリエンス マネージャです。彼女のオンライン銀行口座は一時的に停止されています。
Nino Bilicは、Exchange Server のサポータビリティ プログラム マネージャです。彼は最近クレジット カードに 2 番目の電子メール アドレスを追加しました。


 セキュリティ ウォッチ: ACL 管理用ツール
セキュリティ ウォッチ
ACL 管理用ツール
Jesper M. Johansson

Windows では、アクセス制御リスト (ACL) を使用して、ユーザーやプロセスから、ファイルやフォルダなどのリソースを使用する権限を極めて細かく制御できます。ACL の管理は、ユーザーのシステムのセキュリティ保護に関連する複雑な作業の 1 つです。さいわい、便利なユーティリティが多数あります。
こうしたユーティリティは、アクセス許可や ACL に関連する作業の自動化や簡素化に役立ちます。
ほとんどの読者は、古くからある cacls.exe ツールを使い慣れています。このツールは、Windows NT® で最初に同梱され、それ以降すべてのバージョンに付属しています。Windows Vista™ で cacls.exe を実行すると、次のメッセージが表示されます。
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
マイクロソフトは、Windows Vista の ACL に対する更新 (これについては、2007 年 6 月号の TechNet Magazine (technetmagazine.com/issues/ 2007/06) で説明しました) に加え、ACL の管理に使用するツールもいくつか更新しました。興味深いことに、この中で最も大きく更新されたのがコマンド ライン ツールです。
icacls.exe は Windows Vista で新たに導入されました (やや機能の低いバージョンが Windows Server® 2003 Service Pack 2 にも含まれています)。icacls.exe は最終的には cacls.exe に置き換わる予定です。お気付きかもしれませんが、このツールは更新が不完全で、Windows® 2000 で導入されたきめ細かなアクセス許可をサポートしなかったため、約 7 年も遅れた更新となってしまいました。
驚くことに、cacls.exe は廃止予定であるにもかかわらず、実際にはいくつかの新機能を含んでいます。まず、接合ポイントとシンボリック リンクの両方を認識し、これらを詳しく調査できます。次に、セキュリティ記述子定義言語 (SDDL) 文字列を使用して ACL の出力と設定の両方を実行できます。
ただし、cacls.exe が更新されたとはいえ、実際には、icacls.exe に含まれる機能が必要です。

ACL の保存と復元
過去 10 年間 (少なくとも私は)、後日復元できるように ACL を保存する機能を待ち望んできました。これは、ACL に対して実行できる最も複雑な操作の 1 つになります。ある特殊な場合を除いて、そもそも ACL が壊れていなかった元の状態に正確に戻せる可能性はほとんどありません。それでも、この機能は非常に役に立つ可能性があります。
ACL の保存や復元の方法を詳しく説明する前に、まず、これがなぜそんなに難しいかを説明しましょう。たとえば、ある地方大学に学生のユーザー データを含む階層があるとします。2 月 1 日に ACL を保存しましたが、4 月 17 日に、ACL がどういうわけか壊れていることに気付いたので、保存したコピーから復元するとします。この操作に何か複雑な点はあるでしょうか。
まず、新学期は 4 月 2 日に始まりました。学生の約 15% が卒業したため、卒業した学生のディレクトリはもう存在しません。したがって、バックアップ ファイルには、無効な ACL があります。また、新学期から、新入生の一団 (15%) も入学してきました。新入生にはホーム ディレクトリが用意されましたが、バックアップ ファイルには ACL がありません。彼らの ACL はどうしましょう。当然、70% の学生はまだ在籍していますが、彼らは新しいファイルやフォルダの作成や、ファイルやフォルダの削除を行っています。削除されたファイルやフォルダは無視できますが、新しく作成したフォルダはどのように構成すればよいでしょうか。学生が 3 月 4 日に友人とフォルダを共有していた場合はどうなるのでしょう。ACL を復元するときに、共有が解除されてもかまわないでしょうか。
ACL の保存と復元は、多くの人が思っているほど簡単に実行できる操作ではありません。このような操作を行う場合は、慎重に進める必要があります。結果として、不明確な動作を行うことになる可能性もあります。間違いなく、ACL の復元は最後の手段です。バックアップしてから時間が経つほど、復元時に何かが機能しなくなる可能性が高くなります。
それでもこの機能を使用する場合は、/save スイッチを使用して icacls.exe を実行します。
icacls <target> /save acls.bin /t
これにより、ACL は acls.bin というファイルに保存されます。ファイルには、ACL が設定されたオブジェクトごとに 1 行、その後、SDDL で ACL を指定する 1 行が含まれます。/t スイッチを使用すると、指定したオブジェクトと、そのオブジェクトの下にあるすべてのオブジェクトとコンテナを対象にコマンドが機能します。
保存機能がツールキットに加わったのは喜ばしいことですが、この機能にはいくつか欠陥があります。たとえば、システム アクセス制御リスト (SACL) ではなく、随時アクセス制御リスト (DACL) のみが保存されます。実際、SACL があると、このことを示すダミー値は保存されますが、SACL のどの部分も保存されません。
また、ACL の保存方法から、興味深い問題が生じています。保存した ACL をお気に入りのテキスト エディタで開く際は、次のことを忘れないようにしてください。
保存した ACL は編集しないでください。
保存した ACL を含むファイルをテキスト エディタで開くと、一見 Unicode (UTF-16) 形式のテキスト ファイルのように見えます。実際、ほとんどテキスト ファイルです。そのため、テキスト エディタで ACL を編集および保存できると考えがちです。しかし、このような操作は行わないでください。
保存した ACL が含まれるファイルをテキスト エディタで開いてから保存すると、そのファイルから ACL を復元できなくなります。結局、実際には Unicode テキスト ファイルではなかったことがわかります。Unicode テキスト ファイルは、2 バイトの 0xfffe で始まらなければなりません。メモ帳などのテキスト エディタでファイルを保存すると、実はこのフラグがファイルの先頭 2 バイトに設定されます。しかし、icacls.exe ツールでは、ACL データがファイルのバイト 0 の位置から始まると想定しています。その結果、先頭 2 バイトも操作対象のオブジェクトを示す文字列の一部であると見なされ、ファイル内の ACL を解析できず、バックアップ ファイルが使用できなくなります。
マイクロソフトではこの問題を認識していますが、Windows Vista のベータ期間終了間際に報告されたため、リリース前にこの欠陥を修正できませんでした。現時点では、いつ修正するか、さらには修正するかどうかもわかりません。したがって、今のところ、保存した ACL は編集しないことをお勧めします。編集が必要な場合は、ファイルを .bin ファイルとして保存して、 (お好みの開発環境などの) 16 進エディタを使用してください。
/save スイッチを使用して ACL を保存したら、/restore スイッチを指定して icacls.exe を実行し、ACL を復元できます。最も単純な形式の復元コマンドは、次の構文を使用します。
icacls <directory> /restore acls.bin
復元手順は、ファイル単位には機能しません。これを確認するために、図 1 に示す一連のコマンドをご覧ください。ここでは、1 つファイルを対象に icacls.exe を実行して、保存ファイルを作成しています。その後、/save を /restore に置き換えて、そのファイルを復元します。この操作は失敗します。それは、復元コマンドがディレクトリのみで機能するためです。復元対象のファイルは、acls.bin ファイル内に既に指定されています。ACL を復元するには、ファイルではなくディレクトリを指定します。これは最後のコマンド行で行っており、操作対象のオブジェクトに "." を指定します。
Figure 1 ACL の保存と復元 (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
復元コマンドは権限を昇格して実行する必要があることにも注意してください。保存コマンドは、ACL の読み取り権限さえあれば、権限の低い管理者や標準ユーザーで実行されているコマンド プロンプトからも実行できます。ただし、ACL を復元するには、完全な管理トークンが必要です。

SID の置き換え
icacls.exe の非常に便利なもう 1 つの機能に、あるユーザーのアクセス許可を別のユーザーのアクセス許可に置き換える機能があります。この置き換えは、復元時に /substitute スイッチを使用して行います。substitute スイッチに関するドキュメントでは、このスイッチには SID が必要であると記載されていますが、後から、実際には通常のユーザー名も指定できると説明されています。したがって、図 2 に示すシーケンスが機能します。
Figure 2 復元時の SID の置き換え (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
ご覧のとおり、結果として以前と同じ ACL になりますが、foo のアクセス許可を指定するのに使用された ACE は、代わりに bar のアクセス許可を指定するようになります。

所有者の変更
UNIX システムでは主に、chown ツールが長い間使用されてきました。本来、Windows には、オブジェクトの所有者を変更する方法は組み込まれていませんでした。その後、setowner ツールがリソース キットに組み込まれ、takeown.exe ツールが Windows NT 4.0 に組み込まれました。ただし、このユーティリティを使用しても所有権を得ることしかできず、相手のパスワードを知らない限り、所有権を他のユーザーに付与することはできませんでした。icacls.exe には、所有者を設定できるアクセス許可が与えられているオブジェクトの所有者を設定する機能が組み込まれるようになりました。
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
残念ながら、icacls.exe ではオブジェクトの所有者を表示できません。実際には、コマンド ラインからオブジェクトの所有者を表示する方法はありません。さらに、オブジェクトの ACL を保存しても、オブジェクトの所有者は保存されません。
icacls.exe にも、所有者を変更する際に SeTakeOwnershipPrivilege を呼び出さないというバグがあります。ACL に基づいてオブジェクトの所有者を変更する権限があれば、icacls.exe は通常どおり機能します。ただし、管理者であっても、オブジェクトの ACL に基づいて所有者を変更するアクセス許可がなければ、このバグが原因で、この操作に icacls.exe を使用することはできません。その場合は、takeown.exe ツールを使用する必要があります。このツールからは SeTakeOwnershipPrivilege を呼び出しますが、任意のアカウントではなく、使用中のアカウントまたは Administrators グループに所有者を変更することしかできません。
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
当然ながら、subinacl ツール (Microsoft ダウンロード センターからダウンロード可能) にも setowner スイッチがあることに注意してください。実際、多くの場合 subinacl は icacls よりも直感的に機能しますが、使用はさらに複雑になります。

特定のユーザー向けファイルの検索
icacls には、他にも便利な機能があります。特定のユーザーにアクセスが許可されたファイルを検索できます。以下に例を示します。
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
これは、特定のユーザーがアクセスできるファイルを確認する場合に役立ちます。

ACL のリセットと変更
ACL が破損した場合や破棄された場合、icacls.exe では、親から継承するように ACL をリセットできます。これは、2006 年秋に発生したゼロデイのセキュリティ問題で非常に役立ちました。Windows コンポーネントでの問題を緩和するために使用された方法の 1 つは、オブジェクトに対する Everyone のアクセス許可を拒否することでした。拒否することは容易でしたが、Windows XP や Windows Server 2003 の組み込みツールを使用しても、そのアクセス制御エントリ (ACE) を削除することはほぼ不可能でした。しかし、Windows Vista では、次のコマンドを実行するだけでリセットできます。
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
もちろん、icacls.exe では、標準の許可、拒否、削除の操作すべてを行うことができます。これらの操作のうち、実際に新しいのは、削除だけです。このスイッチを使用すると、特定のオブジェクトや階層から、指定したユーザーのすべての許可 ACE、すべての拒否 ACE、またはその両方を削除できます。許可、削除、および拒否の各操作の例を図 3 に示します。
Figure 3 許可、拒否、および削除の操作 (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
拒否 ACE のみを削除する機能は、特定のグループやユーザーまで、オブジェクトのアクセスを許可する場合に役立ちます。

整合性レベルの設定
icacls.exe には、整合性レベルを表示および設定する機能もあります。Windows Vista では、オブジェクトへの整合性ラベルの設定がサポートされます。icacls.exe は、この操作に使用するコマンド ライン ツールです。
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
icacls.exe は、オブジェクトに整合性ラベルが明示的に設定されている場合にそのラベルを表示するだけです。ほとんどのファイルには明示的に設定されていないため、表示されることはめったにありません。
最後に、icacls.exe では、オブジェクトに正規の ACL があることを確認できます。既に説明したように、サードパーティのツールでは、ACL に ACE を間違った順序で配置することがわかっています。icacls.exe では、次に示すように、こうした問題を確認して修正できます。
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

ACL UI
ACL UI (ACL ユーザー インターフェイス) は、Windows XP から多少変更されました。Windows XP と Windows Vista の ACL UI のダイアログを、それぞれ図 4 と図 5 に示します。
図 4 Windows XP の ACL UI ダイアログ
図 4 Windows XP の ACL UI ダイアログ
図 5 Windows Vista の ACL UI ダイアログ
図 5 Windows Vista の ACL UI ダイアログ
ご覧のように、いくつか変更点があります。まず、ダイアログでは、最終的に、操作対象となるオブジェクトが非常に明確に表示されます。これは、同時に複数のオブジェクトを操作している場合に役立ちます。次に、一番下に関連情報へのハイパーリンクがあります。しかし、最も注目すべき変更は、[追加] ボタンと [削除] ボタンがなくなったことです。これら 2 つのボタンが [編集] ボタンに置き換わっています。[編集] ボタンは、主に Windows Vista のユーザー アクセス制御 (UAC) をサポートするためにあります。ボタン上に盾が表示されていることからわかるように、このダイアログを起動したユーザーは、ACL を編集するアクセス許可がないため、アクセス許可を編集するには、権限を昇格する必要があります。C: ドライブのルートにフォルダを作成した直後にプロパティを確認すると、盾が表示されないことに注意してください。フォルダの所有者であれば、ACL を編集する暗黙のアクセス許可があるため、盾が表示されません。盾は COM モニカを表します。COM モニカは、実行中のプロセスの一部に対して権限の昇格を問い合わせるプロンプトを表示するために使用されるメカニズムです。[編集] をクリックすると、なじみのある昇格ダイアログが表示されます。昇格ダイアログで [続行] をクリックすると、Windows XP で [追加] をクリックしたときに表示されるのとほぼ同じダイアログが表示されます。ACL UI は複数の局面でこうした 2 種類のダイアログの概念に従っています。権限の昇格が行われるまでは 1 つのダイアログを表示し、昇格が行われると、以前のバージョンの Windows の使い慣れた古いダイアログが表示されます。
[詳細設定] をクリックして [監査] タブをクリックすると、図 6 に示すように、権限の昇格を必要とするボタンが必ず表示されます。オブジェクトのフル コントロール権限を持っていたり、そのオブジェクトの所有者であっても、権限を昇格しないと監査を変更できません。これは、オブジェクトの SACL を変更する権限が SE_SECURITY_NAME 特権によって管理されているためです。この特権は、GUI ツールでは "監査とセキュリティ ログの管理" と表示されます。既定でこの権限があるのは管理者だけです。ただし、(UAC が有効な場合に) 管理者承認モードで管理者からこの特権が削除されると、管理者であっても、権限の昇格が必要になります。
図 6 Windows Vista で監査設定を変更する場合は常に権限の昇格が要求される
図 6 Windows Vista で監査設定を変更する場合は常に権限の昇格が要求される
ACL を変更する際に必要な権限の昇格について、最後の注意点です。それは、ここに記載した内容はすべて、UAC を無効にしていないことが条件であるという点です。UAC を無効にすると、ダイアログの見た目が異なることを除き、すべての動作が Windows XP の動作に戻ります。ただし、トークンには常に Administrators の SID が含まれるようになるため、管理者としてログオンした場合、権限の昇格は必要ありません。

その他のツール
icacls.exe は、cacls.exe を根本から改良した、非常に有益なツールですが、まだいくつか欠点があります。おそらく、ファイルとディレクトリ以外のオブジェクトへのアクセス許可を管理できないことがその代表です。Windows Vista でのその他のオブジェクトの ACL への変更は、Windows XP に比べればあまり行われていませんが、サービス、レジストリ キー、または Active Directory® オブジェクトの ACL の管理が必要になることもまだまだあります。
コマンド ラインの愛好家であれば、この操作には subinacl.exe が必要です。subinacl.exe は、サポート ツールに含まれています。また、ダウンロードすることもできます。
ただし、断っておきますが、subinacl.exe の使用は簡単ではありません。実際、まったく役に立たない場合もあります。一方、アクセス制御を管理する場合は実に強力なツールです。すべての管理者は、このツールを必要とします。

レジストリの ACL
レジストリの ACL は、ファイル システムの ACL とまったく同様に変更が行われました。ただし、この変更は、ファイル システムへの変更ほど範囲は広くありません。以前のバージョンの Windows との最も明確な違いは、Power Users の廃止により、ほとんどすべての Power User ACE がなくなったことです。Power Users は、他のユーザーよりも強力であるべきではありません。ただし、Power Users のすべての ACE が実際になくなるわけではないため、ACL が実際にいかに複雑になったかを証明するにすぎません。残念なことに、いくつかは残ってしまいました。
レジストリの ACL を見ていくと、いくつかの場所に RESTRICTED という SID の ACE があるのが確認されます。これは、Windows Vista で新しく導入された SID ではありませんが、十分に理解されていない、興味深い SID です。RESTRICTED SID は、制限付きトークンを提示するプロセスを示します。制限付きトークンは、CreateRestrictedToken API の特殊な機能を使用して作成されます。このようなトークンでは、1 つ以上の SID を制限します。これらの SID は、個別のアクセス チェックに使用されます。たとえば、制限付きトークンで実行されているプロセスがあるとします。そのプロセスから RESTRICTED SID の ACE を備えたオブジェクトにアクセスを試みると、実際には、Windows で 2 つのアクセス チェックが実行されます。まず、通常のアクセス チェックが行われます。次に、最初のアクセス チェックとまったく同様に機能しますが、トークンで制限している SID のみに対してアクセス チェックを行います。両方のアクセス チェックに合格する必要があります。
現状では、特にレジストリに、RESTRICTED SID を使用する ACL が複数あります。図 7 に、こうした ACL のスクリーン ショットを示します。
図 7 レジストリの ACL で RESTRICTED の ACE を複数の場所に含める
図 7 レジストリの ACL で RESTRICTED の ACE を複数の場所に含める
現時点では、特に SID を制限することに関して、制限付きトークンの機能を使用するプロセスはほとんどありません。実行するプロセスの一例として、Windows ファイアウォール、ベース フィルタ エンジン、および診断ポリシー サービスをホストするサービス プロセスがあります。このプロセスでは、書き込み制限付きのトークンも使用します。調べたところ、Windows Vista では、現在、9 個のサービスのみで、RESTRICTED トークンと書き込み制限付きトークンを使用しています。
以前のバージョンの Windows と同様に、レジストリのアクセス許可に関するベスト プラクティスは、慎重に進めます。例外的な状況や対象を限定する場合を除いて、レジストリのアクセス許可は変更しないでください。複雑な継承モデルや注意を要する操作がレジストリで実行された場合に、そのレジストリの ACL を不注意に変更すると、致命的なエラーが受け入れがたいほど高い確率で発生します。

まとめ
Windows のほとんどのバージョンと同様に、Windows Vista でもアクセス制御が少し変更されています。ただし、他のいくつかの最新バージョンとは異なり、最終的には動作の大幅な変更につながる、小さな変更が数多く行われています。特に、UAC は、整合性ラベルや ACL UI の変更など、複数の変更が必要でした。さらに、これまでの記録上初めて ACL が大幅に整理されました。
多くの点で、Windows の既定の ACL が Windows Vista で簡略化されました。このようなことは今まで一度もありませんでした。ただし、これまでのバージョンと同様に、アクセス制御については十分に理解するまで、慎重に扱う必要があります。このことは、特に新しいバージョンの OS で当てはまります。このコラムで説明したツールを使用することで、ACL の調査が楽になるとよいのですが。

Jesper M. Johansson は、ソフトウェアのセキュリティ問題に取り組む Principal Security Engineer で、TechNet Magazine の編集にも携わっています。MIS の博士号を持ち、コンピュータ セキュリティの分野で 20 年以上の経験があります。このコラムは、Roger Grimes と Jesper Johansson が共同で執筆した新しい書籍『Windows Vista Security: Securing Vista Against Malicious Attacks』(Wiley、2007 年刊) から引用したものです。


 デスクトップ ファイル: Microsoft Desktop Optimization Pack
デスクトップ ファイル
Microsoft Desktop Optimization Pack
Wes Miller
このコラムは、Microsoft Desktop Optimization Pack のプレリリース版の要素を基にしています。ここに記載されているすべての情報は変更される可能性があります。

マイクロソフトは、数年前にソフトウェア アシュアランス (SA) ライセンス プログラムを開始してから、ユーザーにとっての価値が高まるように、継続的に SA に機能を追加しようと努めてきました。また、ライセンスに含まれているマイクロソフト製品のアップグレードを提供するだけでなく、
Windows や Office を始めとするマイクロソフト製のソフトウェアの操作性を向上するための製品やテクノロジ (たとえば、Windows® PE が最初の 1 つです) を提供することにも努めてきました。
このようなツールとプログラムの多くは、組織の SA 適用範囲に含まれる Windows や Office をはじめとするマイクロソフト アプリケーションの総保有コストを削減するための追加機能を提供することを目的としています。
2006 年に、マイクロソフトは共通した目的の下に複数の企業を買収しました。この目的とは、Windows や Windows ベースのアプリケーションについて、総保有コストを削減し、管理と修復に伴う複雑さを緩和するということでした。マイクロソフトは、新しく買収した多くのテクノロジを新製品に組み込み、SA を所有するユーザーが付加価値として利用できるようにしています。Softricity、DesktopStandard、AssetMetrix、および Winternals Software 各社のテクノロジは、Microsoft® Desktop Optimization Pack (MDOP) のコンポーネントとして、来年中には入手可能になります。また、MDOP には、Microsoft System Center Desktop Error Monitoring と呼ばれる、マイクロソフト社内で構築したコンポーネントも含まれる予定です。
コスト削減の観点から話をすると、マイクロソフトは、MDOP を使用する組織はデスクトップ 1 台当たり 1 年につき 100 ～ 500 ドル節約できると見積もっています。実際にどれくらい節約できるかは、MDOP の使用時に実装するベスト プラクティスによって異なります。MDOP の詳細については、オンライン (windowsvista.com/optimizeddesktop) でご確認ください。

Microsoft Desktop Optimization Pack の目標
簡単に言うと、MDOP の主な目標は、マイクロソフトが新しい管理テクノロジをもっと柔軟なスケジュールで提供できるようにすることです。新しいオペレーティング システムのリリースと併せて新しい管理テクノロジを提供するのでは遅いのです。つまり、マイクロソフトは、Windows XP と Windows Vista™ の間にあった時間の空白を再び作ってしまうことがないようにする必要があります。MDOP によって、リリース間に想定可能なタイムフレームでツールを提供すれば、マイクロソフトは MDOP ユーザーのニーズに柔軟に対応できるようになります。その結果、企業ユーザーはソフトウェア投資の価値を最大限に高めることができます。
マイクロソフトは、企業の俊敏性を高めるために、ユーザーがより動的なインフラストラクチャに移行できるようにするための戦略を模索してきました。動的とは、マイクロソフトが Dynamic Systems Initiative (DSI) で定義する意味においてです。DSI の詳細については、microsoft.com/business/dsi に記載されている情報をご覧ください。
高レベルな戦略についてはこれで十分です。それでは、MDOP に含まれている 5 つの各テクノロジを見てみましょう。
  • SoftGrid Application Virtualization
  • Asset Inventory Service
  • Diagnostics and Recovery Toolset
  • Advanced Group Policy Management
  • System Center Desktop Error Monitoring

SoftGrid Application Virtualization
SoftGrid Application Virtualization は Softricity 社から買収したもので、その名のとおり、アプリケーションの仮想化を提供します。SoftGrid について詳しく調べ始めたころ、それが Windows 2000 IntelliMirror® のアプリケーション発行機能が強化されたものであることに気付きました。その理由は、アプリケーションが、クライアントに発行されるのではなく、完全に仮想化されるからです。このため、アプリケーションは、クライアント (またはターミナル サーバー) システムで簡単に使用できます。重要なのは、アプリケーションを一元管理できるだけでなく、必要に応じて、取り消したり更新したりできることです。SoftGrid モデルでは、MSI や変換の従来のモデルに比べて、アプリケーションを展開する際の手間やリスクが大幅に減少します。
SoftGrid を評価する方法の 1 つは、仮想イメージの意味を考えることです。Windows (および多くの場合は Windows に含まれるアプリケーション) をシステムに展開するときに使用するディスク イメージの概念については理解されていることでしょう。SoftGrid は実質的にはアプリケーションを取得して、それを OS イメージ全体ではなくアプリケーション イメージにパッケージ化します。
SoftGrid Application Virtualization は、アプリケーションの仮想化、アプリケーションの配信、および一元管理コンソールという 3 つの主要なコンポーネントで構成されています。
アプリケーションの仮想化自体は、すべてのコンポーネントの Windows ファイル システム (システム ファイルを含む)、Windows レジストリ、フォント、.ini ファイル、COM オブジェクトと DCOM オブジェクト、サービス、カーネル オブジェクト (セマフォ、ミューテックス)、名前付きオブジェクト、および名前空間を仮想的に表現したもので構成されます。
重要なのは、SoftGrid の仮想化を Windows Vista UAC でリダイレクトを実行する方法と間違えないようにすることです。UAC を使用した場合、アプリケーションがレジストリやファイル システムの保護された領域に対して書き込みや変更を行おうとすると、レジストリやファイル システムのユーザー固有のビューにリダイレクトされます。一方、SoftGrid では、アプリケーションをオペレーティング システムに適切に仮想化する概念を使用します。これには、オペレーティング システムを構成するすべてのレジストリ コンポーネントとファイル システム コンポーネントが含まれます。しかし、SoftGrid のスマートさは、アプリケーションを定義する単一の BLOB がないことです。そうではなく、SoftGrid は次の項目で構成されているのです。
  • 最大 4 GB の SFT ファイル。1 つ以上のアプリケーションとそのすべての依存関係 (Windows 依存関係を除く) が含まれます。これらは、対象のシステム上にあると考えられます。
  • 約 2 KB の OSD ファイル。アプリケーションをどのように要求して実行するかの定義が含まれます。OSD ファイルは、EXE と見なすことができます。
  • 約 24 KB の ICO ファイル。実質的には、アプリケーションを起動するショートカットです。
  • 約 13 KB の SPRJ ファイル。シーケンサ (SoftGrid の中核となるツール) によって、既存のパッケージを公開する、開く、更新する、修復するといった処理を行うときに使用されます。
SoftGrid Application Virtualization のしくみについては、Web サイト (softricity.com/products/architecture.asp) の説明図を参照してください。
SoftGrid ソリューションの大きな利点は、一元管理コンソール (図 1 参照) を使用して、特定の Active Directory® ユーザーまたはユーザー セットが使用できるアプリケーションを決定できることです。決定したアプリケーションは、業界標準のストリーミング プロトコルを経由して、オンデマンドでユーザーにすばやく配信されます。アプリケーションは、一度インストールされると、ローカルにインストールされているかのように動作します。また、アプリケーションは (移動ユーザー プロファイルを使用した場合でも) ユーザーがカスタマイズした内容を認識し、クライアントがネットワークから切断されている場合でも機能します。管理者は、動的または自動的に (一定時間経過した後など)、アプリケーションを使用できないようにすることもできます。
図 1 SoftGrid Management Console
図 1 SoftGrid Management Console
最も重要なのは、アプリケーションをこのような方法で展開するため、アプリケーション全体を入手できる必要がないことです。アプリケーション全体ではなく、ユーザーが使用しているアプリケーションの実行に必要な部分だけがダウンロードされます。Microsoft Office すべてをパッケージとして入手できるようにするシナリオを想像してみてください。ユーザーが Word しか実行しない場合は、Word の実行に必要なコンポーネントだけがダウンロードされます。Excel® や PowerPoint® などの実行に必要なコンポーネントはダウンロードされません。ユーザーがこのようなアプリケーションの 1 つ (たとえば、Excel) を実行するとすぐに、必要に応じて、関連するコンポーネントがダウンロードされます。
ERD の内容
  • Command Prompt (コマンド プロンプト)
  • Explorer (エクスプローラ)
  • Search (検索)
  • Notepad (メモ帳)
  • Solution Wizard (ソリューション ウィザード)
  • Administrative Tools (管理ツール): Autoruns、Disk Management (ディスクの管理)、Event Viewer (イベント ビューア)、Registry Editor (レジストリ エディタ)、Services and Drivers (サービスとドライバ)、System Information (システム情報)
  • Networking Tools (ネットワーク ツール): File Sharing (ファイル共有)、Map Network Drive (ネットワーク ドライブの割り当て)、TCP/IP Configuration (TCP/IP 構成情報)
  • System Tools (システム ツール): Crash Analyzer (クラッシュ分析機能)、Disk Commander (ディスク復旧機能)、DiskWipe (ディスク内容の完全削除機能)、FileRestore (ファイルの復旧機能)、Hotfix Uninstall (修正プログラムのアンインストール機能)、Locksmith、System File Repair (システム ファイルの修復機能)、System Restore (システム復元機能)

SoftGrid のもう 1 つのコンポーネントとして、メータリングとライセンスの自動チェックを実行する機能があります。この機能により、追加のソフトウェアを必要とすることなく、ソフトウェア ライセンスに準拠した状態を保つことができます。
ほとんどすべてのアプリケーションを仮想化できます。主な例外として、Internet Explorer® を始めとする Windows コンポーネント (修正プログラムや Service Pack を含む)、ウイルス対策ソフトウェア、およびデバイス ドライバがあります。SoftGrid の動作の詳細や SoftGrid で実行できることの調査に関心がある方は、Softricity.com にあるホワイト ペーパーを確認することをお勧めします。

Advanced Group Policy Management
DesktopStandard 社は、グループ ポリシーの脆弱なリンクの一部を強化するツールを開発したことで有名になりました。マイクロソフトは、Advanced Group Policy Management (以前は MDOP の GPOVault として知られていたツール) という優れたツールを提供しています。このツールを使用すると、強力 (場合によっては危険) な GPO を、より洗練されたプロセスとして管理できます。
ソース管理ソフトウェアの基本をよく理解されている方は、Active Directory グループ ポリシーのソース管理として Advanced Group Policy Management を想像してみてください (Advanced Group Policy Management コンソールのスクリーンショットについては、図 2 を参照してください)。管理者は、既存のポリシーの変更をチェック アウトして変更を行い、その変更をチェック インすることで、グループ ポリシー管理コンソールのようなレポートを使用して結果を監査します。管理者は、必要なポリシーの状態に達したことを確認できたら、変更をコミットして保持することができます。優れたソース管理ソフトウェアと同様に、問題が発生したときは、変更内容を変更前の状態に迅速かつ安全にロールバックできます。このプロセスでは、作業手順に迷うようなことはありません。
図 2 Advanced Group Policy Management コンソール
図 2 Advanced Group Policy Management コンソール
このプロセスのもう 1 つの主な側面として、ポリシーをオフラインで編集する機能があります。オンラインのアクティブなシステムすべてに変更を加える必要はありません。このため、ドメインまたは OU 全体に変更を加える前に、変更を切り離してテストできます。
最後に、Advanced Group Policy Management では、役割ベースのモデルを使用することで、デザインされたワークフロー プロセスを通じて変更を行うことができます。管理者は、役割 (編集者、校閲者、承認者など) を作成することで、制御された方法で変更を加えることができるプロセスを適切に導入できます。したがって、実装者が変更をコミットできると確信しても、強力な変更管理メカニズムがあるので、適切な承認なく無条件に GPO の変更を行うことはできません。

Asset Inventory Service
Asset Inventory Service は、マイクロソフトが AssetMetrix 社を買収して獲得したテクノロジから構成されている、非常に強力なインベントリおよび資産管理ソリューションです。MDOP の他のコンポーネントとは異なり、AIS はホストされた Web モデルを使用します。AIS は、一度だけまたは定期的に実行できる、ロー フットプリントかつ低帯域幅のエージェントを使用します。このため、管理者は、400,000 を超えるアプリケーションが含まれている、マイクロソフトがホストする大規模なデータベースを検索して、どのアプリケーションがクライアント システムにインストールされているのかを判断できます。その後、AIS は、このロールアップされたデータを取得してそのデータを購入済みのライセンスと一致させることで、法令遵守を保証し、ライセンスの過剰購入による浪費を軽減できます。
管理者によっては、最初は、AIS を使用するのをためらうことがあります。これは、AIS がファイアウォール外でホストされたモデルであり、インストールされたソフトウェアの内部システムの一覧を作成するためです。しかし、重要なのは、AIS を構成するアプリケーションの核となるコンポーネントを再作成することから始めて、マイクロソフトが組織のプライバシーを保証するために行ってきた幅広い作業を理解することなのです。各コンピュータのデータを再度組織のデータに結び付けることはありません。また、マイクロソフトは、ユーザーが AIS で使用されているモデルに満足できるように、サードパーティのデータ転送テクノロジも保証する予定です。

Diagnostics and Recovery Toolset
(ここ数か月間に私のコラムを読んだことがあれば) ご存知かもしれませんが、私は、マイクロソフトが Winternals 社を買収したときは、Winternals 社の社員でした。Winternals 社に在職中、Winternals Administrator’s Pak など、ほとんどの Winternals 社製品のプロダクト マネージャを務めていました。Winternals Administrator’s Pak は、Microsoft Diagnostics and Recovery Toolset (DaRT) の前身だったものです。以前 Administrator’s Pak に含まれていたツールの中には、DaRT に同梱されていないものがありますが、ERD Commander 製品を構成する主要なコンポーネントは引き続き使用できます。
DaRT の目的は、システムが正常に起動しない場合でもシステムの問題を診断できるツール セットを提供することです。また、このような問題はオフラインで修復できることがよくあります。
ERD Commander では、Windows PE を使用して、起動されていないか、正常に起動していないシステムを起動します。Windows エクスプローラのようなカスタム ユーザー インターフェイスで、一連のツールを使用できます。これらのツールのうち Crash Analyzer (クラッシュ分析機能) および FileRestore (ファイルの復旧機能) の 2 つは、オンラインでも使用することができます。ただし、オフラインでの診断や復旧に ERD Commander を使用していないシステムでこれらのツールを実行したい場合は、そのシステムにこれらのツールをインストールする必要があります。
図 3 に、DaRT バージョンの ERD Commander を示します。ERD Commander コンポーネントに同梱されているツールの一覧については、補足記事を参照してください。Explorer (エクスプローラ) ツールを除き、最初の 5 つのツールは、通常の Windows インストールで使用するのと同じアプリケーションです。Explorer (エクスプローラ) は、起動元のスタート メニュー アプリケーションと同様、Windows PE で実行されるように開発された特殊な (小さい) バージョンです。
図 3 ERD Commander
図 3 ERD Commander
Autoruns は、Sysinternals 社の同じ名前のツールから派生したツールで、システムの起動時やユーザーのログオン時に起動するように設定されているすべてのアプリケーションを表示できます。Disk Management (ディスクの管理)、Event Viewer (イベント ビューア)、Services and Drivers (サービスとドライバ)、および System Information (システム情報) は、一般的なユーザー インターフェイス内に存在するツールで、Windows にある同じ名前のツールと同等のエクスペリエンスを提供します。Services and Drivers (サービスとドライバ) は、正常に動作しないデバイス ドライバやサービスが原因で、システムのエラーが発生している場合に、システムを起動できるようにする点で特に役立ちます。最後に、オフライン システムのレジストリを操作できるように、Windows レジストリ エディタが含まれています。
ネットワーク接続は、ERD Commander でも使用できます。システムは DHCP により自動的に構成されますが、静的 IP アドレスは TCP/IP Configuration アプレットを使用して設定できます。DHCP と静的な IP アドレスのどちらを使用するかに関係なく、ネットワーク ドライブを割り当ててダウンしたシステムとの間でファイルをコピーするか、ファイル共有を使用してシステムをファイル サーバーに変換し、作動中のシステムを使用して障害が発生したシステムからファイルをコピーすることができます。
最後に、含まれているその他のツールについても紹介します。Crash Analyzer (クラッシュ分析機能) は、Debugging Tools for Windows を使用してクラッシュの原因を診断します。Debugging Tools for Windows は、別にダウンロードしてインストールする必要があります。また、Debugging Tools for Windows は無償ですが、頻繁に更新されます。Crash Analyzer (クラッシュ分析機能) は、システムが起動していない場合に ERD Commander でオフライン実行するか、DaRT がインストールされている実行中のシステムに DMP ファイルをコピーして診断することができます。問題の原因がわかっていて、その原因が新しいサービスやドライバにある場合は、Services and Drivers (サービスとドライバ) ツールを使用して該当するサービスやドライバを無効にし、システムが再度正常に機能するようになるかどうかを確認できます。
Disk Commander (ディスク復旧機能) は、誤って削除または破損したパーティションだけでなく、削除されたファイル グループやディレクトリも復元できます。対照的に、DiskWipe (ディスク内容の完全削除機能) を使用すると、DoD 対応のディスクやボリュームを完全に削除できます。FileRestore (ファイルの復旧機能) を使用すると、誤って削除された 1 つのファイルを (オンラインでもオフラインでも) 回復できます。どのツールを使用する場合でも、ファイルの種類と、削除後の時間やディスクの動作状況が回復性に影響することを覚えておいてください。
Windows 修正プログラムや Service Pack が原因でシステムが正常に起動しなくなった場合は、Hotfix Uninstall (修正プログラムのアンインストール機能) を使用して、1 つ以上の修正プログラムまたは Service Pack を選択してアンインストールできます。Windows はオフラインでのアプリケーションの完全な削除をサポートしていないため、プロセスを完了するには、再起動する必要があります。多くの場合、再起動するように指示されます。
Locksmith は、Winternals 社の ERD Commander ツールセットに同梱されている、非常に人気の高いツールの 1 つでした。このツールを使用すると、ローカル ユーザーのパスワードをリセットできます。Locksmith はドメイン コントローラでは機能しないので、ドメイン ユーザーのパスワードをリセットすることはできません。通常は、パスワードを忘れたり組織を辞めたりしたローカル管理者のパスワードをリセットするために使用されます。System File Repair (システム ファイルの修復機能) は、保護されているすべてのシステム ファイルを調査して破損していないかどうかを確認し、必要に応じて置き換えます。System Restore (システム復元機能) を使用すると、名前からわかるとおり、Windows XP システムの Windows システム復元ポイントにロールバックまたはロールフォワードできます (この機能を使用するには、Windows XP に復元ポイントが事前に設定されている必要があります)。私もこの非常に優れた機能に救われた多くのユーザーの 1 人です。
ERD Commander および DaRT のツールは、多少まとまりがないように見えるかもしれませんが、Winternals 社が長い期間をかけて開発したユーティリティをまとめたものです。皆さんはこれらのユーティリティの価値を見出し、これらのユーティリティが復旧作業やトラブルシューティング作業に役立つことを理解してくれるでしょう。

System Center Desktop Error Monitoring
System Center Desktop Error Monitoring (DEM) により、組織は、Windows のクラッシュやアプリケーションのハングを迅速かつ簡単に一元管理および診断できます。DEM は、マイクロソフトにクラッシュやハングに関するレポートを送信するのではなく、グループ ポリシーや組み込みの Windows エラー報告を使用して、組織内の診断用に指定されたサーバーにレポートを送信します (追加のソフトウェア エージェントは必要ありません)。DEM サーバーのすべてのデータは SQL Server データベースに格納されるため、所有している内部アプリケーションやレポート用に収集したデータを簡単に照会できます。これにより、組織内の問題を事前に診断できます。この情報を使用すると、このような障害のレポートを要求し、クラッシュやハングの主な原因を突き止めることができます。さらに、システム ダウンタイムを最小限に抑えるか解消するために、Windows やアプリケーションの修正プログラムに対し確実に優先順位を付けることができます。
また、マイクロソフトに結果をアップロードするように DEM サーバーを構成するだけでなく、マイクロソフトやサードパーティのアプリケーションの最新のトラブルシューティング データを DEM で自動的にダウンロードすることもできます。クラッシュやハングが発生したときに、クライアントから追加データを収集できます。

MDOP のライセンス
ユーザーが MDOP のライセンスを取得するための第 1 要件は、既にマイクロソフト SA 契約を結んでいることです。ライセンスの初期コストはデスクトップ 1 台ごとに 7 ～ 10 ドルです。ボリューム ディスカウントや教育機関向けの価格設定もあります。
MDOP は SA 契約のコンテキスト以外では入手できませんが、1 つだけ例外があります。それは、SoftGrid テクノロジをターミナル サーバー (softricity.com/solutions/sbc.asp を参照) や SMS (softricity.com/products/softgrid-sms.asp 参照) と共に使用するユーザーです。AssetMetrix テクノロジは、今後の SMS および System Center Configuration Manager のリリースで使用できるようになります。

可用性と更新プログラム
現在、MDOP の初期コンポーネントが入手できます。各コンポーネントは次のように配布されています。
  • SoftGrid は、2007 年初期から、マイクロソフトが提供しています。
  • Microsoft DaRT は、2007 年 5 月から提供されています。
  • GPOVault テクノロジは、2007 年 7 月から提供されます。
  • Desktop Error Monitoring は、2007 年 7 月から MDOP で提供されます。
  • AssetMetrix テクノロジは、2007 年 7 月にベータ版で提供され、8 月にリリース版で提供されます。
  • DaRT コンポーネントの更新プログラムは 2007 年後半に提供される予定です。主な拡張は Windows Vista との互換性です。
MDOP の今後のリリース計画では、年に 2 回、機能強化、アップグレード、および新機能を提供していく予定です。

MDOP の方向性
前述のとおり、AssetMetrix テクノロジの主要なコンポーネントは、System Center Configuration Manager の今後のバージョンに統合される予定です。実際、マイクロソフトが時間をかけて MDOP 機能を進化させていくにつれて、その一部がマイクロソフトの基準となる展開、管理、および構成テクノロジに少しずつ入っていくことを予想できます。新しいテクノロジ (マイクロソフトが作成したものもあれば、他の企業から買収したものもあります) は、MDOP の今後のバージョンでも使用できます。つまり、MDOP は、最先端の管理および構成テクノロジの、進化中のパッケージとなります。

Wes Miller は、テキサス州オースティンにある Pluck 社の開発マネージャです。以前は、オースティンにある Winternals Software に勤務しており、その前はマイクロソフトで Windows のプログラム マネージャとプロダクト マネージャを兼任していました。Wes の連絡先は、technet@getwired.com (英語のみ) です。
このコラムの執筆に協力してくれた Microsoft Desktop Optimization Pack のプロダクト マネージャである Chad Jones と Gavriella Schuster に感謝します。


 Windows 秘話: セーフ モードの治癒力
Windows 秘話
セーフ モードの治癒力
Raymond Chen

Windows のセーフ モード (またの名を "おかしくなっちゃった、助けて" モード) が Windows® 95 で初めて導入されたときに行っていた処理はドライバを無効にすることだけでした。また、自動的に修復できるものを修正することも目的としていました。
たとえば、セーフ モードで起動すると、アイコンが画面に表示されない場所に配置されていることがあるので、エクスプローラでは、デスクトップにあるすべてのアイコンの位置を確認し、すべてのアイコンが表示されるようにします。
ここで説明している状況を再現するには、デスクトップにアイコンを 2 つ作成し、1 つを画面の左端に、もう 1 つを画面の右端に配置します。<formatting role="bold">Ctrl</formatting> キーを押しながら 2 つのアイコンをクリックして選択し、左端にあるアイコンをドラッグして画面の右端に移動します。右端にあるアイコンはドラッグしたアイコンとの相対位置を維持するため、この操作を行うと、右端にあるアイコンも一緒に移動されます。そのため、右端にあったアイコンが画面上から消えてなくなります。
ユーザーはセーフ モードを使用すると Windows をトラブルシューティングできる
ユーザーはセーフ モードを使用すると Windows をトラブルシューティングできる
セーフ モードで起動したときにエクスプローラがアイコンの位置を修正しないと、トラブルシューティングの指示は役に立つどころか、混乱を招きかねません。
  1. コンピュータをセーフ モードで起動します (さて、起動しました)。
  2. [マイ コンピュータ] アイコンをダブルクリックします (おや、私のデスクトップには [マイ コンピュータ] アイコンがありません)。
  3. ...
[マイ コンピュータ] アイコンは画面上から消えてなくなっているか、または利用できない状態です。私は、トラブルシューティングの手順 2 で行き詰まってしまいました。
ユーザーからは「アイコンを自動的に修復しないでほしい。」という意見が寄せられています。「この問題について技術サポートに問い合わせたときに、サポート担当者が、デスクトップを右クリックし、アイコンの位置を元に戻すオプションをクリックするという方法を伝えれば、問題を修正できるし、セーフ モードを使用することによってデスクトップにあるアイコンの位置がおかしくなってしまうことはない。」と。
そもそも "ユーザーが、この問題について技術サポートに問い合わると" という時点で試合に負けています。ユーザーが問い合わせなければならないという状況が発生した時点でアウトです。
また、この提案は、セーフ モードを使用するユーザーの心理状態に気付いていません。ユーザーがセーフ モードで起動した後に何をしなければならないのかを把握していないことはありますが、ユーザーがセーフ モードで起動するのは、コンピュータが正常に動作しない場合です。ユーザーは単に自動修復の状況を眺めているのが関の山です。何かがおかしいからセーフ モードを試してみるといった具合です。Windows 95 では、このようなユーザーの心理状態を利用して、セーフ モードにさまざまな自動修正処理を実装しました。これは実にうまくいきました。
ユーザーからの問い合わせに対して「セーフ モードで起動すれば、問題が自動的に修復されます。」と伝えたらどうでしょうか。ユーザーは「それなら簡単だ。どうしてもっと早く試さなかったのだろう。」と思うでしょう。
「セーフ モードで起動して、ここを右クリックしてください。次に、このメニュー オプションを選択し、このボックスをクリックしてください。」というように長い指示を提示した場合、ユーザーは指示に従って問題を修復することはできますが、ユーザーがコンピュータを使いやすいものと感じるようにすることには貢献できません。それどころか、ユーザーは、自分が無力だと感じ、コンピュータを使わなくなってしまうかもしれません。ユーザーは、自信を持つどころか、学習性無力感という状態に陥り、「自分では、この解決策を見つけることは到底できなかった。コンピュータとは難解なものだ。」と思ってしまうことでしょう。

Raymond Chenは自分の Web サイト「The Old New Thing」および同じタイトルの書籍 (Addison-Wesley、2007 年) で、Windows の歴史と Win32 プログラミングについて扱っています。彼は爆弾の導火線に火が付く前に逃げ出すことをよしとする人です。