 TechNet Magazine February 2008

TechNet Magazine February 2008

Sharepoint: 企業内のデータを賢く収集する方法

情報は、企業の最も重要な資産の 1 つです。しかし、電子メール、Web ベースのフォーム、アンケートなどのメカニズムによって収集される大量のデータを管理することは難しい場合があります。この記事では、Microsoft Office system を使用してシステムを統合し、簡単にデータにアクセスできるようにする方法について説明します。

Keith Deshaies SharePoint: 強力なアンケート用インフラストラクチャを構築する

データの収集と分析はビジネスにとって欠かせませんが、各チームが必要とするデータを必要なときに収集できるツールが必要です。この記事では、WSS 3.0、MOSS 2007、および InfoPath 2007 を使用して、全社規模で使用できる包括的で柔軟なアンケート ソリューションを構築する方法について説明します。

Jim Bradley Sharepoint: カスタム コンテンツ タイプを使用してデータ管理を標準化する

多種多様なドキュメントやその他のコンテンツ アイテムが大規模な組織内の至る所に大量に保存されている場合、それらのドキュメント、関連するメタデータ、およびドキュメントの動きを集中的かつ再利用可能な方法で管理することは難しくなる可能性があります。この記事では、SharePoint 2007 のコンテンツ タイプを使用して、企業全体のコンテンツ管理を簡略化する方法について説明します。

Pav Cherny Office Communications Server: プレゼンスが OCS 2007 にもたらす力

Office Communications Server 2007 は、音声通話、ビデオ会議、電子メール メッセージ、IM のいずれを送信する場合でも、ユーザーの連絡可能性に関する情報を使用して、通信を最も適切な場所にルーティングします。この記事では、OCS 2007 システムがどのようにプレゼンスを使用してエンドポイントどうしを結び付けているかについて説明します。

Rajesh Ramanathan Office Communications Server: OCS 2007 ボイスの展開を計画する

Office Communications Server 2007 を既存の PBX システムと統合するのは困難な作業です。これには統合シナリオを選択し、通話のルーティングを理解し、ユーザー設定の構成の方法を把握し、番号計画に対応するなどの必要がありますが、心配する必要はありません。この記事で必要な知識について説明します。

Jochen Kunert and Rui Maximo ハイ パフォーマンス コンピューティング: Windows Compute Cluster Server の概要

ハイ パフォーマンス コンピューティングは、大規模な専用システムに頼ることなく、小規模かつ標準的なシステムのクラスタを使用します。このようにワークロードを分散することで、コストのかからないソリューションによって複雑な問題をすばやく解決できます。この記事では、Windows Compute Cluster Server 2003 で提供される計算クラスタ機能とサポートについて説明します。

John Kelbley and Doug Lindsey オンライン番外編: ターミナル サービスを使用して 2007 Office system を展開する

2007 Microsoft Office system ではデザインが変更されています。ターミナル サービス サーバー ファームに展開する前に、このような変更点を認識しておく必要があります。この記事では、主な変更点を紹介します。

James D. Silliman 編集長から: 膨大な量の情報に対処する

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

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

Greg Steen SQL に関する Q&A: 非クラスタ化インデックスと権限の保持

Saleem Hakani and Dan Carollo ユーティリティ スポットライト: ADMX Migrator

Windows Vista では、グループ ポリシー テンプレートの形式が XML ベースの構造に変更されました。ADMX Migrator ユーティリティを使用すると、従来の ADM ファイルを新しい ADMX 形式のファイルに変換できるだけでなく、独自の ADMX ファイルを簡単に作成することができます。

Lance Whitney The Cable Guy: IEEE 802.1X ワイヤード認証

IEEE 802.1X 認証を使用すると、イントラネットへのアクセスに新たなセキュリティの防壁を設けることができます。Windows Vista と Windows Server 2008 で、ワイヤード (有線) ネットワークでの IEEE 802.1X 認証の実装がどのように容易になったかを紹介します。

Joseph Davies Windows PowerShell: シェルでアクセス許可を操作する

Windows のアクセス許可は、残念ながら本質的に複雑です。しかし、Windows PowerShell が役立つ可能性があります。この記事では、Windows のアクセス許可のしくみについて簡単に概説した後、これらを簡単に操作する方法について説明します。

Don Jones Hey, Scripting Guy!: 競技会へのお誘いと XML 関連のスクリプト

Microsoft Scripting Guys が 2008 Scripting Games について延々と語ります。また、XML ドキュメントを作成および変更する方法や、XML ドキュメントにデータを追加する方法について説明します。ところで、2008 Scripting Games については既にご存知でしょうか。

The Microsoft Scripting Guys セキュリティ ウォッチ: 島巡り : 望ましくない依存関係を軽減する

セキュリティ上望ましくない依存関係によって、ネットワーク全体が攻撃にさらされることがあります。この記事では、環境の依存関係を分析して潜在的な問題を解決できるように、セキュリティの依存関係のしくみについて説明します。

Jesper M. Johansson デスクトップ ファイル: Windows XP と Windows PE 2.0 によるデュアル ブート

Windows と同じパーティションから Windows PE 2.0 をブートすることには、多くのメリットがあります。この記事では、Windows XP と Windows PE 2.0 を同じパーティションからデュアル ブートする方法と、その方法を使用することで解決される問題について説明します。

Wes Miller フィールド ノート: PC を寄付する

古くなったハードウェアを寄付すると、古くなったハードウェアがごみ廃棄場行きになることがなくなり、環境保護にもつながります。この記事では、古くなったコンピュータ機器から個人情報を完全に削除して、コンピュータを再利用できるようにするためのヒントを紹介します。

Jim Lynch Windows 秘話: 不要になった機能を廃止する

この記事では、あまり需要が高くない 2 つの機能が削除された経緯について説明します。

Raymond Chen


 Sharepoint: 企業内のデータを賢く収集する方法
Sharepoint Keith Deshaies

企業内のデータを賢く収集する方法
概要:
  • データを収集して処理する
  • プレゼンテーション ロジックと情報管理ロジックを分離する
  • Microsoft Office 2007 テクノロジを使用してデータ収集ソリューションを構築する
この記事で使用しているコードのダウンロード: DataGathering2008_02.exe (567KB)

企業では、膨大な量の情報がさまざまな方法で収集されます。これらのデータは、電子メール、アンケート、Web フォーム、およびその他のデータ収集メカニズムによって取得されます。通常、データとは便利な
ものです。しかし、一連のデータ収集ツールとさまざまな種類の情報をすべて管理することは困難です。信頼性の高い方法でデータを統合して安全に共有することは、IT 組織が常に直面している課題です。標準とサービス指向アーキテクチャは進化しており、より安全かつ容易に IT プロフェッショナルがデータにアクセスできるようになってきました。しかし、企業のアーキテクチャを効率的に構築できるツールやテクノロジを所有していても、ツールやテクノロジどうしを相互運用できないことがよくあります。これは、ソリューションの孤立につながります。
たとえば、Microsoft® Office system で使用できるテクノロジを例に考えてみましょう。Windows® SharePoint® Services 3.0 を使用すると、部署別のアンケートをすばやく作成できますが、これが標準のソリューションであるかどうかは組織によって異なります。Web ベースのコラボレーションとデータの統合を実装するためのプラットフォームとして ASP.NET と SharePoint を使用している企業では、このようなアンケートを標準のソリューションとして使用できます。しかし、私が作業しているような環境では、SharePoint は数あるプラットフォームのうちの 1 つでしかありません。
確かに、SharePoint では IBM、HP、Siebel などのシステムとの統合を行うためのさまざまなオプションが提供されます。これは、特定の目的を達成するためのソリューションを作成し、最終的にデータをさまざまなバックエンド システムに渡す必要がある上級ユーザーにとっては便利です。ただし、ソリューション アーキテクトは、InfoPath® 2007 というさらに優れた方法も利用できます。
2007 Office system に含まれている InfoPath 2007 を使用すると、ソリューションのプレゼンテーション ロジックと、サーバー側でホストされる情報管理ロジックを分離できます。XML ベースの InfoPath テクノロジを使用すると、企業規模のデータ収集ソリューションを構築できます。また、InfoPath フォームをデザインする際に、XML、Web サービス、ソリューション アーキテクチャ、ASP.NET、SharePoint オブジェクト モデルなどに関する詳細な知識が必要になることはほとんどありません。
この記事では、InfoPath 2007、Office SharePoint Server 2007、および Forms Services を使用して柔軟なデータ収集ソリューションを構築する方法について説明します。また、XML を使用して、複数の層から構成されるエンタープライズ アーキテクチャのプレゼンテーション ロジックとビジネス ロジックをどのように分離できるかについても説明します。
この記事で使用する "データ収集" という言葉は、人的情報源から情報を収集するプロセスを指しています。もちろん、データ ソースのクロールなど、データ収集の方法は他にもありますが、このような自動化された方法については、この記事では扱いません。

データを取得して処理する
データの取得要件は複雑になる可能性がありますが、共通している部分がいくつかあります。このような共通部分を一元管理用のモジュールで処理し、分離したコンポーネントで一意の要件を処理することによって、余分な作業の量、保守作業に関連するオーバーヘッド、および総保有コストを削減できます。
たとえば、株式会社では、法令遵守規定を基にビジネス要件が決定され、この要件を基に全社の情報管理ポリシーが決定されます。このようなポリシーは、複数の部署にまたがるデータ収集ソリューションに影響し、多くの場合、各部署内で重複した作業が発生します。たとえば、個人情報の収集に関するルールがあります。人事部によって社員情報の処理のために個人情報が収集され、顧客サービス部門によって顧客情報の処理のために個人情報が収集される場合、2 つの部署で重複した作業が発生します。部署間で似ているが関連していないビジネス プロセスが存在する場合、情報管理ソリューションを統合できる可能性があります。
図 1 は、典型的なビジネス プロセスの例を示しています。仕事の割り当てを同僚と交換する場合、まずその同僚の同意を得ます。次に、仕事のスケジュールの管理者または調整役の承認を受け、最後に上司からの承認を受けます。たとえば、従業員が勤務シフトを交代する場合がこれに該当します。このような交換はさまざまな部署で発生し、異なるフォームが使用される可能性がありますが、ワークフローと情報管理ロジックは、各部署のソリューション間で共有できます。
図 1 部署間で共有できるデータ収集プロセスの例
図 1 部署間で共有できるデータ収集プロセスの例
もちろん、重複するコンポーネントの統合は、非常に手間のかかる作業です。全社規模で組織の変更を進めるのは簡単ではありませんが、Office system テクノロジを使用すると、このような変更を簡略化できる堅固な基盤を構築することができます。InfoPath 2007 を使用すると、一元化および標準化された情報管理システムと統合できるフォーム アプリケーションを部署ごとに作成できます。また、IT 部門は、SharePoint 2007 を使用すると、サイト コレクション、サイト、およびドキュメント ライブラリの管理作業を個々の部署やチームに委任できます。この結果、IT 部門がほとんど関与しなくてもチームが独自のソリューションを構築および展開できるようになります。また、引き続き IT 部門が、ワークフロー、情報管理ポリシー、バックアップ手順など、すべての共有サービスおよびコンポーネントを管理できます。

データ収集作業を一元化する
多くの場合、企業では、各部署用のアプリケーション サーバーを用意して、それぞれの情報管理のニーズに対応しています。IT 部門の作業はハードウェアとオペレーティング システムの稼動状態を維持することのみであり、ソリューションの管理はすべて各部門が行います。部署間の調整はほとんどないため、情報の共有は困難です。
データ収集を一元化する際の技術的な課題は、主に、共有環境でホストされるカスタム コンポーネントのセキュリティ、パフォーマンス、保守、およびサポートに関連しています。たとえば、部署用のアプリケーション サーバーで個々のソリューションがホストされる場合は、動作に異常があるコンポーネントの影響範囲はそのアプリケーション サーバーに限定されます。しかし、共有環境では、動作に異常があるコンポーネントが、より広範囲のビジネス プロセスに影響する可能性があります。したがって、IT 部門は一元管理用のシステム上で実行されるカスタム コンポーネントの展開と保守に関する厳密なポリシーを定義する必要があります。
各部署の SharePoint ソリューションを一元管理用のサーバー ファームでホストするには、各部署のソリューションで実行されているカスタム コンポーネントをすべて一元管理用のアプリケーション サーバーに展開して保守する必要があります。あるソリューションでは、カスタム フィールド型を使用してソリューションの UI を拡張し、バックエンドの Web サービスから取得したデータを基にドロップダウン リストを表示している可能性があります。別のソリューションでは、同じ目的で Web パーツを使用していたり、カスタム ワークフローを使用していることが考えられます。これらはすべてマネージ コードで記述されており、Microsoft .NET Framework アセンブリとして展開されています。
比較的少数の SharePoint ソリューションを一元管理用のアプリケーション サーバー ファームに移動する場合でも、構成やサポートに関する複雑な問題が発生する可能性があります。アセンブリをグローバル アセンブリ キャッシュ (GAC) に展開する必要がある場合、そのアセンブリは完全に信頼されたアセンブリとして実行されるため、セキュリティに関する問題が発生します。プログラムが適切に記述されていないコンポーネントが原因で、システムが SQL インジェクション、クロスサイト スクリプティング、またはサービス拒否攻撃を受ける可能性があります。また、これらのコンポーネントが、通常のワークロードだけでなく、ピーク時の要求や長時間の運用にも対応できるようにする必要があります。さらに、これらのコンポーネントが他のプロセスをブロックしないようにして、イベントが同期を取って処理されるようにしたり、信頼性の高い入力データ検証を実行して、ユーザーがデータベースやリモート Web システムの更新に使用される列に、SQL ステートメントやスクリプトを挿入できないようにしたりする必要もあります。
まとめると、最終的な目標は、標準の製品機能を基に安全性とスケーラビリティに重点を置いたサーバーを構成することです。十分にテストされた再利用可能なソリューションを使用すると、多数のカスタム コンポーネントを作成する必要がなくなります。フロントエンドを分離し、バックエンドを一元管理するという方法は理にかなっています。重要なことは、コンポーネントの結合度を抑えて、既存のソリューションの再利用性を高めることです。

ビジネス ロジックを分離する
では、サーバー上に構成できる柔軟なデータ収集ソリューションを構築するには、どうすればよいでしょうか。最善の戦略は、図 2 のようにソリューションのアーキテクチャを個別の層に分割することです。これらは、データ リポジトリ層、ビジネス ロジック層、およびプレゼンテーションまたは UI 層です。最近の一般的なアーキテクチャでは、UI がブラウザで提供され、ビジネス ロジックが Web アプリケーション サーバーに配置されます。これらはそれぞれ、データベースや非リレーショナル データ リポジトリにアクセスします。
図 2 3 層アーキテクチャを基盤とする一般的な企業用ソリューション
図 2 3 層アーキテクチャを基盤とする一般的な企業用ソリューション
多くの場合、ビジネス ロジックにはトランザクション ロジックが含まれており、トランザクションがデータベース管理システム間で自動的に適用されるようになっています。また、ビジネス ロジックでは、HTTP、メッセージ キュー、RPC などを経由して複数の中間層サービスを統合している場合があります。ただし、全体的なソリューションのアーキテクチャは基本的に 3 層モデルのままです。
図 2 には、企業環境でのビジネス ロジックの複雑さが表されていません。この図のアプリケーション サーバーは、単にブラウザ ベースのフォームの表示と送信されたデータの処理のみを行っており、ワークフロー、法令遵守、または情報管理に関する要件は考慮されていないように見えます。これらの要件に対処するには、ビジネス ロジックをプレゼンテーション ロジックと情報管理ロジックの 2 つに分割する必要があります。これにより、ソリューションごとに最初からコンポーネントを構築し直すことなく、中間層のコンポーネントを必要に応じて組み合わせることができます。
図 3 は、このアーキテクチャを示しています。中心にはコンテンツやデータがあり、それを情報管理ロジックが囲んでいます。このロジックが、コンテンツのライフサイクルの最初から最後までコンテンツを制御します。プレゼンテーション ロジックは、情報管理ロジックと連動して、ユーザー インターフェイスを使用したデータへのアクセスを提供します。
図 3 プレゼンテーション ロジックと情報管理ロジックの分離
図 3 プレゼンテーション ロジックと情報管理ロジックの分離

XML を収集して処理する
サービス指向アプリケーション (SOA) 環境では、コンポーネント間でデータとデータ構造を共有したり、これらを定義したりする際に、主に XML が標準として使用されます。したがって、プレゼンテーション コンポーネントと情報管理コンポーネント間の通信には XML が適しています。
通信では 2 つの処理を実行する必要があります。つまり、XML をブラウザから参照できるドキュメントに変換するだけでなく、フォームから XML ドキュメントを生成する必要があります。最近まで、XML ベースのフォーム アプリケーションの作成には、かなり高度なプログラミング技術が必要でした。組織間の情報交換を容易にするために、結果として得られる XML データを業界で使用されているスキーマに準拠させる必要がある場合は、特に高度な技術が必要でした。
InfoPath 2007 を使用すると、XML ベースのフォームの開発が大幅に簡素化されます。XML に関する詳細な知識があれば役立つことは確かですが、フォーム デザイナや上級ユーザーは、XML に精通していなくても、XML ベースのフォーム アプリケーションを作成できます。必要な作業は、XML ドキュメントや XML スキーマを InfoPath にインポートし、データソースの個々の属性と要素のノードをフォームのフィールドにマップすることだけです。また、Web サービスや SQL Server® データベース、または空白のテンプレートを基にフォームを最初から作成することもできます。この場合、基になるスキーマとデータ バインドが InfoPath によってバックグラウンドで自動的に作成されます。
InfoPath と XML スキーマを使用したフォームの標準化には、いくつかの利点があります。既に適切に定義された XML スキーマがある場合は、ワークフローのフォーム デザイナと開発者、および情報管理コンポーネントが揃っていれば、同じデータ構造を基にソリューションを作成できます。フォーム デザイナが一から作業を行う場合、開発者は、基になるデータ構造にそのデザインが与える影響を確認するために、フォームが完成するまで待機する必要があります。データ構造を一度定義すれば、今後新しいフォーム テンプレートなどのソリューションを同じデータ構造で作成する際に、既存のワークフローと情報管理コンポーネントを再利用できます。また、今後作成するワークフローや情報管理コンポーネントを既存のフォームおよびデータと連携させることができます。業界の標準として確立されているスキーマを基にデータ収集ソリューションを作成すれば、ソリューションの柔軟性はさらに高まります。実際に、これらのソリューションでは、同じスキーマを使用する他社製のソリューションとの互換性も提供されます。
社員を上司と関連付ける簡単な DirectReports スキーマを作成しました。上司は、このスキーマに基づいて作成されたフォームを使用して、直属の部下を評価できます。この記事の付属リソース (technetmagazine.com/code08.aspx) の Direct Reports フォルダには、このスキーマ、フォーム、およびフォームの再作成手順が記載された readme.htm が含まれています。基本的なフォームですが、一般的な考え方をよく表しています。
非常に重要なことを 1 つお話します。InfoPath では検証ロジックを作成しませんでしたが、ユーザー ID と電子メール アドレスは特定の形式 (domain\account および recipient@domain.tld) で入力する必要があります。この形式に準拠していない XML ドキュメントは無効になります。これは、XML スキーマによって、これらの形式が定義されているためです。図 4 からわかるように、無効なデータが入力されたフォームを保存することはできますが、送信することはできません (フォームにダミーの送信ルールを追加してあるため、実際にデータを任意の場所に送信しなくても、このことを確認できます)。フォームの内容が適切に入力されており、このようなエラーが発生しないかどうかが、InfoPath 2007 の検証によって自動的に確認されます。
図 4a 検証エラーが発生するとユーザーはフォームを送信できない
図 4a 検証エラーが発生するとユーザーはフォームを送信できない
図 4b 生成されたエラー メッセージ
図 4b 生成されたエラー メッセージ
XML スキーマは、プレゼンテーション ロジックと情報管理ロジックをつなぐ役割を果たします。このスキーマは InfoPath によってロックされるため、フォーム デザイナが意図的にデータ構造を変更することはできません。このことは重要です。業界で標準として確立されている XML スキーマを変更すると、新しいフォーム テンプレートと組み合わせて使用するワークフロー モジュールなど、企業の既存のソリューションが機能しなくなる可能性があります。
InfoPath では、高度なプレゼンテーション ロジックからフォーム アプリケーションを作成するための機能が多数提供されています。XML ファイル、Web サービス、SharePoint のライブラリとリスト、データベースなどのデータを利用して、意味のある既定値を設定できます。ルールとユーザーの選択内容に基づいてフィールドの値を変更したり、検証ロジックを追加したりすることができます。また、最も複雑なカスタマイズ要件を満たすマネージ コードを追加したり、Forms Service を使用して Web 経由でフォーム テンプレートへのアクセスを提供したりすることもできます。どの場合も、フォームから収集されたデータは、最終的にスキーマの定義に準拠した XML ドキュメントとして情報管理ロジックに渡されます。

XML またはメタデータを使用して作業する
送信された XML ドキュメントに情報管理ロジックを直接適用するのと、必要な情報をメタデータに抜き出すパーサーを使用するのとでは、どちらがよいでしょうか。SharePoint では、どちらの方法もサポートされています。開発者は XML ドキュメントを直接操作することに慣れていますが、メタデータを使用した方がより高い柔軟性が得られます。
このことを示すために、Direct Reports フォームから渡された XML ドキュメントを解析する、図 4 のような簡単な Web サービスを作成しました (この記事の付属リソースの MLParsingWebService フォルダには、ソース コード、セットアップ ファイル、および詳細な手順が記載された readme.htm が含まれています)。この Web サービスは、上司のユーザー ID を XML ドキュメントから読み取り、そのユーザー ID をドメイン名とユーザー名に分割して、この 2 つの部分を基にメッセージを作成します。その後、処理された情報を擬似エラー メッセージの形式で InfoPath フォームに表示する汎用的な例外を生成します。この方法を使用すると、データが送信された後、簡単にダイアログ ボックスを InfoPath にポップアップ表示できます。この Web サービスは適切に機能しますが、基になっているデータ ソースを変更 (たとえば、readme.htm ファイルで説明されているように、DirectReports.xsd の OrgPerson 要素の名前を Manager に変更し、新しいスキーマを使用して InfoPath フォームを更新) すると失敗します。しかし、これは驚くようなことではありません。XML ドキュメントが変更されたため、user-id 要素にアクセスするための XPath 式は無効になっています。OrgPerson スキーマと Manager スキーマの内容はほぼ同じであるため、これを基に作成される InfoPath フォームや目的の処理結果も同じものになります。しかし、違いがほとんどない場合でも、別々の Web サービスを展開して維持する必要があります。
これは、アプリケーション サーバーにできるだけカスタム コードを配置しないようにする必要がある場合は、あまり良い方法ではありません。これに対して、XML ノードをメタデータ フィールドにマップし、メタデータに基づいて処理を実行する方法であれば、XML スキーマが異なる場合でも、類似したデータ構造に同じワークフローと情報管理ロジックを使用できます。子要素が正しいメタデータ フィールドにマップされ、データの形式が処理要件を満たすようにすれば、既存のコードを再利用できます。
XML ノードをメタデータ フィールドにマップする作業は、XML ノードを InfoPath フォームの UI コントロールにバインドする作業と似ています (図 5 参照)。SharePoint のメタデータ フィールドはサイトまたはリスト レベルで定義されており、コンテンツ タイプの定義で参照されている列に対応しています。コンテンツ タイプでは、メタデータ フィールド、ワークフロー、フォームなど、コンテンツ アイテムの特性が定義されます。SharePoint は、プロパティの昇格と降格を実行する組み込みの XML パーサーを使用して、コンテンツ タイプのメタデータ フィールドと、関連付けられている XML ドキュメント内の対応するノードの同期を維持します。プロパティの昇格時には、XML パーサーが XML ドキュメントからノードの値を抽出して、ドキュメント ライブラリの対応する列に設定します。プロパティの降格時にはこの逆の処理が実行され、ドキュメント ライブラリの列の値がドキュメントに書き込まれます。最も重要な点は、XML パーサーによって、メタデータ フィールドとマップされている XML ノードの同期が維持されるということです。
図 5 InfoPath と SharePoint との間の XML スキーマのマッピング
図 5 InfoPath と SharePoint との間の XML スキーマのマッピング
SharePoint オブジェクト モデルを使用すると、Web パーツ、ワークフロー、および情報管理ロジックを、メタデータ フィールドだけでなく、基になっている XML ドキュメントと連携させることもできます。マップされたメタデータ フィールドの値と XML ドキュメントのノードの値は、片方を変更するともう一方が変更されます。しかし、直接 XML ドキュメントと連携させると、ビジネス ロジックと XML スキーマの結合度が高まります。一方、マップされたメタデータ フィールドを使用すると、コードの再利用性が高まります。自分の環境に適した方法を判断する必要があることは明らかですが、通常は、SharePoint ソリューションをメタデータ フィールドと連携させた方が、柔軟性が高まり、コードを再利用しやすくなります。
この記事の付属リソースには、SharePoint での XML ノードとメタデータ フィールドの関連付けを示すことを目的とした、カスタム ドキュメント ライブラリを準備する SharePoint 機能が含まれています (付属リソースの OrgPersonLib フォルダにある OrgPersonContentType.xml を参照してください)。OrgPerson コンテンツ タイプは、UserID、FullName、Email、および Direct_x0020_Reports という 4 つのフィールドを参照します。FullName と EMail は組み込みのフィールドです。UserID と Direct_x0020_Reports は、OrgPersonSiteColumns.xml で定義されているカスタム フィールドです。
フィールドの定義は非常に単純です。フィールドの定義内でフィールドを直接 XML ノードにバインドすることもできますが、コンテンツ タイプ内でこの情報を上書きすることもできます。今回は後者の手法を使用することにしました。これは、XML ドキュメントに関連付けられていないコンテンツ タイプのカスタム フィールドと、異なる XML 構造に依存するコンテンツ タイプのカスタム フィールドを使用できるためです。OrgPerson コンテンツ タイプにより、前述の OrgPerson スキーマの配置に対応する XML ノードにメタデータ フィールドがバインドされます。また、同じメタデータ フィールドをさまざまな XML ノードにバインドするその他のコンテンツ タイプの定義を記述した、AdditionalContentTypes.xml も提供されています。Node 属性の XPath 式を見ると、違いを確認できます。
OrgPersonLib タイプのドキュメント ライブラリには、さまざまな種類の XML ドキュメントを格納できますが、ノードの値は同じライブラリ列で公開されます。この単純なマッピング手法では、4 種類のコンテンツ タイプ (OrgPerson、Manager、Supervisor、および User) が共通のメタデータ フィールドを参照しているため、ワークフローと情報管理ロジックを再利用することもできます。
図 6 は、Direct_x0020_Reports を参照する OrgPerson コンテンツ タイプの FieldRef 要素を示しています。この要素は、XPath 式 /OrgPerson/direct-report/user-id に従って、フィールドを直属の部下の user-id ノードにマップしています。XML ドキュメントには直属の部下のエントリを複数含めることができるため、Aggregation 属性を指定することが重要です。この属性は、返された値のコレクションを XML パーサーがどのように処理するかを定義します。この属性を省略すると、XML パーサーは最初のノードの値のみを抽出します。サポートされる集計値は、sum、count、average、min、max、merge、plain text、first、および last です。
図 6 XPath 式にマップされたメタデータ フィールド
図 6 XPath 式にマップされたメタデータ フィールド
すべてのサンプル コンテンツ タイプでは、DocumentTemplate に標準の upload.aspx ページが 使用されているため、SharePoint UI の [新規] をクリックすると、XML ファイルをドキュメント ライブラリにアップロードできます。拡張子が .xml のファイルをアップロードすると、SharePoint は自動的に組み込みの XML パーサーを呼び出します (例外は WordProcessingML ファイルであり、この場合は WordProcessingML パーサーが呼び出されます)。XML パーサーは、アップロードされた .xml ファイルを調べ、関連付けられているコンテンツ タイプを特定します。これは、フィールドの定義で指定されている場所からノードの値を抽出して、プロパティの昇格を実行できるようにするためです (OrgPersonLib\XMLFiles フォルダにある OrgPerson.xml ファイルをアップロードすると、この処理を確認できます)。この XML ドキュメントの構造は、OrgPerson コンテンツ タイプの定義で指定されている XPath 式に対応しています。SharePoint は、この対応関係に従って .xml ファイルからデータを抽出し、そのデータを対応するライブラリの列に書き込んで、EditForm.aspx ページに表示します。これにより、読み取り専用になっていないドキュメント プロパティを確認および更新できるようになります。図 7 は、OrgPerson.xml から抽出したデータが表示された EditForm.aspx フォームを示しています。
図 7 抽出したデータが表示された EditForm.aspx フォーム
図 7 抽出したデータが表示された EditForm.aspx フォーム
EditForm.aspx の User ID、Full Name、または E-Mail の値を変更すると、SharePoint はプロパティの降格を実行し、基になっている XML ドキュメント内のノードの値を変更します。ただし SharePoint では、ユーザーがフォーム自体に必要なロジックを実装しない限り、XML スキーマの制限は適用されません。
また、SharePoint では、フォーム アプリケーションのプレゼンテーション ロジックは実行されません。たとえば、User ID を変更すると、SharePoint では新しい値が NetBIOS の規則に準拠しているかどうかが検証されず、Full Name および E-Mail フィールドが新しい選択内容に合わせて自動的に更新されません。したがって、個々のフィールドを変更することによって不整合が発生する場合は、コンテンツ タイプの定義の対応する列を読み取り専用にする必要があります。これにより、ユーザーはデータの更新に InfoPath などのフォーム アプリケーションを使用することを強制されます。また、XML パーサーによって、XML ドキュメントの変更を対応する SharePoint のメタデータ フィールドに昇格する処理が実行されます。
OrgPersonLib サンプルでは、OrgPersonLib\XMLFiles フォルダにある任意の .xml ファイルをアップロードできます。これらの .xml ファイルでは非常にさまざまなデータ構造が使用されていますが、SharePoint はこれらのコンテンツ タイプを認識して、正しいノードの値をサイト内の列に昇格させます。これは、XML ファイル内の処理命令を使用して、XML ドキュメントを対応するコンテンツ タイプに関連付けているためです。ただし、OrgPerson.xml ファイルにはこの情報が含まれていません。しかし、このことは問題ではありません。SharePoint が処理命令やドキュメント テンプレートを使用して XML ドキュメントをコンテンツ タイプに関連付けることができない場合、SharePoint では既定のコンテンツ タイプが使用されます。OrgPersonLib の場合は OrgPerson コンテンツ タイプがこれに該当するため、XML ドキュメントは正しく解析されます。
図 8 は、どのようにして XML ドキュメントを明示的にコンテンツ タイプに関連付けることができるかを示しています。MicrosoftWindowsSharePointServices 処理命令では、ContentTypeID として 0x010100668E393E4F0EFF4294DBD202D5D8321D が定義されています。これは、AdditionalContentTypes.xml で定義されている User コンテンツ タイプの ID と同じです。
図 8 User.xml サンプル ファイルの処理命令と XML データ
図 8 User.xml サンプル ファイルの処理命令と XML データ
XML パーサーは、MicrosoftWindowsSharePointServices 処理命令を処理し、ContentTypeID の値を ContentType メタデータ フィールドに書き込みます。このメタデータ フィールドは、すべての SharePoint コンテンツ タイプによって共有されています。これは、System コンテンツ タイプのルート レベルでこのフィールドが定義されているためです。fieldswss.xml ファイル (%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields フォルダにあります) を SharePoint サーバー上で開き、MicrosoftWindowsSharePointServices を検索すると、SharePoint では処理命令がどのように ContentType フィールドに関連付けられているかを確認できます。PITarget 属性は MicrosoftWindowsSharePointServices (処理命令) を参照し、PIAttribute は ContentTypeID (User コンテンツ タイプの ID を保持します) を参照しています。

InfoPath でのコンテンツ タイプの関連付け
XML の解析とコンテンツ タイプの関連付けには専門的な知識が必要であるため、多くのフォーム デザイナが敬遠していますが、InfoPath 2007 を使用すると細かい処理がすべて自動で行われます。OrgPersonLib サンプルに付属している readme.htm ファイルには、SharePoint で Direct Reports フォーム テンプレートを公開し、新しいコンテンツ タイプを作成して再び同じメタデータ フィールド (UserID、FullName、Email、および Direct_x0020_Reports) にバインドする手順が記載されています。SharePoint UI を使用して、OrgPersonLib ドキュメント ライブラリに新しいコンテンツ タイプを簡単に追加できます。ただし、新しいコンテンツ タイプのドキュメント テンプレートには InfoPath フォーム テンプレートが指定されているため、既存の XML ドキュメントを更新するとフォーム アプリケーションが呼び出されます。図 9 は、InfoPath 公開ウィザードにより、XML ノードの値と SharePoint サイトの列との間のプロパティのマッピングがどのように簡略化されるかを示しています。この場合も、ノードの値と既存のサイト列を関連付けると、既存の SharePoint コンポーネントを再利用できます。
図 9 InfoPath 2007 でのプロパティのマッピング
図 9 InfoPath 2007 でのプロパティのマッピング

まとめ
オンラインの参考資料
  • InfoPath 2007 チームのブログ
  • W3C XML スキーマの使用と開発
  • XML スキーマの概要
  • Office SharePoint Server 2007 でのワークフロー
  • InfoPath 2007 Forms Services

企業のアーキテクトは、Office で提供されるテクノロジを使用すると、コードの再利用と情報交換を促進するデータ収集ソリューションを作成できます。InfoPath 2007 を使用すると、各部署がさまざまな情報源から情報を取得できるソリューションを作成し、収集したデータを SharePoint などのさまざまなシステムに送信できます。また、SharePoint では、ワークフローと情報管理コンポーネントの作成に使用できる、包括的な一連の Web サービスとインターフェイスが提供されます。これらのコンポーネントを一元管理用の SharePoint サーバーでホストすることによって、各部署専用のアプリケーションの作成に必要なインフラストラクチャを確立できます。
また、各部署はデータ収集ソリューションをこれまでよりも短時間で作成できるようになります。法令遵守やその他のグローバルなビジネス要件に全部門レベルで対処し、アプリケーション サーバー上に配置するカスタム コンポーネントの数を減らすことで、IT 環境の保守性と信頼性を高めることができます。

Keith Deshaies は、フリーランスのテクニカル ライターであり、大手電気通信企業の IT アナリストです。Microsoft Office および SharePoint テクノロジを専門としており、Society for Technical Communications の会員でもあります。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 SharePoint: 強力なアンケート用インフラストラクチャを構築する
SharePoint Jim Bradley

強力なアンケート用インフラストラクチャを構築する
概要:
  • アンケート ソリューションを計画して実装する
  • SharePoint ライブラリにアンケート結果を収集して処理する
  • パフォーマンスとセキュリティの問題を管理する

情報なしに良い判断をすることなどできません。下した判断がビジネスに影響を与える場合は、勘ではうまくいきません。これは、チームのパーティ会場を決める場合にも、
新製品をリリースするために人材の 50% の再配置を検討する場合にも当てはまります。では、どうすればこうした情報を入手できるのでしょうか。
アンケートは、自社製品に対する顧客満足度から、前回のチーム ミーティングで手配したサンドイッチが好評であったかどうかなど、あらゆるトピックについてフィードバックを収集するうえで有効かつコスト効率の良い方法です。アンケートによって、将来の製品、システム、またはプロセスの改善や開発に必要な概略情報を得られます。問題は、IT プロフェッショナルであるあなたが、データを収集し、情報を意味のある形で使用できるように保存するアンケート システムをどのように実装するかです。
おそらく、このようなデータの収集、構造化、および分析に必要なツールは、既に所有されていると思います。2007 Microsoft® Office system では、このような、しかも非常に使いやすいツールを提供しています。実際、アンケートを実施する方法にはさまざまな方法があります。大切なことは、ニーズに合った方法を選ぶことです。たとえば、電子メール ベースのアンケートは、少数の回答者を対象とし、重要性の低いデータを扱う、即興でリアルタイムのデータ収集を行う方法として適しています。詳細については、補足記事「電子メールを使用して簡易アンケートを実施する」を参照してください。一方、データベースを使用するアンケートは、多数の回答者を対象とし、ミッション クリティカルなデータを扱う、より複雑なデータ収集に適しています。このトピックの詳細については、補足記事「データベースによるアンケート ソリューションを構築する」を参照してください。
この記事では、より包括的で柔軟な "SharePoint® ベースのオンライン アンケート" のソリューションを紹介します。このソリューションは、ミッション クリティカルなアンケートにも、ミッション クリティカルでないアンケートにも適しており、複雑さのレベルも問いません。SharePoint のアンケートは、Web ベースのアンケートなので、Web ブラウザを利用できるユーザーであればだれでも回答できます。モバイル デバイスもサポートされています。また、SharePoint のアンケートでは、記名または匿名での回答が可能で、リアルタイムで結果を入手でき、分析ツールを利用することもできます。
このようなアンケートは、Windows® SharePoint Services 3.0 (WSS) と Forms Server および InfoPath® を組み合わせるか、Microsoft Office SharePoint Server 2007 (MOSS) と Forms Services および InfoPath® を組み合わせて実装します (これらのテクノロジの説明については 図 1 を参照してください)。どちらのシナリオも基本的には同じ機能を提供するため、ここでは、後者の組み合わせを基に解説します。各 SharePoint 製品と各製品の機能の包括的な比較表については、「Microsoft Office SharePoint Server 2007 製品比較表のダウンロード」(office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx) を参照してください。
Figure 1 SharePoint アンケートを構成するマイクロソフト テクノロジ (Close Figure 1)

テクノロジ | 説明
Microsoft Office InfoPath 2007 | Microsoft Office InfoPath 2007 は、フォームを作成して情報を収集するツールです。詳細については、office.microsoft.com/infopath を参照してください。
Windows SharePoint Services 3.0 | SharePoint Team Services の後継である Windows SharePoint Services 3.0 は、拡張された SharePoint アプリケーションを作成する基盤になります。詳細については、microsoft.com/technet/windowsserver/sharepoint/techinfo/overview.mspx を参照してください。
Microsoft Office SharePoint Server 2007 | Microsoft Office SharePoint Server 2007 (旧 SharePoint Portal Server 2003) は、2007 Office system クライアントによって SharePoint アプリケーションのコンテンツを生成および利用できるようにするサーバー側のインフラストラクチャを提供します。詳細については、microsoft.com/sharepoint を参照してください。
InfoPath Forms Services、Microsoft Office Forms Server 2007 | InfoPath Forms Services を使用すると、InfoPath がインストールされていなくても Web ブラウザを使用して InfoPath フォームに記入できるため、複数のプラットフォームや複数のブラウザに対応できるアンケートを実装できます。Forms Services には Windows SharePoint Services 3.0 が必要ですが、同じ機能は Microsoft Office Forms Server 2007 というスタンドアロン製品でも提供されています。Forms Services の詳細については、microsoft.com/ms540731 を参照してください。Forms Server の詳細については、office.microsoft.com/en-us/formsserver/FX100490391033.aspx を参照してください。

計画と実装
アンケートをデザインするときは、事前にさまざまな要因を検討する必要があります。これには高度な分析が必要になるため、時間をかけて、綿密なアンケート計画を策定してください。計画の初期段階では、問題の範囲と取得するデータの種類を定義し、使用する必要があるテクノロジを決定し、予算と管理面の要件を特定します。この作業が済んだら、実装に取り掛かることができます。一般的なワークフローは、アンケート フォームのデザイン、フォームの発行、回答の収集と検証、データの集約と分析、結果のレポートです。
アンケートの実装ワークフローには、通常、少なくともアンケートのデザイナ、回答者、およびアナリストが関与します (図 2 参照)。もちろん、アンケートのワークフローの複雑さはワークフローによって大幅に異なります。たとえば、全社規模のアンケートでは、デザインの編集と承認のプロセスを何度か繰り返すことになるでしょう。また、回答者に対する自動通知を使用したり、さまざまな形でのサポートやトラブルシューティング、および管理者がリアルタイムで結果を確認できる機能を提供したり、最終的な分析結果を決定して報告するための明確なプロセスが用意される可能性が高いでしょう。このような複雑なワークフローには、ワークフローとレポート機能をサポートする Web ベースのシステムが不可欠です。
図 2 フォーム デザインからデータ分析までのアンケート ワークフロー
図 2 フォーム デザインからデータ分析までのアンケート ワークフロー

包括的なソリューションの検討事項
包括的なアンケート ソリューションが満たすべき重要な要件は多数あります。このようなソリューションは、IT 部門のサポートを最小限にとどめ、プログラミング技術を必要とすることなく、個々のチームや部署がアンケートを作成および配布して、結果を収集できるものである必要があります。フォーム作成ツールは、使いやすい WYSIWYG 型のインターフェイスのほか、パイプ、分岐、条件ロジックを支援する機能を豊富に備えている必要があります。また、言うまでもなく、アンケート フォームの作成ツールは、規模や複雑さにかかわらず、あらゆるアンケートに対応できる必要があります。
さらに、アンケートを Web サーバー上で実行し、中央管理された SQL Server® データベースと統合し、各部署が専用の SQL データベース サーバーを管理しなくて良い状態にする必要があります。インターネットにアクセスできる回答者が、標準準拠の任意のブラウザからアンケートに回答できる必要があります。
アンケート プロセスは、ワークフローに簡単にリンクできるもので、セキュリティを損なうことなく、ビジネス ニーズを満たすことができる必要があります。また、多くの組織では、アンケート ソリューションで多言語がサポートされる必要があります。
MOSS 2007、WSS 3.0、および InfoPath 2007 を併用すると、このような要件をすべて満たす統合ソリューションを作成できます。図 3 に、SharePoint ソリューションを構成するさまざまなコンポーネントを示します。ただし、この包括的なアンケート ソリューションについて説明する前に、WSS 単体で実現できる機能について簡単に説明します。その後、ソリューションに MOSS と InfoPath を追加することで得られる、付加的な機能について説明します。
図 3 SharePoint ソリューションのコンポーネント
図 3 SharePoint ソリューションのコンポーネント

WSS 単体で作業する
他のコンポーネントなしでも、WSS を単体で使用してアンケートを作成して実装することができます。実際、WSS には、プロセスを容易にするアンケート テンプレートが含まれています。アンケートを作成するには、[スタート] メニューをクリックし、[すべてのプログラム] をポイントします。次に、[管理ツール] をポイントし、[SharePoint 3.0 サーバーの全体管理] をクリックします。ドロップダウン リストから、[サイトの操作] をクリックして、[作成] をクリックすると、[作成] ページが表示されます。このページには、[ライブラリ]、[通信]、[リスト]、[カスタム リスト]、[Web ページ] という見出しがあります。各見出しの下には、テンプレート オプションが表示されています。[リスト] 見出しにある [アンケート] をクリックします。
この時点で、WSS によってアンケート作成プロセスの手順が順を追って示されます。自由回答形式の質問 (オープン クエスチョン) や回答が限定される形式の質問 (クローズド クエスチョン) を作成したり、質問を無回答にできるかどうかを指定したりできます。また、回答に応じて別の質問へと回答者を誘導する分岐ロジック アンケートを作成することもできます。アンケートは匿名でも、必要に応じて、回答者を特定できるようにすることもできます。また、アンケートにワークフローを割り当てることもできます。
アンケートはブラウザ ベースなので、アンケートの作成や回答に特別なソフトウェアは必要ありません。回答者がアンケートに回答するのに必要な作業は、SharePoint サイトにアクセスして、フォームに回答を入力するだけです。アクセス許可は親サイトから継承されますが、SharePoint の [操作] メニューから直接編集することができます。アンケートの回答は SharePoint アンケート サイトに保存され、結果は一覧やグラフ形式で表示したり、Excel® にエクスポートしたりすることができます。
繰り返しになりますが、(図 4 のプロセスによる) このソリューションは、WSS だけを使用して実現できるもので、その他のソフトウェアは必要ありません。既に適切にデザインされた SharePoint サイトが運用されている場合は、各部門は IT 部門の支援をほとんどまたはまったく必要とせずに、アンケートを作成して実装できます。
図 4 Windows SharePoint Services ベースのアンケート
図 4 Windows SharePoint Services ベースのアンケート
WSS 単体のプロセスの制限事項は、アンケートをカスタマイズする必要がある場合に明らかになります。WSS では、さまざまな既定の ASPX ページ (AllItems.aspx、DispForm.aspx、EditForm.aspx、NewForm.aspx、overview.aspx,、および summary.aspx) を使用してアンケート リストを作成します。WSS の既定以外のパラメータを使用すればページをカスタマイズすることはできますが、ほとんどの機能は、容易にはカスタマイズできない Web パーツにより提供されています。また、WSS 単体のソリューションが最適であるのは、会社の ERP システムなど、外部データソースと統合する必要がないアンケートです。
アンケート ソリューションを拡張してカスタムの UI を組み込んだり、他のデータ ソースと統合する必要がある場合は、MOSS、WSS、および InfoPath を組み合わせたソリューションの使用を検討してください。

包括的なアンケート ソリューション
MOSS には WSS を拡張する多数の機能がありますが、ここでは 1 つのコンポーネント InfoPath Forms Services のみについて説明します。InfoPath Forms Services に関しては、InfoPath のインストールが必要になるのは、アンケート デザイナのみです。他のユーザーがアンケートにアクセスする場合は、Web ブラウザを使用できます。
デザイナが、InfoPath で、ブラウザを使用してフォームに入力できるようにするオプションを選択すると、どの標準準拠の Web ブラウザでも表示できるフォームが作成されます。Web ベースのフォームは、InfoPath フォームと同様に機能しますが、高度な InfoPath 機能 (ユーザー ロール、縦書きテキスト、ダイアログ ボックスの動作、高度なコントロールなど) を使用できる点が異なります。フォームは、作成されると SharePoint ライブラリまたはリストに発行されます。また、デザイン チェックと呼ばれる別の InfoPath 機能により、アンケート フォームの InfoPath Forms Services との互換性が確保されます。
InfoPath フォームのライブラリとブラウザ対応フォームのライブラリの間に、違いはありません。どちらの場合も、フォーム テンプレートは .xsn ファイルです。InfoPath Forms Services によってフォームがブラウザに表示されるか、ファイルがクライアントにダウンロードされて、直接 InfoPath で表示されます。アンケート デザイナが少なくとも SharePoint サイトに対する投稿者アクセス許可を保持している場合は、SharePoint ドキュメント ライブラリを使用して、フォーム テンプレートを発行できます。
回答者が標準準拠のブラウザを使用している場合は、InfoPath Forms Services アンケートに回答でき、回答はシームレスに SharePoint サーバーに返されます。データは SharePoint 内で安全に保存、解析、共有、および分析 (Excel、SQL、または他のネットワーク上で利用できるツールを使用) できます。このような作業はすべて、最低限の IT 管理者による支援を受けるだけで実現できます。

ポストバックとパフォーマンスの問題
ただし、パフォーマンスの問題が発生する可能性があります。たとえば、ブラウザ対応フォームは、SharePoint サーバーのシステム アカウントのコンテキストで実行されます。つまり、フォームにコードやデータ接続が含まれていると (図 5 参照)、コードまたはデータ接続がクライアントではなくサーバー上で実行されます。また、複雑なフォームではサーバーにデータを頻繁にポストバックしなければならない可能性があり、サーバーのワークロードが増加します。
図 5 追加のデータ接続がある InfoPath Forms Services ベースのアンケート ソリューション
図 5 追加のデータ接続がある InfoPath Forms Services ベースのアンケート ソリューション
アンケートでポストバックが多く使用されるほど、フロントエンド Web サーバーの負荷が高くなります。ただし、回答に基づく分岐を実装する場合など、ポストバックを使用せざるを得ない場合もあります。システムに悪影響が出る可能性を最小限に抑えるため、アンケート デザイナはポストバックの問題を認識し、ポストバックの使用を回避できない場合にアンケートを実装する最適な方法を理解しておく必要があります。たとえば、ユーザーが [次へ] ボタンをクリックするとサーバーにデータがポストバックされるウィザードのようなアンケートを使用します。これにより、ボストバックの回数を減らすことができます。
InfoPath Forms Services では、サーバー上で現在アクティブな各フォームの状態を維持する必要があります。既定のセッションのタイムアウトは 60 分です。つまり、記入に 60 分より長くかかる複雑なアンケートで、その間ポストバックが発生しないと、サーバーのセッションが閉じられます。 入力されていても送信されていないデータは失われ、回答者は最初からやり直す必要があります。
これは、多数の回答者が同時に同じアンケート フォームに回答を入力しているときや、アンケートに大規模なデータ ソースが使用されていたり、添付ファイルが含まれていたりするときに、大きな問題になります。詳細については、「InfoPath 2007 フォームのパフォーマンスを改善する」(msdn2.microsoft.com/bb380251) を参照してください。

セキュリティの考慮事項
詳細なセキュリティについては、この記事の範囲外ですが、いくつかセキュリティの考慮事項について説明しておきます。まず、SharePoint と InfoPath 2007 をマイクロソフトが 2002 年初めに採用した Microsoft Trustworthy Computing (信頼できるコンピューティング) 活動に従って構成されています。InfoPath フォームには、3 つのセキュリティ レベルがあり、制限あり、ドメイン、および完全信頼のいずれかのレベルを設定できます。また、既定では、InfoPath によって自動的に推奨されるセキュリティ レベルが特定されて、フォームに適用されます。
デジタル署名機能も、フォームが特定のユーザーによって作成または入力され、改変されていないことを保証するうえで有効です。また、Information Rights Management (IRM) を使用すると、テンプレートや入力済みのフォームへのアクセスを制限できます。悪意のあるユーザーが有害なコードを含むフォームをアップロードしたり、SharePoint プラットフォームを使用してデータ接続を利用し、他のシステムに攻撃を仕掛けたりしないように、InfoPath では、ユーザーが展開したフォームと管理者が展開したフォームが区別されます。フォームにカスタム コードが含まれておらず、ドメイン間のデータ接続を制限するドメイン セキュリティ レベルを使用しているフォームであれば、ユーザーがフォームをアップロードできます。大半のアンケート ソリューションでは、このような構成で十分です。
アンケート デザイナが、完全信頼セキュリティ レベルを取得してリソースに無制限にアクセスできるようにする場合、フォームの発行には IT 管理者による承認が必要です。既定では、フォームにマネージ コードが含まれる場合、ドメイン間のデータ接続がフォーム テンプレートに定義されている場合、フォームが中央管理されるデータ接続ライブラリで定義されているデータ接続を使用する場合、およびモバイル デバイスでの表示をサポートするオプションが有効にされている場合は、IT 管理者による承認が必要です。
完全信頼セキュリティ レベルの場合、アンケート デザイナが InfoPath フォームを作成して、フォーム テンプレートを保存すると、テンプレートまたは .xsn ファイルが SharePoint の管理者に、電子メールの添付ファイルとして送信されるか、ネットワーク共有を利用して渡されます。次に、IT 管理者がアンケートの機能とそれに含まれるコードを確認してから、アンケートを運用システムに展開します。IT 管理者は、アンケート テンプレートをサイト コレクションにアップロードし、アンケート テンプレートをアクティブ化することで、展開を完了します。どちらの作業も、WSS のサーバーの管理コンソールの [アプリケーション構成の管理] ページで完了できます。つまり、IT 管理者はフォームの発行作業を各部門に委任しても、フォームが基本的なデータ収集以外の操作を行う場合には、発行プロセスを引き続き監督することができます。
IT 管理者による監督が必要な一般的な状況としては、フォームに既定のデータを入力する必要がある場合やアンケート結果が複数のデータ ソースに送信される場合などがあります。既定では、ドメイン信頼フォーム テンプレートでは、ドメイン間のデータ接続を確立できませんが、この制限を解消するために、以下のような対策を講じることができます。
  • 完全信頼アクセス許可を付与する。
  • データ接続ライブラリのデータ接続を使用して、ドメイン信頼を確立する。
  • 中央管理される接続ライブラリと併せてドメイン信頼を使用する。
完全信頼または中央管理された接続ライブラリを使用する場合は、フォームの発行時に管理者による承認が必要です。ただし、データ接続ライブラリ (DCL) では、サイト コレクション レベルで管理されている DCL を使用して、ユーザーが発行したフォームをドメインの境界を越えて使用できます。この DCL は、各部門で管理することができます。ただし、各部門が独自のサーバー ベースのデータ接続を確立できるようにすると、セキュリティ上の問題になり得ることに注意してください。
最も安全なのは、データ接続を中央管理されている接続ライブラリで定義し、IT 管理者がデータ接続を使用する高度なアンケート フォームを展開する方法です。中央管理されている接続ライブラリは、すべてのサイト コレクションとサーバー ファーム全体で利用できるため便利です。このようにすると、管理者が一元的に認証設定を定義して、ローカルの SharePoint サーバー上にないデータ ソースへのアクセスを管理できます。詳細については、「データ接続、認証、および代替アクセス マッピングについて」(msdn2.microsoft.com/ms771995) を参照してください。

まとめ
アンケートは、どの企業にとっても、どのレベルであっても、ミッション クリティカルな情報 (とミッション クリティカルでない情報) を収集するための強力な手段です。ただし、有効なアンケートを作成するには、適切なツールを使用し、綿密な計画を立て、デザインと技術のバランスを取る必要があります。事前によく計画を練ることは、組織内の各部署がアンケート データを作成、送受信、保存、分析できるソリューションを構築するうえで役立ちます。
最も有効なアンケートは、タイミングよく適切な情報を収集できるアンケートです。必要なときに情報を収集するためには、セキュリティを侵害することなく、部署レベルで、アンケートを簡単に作成および管理できるソリューションが必要です。InfoPath ではほとんどトレーニングなしに使用できる直感的なインターフェイスを採用し、インフォメーション ワーカーが質の高いアンケートを作成できるようにしています。また、InfoPath を使用すると、多くの IT 管理を必要とせずに、質の高いアンケート データを収集できます。
InfoPath 2007 は、WSS および MOSS とシームレスに連携し、複数のプラットフォームや複数のブラウザと互換性のある、機能が豊富で複雑なアンケート ソリューションを容易に構築できるようにしています。これにより、企業は最も重要な資産の 1 つである "情報" を活用できます。
電子メールを使用して簡易アンケートを実施する
即興のアンケートは、少数の回答者からデータをすばやく収集する場合に不可欠なツールです。電子メール ベースのアンケートは、すばやく作成でき、専用のサーバーや IT 部門の支援を必要としないため、このようなリアルタイムの調査には最適です。最も簡単な方法の 1 つは、Microsoft® Outlook® メッセージ内に返信ボタンを埋め込む方法で、アンケートを送受信し、結果を一覧にまとめることができます。
返信ボタンを使用するアンケートを発行すると、アンケートの質問と返信ボタン (ここには選択肢のドロップダウン リストが表示されます) が含まれたメールが受信者に送られます。受信者は、選択肢の 1 つをクリックして、回答します。クリックすると、"返信ボタンの " <選択肢> " を選択しました。" というメッセージのポップアップ ウィンドウが表示されます。このとき、回答を送信するか変更するかを選択できます。
アンケート デザイナまたは委任を受けたユーザーが、個々の回答を電子メールで受け取り、手動で結果を一覧にまとめます。アンケートが多数の受信者に送られる場合は、Outlook で (自動仕分けウィザードを使用して) 自動的に回答を専用のフォルダに振り分けるルールを作成します (図 A 参照)。
図 A 自動的に専用のフォルダに振り分けられたアンケートの回答
図 A 自動的に専用のフォルダに振り分けられたアンケートの回答
ただし、返信ボタンにはかなりの制限があります。電子メール メッセージにアンケート フォームを挿入すると、さらに多くのデータを収集できますが、このデータを手動で取得してまとめることは困難です。電子メール ベースでより複雑なアンケートを実現する場合は、VBScript を使用して Outlook アンケートをカスタマイズします。フォームをカスタマイズすることで、より複雑で多くのデータを収集して分析しやすくできます。Outlook 2007 の開発者向け機能を利用するには、まず [開発] タブを表示します (図 B 参照)。
図 B Outlook 2007 の [開発] タブ
図 B Outlook 2007 の [開発] タブ
カスタムの Outlook フォームの作成は、一般の Outlook ユーザーの知識では及びません。しかし、InfoPath® 2007 では、カスタム フォームを簡単に実装できる新機能が提供されています。特別な専門知識がなくても、InfoPath フォームとテンプレートを次の 3 通りの方法で作成できます。
  • 既存の Microsoft Word 文書または Excel® スプレッドシートをインポートする。
  • デザイン済みの InfoPath テンプレートをダウンロードして、特定のニーズに合わせて変更する。
  • InfoPath のフォーム デザイン機能を使用して、ゼロからテンプレートをデザインする。
どの場合でも、テンプレートは Outlook に発行し、電子メールで配信できます。InfoPath 2007 と Outlook 2007 を使用すれば、数時間で、IT 部門の支援をほとんどまたはまったく受けることなく、20 項目から成るアンケートを作成し、これを一群のユーザーに電子メールで送信して、Outlook で結果を受信し、Excel スプレッドシートでデータを分析することができます。
このシナリオの唯一の要件は、InfoPath と Outlook がすべてのアンケート対象者のコンピュータにインストールされていることです。InfoPath 2007 により Outlook 2007 の機能が拡張されるため、アンケートの対象者は Outlook インターフェイスから直接アンケートに回答できます。
ただし、InfoPath でサポートされるのは、電子メール ベースのアンケートだけではありません。Web サービスや SQL Server® データベースに対するクエリ実行やデータ送信を行うテンプレートを作成したり、既存の XML ドキュメントまたは XML スキーマをデータ ソースとして使用したりできます。つまり、最低限のトレーニングを受ければ、コードをほとんどあるいはまったく追加せずに、XML の持つ威力と柔軟性を利用できます。
電子メールによるアンケート ソリューションには、目立った欠点がいくつかあります。たとえば、このようなアンケートでは、電子メール アドレスが知られてしまうため、匿名で行うことができません。このため、正直な回答が得られず、結果がゆがむ可能性があります。また、フィッシング攻撃などセキュリティ上の問題もあるため、電子メール ベースのアンケートを使用して収集できる情報の種類や細かさは制限されます。

データベースによるアンケート ソリューションを構築する
多数の回答者を対象とするより複雑な調査では、Outlook® のフォルダを使用して、すべてのデータの管理と分析を行うのは困難なので、電子メール ベースのアンケートは適していません。より堅牢なソリューションは、アンケートの回答をデータベースに送る方法です。データベースが提供する高度なストレージ、インデックス作成、処理、およびレポート機能は、非常に便利です。たとえば、Microsoft® SQL Server® 2005 には、アンケート結果の自動処理に使用できる SQL Server Reporting Services があります。
回答をデータベースに送信する InfoPath フォーム テンプレートを作成するには、まず Access® または SQL Server データベースをネットワーク内に作成する必要があります。データベースを作成したら、InfoPath® で、フォーム テンプレートのデザイン ウィザードを使用して、テンプレートの作成を開始できます。これにより、フォームをデータベースにリンクする手順を導くデータ接続ウィザードが表示されます。InfoPath では、データベース内の情報を使用して、データ ソース クエリとデータ フィールドが作成されます。
ほとんどの場合、トレーニングやサポートをほとんど受けずに、アンケートに回答して送信できます。ただし、(データが直接データベースに渡される) このシナリオでは、回答者のコンピュータに InfoPath と Outlook がインストールされていて、回答者が会社のファイアウォール内で作業をしているか、会社のネットワークに VPN を介してアクセスできる必要があります。
InfoPath のデータ接続ウィザードは、Microsoft SQL Server 2000 以降、または ADOXML をネイティブで使用する Access データベースにしか対応していません。他のデータベースにデータを直接送信することは、サポートされていません。また、InfoPath ではデータベース フィールドにリッチ テキスト コントロールをバインドできず、ラージ バイナリ データ型もサポートされていません。
ネットワーク トポロジが拡大し複雑になるほど、中間 Web サービスにデータを送信してから、データをデータベースに渡す方法が有効になります。また、Web サービスを利用して、アンケート フォームのフロントエンドとデータベースのバックエンドに分離することで、Web サーバーにビジネス ロジックを実装しやすくなります。Web サービスは HTTP または HTTPS 接続経由で実行されるため、回答者がデータをファイアウォールを利用して送信できます (図 C 参照)。ただし、この場合も、回答者のコンピュータに InfoPath 2003 または InfoPath 2007 がインストールされている必要があります。
このシナリオの欠点は、実装に IT 部門の関与が必要になることです。このプロセスの詳細については、この記事では説明しませんが、データベース ソリューションをゼロから構築する場合は、かなりの作業が必要になります。事前の計画、適切なアンケートのデザイン、Web サービスのプログラミング、データベース バックエンドのデザインが必要です。InfoPath 2007 を使用すると、このプロセスのフォーム デザインの作業が簡素化されますが、ソリューション全体では、確かなプログラミングとデータベース デザインの技術が必要です。また、ワークフローや多言語サポートなど、高度な機能を追加すると、実装コストは格段に高くなります。
図 C Web サービスを利用した InfoPath データ フロー
図 C Web サービスを利用した InfoPath データ フロー

Jim Bradley は、マイクロソフトのサーバー製品のユーザー支援ドキュメントを専門とするテクニカル コミュニケーション会社 CoyoteTech LLC の所有者です。「Microsoft Exchange Server 2007 エッジ トランスポートとメッセージングの保護」、「Microsoft Exchange Server 2007 での 64 ビットへの移行」、「Microsoft Exchange Server 2003 テクニカル リファレンス ガイド」などのドキュメント プロジェクトを手がけています。


 Sharepoint: カスタム コンテンツ タイプを使用してデータ管理を標準化する
Sharepoint Pav Cherny

カスタム コンテンツ タイプを使用してデータ管理を標準化する
概要:
  • SharePoint を使用してコンテンツのライフサイクルを管理する
  • ドキュメント情報パネルを作成する
  • InfoPath を使用して Office ドキュメントと SharePoint ドキュメントを編集する
この記事で使用しているコードのダウンロード: ContentTypes2008_02.exe (779KB)

企業環境でよく見られますが、ドキュメントやその他のコンテンツ アイテムが大量に存在する場合、それらのドキュメント、関連するメタデータ、およびドキュメントの動きを集中的かつ再利用可能な方法で管理することは、
業務上および技術上困難な作業になります。Microsoft® Office SharePoint® Server 2007 を使用すると、組織内のさまざまなチームが Web サイトのワークスペース、ドキュメント ライブラリ、およびリストを共有できるようになるため、企業全体のコラボレーションが促進されます。
SharePoint 2007 のコンテンツ タイプを使用することで、コンテンツのさまざまな要素とライフサイクルの特性を標準化できます。サイト コンテンツ タイプは、特定のサイト コレクション、サイト、リスト、またはドキュメント ライブラリとは無関係に作成できるメタデータ定義です。これにより、企業全体で使用する一貫したプロパティ、ワークフロー、情報管理ポリシーなどの要素を設定し、各部門またはサイト所有者が目的に応じてコンテンツ タイプをカスタマイズできるようになります。
この記事では、Windows® SharePoint Services (WSS) 3.0 と Microsoft Office SharePoint Server (MOSS) 2007 で導入された新しい SharePoint コンテンツ モデルを使用して、一般的な特性に基づいたエンタープライズ コンテンツの階層を構築する方法について説明します。これらのコンテンツ階層を使用すると、一貫したメタデータ、ワークフロー、および情報管理ポリシーをグローバル レベルで適用し、サイト コレクション、サイト、ドキュメント ライブラリ、およびリスト レベルで、それぞれのコンテンツ管理のニーズに合わせてこれらを柔軟に変更できるようになります。
この記事の付属リソースには、SharePoint コンテンツ タイプの下位レベルのいくつかの要素についてわかりやすく説明することを目的とした、多くのカスタム ツールが含まれています。また、ツールを必要に応じて拡張できるように、これらのソース コードも提供されています。ただし、これらのツールは十分にテストされていないため、運用システムでは使用しないようにしてください。これらのコードは、TechNet Magazine Web サイト (technetmagazine.com/code08.aspx) からダウンロードできます。

コンテンツのライフサイクルとコンテンツ タイプの定義
SharePoint の関連リソース
  • InfoPath チームのブログ
  • Office SharePoint Server 2007 でのワークフロー
  • TechNet Web キャスト : SharePoint Server 2007 で検索機能をインストールして構成する
  • InfoPath Forms Services

組織でドキュメントやその他のコンテンツを管理する場合、多くのことを考慮する必要があります。特に、コンテンツを作成、公開、アーカイブ、および削除するときに、どのユーザーまたはプロセスがそれぞれどのような操作を実行するかを定義する必要があります。また、多くの場合、コンテンツを作成するための特定のテンプレートの作成、ユーザーに職責とアクセス権を割り当てるためのロールの定義、バージョン管理の提供、規制遵守の監視、保存とアーカイブ、メタデータの定義などを行う必要があります。
SharePoint コンテンツ モデルは、特定のコンテンツのライフサイクルがどれほど複雑でも、全般的な特性と個々のフェーズによって各コンテンツ アイテムの処理方法が決定されることを認識しています。たとえば、テンプレートと入力フォームを使用してコンテンツの作成を構造化したり、メタデータを使用してコンテンツの表示と検索を構造化したりできます。また、編集や承認などのワークフローの要件、アーカイブの要件、有効期間、および適用可能な情報管理ポリシーを使用して、各コンテンツ アイテムを識別できます。一部のコンテンツは、特別なテンプレートを必要としない場合や、アーカイブされない場合がありますが、それらのこともライフサイクルの特性として他のアイテムとの識別に使用されます。
SharePoint コンテンツ モデルを使用すると、各コンテンツ タイプを定義して、階層関係を確立できるようになります。階層関係では、子が親コンテンツ タイプから一般的な特性を継承し、必要に応じて特定の特性を追加します。
これを理解するための最も良い方法は、SharePoint の組み込みのコンテンツ タイプを調べてみることです。WSS 3.0 と MOSS 2007 には、ドキュメントやタスクなど、ドキュメント ライブラリまたはリストに格納できる一般的なアイテム用にあらかじめ定義された多くのコンテンツ タイプが含まれています。これらの標準のコンテンツ タイプの定義は、SharePoint サーバーの %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes フォルダにあります。このフォルダには、feature.xml というマニフェスト ファイルがあります。このファイルの内容を調べると、SharePoint では、標準のコンテンツ タイプの定義が、サイト コレクションを対象範囲とする (Scope="Site") 非表示の機能 (Hidden="TRUE") として実装されていることがわかります。また、実際のコンテンツ タイプの要素が格納されている要素マニフェスト ファイルが ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />) であることも確認できます。
SharePoint 機能についてさらに詳しく理解するには、MSDN® Magazine (msdnmagazine.com/issues/07/05/OfficeSpace) の Ted Pattison の Office Space コラム「SharePoint の機能」を参照することをお勧めします。
では、ctypeswss.xml ファイルをメモ帳で開き、これらの標準のコンテンツ タイプを調べてみましょう。SharePoint ユーザー インターフェイスに表示されるかどうかに関係なく、さまざまなコンテンツ タイプの内容を確認してください。ctypeswss.xml の内容は変更しないようにする必要があります。ctypeswss.xml を編集して、標準のコンテンツ タイプに新しいフィールドを追加したり、非表示のコンテンツ タイプを表示して SharePoint ユーザーが新しいコンテンツ タイプの作成に使用できるようにすることを考えるかもしれませんが、通常はその必要はありません。また、ctypeswss.xml を編集するとサポートされていない構成になるため、後から Service Pack をインストールしたときに、カスタマイズした内容が上書きされ、コンテンツ管理ソリューションが機能しなくなる場合があります。
より適切な方法は、必要な要素を新しい要素マニフェスト ファイルにコピーし、必要に応じてカスタマイズしてから、サイト コレクションを対象範囲とする新しい機能としてそのカスタム コンテンツ タイプを展開することです。サイト コレクションを対象範囲とすることで、サイト コレクション内のすべてのサイトでそのコンテンツ タイプを使用できるようになります。
ctypeswss.xml に Collaborative Application Markup Language (CAML) で記述されている System コンテンツ タイプの定義を次に示します。
<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>
Group 属性と Sealed 属性は、System コンテンツ タイプが非表示であり、シールされていることを示しています。そのため、SharePoint ユーザー インターフェイスでこのコンテンツ タイプを変更することはできません。System コンテンツ タイプには、ContentType というサイト内の組み込みの列を参照する FieldRef 要素が 1 つだけ含まれています。これは、最上位レベルの抽象要素です。他のすべての SharePoint コンテンツ タイプは、System コンテンツ タイプからこのプロパティを継承します。このようにして、SharePoint では、ドキュメント ライブラリまたはリストに格納されるすべてのコンテンツ アイテムにこのプロパティが含まれます。
図 1 は、この記事の付属リソースに含まれている ContentTypeHierarchy Web パーツを示しています。この図で階層をより直感的に理解していただけると思います。System が他のすべてのコンテンツ タイプのルートであり、その後に Item などが続きます。たとえば、Item コンテンツ タイプでは、それに続くレベルの設定が定義されています。ctypeswss.xml を確認すると、Title というサイト内の列を参照する単一のメタデータ フィールドが定義されていることがわかります。このようにして、下位レベルのすべての組み込みのコンテンツ タイプに Title プロパティが含まれます。
図 1 WSS 3.0 の組み込みのコンテンツ タイプの階層
図 1 WSS 3.0 の組み込みのコンテンツ タイプの階層
ctypeswss.xml に記述されている Document コンテンツ タイプの定義が示しているように、継承されたフィールドを削除することもできます。Document コンテンツ タイプには、対応する複数の RemoveFieldRef 要素が含まれています。ただし、Title フィールドによって、SharePoint のドキュメント ライブラリ ビューとリスト ビューの編集コントロール ボックス (ECB) ドロップダウン メニューへのアクセスが提供されるため、Title フィールドはカスタム コンテンツ タイプでも維持した方がよいでしょう。
継承されたフィールドの名前を変更する方法を示す良い例は、ctypeswss.xml の Far East Contact コンテンツ タイプです。対応するコンテンツ タイプ ID の 0x0116 を検索した後、Name="Title" という属性が含まれた FieldRef 要素を調べます。DisplayName 属性を使用して、ユーザー インターフェイスに表示されるフィールドの名前をどのように変更できるかを確認してください。この例では、DisplayName 属性を使用して、ユーザー インターフェイスに表示される Title フィールドの名前を "$Resources:core,Last_Name;" で参照されるローカライズ版のデータ値に変更しています。
図 1 をよく見ると、ContentType 要素の ID 属性によってコンテンツ タイプが一意に識別され、階層関係が確立されていることがわかります。どの ID も、親コンテンツ タイプの ID で始まり、その後に 16 進値が続いています。通常、標準のコンテンツ タイプには、子コンテンツ タイプに固有の新しい ID を作成するための 2 つの 16 進値が付加されます。もう 1 つの手法は、"00" と 16 進数の GUID を付加することです。たとえば、Office Data Connection File と Universal Data Connection File は、この手法を使用して Document コンテンツ タイプから派生させたコンテンツ タイプです。
ユーザーが覚えておく必要がある重要なポイントは、ContentType 要素の ID 属性を 1,024 文字以下にする必要があるということです。このため、16 進数の GUID を付加する方法をすべてのコンテンツ タイプで使用していると、階層関係の規模が大きくなった場合に問題が発生する可能性があります。ただし、2 つの 16 進値を追加する方法では ID が一意にならない場合があるため、この方法から始めることはお勧めできません。
一意性を確保するには、GUID の手法を使用してエンタープライズ コンテンツ タイプ用のグローバル名前空間を作成し、その名前空間内で、2 つの 16 進値を追加する方法に切り替えます。ID 属性と、コンテンツ タイプの定義のその他の要素については、WSS 3.0 SDK の「コンテンツ タイプ定義スキーマ」を参照してください。

コンテンツ タイプの依存関係
次に、SharePoint コンテンツ タイプを使用してコンテンツ アイテムの管理を構造化する方法について説明します。ドキュメント ライブラリとリスト、コンテンツ タイプ、サイト内の列、フィールド型との間の相互依存関係など、いくつかの依存関係を考慮する必要があります。ライブラリとリストはコンテンツ タイプを参照し、コンテンツ タイプはサイト内の列を参照します。また、サイト内の列はフィールド型 (Text、Note、Choice、Number、Currency といった標準的な WSS フィールド型) を参照します。これらの型は、Microsoft .NET Framework アセンブリ (WSS のコア アセンブリである Microsoft.SharePoint.dll など) に含まれています。
例として、もう一度 System コンテンツ タイプを使用します。先ほどは、CAML で定義された、このコンテンツ タイプのマニフェスト ファイルのエントリについて説明しました。既に説明したように、このコンテンツ タイプには、ContentType というサイト内の列を参照する FieldRef 要素が含まれています。このコンテンツ タイプの定義では、サイト内の列である ContentType そのものは定義されていないことに注意してください。ContentType は Text フィールドであり、%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields フォルダにある要素マニフェスト fieldswss.xml で定義されています。Text フィールド型は、%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML にある fldtypes.xml で定義されています。この依存関係ツリーからわかる重要なポイントは、SharePoint サーバー上のすべてのリソースを利用できるようにする必要があるということです。
使用するコンテンツ タイプは、ドキュメント ライブラリとリストのサイト レベル、またはさらに上位のサイトに作成する必要があります。同様に、コンテンツ タイプのメタデータ フィールドは、サイト内の既存の列を参照する必要があります。標準またはカスタム フィールド型に基づいて、コンテンツ タイプに標準またはカスタムのサイト内の列を追加できますが、これらのサイト内の列がローカル サイトに存在する必要があります。さらに、カスタム フィールド型を使用する場合は、基になっている .NET アセンブリが SharePoint サーバーに展開されている必要があります。
同様の依存関係は、ドキュメント テンプレート、カスタム イベント レシーバ、ワークフロー、およびその他のコンポーネントを参照するコンテンツ タイプにも当てはまります。たとえば、コンテンツ タイプの定義に、そのコンテンツ タイプに関連付けられたドキュメント テンプレートを参照する DocumentTemplate 要素を含めることができます。また、コンテンツ タイプの定義には、名前空間定義、ドキュメント情報パネルの定義、カスタマイズされた情報など、コンテンツ タイプの追加の特性を定義する 1 つ以上の XmlDocument 子要素を持つ XmlDocuments 要素を含めることもできます。

グローバル コンテンツ タイプを作成する
作成権限を持つユーザーは、新しいコンテンツ タイプとサイト内の列を SharePoint ユーザー インターフェイスで直接作成できます。ただし、そのコンテンツ タイプは、ローカル サイトとそれよりも下位のサイトでのみ使用できます。カスタムのサイト内の列は、ローカル サイトでのみ使用できます。これは、グローバル コンテンツ タイプを作成する場合には不十分です。グローバル コンテンツ タイプは、環境内のすべてのサイト コレクションで使用できるようにする必要があります。ここで、SharePoint 機能が役立ちます。SharePoint 機能は、簡単に複数のサイト コレクションにインストールしてアクティブ化することができます。このため、すべての場所に一貫性のあるサイト内の列とコンテンツ タイプの定義を適用することができます。
この記事の付属リソースには、グローバル コンテンツ タイプの作成方法を示す AdventureWorks というサンプル機能が含まれています。この機能では、Customer Documentation (顧客用ドキュメント) という汎用的なコンテンツ タイプが定義されています。これは、提案書やセールス レターなど、さまざまな種類の顧客資料を作成する際に使用できます。このようなドキュメントには、会社名、連絡先の詳細、住所などの顧客情報が関連付けられている必要があると考えるのが妥当です。このため、このコンテンツ タイプ用に Customer Name というカスタム フィールドを作成し、Department や Primary Phone などの組み込みフィールドをいくつか追加しました。付属のサンプルでは、ContentTypes.xml ファイルを編集してコンテンツ タイプとフィールドを変更し、SiteColumns.xml ファイルを編集してフィールドの参照を変更することができます。
readme.htm ファイルの説明に従ってこの機能を展開すると、複数のサイト コレクションで同時にこの機能をアクティブ化することができます。展開後、Customer Documentation コンテンツ タイプをグローバルに使用できます。個々の部門では、対象のドキュメント テンプレートに関連付けられた派生コンテンツ タイプを使用して、特定の顧客用ドキュメントを作成できます。付属リソースには、営業とコンサルティングで使用できるサンプル ドキュメント テンプレートが含まれています。図 2 は、コンテンツ タイプの作成例を示しています。
図 2 顧客用ドキュメントの親コンテンツ タイプと子コンテンツ タイプ
図 2 顧客用ドキュメントの親コンテンツ タイプと子コンテンツ タイプ
WSS 3.0 と MOSS 2007 では、いくつかの方法でカスタムのサイト内の列とコンテンツ タイプの機能を作成できます。まず、WSS 3.0 SDK を参考にして、XML ファイルを一から作成できます。SharePoint Designer を使用して、個人用 Web パッケージへのリストのエクスポート、エクスポートした .fwp ファイルから .cab ファイルへの名前の変更、および .cab ファイルからの manifest.xml ファイルの抽出を行い、その後 manifest.xml ファイルの ContentType 定義を検索することもできます。残念ながら、どちらも不便でエラーが発生しやすい方法です。
対照的に、SharePoint ユーザー インターフェイスでは、カスタムのサイト内の列とコンテンツ タイプを非常に簡単に作成できます。ただし、このインターフェイスでは、機能の XML ファイルを編集することはできません。機能を使用すると SharePoint リソースを効率的に準備できますが、一度準備されたリソースはコンテンツ データベース内にしか存在しなくなります。おそらく、今後の WSS のバージョンでは、Web パーツのエクスポートと同じように、サイト内の列とコンテンツ タイプを SharePoint ユーザー インターフェイスから XML ファイルにエクスポートする機能が追加されるでしょう。現時点では、今あるもので対応する必要があります。
付属リソースには、出発点として使用できる ContentTypeSchema という Web パーツが含まれています。この Web パーツは、SharePoint オブジェクト モデルを使用して、選択したコンテンツ タイプから SchemaXML プロパティを抽出します。この Web パーツは eXtensible Stylesheet Language Transformation (XSLT) ベースの変換を使用し、ユーザー インターフェイスで [Display] (表示) ボタンをクリックする前に選択したオプションに応じて、Field の定義や ContentType の定義を導き出します。
図 3 は、この Web パーツを実際に使用したときの画面を示しています。この画面には、Customer Documentation コンテンツ タイプから派生した Active Directory® Documentation コンテンツ タイプが表示されています。Active Directory Documentation コンテンツ タイプは、カスタムの Microsoft Word テンプレート (Active Directory Template.dot) に関連付けられています。このコンテンツ タイプにはフィールドが追加されていないことに注意してください。すべてのフィールドは、親コンテンツ タイプから継承されます。
環境で ContentTypeSchema Web パーツの使用を計画している場合は、この Web パーツが十分にテストされていないことに注意してください。この Web パーツでは、比較的複雑な XSL 変換を使用して、現在選択されているコンテンツ タイプの SchemaXML プロパティとその親コンテンツ タイプとの間の差分を作成しています。ただし実際には、XSLT 1.0 の設計は高度な XML ドキュメント変換には対応していません。XML ノードを比較する機能は組み込まれていません。また、XML 名前空間では、CDATA セクションと同様、XSLT 1.0 で効率的に対処できない問題が発生します。
SharePoint では、SharePoint ユーザー インターフェイスや SharePoint オブジェクト モデルを使用して作成されたサイト内の列とサイト コンテンツ タイプの定義が、コンテンツ データベース内の ContentTypes というテーブルに格納されます。図 3 で、カスタム コンテンツ タイプの ID を見てみましょう。この ID を使用して、T-SQL ステートメント SELECT Definition FROM ContentTypes WHERE ContentTypeId = <コンテンツ タイプの ID> を実行すると、図 3 とまったく同じ結果が返されます。
図 3 ContentTypeSchema Web パーツ内のカスタム コンテンツ タイプの定義
図 3 ContentTypeSchema Web パーツ内のカスタム コンテンツ タイプの定義
どの方法を使用する場合でも、一度サイト内の列とコンテンツ タイプの定義を取得すれば、企業全体に適用するコンテンツ タイプ用の機能を非常に簡単に作成できます。部門または企業のすべてのグローバルなサイト内の列とコンテンツ タイプに 1 つの機能を使用することをお勧めします。これにより、どこにサイト内の列とコンテンツ タイプの定義を新しく追加する必要があるかが明らかになります。

カスタム メタデータに基づいた企業全体の検索
コンテンツ タイプ階層のメリットとしてまず挙げられるのは、すべての子コンテンツ タイプが親コンテンツ タイプのメタデータ フィールドを継承することです。すべてのコンテンツ タイプには共通のメタデータ フィールドが含まれているため、ユーザーはドキュメント ライブラリのカスタム ビューおよびフィルタを非常に簡単に作成できます。
AdventureWorks サンプル機能は、このことを非常に直感的に表しています。コンサルタントと営業担当者のどちらが作成したコンテンツであるかにかかわらず、作成した Word 2007 文書をドキュメント ライブラリに保存する際には、Customer Name を指定する必要があります。これは、Customer Documentation 親コンテンツ タイプで、このメタデータ フィールドが必須のフィールドとして定義されているためです。コンサルタント チームや営業チームのメンバは、ドキュメント ライブラリ ビューで、Customer Name に基づいたアイテムのグループ化またはフィルタを実行することにより、顧客用の既存のドキュメントを迅速かつ便利に検索できます (図 4 参照)。
図 4 共通のメタデータに基づいてライブラリ内のさまざまなドキュメントをグループ化する
図 4 共通のメタデータに基づいてライブラリ内のさまざまなドキュメントをグループ化する
また、共通のメタデータを使用することにより、WSS 3.0 と MOSS 2007 の検索機能で、複数のドキュメント ライブラリとサイトのコンテンツを簡単に検索することができます。WSS では、1 つのサイト コレクション内のサイト、ライブラリ、およびリストの検索がサポートされています。MOSS 2007 ではこれらの基本的な機能がさらに強化されており、企業規模の検索センターを実装して、SharePoint 3.0 サーバーの全体管理のユーザー インターフェイスでカスタム メタデータを管理することができます。ここからは、この MOSS 2007 に重点を置いて説明します。
MOSS 2007 の共有サービス プロバイダ (SSP) を構成して SharePoint サイトをクロールすると、コンテンツ ソースで使用されているカスタム メタデータ フィールドを MOSS 2007 が自動的に検出できるようになります。したがって、クロールされたプロパティのリスト内にあるカスタム メタデータ フィールドを検索できます。
SharePoint 機能で定義されているメタデータ フィールドは、通常、SharePoint カテゴリに分類されます。SharePoint サーバーの全体管理で SharePoint カテゴリを開くには、サイド リンク バーの [共有サービス管理] で、SSP へのリンクをクリックし、[検索の設定]、[メタデータ プロパティのマッピング] を順にクリックします。次に、サイド リンク バーの [クロールされたプロパティ] をクリックします。
次に、実際の例を示します。Customer Name というメタデータ フィールドのクロールされたプロパティは、ows_Customer_x0020_Name になります。SharePoint では、クロールされたプロパティの前に "ows_" が付けられます。"_x0020_" は、1 つのスペースがエンコードされた表現です。このクロールされたプロパティの詳細を表示すると、このプロパティが検索インデックスに既定で含まれていることがわかります。そのため、ユーザーは、このクロールされたプロパティの値を使用して、コンテンツの検索を実行できます。ただし、検索の精度を高めるために、クロールされたプロパティを管理プロパティにマップしないようにして、ユーザーが明示的に顧客名でコンテンツを検索できるようにすることもできます。
クロールされたプロパティを管理プロパティにマップする場合、2 つの方法を使用できます。これらは、クロールされたプロパティごとに新しい管理プロパティを自動的に生成する方法、およびクロールされたプロパティを管理プロパティに手動でマップする方法です。最初の方法は、目的のクロールされたプロパティが属するカテゴリの設定を表示する場合に使用できます (クロールされたプロパティを SharePoint カテゴリなどのカテゴリ別に表示する場合は、サイド リンク バーの [カテゴリの編集] をクリックします)。[クロールされたプロパティの一括設定] で、[このカテゴリのクロールで検出された各プロパティ用に新しい管理プロパティを自動生成する] チェック ボックスをオンにする必要があります。ただし、SharePoint では、自動的に作成された管理プロパティに "ows" が付けられ、スペースが "x0020" でエスケープされます。クロールされたプロパティ ows_Customer_x0020_Name の管理プロパティは、owsCustomerx0020Name になります。ただしこれは、あまりわかりやすいプロパティ名ではありません。
おそらく、より適切な方法は、企業全体用のコンテンツ タイプを展開してから、クロールされたプロパティを管理プロパティに手動でマップすることです。クロールされたプロパティは、1 つ以上の管理プロパティにマップできます。SharePoint サーバーの全体管理で新しい管理プロパティを作成するには、サイド リンク バーの [共有サービス管理] で、SSP へのリンクをクリックし、[検索の設定]、[メタデータ プロパティのマッピング] を順にクリックします。次に、[新しい管理プロパティ] をクリックし、必要な情報を指定して、新しい管理プロパティを目的のクロールされたプロパティに関連付けます。
ユーザーは、管理プロパティを "プロパティ: 構文" の形式で指定するか、高度な検索で指定することによって、関連するコンテンツ アイテムを検索できます。たとえば、クロールされたプロパティ ows_Customer_x0020_Name を管理プロパティ Customer にマップすると、ユーザーは、単純に標準の検索ボックスで "Customer: <顧客名>" (Customer: Contoso など) と指定するだけで、顧客用のドキュメントを検索できます。
また、[高度な検索] ページのプロパティ リストには、コンテンツ タイプの最も重要なメタデータ フィールドの管理プロパティを含めることをお勧めします。これを行うには、[高度な検索] ページを表示し、[サイトの操作] をクリックして、[ページの編集] を選択します。この後、高度な検索のボックスで [編集] をクリックして、[共有 Web パーツの変更] を選択できます。[プロパティ] カテゴリを展開し、対応するテキスト フィールドにカーソルを移動してボタンをクリックすると、そのプロパティの XML ドキュメントを編集できます。<PropertyDefs> 要素には、<PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/> などのプロパティ定義を追加する必要があります。また、ResultType 要素 (<ResultType DisplayName="All Results" Name="default"> など) の下に、このプロパティ定義への参照を <PropertyRef Name="Customer" /> のように追加する必要があります。図 5a は、変更後の [高度な検索] のユーザー インターフェイスを示しています。図 5b は、検索結果を示しています。
図 5a 顧客名に基づいて IT インフラストラクチャに関するドキュメントを検索する
図 5a 顧客名に基づいて IT インフラストラクチャに関するドキュメントを検索する
図 5b 顧客名による検索の結果
図 5b 顧客名による検索の結果

情報の一貫性を保つ
これで、最も重要なメタデータ フィールドとコンテンツ タイプを標準化し、MOSS 2007 に基づいて検索機能の範囲を企業内のすべてのサイト コレクションに拡張することができました。次は、ユーザーによってメタデータ フィールドに正確な情報が入力されるようにする必要があります。
これを行うための方法は 2 つあります。1 つ目は、ドキュメント テンプレート内の標準のドキュメント情報パネルを、ユーザーに定義済みの入力オプション (リスト ボックスなどで提供されます) を提供するカスタム InfoPath® フォームに置き換える方法です。2 つ目は、イベント レシーバをコンテンツ タイプにバインドし、対応するコンテンツ アイテムの作成、変更、削除をユーザーが行うたびに、メタデータや他の情報の精度を確認する方法です。
2 つの方法は、相互に補完し合っています。InfoPath フォームの主なメリットは、SharePoint コンテンツ タイプのプロパティの編集に便利であることです。一方、イベント レシーバを使用すると、ユーザーが InfoPath フォーム以外の方法でコンテンツ タイプのプロパティを編集した場合でも、有効なメタデータが入力されることが保証されます。イベント ハンドラは、特定のコンテンツ タイプにバインドできます。これにより、ドキュメント ライブラリとは関係なく、すべてのサイト コレクション内の各コンテンツ タイプに関連付けられたすべてのドキュメントに、イベントとその応答を指定できます。イベント ハンドラを作成および展開する方法については、msdn2.microsoft.com/ms453149 を参照してください。
コンテンツ タイプをカスタム ドキュメント情報パネルに関連付ける作業は、InfoPath 2007 がインストールされたコンピュータの SharePoint ユーザー インターフェイスで、そのコンテンツ タイプの [ドキュメント情報パネルの設定] を表示すると簡単に行うことができます。[ドキュメント情報パネル テンプレート] の [新しいカスタム テンプレートの作成] をクリックすると、InfoPath 2007 をデザイン モードで起動できます。ただし、サイト コンテンツ タイプに含まれているいずれかのサイト内の列に SourceID 属性が明示的に指定されていない場合、InfoPath がドキュメント情報パネル フォーム用の有効な XSD スキーマを作成できないことがあります。たとえば、前述の Customer Documentation コンテンツ タイプには Department、Office、e-mail など、連絡先固有の列が複数含まれているため、図 6 のような問題が発生する可能性があります。
図 6 InfoPath 2007 で発生する XSD スキーマの互換性に関する問題
図 6 InfoPath 2007 で発生する XSD スキーマの互換性に関する問題
この問題が発生した場合の解決方法は 2 つあります。1 つ目は、SourceID 属性が明示的に指定されていないサイト内の列への参照をコンテンツ タイプの定義から削除する方法です。2 つ目は、問題の原因である組み込みのサイト内の列を、InfoPath 2007 と互換性があるカスタムのサイト内の列に置き換える方法です。ただし、CAML で記述されたコンテンツ タイプのフィールド参照をコンテンツ データベースに準備した後、特に子コンテンツ タイプが既に作成されている場合は、そのフィールド参照を変更できないことに注意してください。Windows SharePoint Services では親コンテンツ タイプの定義に加えられた変更が追跡されないため、CAML で記述されたコンテンツ タイプの定義ファイルを簡単に更新することも、子コンテンツ タイプに変更を加えることもできません。
子コンテンツ タイプに変更を加えるには、SharePoint ユーザー インターフェイスまたはオブジェクト モデルから親コンテンツ タイプに変更を加えるか、既存のコンテンツ タイプから派生した新しいコンテンツ タイプを定義する必要があります。後者の方法を使用した場合、問題のフィールドを削除し、新しい列を追加できます。ユーザーは、新しいコンテンツ タイプから、その後使用するコンテンツ タイプを定義できます。ユーザーが不適切なコンテンツ タイプを選択しないようにするには、問題がある古いコンテンツ タイプを _Hidden コンテンツ タイプ グループに追加します。
既に述べたように、CAML で記述されたコンテンツ タイプを展開してアクティブ化した後に、そのコンテンツ タイプを更新することはできません。したがって、展開前にグローバル コンテンツ タイプをテストすることが非常に重要です。詳細については、MSDN の記事「コンテンツ タイプの更新」 (msdn2.microsoft.com/aa543504) を参照してください。
適切なフィールド参照が含まれたコンテンツ タイプを作成したら、InfoPath 2007 でカスタム ドキュメント情報パネルを作成できます。最適な方法は、サイト所有者が子コンテンツ タイプのカスタム ドキュメント情報パネルを作成できるようにすることです。InfoPath 2007 では、選択したコンテンツ タイプにカスタム ドキュメント情報パネルを直接発行するためのオプションが提供されます。このオプションを使用すると、展開作業が簡略化されます。また、ドキュメント ライブラリなどの集中管理された場所に InfoPath フォームを公開し、ドキュメント情報パネルへの参照をコンテンツ タイプに含めることもできます。CAML コンテンツ タイプと共にカスタム ドキュメント情報パネルを提供する場合は、この方法が最適です。図 7 は、このファイルの実装のアーキテクチャを示しています。
図 7 MOSS 2007 の集中管理された場所に公開する XSN ファイルの実装
図 7 MOSS 2007 の集中管理された場所に公開する XSN ファイルの実装
この記事のダウンロード ファイルには、AdventureWorks_Update という機能が含まれています。この機能は以前の AdventureWorks 機能を拡張したものであり、InfoPath 2007 と連携するサイト内の列が追加されています。AdventureWorks_Update 機能では、Customer Docs という新しいコンテンツ タイプが提供され、基になっている Customer Documentation コンテンツ タイプは非表示になるようにマークされています。この Customer Docs コンテンツ タイプでは、継承された組み込みのフィールドが新しいサイト内の列に置き換わっており、カスタム ドキュメント情報パネルと関連付けられています。
新しい Customer Docs コンテンツ タイプの定義には、ドキュメント情報パネルに関する情報を提供する XmlDocument 要素が含まれています。具体的には、xsnLocation 要素によって、ドキュメント情報パネルを実装する InfoPath フォーム http://companyresources/DIPs/customerDIP.xsn が参照されています。AdventureWorks_Update 機能を適用するための詳細な手順については、AdventureWorks_Update フォルダにある readme.htm ファイルを参照してください。

まとめ
SharePoint コンテンツ タイプを使用してメタデータのポリシーを作成し、それらの標準化されたポリシーを企業全体で使用してコンテンツを管理することができます。また、コンテンツ タイプ階層により、企業環境全体に関連する特性を標準化し、継承によってそれらをすべてのサイトに適用できるようになります。
特に重要なのは、MOSS 2007 の組み込みの検索機能を拡張することにより、ユーザーが特定のコンテンツを迅速かつ容易に検索できるようになるということです。また、メタデータに関連する情報の一貫性を維持し、情報管理ポリシーを集中管理することもできます。最適な方法は、最も抽象的なメタデータの特性に基づいてグローバル コンテンツ タイプを標準化し、後から変更が発生する可能性を最小限に抑えることです。注意深く設計されたコンテンツ モデルに基づいて作成された SharePoint コンテンツ タイプにより、企業全体でコンテンツのライフサイクルの管理を標準化できる新たな機能が提供されます。

Pav Cherny は、Biblioso Corporation の代表取締役です。主にコラボレーションとユニファイド コミュニケーションに関するマイクロソフト テクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでには、IT の運用とシステム管理について扱った書籍を執筆しています。


 Office Communications Server: プレゼンスが OCS 2007 にもたらす力
Office Communications Server Rajesh Ramanathan

プレゼンスが OCS 2007 にもたらす力
概要:
  • 承認サービスとディレクトリ サービス
  • OCS 2007 のメッセージングに関する選択肢
  • プレゼンスを使用して通信をルーティングする

Microsoft Office Communication Server (OCS) 2007 は、優れた機能を提供する Live Communication Server (LCS) 2005 を基に構築されています。LCS 2005 では、企業規模のインスタント メッセージング (IM) とプレゼンスが
提供されました。また、テレフォニーと既に設置されている PBX をリモート通話コントロール (RCC) によって統合できるようになりました。
OCS 2007 では LCS 2005 のプレゼンス機能と IM 機能がさらに強化され、Office Communicator 2007 を使用した高度なメディア機能と電話機能も追加されているため、本格的な "ソフト電話" に進化したと言えます。また、マイクロソフトでは、メディア用の会議サーバーとエッジ サーバーも開発されました。これらのサーバーを既存の PBX と共に使用するか、単独で完全な機能を提供するソリューションとして使用することにより、通信に関する組織のあらゆるニーズを満たすことができます。
ユーザーは、Office Communicator 2007 で提供される "ソフト電話" 機能を使用することにより、任意の USB デバイスを選択できるようになります。また、Office Communicator 2007 では、優れたエンド ユーザー エクスペリエンスが提供され、保留や転送などのよく使用する通話コントロール機能を簡単に見つけて使用することができます。ユーザーは、電話番号を思い出したり、ダイヤル パッドを使用したりする必要がなくなります。代わりにデスクトップ アプリケーションからクリック 1 つで簡単に通話を開始したり、他のユーザーや配布リストを会話内にドラッグ アンド ドロップして電話会議を作成したりすることができます。
実際の机上電話が必要な場合は、Office Communicator Phone Edition (Tanjay 電話) がユーザーのもう 1 つのエンドポイントとして機能します。このエディションでは、タッチスクリーンに対応したコンテキスト メニューや、馴染みのある Office Communicator のプレゼンスが提供されます。
OCS システムで提供されるこれらの機能は、ユーザーのプレゼンスという概念を意識して構築されています。OCS 2007 は、ユーザーの連絡可能性、通信のエンドポイント、およびユーザーの関係を使用して、常に最適な媒体でユーザーどうしを結び付けます。また、音声、電子メール、IM、およびその他の通信経路が統合されているため、最も効率のよい方法でメッセージをルーティングすることができます。
この記事では、OCS 2007 ソリューションの概要と、さまざまな通信手段がどのように統合されるかについて説明します。また、プレゼンスがユニファイド コミュニケーションの重要な要素としてどのように使用されるか、およびこの機能を活用してどのように音声通話のルーティングが効率化されるかについても説明します。

承認サービスとディレクトリ サービス
エンタープライズ ボイス システムは、通話を許可する際に、ユーザーの ID の有効性を確認できる必要があります。また、通話ごとに制限やポリシーを適用できる必要があります。ボイス オーバー IP (VoIP) システムでは、クライアントはサーバーの認証を受けてから通話を開始する必要があります。これは、物理的な回線の使用権があれば ID の有効性を示すことができた従来の PBX システムと似ています。
OCS 2007 システム (図 1 参照) は、アクセス ポリシーの認証と格納に Active Directory® を使用します。OCS は、Active Directory に登録されているユーザー用のポリシーを基準に通話の有効性を確認します。OCS では、Exchange Server や Microsoft® Outlook® など、マイクロソフトの他のアプリケーションと同じ Active Directory 情報が使用されるため、ユーザーのプロパティとポリシーを拡張し、音声アプリケーションや IM アプリケーションなどのリアルタイム アプリケーションに使用できる統合されたディレクトリを (Active Directory スキーマ拡張を使用して) 提供することにより、音声機能を Active Directory 内の既存のユーザーに追加することができます。
図 1 ユニファイド コミュニケーションに関連する OCS の構成要素
図 1 ユニファイド コミュニケーションに関連する OCS の構成要素
Active Directory で、ユニファイド コミュニケーションに関連する最も重要なプロパティは、ユーザーの電子メール アドレスと非常に近い特性を持つセッション開始プロトコル (SIP) アドレス (SIP URI) です。たとえば、someone@contoso.com という電子メール アドレスを持つ Active Directory 内のユーザーには、sip:someone@contoso.com という SIP アドレスが割り当てられます。SIP アドレスはユーザー オブジェクトに結び付けられているため、単一の ID を提供することによって、ユーザーはデスクトップ コンピュータや Exchange サーバーへのログオンに使用するものと同じ資格情報を使用して OCS サーバーにサインインできるようになります。
もう 1 つの重要なプロパティは、ユーザーの電話番号です。OCS サーバーは、電話番号宛に送信された通話の送信先を内部でユーザーの SIP URI に指定し直し、その通話をルーティングできるようにします。
OCS 2007 では、組織内のディレクトリの検索に使用できるアドレス帳サービス (ABS) インターフェイスが提供されます。アドレス帳のオフライン版であるこのインターフェイスを使用すると、クライアント側で検索操作が実行されるたびにクライアント エンドポイントが Active Directory にアクセスする必要がなくなります。
OCS 2007 では、ABS 以外の機能でも配布リストが活用されています。配布リスト展開 (DLX) サービスを使用すると、Office Communicator でも Outlook と同じ形式で配布リストを表示したり、Communicator の配布リストを展開したりすることができます。ユーザーは、これらの配布リストのメンバが参加する電話会議を Office Communicator から直接構成したり、グループ IM チャットを開始したりすることができます。

音声サービスとメッセージング サービス
OCS の関連資料
詳細については、次のリソースを参照してください。
  • ユニファイド コミュニケーションに関連するイベントと Web キャスト
  • Office Communications Server TechCenter
  • TechNet バーチャル ラボ : ユーザーを有効にして Office Communicator 2007 をインストールする

エンタープライズ ボイス ソリューションでは、ユーザーが最も使い慣れた通話コントロール機能が提供される必要があります。これを踏まえて、OCS 2007 では、よく使用される機能が提供されています。これらの機能には、通話の保留、通話の転送と保留転送、同時着信、および音声以外のモード (IM など) があります。
OCS 2007 は、音声通話のルーティングにおいて中心的な役割を果たしており、発信通話と着信通話の両方をルーティングする機能を提供します。発信通話のルーティングでは、番号の変換、ユーザーに関連付けられたポリシー (国際通話の制限など) の適用、適切なエンドポイントや外部の公衆交換電話網 (PSTN) へのルーティングなどが行われます。着信通話のルーティング機能は、ユーザーが選択した通話の転送や、時間帯とプレゼンスの設定を使用して、着信通話を適切にルーティングします。
OCS は、着信通話自体の終了処理は行いません。SIP 用語で言うと、SIP レジストラと SIP プロキシのような役割を果たします。シグナリングとメディアは 2 点間で提供されます。これらは、すべてシステム内のクライアント エンドポイントから提供されます。Office Communicator 2007 などのシステム内のエンドポイントでは、ネットワークの状態に対する適応力と回復力がある、広帯域のオーディオ コーデック (RTAudio と呼ばれます) が提供されます。
OCS 2007 では、すべての通信モード (音声ビデオ、IM、およびデータ) 用に、会議サーバーの役割を使用したオンプレミス Web 会議が提供されます。OCS ベースの会議サーバーを使用すると、クライアント エンドポイントは、ピアツーピア通信から複数のユーザーが参加するマルチ モーダル通信へのシームレスな移行を提供することができます。このマルチ モーダル通信では、ミュート、参加者の削除、ロックなどの機能を使用することができます。スケジュールされた会議では数百人、臨時のディスカッションでは 100 人まで参加者を増やすことができます。会議を Outlook アドインからスケジュールしたり、通話内で会議への拡張を行うこともできます。また、会議ソリューションでは、ファイルの共有、ホワイトボード、記録などのツールも提供されます。
もちろん、外部の PSTN ネットワークと電話番号への接続、およびフェデレーションが行われている企業や組織内に既に設置されている PBX との接続も提供できる必要があります。OCS 2007 は、一般的なゲートウェイ プロバイダによって提供されている SIP-PSTN ゲートウェイと統合されているため、PSTN や既存の PBX に接続することができます。また、仲介サーバーを構成して、コーデックとシグナリングを変換することができます。仲介サーバーは、マイクロソフトのコーデックがサポートされていないゲートウェイ用に任意で構成することができます。
OCS 2007 は、Exchange Server 2007 ユニファイド メッセージングをボイスメール ソリューションとして使用します。Exchange ユニファイド メッセージングによって、着信音声通話と着信 FAX 通話への通話応答が提供され、受信したメッセージがユーザーの Exchange メールボックスに配置されます。また、企業の特定の個人や部門宛に電話をかけた外部のユーザーへの自動応答も提供されます。
OCS では、音声通話の代わりにリアルタイム IM を使用することができます。また、音声、ビデオ、および IM を同時に使用してマルチモーダルな会話を行うこともできます。さらに、Office Communicator 2007 を使用した IM では、豊富な種類のテキストと書式が提供されます。そして、オーディオとビデオを IM セッションに追加して、IM を使用した会話をいつでもオーディオを使用した会話にシームレスに拡張することができます。
詳細記録、ログ記録、およびトラブルシューティングというコンポーネントも提供されます。詳細記録は、OCS 2007 のサーバー機能である通話の詳細記録を使用して提供されます。システム内で通話が発生するたびに、その通話が着信した時刻、通話に応答したユーザー、通話が転送されたかどうかなど、さまざまなパラメータの記録が作成されます。また、OCS では、規制遵守要件を満たすために IM 会話をログに記録するアーカイブ サーバーも提供されます。QoE (Quality of Experience) 監視サーバーには、発生した通話の品質に関する情報が格納されるため、これらの情報をネットワーク内の通話の品質に関する問題のトラブルシューティングに使用することができます。

登録と初期化
OCS システムのすべてのクライアント エンドポイントは、クライアントの初期化時に、まず OCS への登録とサインオンを行う必要があります。登録は、OCS サーバーに接続する処理であり、この段階でクライアントの存在が公開されます。登録処理では、サーバーによってユーザー ID の認証が行われます。このとき、クライアント インスタンスとサーバーとの間のセキュリティの関連付けが作成されます。このセキュリティの関連付けは、その後クライアントがこのサーバーを経由して行う通話に使用され、クライアントの再登録によって定期的に更新されます。再登録を行うまでの期間は、サーバーのトポロジによって異なります。たとえば、企業の外部から Microsoft AccessTM エッジ サーバーを使用して登録されたクライアント エンドポイントは、企業のファイアウォールの内側に配置されているクライアントよりも頻繁に登録を更新します。
登録が必要なのは、認証されたチャネルを OCS との間に永続的に確保して、音声通話などの着信通知やプレゼンス変更通知を受信する必要があるクライアント エンドポイントのみです。Live Meeting は、会議に参加する場合のみ OCS への接続を必要とするクライアント エンドポイントであるため、OCS への登録は必要ありません。
OCS 2007 内でのクライアントの対話について理解を深めるために、クライアント エンドポイントとしての Office Communicator について詳しく見ていきましょう (Office Communicator に関連するシグナリングの流れは、Office Communicator Phone Edition や Office Communicator Mobile などの他のクライアント エンドポイントに使用されるものと同じです)。登録が完了すると、Office Communicator はクライアント エンドポイントの操作にとって重要な構成情報を取得します。これらの情報を次に示します。
  • 連絡先カード、電子メール アドレス、SIP URI、表示名、電話番号などの個人情報
  • クライアントで有効になっている機能とポリシー
  • サーバーのアドレス (AV エッジ サーバーの SIP アドレスやボイスメール サーバーのアドレスなど)
  • サーバーに格納されている連絡先のバディ リスト
  • クライアントの場所に適用される、数値の書式に関する規則
サーバーへの既存の SIP チャネルを使用してプロビジョニングに関するすべての情報を取得するこのメカニズムを、インバンド プロビジョニングといいます。このメカニズムにより、クライアントがサインオンしたとき (ネットワークやファイアウォールの外部からサインオンした場合も含まれます) に、必ずクライアント エンドポイントを自動的に構成および更新することができます。
登録処理は、サーバーへの登録から始まり、初期化、プレゼンスの取得と設定へと続き、最終的に登録完了状態になります (図 2 参照)。OCS では、1 人のユーザーや 1 つの SIP URI 用に複数のクライアント エンドポイントを登録することができます。登録処理中、サーバーは一意の SIP アドレスをクライアントに返します。これは、すべての着信シグナルを特定のクライアントに送信できるようにするためです。このアドレスは、GRUU (Globally Routable User URI) としても知られています。OCS に登録されたクライアント エンドポイントには、それぞれ別々の GRUU アドレスが OCS サーバーによって割り当てられます。クライアント エンドポイントは、このアドレスによって一意に識別されます。
図 2 登録処理の流れ
図 2 登録処理の流れ
登録数を抑えるために、サーバーに登録できるアクティブなクライアント エンドポイントの数は、どのユーザーでも 8 つに制限されています。1 人のユーザー用に複数のクライアントが登録された場合の構成は、MPOP (multiple points of presence) として知られています。登録されたクライアントが 1 つの場合の構成は、SPOP (single point of presence) といいます。
MPOP の考え方は、OCS システムにとって不可欠です。MPOP によって、ユーザーはどのエンドポイントからの着信通話や IM 通知でも受信できるようになるため、実質的には複数の電話用または IM 用のエンドポイントを保持できることになります。また、魅力的な動的メカニズムを使用して、IM に応答したり、ユーザーのプレゼンスを正確に表したりすることもできます。
たとえばリモート ユーザーが、IM を受信できない Communicator Phone Edition が実行されている IP 電話 (SPOP エンドポイント) にサインオンする場合があります。このエンドポイントの機能は、プレゼンス情報と共に IP 電話によって公開されます。この電話におけるユーザーのプレゼンス状態はオンラインです。別のユーザーはこのオンライン状態を確認し、Communicator を使用して IM の送信を試行することができます。ただし、プレゼンスによって既にデバイスの機能が公開されているため、送信元のユーザーは、送信先のリモート ユーザーが IM に対応したデバイスを使用しておらず、メッセージを受信しない可能性があることを示す通知を受け取ります。
もう 1 つ、IM の自動受け付けの例を紹介します。このリモート ユーザーが 1 つの Communicator インスタンス (SPOP エンドポイント) にサインオンしている場合、IM 会話が開始されるとすぐに、このインスタンスは自動的にメッセージを受け付けます。しかし、リモート ユーザーが 2 つの Communicator インスタンス (ラップトップとデスクトップなど) にサインオンしている場合、このユーザーが 1 つのデバイスからインスタント メッセージを受信できるようになるまでに、10 秒の遅延が発生します。応答がなかった場合、インスタント メッセージは最もアクティブな Communicator インスタンスで自動的に受け付けられます。

プレゼンス
プレゼンスは、ユニファイド コミュニケーションにおいて重要な役割を果たします。ユーザーはこの機能を使用して、通信先のリモート ユーザーが特定のモードで通信できるかどうかをあらかじめ知ることができます。このため、OCS によって通知される "取り込み中 - 通話中" などの状態は、デバイスや回線が使用中であることではなく、ユーザーが取り込み中であることを示しています。また、OCS 2007 ではプレゼンス インフラストラクチャが強化されており、ユーザーは場所、勤務時間、会議の時間などの情報を共有することができます。
さらに、ユーザーは OCS を使用してアクセス許可を指定し、各グループのユーザーがアクセスできるプレゼンス情報がグループのアクセス レベルに基づいて制限されるようにすることができます。また、OCS は "応答不可" などのプレゼンス状態だけでなく、予定表に入力された勤務時間と発信者に提供されたアクセス許可のレベルを使用して、発信した通話でユーザーを呼び出すか、通話をボイスメールに送信するか、というルーティングに関する判断を下します。
Office Communicator に呼び出し先として表示される電話番号は、3 つの情報源から取得されます。2 つはディレクトリ (グローバル アドレス一覧またはアドレス帳サーバー、および Outlook の連絡先)、そしてもう 1 つはプレゼンスです。ユーザーはプレゼンスを使用して、他のユーザーに公開する電話番号を柔軟に決定することができます。
プレゼンスは、多くの音声ルーティングのシナリオでも重要な役割を果たします。たとえば、あるリモート ユーザーのプレゼンスが "取り込み中" であり、"会議中" というテキストが表示されている場合、そのユーザーが音声通話に応答する可能性はあまりありません。この場合、発信者は IM や電子メールを使用した方がよいでしょう。同様に、あるリモート ユーザーのプレゼンスが "応答不可" である場合は、別の通信方法を使用した方がよいと考えることができます。
プレゼンスによって提供される情報には、ユーザーが現在出席している会議の名前や、予定表に記載されている会議の場所などの情報があります。これらの詳細情報は、[チーム] コンテナのユーザーに公開されます。また、特定の機能に適したエンドポイントに関する情報もプレゼンスによって提供されます。この情報は、既定の操作を実行するエンドポイントを選択するために使用されます。たとえば、予定表データの公開 (基本的にどのエンドポイントでも同じ操作が実行されます) は、予定表機能に適したエンドポイントからのみ実行されます。OCS では、適切なエンドポイントを選択するためのロジックが提供されます。
図 3 は、プレゼンスが OCS システムに提供するさまざまな機能を示しています。既に説明したように、プレゼンスは連絡可能性と通信意思を組み合わせたものです。"オンライン" 状態は、ユーザーが通信を行う意思が最も強いことを示しており、"応答不可" 状態はその意思が最も弱いことを示しています。手動で設定する "応答不可" 以外の状態は、Communicator によって自動的に設定されます。この状態は、ユーザーが会議中 ("取り込み中") であるかどうかや、コンピュータから離れているかどうか ("非アクティブ" の後、"退席中" に変わります) など、さまざまな状態に基づいて決定されます (図 4 参照)。
Figure 3 プレゼンス情報の設定方法 (Close Figure 3)

特性 | 設定方法と情報源
連絡可能性と通信意思 (オンライン、オフライン、退席中、取り込み中、応答不可) | 自動。会議の状態や電話の状態などに基づいて決定されます。手動で設定することもできます。
予定表の状態 (会議中、会議の場所) | 自動。ユーザーの設定に基づいて決定されます。
デバイスの機能 (IM への対応) | 自動。MPOP デバイスに基づいて決定されます。
電話番号 | 自動。ユーザーの設定に基づいて決定されます。
最もアクティブなエンドポイント | 自動。ユーザーの活動に基づいて決定されます。
メモ | 手動。このメモよりも不在メモの方が優先されます。
不在メモ | 自動。予定表に基づいて決定されます。
勤務時間 | 自動。空き時間データに基づいて決定されます。
場所 | 手動。ユーザーの選択内容に基づいて決定されます。
図 4 連絡可能性と通信意思を組み合わせたプレゼンス
図 4 連絡可能性と通信意思を組み合わせたプレゼンス
連絡可能性は、ユーザーが現在サインオンしているデバイスによって異なる場合があります。1 人のユーザーによって複数のデバイスが使用され、各デバイスによってプレゼンス情報とそのデバイスに格納されたユーザー データが公開されるため、状態を参照するユーザーに 1 つの状態を表示するための集計ロジックが必要です。OCS では、さまざまなパラメータ、デバイス、およびプレゼンス システムが受け取った入力に基づいてプレゼンスを算出する集計ロジックが提供されます。
集計について詳しく説明する前に、集計された情報がどのようにしてユーザーに公開されるかを説明しておきましょう。OCS 2007 ではコンテナという概念が導入されています。この概念は、社会的なグループに関連付けられたアクセス レベルと少し似ています。提供される情報はコンテナごとに異なり、特定のコンテナに追加されたユーザーは、そのコンテナに公開されている情報にのみアクセスできます。このユーザーのバディ リストに含まれているユーザーは、利用可能ないずれかのコンテナ内に存在する必要があります。ユーザーは、Office Communicator を使用すると、関係のレベルに基づいて、他のユーザーをコンテナに割り当てたり、他のコンテナに移動したりすることができます。Office Communicator は、優れたヒューリスティックを使用して既定のコンテナを自動的に選択します (図 5 参照)。
Figure 5 プレゼンス コンテナ (Close Figure 5)

コンテナ | 目的
禁止 | プレゼンス情報は公開されません。禁止されているユーザーからの通話は拒否されます。ただし、禁止されているユーザーは名前と電子メールに関する情報を参照できます。
公開用 | 名前、役職、会社名、電子メール アドレス、および制限付きの連絡可能性が公開されます。
社内 | 連絡先情報、基本スケジュール、および連絡可能性が公開されます。
チーム | 勤務先の電話番号と携帯電話番号、予定、および連絡可能性が公開されます。そのユーザーが "取り込み中" 状態であっても割り込むことができます。
個人用 | 自宅の電話番号と携帯電話番号を含む、公開されているすべての連絡先情報を参照できます。
OCS のプレゼンス集計により、デバイスがサーバーに報告したさまざまなプレゼンス状態に基づいて、ユーザーの正確なプレゼンスが決定されます。図 6 は、どのようにしてさまざまな要素からプレゼンスが集計されるかを示しています。プレゼンス状態やユーザーの活動などの情報は、OCS のプレゼンス集計メカニズムを経由して送信され、その後コンテナに公開されますが、連絡先などのその他の情報は、クライアント エンドポイントによって各コンテナに追加されることに注意してください。[禁止] コンテナは図 6 には記載していません。これは、このコンテナにはメンバシップ以外の情報が公開されないためです。
図 6 プレゼンスの集計と公開
図 6 プレゼンスの集計と公開
OCS システムでは、あるユーザーが別のユーザーを連絡先リスト (バディ リスト) に追加すると、プレゼンスの関係が確立されます。しかし、OCS システムでは、企業ディレクトリ内の他のユーザーを個別に連絡先に追加しなくても、それらのユーザーのプレゼンスを参照できます。
他のユーザーのプレゼンスを参照する最も単純な方法は、Office Communicator でユーザーを検索することです。この操作を行うと、サーバーへのクエリが 1 つ生成されますが、そのリモート ユーザーのプレゼンス状態が変更されたことを示す通知はサブスクライブされません。しかし、ユーザーが別のユーザーをバディ リストに追加すると、そのユーザーのプレゼンス状態が変更されたことを示す通知がサブスクライブされるようになります。これは、プレゼンスが変更されたときに OCS が自動的に通知を送信できるようにするためです。

IM とオーディオ
IM は、登録とプレゼンスの両方を活用します。OCS システムでは、メッセージがピアツーピアで送受信されます。OCS サーバーは、Office Communicator クライアント間のメッセージを中継するプロキシとして機能します。
ユーザーが別のユーザーに最初に送信するメッセージは重要です。SIP 用語で言うと、このメッセージによってセッションが確立されます。セッションを確立する際には、登録されているクライアントから適切な MPOP クライアントを検出する処理が実行され、ここで OCS がプロキシとして重要な役割を果たします。ユーザーが着信 IM セッションを受け付けるか、そのユーザーの MPOP エンドポイントが自動的にセッションを受け付けた場合、その後は OCS が適切なクライアントを検索する必要はなくなり、メッセージはスムーズに送受信されます。
ユーザーは、デスクトップ上の IM 会話ウィンドウを開いたままにしておくことができます。Office Communicator 2007 では、10 分間何も操作が行われなかった場合、SIP セッションが終了します (IM ウィンドウは開いたままです)。IM セッションは、どちらのユーザーが終了することもできます。IM セッションが終了すると、Office Communicator 2007 によって、その会話の履歴アイテムが自動的に作成されます。このアイテムによって、Outlook の [会話履歴] フォルダに会話の内容全体が記録されます。これは、Office Communicator によって Outlook に作成される特殊なフォルダです。このクライアント側のログ記録機能は任意で有効にすることができ、既定では無効になっています。会話履歴は、同じユーザーとの会話を再開するときに、Office Communicator によって使用されます。このため、ユーザーはこの機能を有効にすると、IM ウィンドウを閉じた後でも簡単に IM 会話を続行することができます。
ここで説明した分岐と MPOP に関する IM の構造は、音声のシナリオにも非常によく当てはまります。このシナリオの招待文には、IM セッションの説明の代わりに、オーディオ機能を示す音声セッションの説明が記載されます。OCS では、IM の場合と同じように、すべてのエンドポイントへの音声通話に分岐が適用されます。
音声のシグナリングの大部分は IM の考え方に基づいていますが、このシナリオではメディアに対処する必要があります。これについては、今後の記事で詳しく説明する予定です。

Rajesh Ramanathan は通信業界に 14 年間携わっており、現在は Office Communicator チームのリード プログラム マネージャを務めています。連絡先は rajeshra@microsoft.com (英語のみ) です。


 Office Communications Server: OCS 2007 ボイスの展開を計画する
Office Communications Server Jochen Kunert and Rui Maximo

OCS 2007 ボイスの展開を計画する
概要:
  • テレフォニーの統合シナリオ
  • Office Communications Server の構成
  • ユーザー、番号計画、およびルート

Office Communications Server (OCS) 2007 は、リアルタイム通信メディアを、Web 電話会議
(データ、音声、ビデオの共有)、インスタント メッセージング、音声やビデオ会話などのユーザー プレゼンス情報と統合するエンタープライズ製品です。OCS 2007 と既存の PBX システムの統合は困難な場合があります。Office Communications Server 2007 は PBX としては設計されていません。というのは、PBX システムは電話にしか対応していませんが、今日のインフォメーション ワーカーは日常のワークフローの中で、電子メール、インスタント メッセージング、電話、ボイスメールなどのさまざまなメディア通信を活用しているからです。
管理者が最適な 1 つのテレフォニー、または企業テレフォニー統合戦略を作成するのに必要な柔軟性を提供するために、Office Communications Server 2007 では既存のテレフォニー環境と統合する 3 つの構成シナリオが用意されています。そのシナリオは、リモート通話コントロール、エンタープライズ ボイス、および PBX 統合エンタープライズ ボイスです。
この記事では、既存のテレフォニー システムと統合する必要がある OCS 2007 のテレフォニー展開の計画時の考慮事項に重点を置いて説明します。この情報は、システム アーキテクト、IT 管理者、およびテレフォニー管理者にとって、特に興味深いものとなるでしょう。その他のシナリオについても説明しますが、この記事では Office Communications Server 2007 エンタープライズ ボイスに重点を置いて説明します。

リモート通話コントロール
OCS の関連資料
  • Pro LCS: Live Communications Server Administration
  • Office Communications Server 2007 を使用してテレフォニーを統合する
  • エンタープライズ ボイスの計画と導入ガイド

リモート通話コントロール (RCC) シナリオでは、ユーザーは既に PBX、IP-PBX、または時分割多重 (TDM) の机上電話を使用していることを前提としています。Office Communicator 2007 クライアントを使用すると、ユーザーは、ダイヤル パッドからダイヤルしたり、ヘッドセットを使用することなく、机上電話から電話をかけたり、通話に応答したりすることができます。ユーザーは Office Communicator 2007 から机上電話をコントロールできますが、音声は依然として PBX システムによって処理され、ボイス オーバー IP (VoIP) 通話には変換されません。Office Communicator 2007 で机上電話をコントロールしていても、また Office Communicator 2007 が実行中かどうかにかかわらず、PBX 電話で電話をかけたり受けたりすることは依然として可能です。
Office Communicator 2007 と OCS 2007 で RCC を有効にするには、Office Communications Server 2007 環境で RCC を有効にし、セッション開始プロトコル (SIP) と Computer Supported Telephony Application (CSTA) ゲートウェイを展開する必要があります。SIP/CSTA ゲートウェイは使用中の PBX システムと相互運用する必要があり、2 つのシステムをブリッジするため、OCS 2007 とも互換性がなければなりません。Office Communicator 2007 では、PBX 電話のコントロールに CSTA プロトコルを使用しています。このプロトコルは、電話スイッチ (PBX) とのインターフェイスとなる、ECMA (ヨーロッパ電子計算機工業会) の規格 269 で規定されている XML スキーマを定義します。この規格については、www.ecma-international.org/publications/standards/Ecma-269.htm を参照してください。
Office Communications Server 2007 によってルーティングされた SIP ペイロードとして PBX 電話をコントロールするために、Office Communicator 2007 は、SIP/CSTA ゲートウェイに CSTA コマンドを送ります。Office Communications Server 2007 では CSTA を理解する必要はありません。理解する必要があるのは、どうやってルーティングするか、ということだけです。SIP/CSTA ゲートウェイでは、コマンドを受け取ると、PBX で使用されているネイティブ プロトコルに変換します。これを示したものが図 1 です。
図 1 RCC 統合シナリオ
図 1 RCC 統合シナリオ
RCC を有効にするには 5 つの手順が必要です。1 つ目の手順では、PBX と通信するように SIP/CSTA ゲートウェイを構成します。2 つ目の手順では、CSTA 要求を SIP/CSTA ゲートウェイにルーティングするように OCS 2007 を構成します。3 つ目の手順では、RCC に対応するようにユーザーを構成します。4 つ目の手順では、Office Communicator 2007 を構成します。そして、5 つ目の手順では、OCS 2007 の正規化ルールを定義します。このルールは、アドレス帳電話番号の正規化にも使用されますが、エンタープライズ ボイスと組み合わせて使用されている電話番号正規化ルールとは別のルールです。

エンタープライズ ボイス
ユーザーがエンタープライズ ボイスに対応するように構成されると、PBX 電話ではなく、Office Communicator 2007 または Office Communicator Phone Edition が通常使用する電話となります。Office Communicator 2007 には一意の電話番号が割り当てられます (テストでは、既存の PBX 電話を Office Communicator 2007 に新しく割り当てられた内線番号に転送することができます)。推奨の USB オーディオ デバイスと併用すると、Office Communicator 2007 は通話コントロール (または信号) とメディア (音声とビデオ) の両方に対応します。
このシナリオでは、Office Communications Server 2007 は、通話を IP ネットワーク (IP 間通話) 上の Office Communicator 2007 エンドポイントにルーティングし、公衆交換電話網 (PSTN) と PBX (IP-PSTN 通話) 間の通話をルーティングします。OCS 2007 では PSTN にルーティングされた通話にダイヤル制限を適用します。
Office Communications Server 2007 環境を、PBX または PSTN に接続するには、メディア ゲートウェイを展開する必要があります (メディア ゲートウェイは、SIP/PSTN または IP/PSTN ゲートウェイとも呼ばれます)。図 2 に示しているように、Office Communications Server 2007 環境に接続するには、メディア ゲートウェイを仲介サーバー (OCS 2007 のサーバーとしての役割) と組み合わせて使用する必要があります。また、仲介サーバーと関連付けられたメディア ゲートウェイは、物理的に同じ場所にインストールされている必要があります。
図 2 PSTN または既存の PBX を使用したエンタープライズ ボイスの統合シナリオ
図 2 PSTN または既存の PBX を使用したエンタープライズ ボイスの統合シナリオ
OCS 2007 では承認済みの暗号化通信のみを許可するので、仲介サーバーは、標準 SIP (セキュリティで保護されていない SIP 実装も含む) をサポートするメディア ゲートウェイを Office Communications Server 2007 に接続することを可能にします。また仲介サーバーのもう 1 つの役割は、標準コーデック (G.711、G.723など) とマイクロソフトのリアルタイム オーディオ コーデック間のコーデック変換を処理することです。Office Communications Server 2007 でサポートされるメディア ゲートウェイのリストについては、「戦略的なハードウェア パートナー」(technet.microsoft.com/bb735838) を参照してください。
メディア ゲートウェイは PSTN または既存の PBX の Primary Rate Interface (PRI) トランク接続に直接接続することができます。図 2 は、エンタープライズ ボイス シナリオを PSTN および既存の PBX と統合する実現可能な統合シナリオを示しています。ディレクタ (通常は Office Communications Server Standard Edition がインストールされたサーバー) はエンタープライズ ボイスの展開に必要ではありませんが、ディレクタの使用は推奨されています。
エンタープライズ ボイスを有効にするには 4 つの手順が必要です。1 つ目の手順は、メディア ゲートウェイの展開と構成です。メディア ゲートウェイは、マイクロソフト パートナーの製品なので、各メディア ゲートウェイの展開手順は異なります。メディア ゲートウェイの展開手順については、各ベンダが提供しているドキュメントを参照してください。
2 つ目の手順は、すべてのメディア ゲートウェイに仲介サーバーを展開することです。ここでは、仲介サーバーの 1 枚のネットワーク カードはメディア ゲートウェイからトラフィックを送受信するために構成し、もう 1 枚のネットワーク カードは Office Communications Server 2007 (通常は Enterprise Edition が展開されているディレクタ) からトラフィックを送受信するために構成する必要があります。メディア ゲートウェイがアドバンスト ゲートウェイである場合を除き、OCS 2007 エンタープライズ ボイス インフラストラクチャと相互運用するには、OCS 2007 仲介サーバーの役割をサポートする必要があります。
3 つ目の手順は番号計画を定義することです。これにはボイス ポリシー、電話のルーティング、場所のプロファイルを定義することが含まれます。
そして、4 つ目の手順はエンタープライズ ボイスに対応するようにユーザーを構成することです。また、PBX または PSTN からの通話を送受信するには、ユーザーがエンタープライズ ボイスに対応している必要があります。このためには、各ユーザーに一意の電話番号を割り当てる必要があります。

PBX 統合を使用したエンタープライズ ボイス
この構成はエンタープライズ ボイス構成の拡張機能です。異なるのは、ユーザーの PBX 電話と Office Communicator クライアントが同期される点です。この構成は、PBX 経由で PSTN に接続するエンタープライズ ボイス シナリオ (図 2 参照) に似ています。しかし、この構成では、ユーザーの PBX 電話を Office Communicator 2007 クライアントと置き換えるのではなく、Office Communicator 2007 と既存の PBX 電話では同じ電話番号を使用します。
発信者が、別の PBX 電話または PSTN 電話からユーザーの内線番号をダイヤルした場合、PBX システムは、通話をユーザーの PBX 電話とユーザーの Office Communicator 2007 クライアントに Office Communications Server 2007 を通して分岐します。ユーザーの Office Communicatior 2007 クライアントと PBX 電話は着信通話がある場合、同時に鳴ります。これに対して、Office Communications Server では OCS 2007 から発信された通話をメディア ゲートウェイを通して PBX へ分岐します。このシナリオは Office Communicator Phone Edition を使用している場合は実現できません。この構成では、ボイスメールが PBX のボイスメール システムで処理される必要があります。Exchange Server 2007 のユニファイド メッセージングは、このようなユーザーのボイスメール ソリューションとして使用することはできません。
PBX 統合を使用したエンタープライズ ボイスを有効にするには、エンタープライズ ボイスの展開と同じ手順が必要ですが、それに加えてもう 3 つの手順が必要です。1 つ目の追加手順は、メディア ゲートウェイを PBX に直接接続することです。2 つ目の手順は、このシナリオをサポートするように PBX を構成することです (使用している PBX のベンダによっては、ここで PBX のソフトウェアの更新が必要になることがあります)。そして、3 つ目の手順は、ユーザーを PBX 統合に対応するように構成することです。
マイクロソフトは、メディア ゲートウェイの介在なしで、仲介サーバーが直接 IP PBX に接続するためのサポートを提供できるよう取り組んでいます。このトピックに関する最新情報については、technet.microsoft.com/bb735838 を参照してください。

Office Communications Server を構成する
エンタープライズ ボイス機能は Office Communications Server 2007 Enterprise Edition と Office Communications Server 2007 Standard Edition で実行中のサービスで処理されます。図 3 では、送受信される通話をルーティングするエンタープライズ ボイス機能を提供するサービスを示しています。
Figure 3 エンタープライズ ボイス サービス (Close Figure 3)

サービス | 説明
変換サービス | 場所のプロファイルまたは電話のコンテキストに基づいて正規化ルールを適用します。
ユーザー サービス | 対象となる電話番号について、番号の逆引き参照を行います。
着信ルーティング コンポーネント | 対象ユーザーの通話設定に適用します。
Exchange ユニファイド メッセージング | 要求を必要に応じてボイスメールに転送します。
送信ルーティング コンポーネント | 最適なルートを URI とユーザー ポリシーに基づいて決定します。
図 4 では、OCS 2007 によって PC 間通話を行うためにルーティングされた受信通話を、これらの各コンポーネントがどのように処理するかを示します。着信通話は、Office Communicator 2007 または Office Communicator Phone Edition などの接続済みのエンドポイントまたは PSTN/PBX (PSTN-SIP 通話) の仲介サーバーから発信されます。Office Communicator 2007 などの発信者の Office Communications Server 2007 クライアント エンドポイントの 1 つから発信された通話は、Standard Edition サーバーまたはユーザーがホームとして使用しているエンタープライズ プールに送信されます。これをユーザーのホーム プールといいます。
図 4 OCS フロント エンド サーバーにおけるエンタープライズ ボイスに関連するサービスの操作
図 4 OCS フロント エンド サーバーにおけるエンタープライズ ボイスに関連するサービスの操作
この時点で、Office Communications Server 2007 は、通話を処理して、どこにルーティングするかを判断します。この次ホップは、通話の呼び出し先のホーム プール、仲介サーバー、または Microsoft® Exchange Server 2007 のユニファイド メッセージングのどれかです (図 5 参照)。通話が他のホーム プールにルーティングされると、OCS 2007 では通話の呼び出し先のすべてのアクティブなエンドポイントに通話を送信します。呼び出し先の Office Communicator 2007 または Office Communicator Phone Edition では、着信音が鳴り、デバイスにポップアップ ウィンドウ通知が表示されます。
図 5 通話のルーティング
図 5 通話のルーティング
通話が仲介サーバーにルーティングされる場合、サーバーは特定のメディア ゲートウェイにルーティングするように構成されています。メディア ゲートウェイが PBX に直接接続されている場合、通話は PBX によって机上電話または PSTN にルーティングされます。しかし、メディア ゲートウェイが PSTN に直接接続されている場合は、通話は PSTN に送信されます。
次ホップが Exchange Server 2007 のユニファイド メッセージングの場合、発信者はメッセージを残すことができます。呼び出し先が Office Communications Server 2007 にサインインしているかどうかにかかわらず、ボイス メールは使用可能です。
呼び出し先が通話に応じると、呼び出し元の Office Communicator 2007 または Office Communicator Phone Edition から、呼び出し先の Office Communicator 2007 または Office Communicator Phone Edition へ、IP 間通話として直接音声が送信されます。呼び出し元が PBX または PSTN 電話を使用している場合、仲介サーバーは呼び出し先の Office Communicator 2007 または Office Communicator Phone Edition へ、IP-PSTN 間通話として音声トラフィックを直接送信します。OCS 2007 では通話シグナリングのみが処理されるので、音声とビデオはエンドポイント間で直接やり取りされ、OCS 2007 によってルーティングはされません。

ユーザーを構成する
エンタープライズ ボイスが有効になっているユーザーには、組織内で一意の電話番号が割り当てられている必要があります。この構成は Active Directory® で行います。これは、電話機に電話番号を割り当てる、多くのテレフォニー システムと異なる点です。このデザインのメリットは、クライアントから OCS 2007 にサインインすることによって、ユーザーが Office Communicator 2007 を実行中の任意のコンピュータを電話として使用できる点です。この携帯性の高い機能は、在宅勤務者や現場の勤務者に魅力的な機能となるでしょう。
Active Directory では、ユーザーの電話番号は E.164 形式で指定されます。この形式は、明確に一意な電話番号の付番パターンを表す国際公共通信の番号計画を定義します。E.164 形式は電話番号を次の形式で指定します。
+<country code><area code><phone number>
エンタープライズ ボイスが有効になっているユーザーは、SIP URI と E.164 という 2 とおりの一意の電話番号を使用します。電話番号がダイヤルされると、Office Communications Server は E.164 形式の電話番号 (+14255551212) をユーザーの SIP URI (joe@contoso.com) に解決します。これを受けて、Office Communications Server 2007 は、呼び出し先の SIP URI に基づいて通話をルーティングします。電話番号を SIP URI に解決できない場合、OCS 2007 は仲介サーバーを通して通話を PBX/PSTN へルーティングします。
すべての Office Communications Server ユーザーに一意な電話番号を割り当てるエンタープライズ ボイス展開を計画している場合、既存のテレフォニー システムを考慮する必要があります。メディア ゲートウェイを介して PSTN に直接接続している場合、OCS 2007 ユーザーに配布できる Direct-Inward-Dialing (DID) 番号である 2 ～ 3 桁の内線番号で構成された 1 つの番号ブロックを使用する可能性が高いでしょう。PBX 経由で PSTN に接続する場合は、PBX によって提供される DID 番号ブロックを OCS 2007 ユーザーに割り当てる可能性が高いでしょう。

番号計画
E.164 形式の電話番号では一意な電話番号を実現できますが、番号をダイヤルするのに便利な形式ではありません。また、Office Communicator Phone Edition または 標準の PBX/PSTN 電話では、この形式で番号を入力することができません。10 桁のダイヤルパッドを使って、どうやって + 文字を指定するのでしょうか。ユーザーは、短い内線番号をダイヤルするのに慣れています。このような内線番号は、特定の場所では一意でも、全社規模では一意でないでしょう。そのため、このような内線番号を E.164 形式に変換する変換ルールを指定する必要があります。
管理者は、このような番号変換を行うために、正規化ルールを指定する場所のプロファイルを定義する必要があります。電話番号がクライアント (Office Communicator 2007 または Office Communicator Phone Edition) または Office Communications Server 2007 の変換サービスによって、E.164 形式に拡張された後、ユーザー サービスでは番号の逆引き参照を実行して、E.164 番号を対応する SIP URI と照合させます。場所のプロファイルで定義された正規化ルールは、一致するものが検出されると、正規表現を使用して変換処理を行います。たとえば、1234 がダイヤルされると、+1425555{4 桁} へ変換できるすべての 4 桁のパターンを検出する正規化表現は 1234 を +1425551234 に変換します。そのため場所のプロファイルによって、ユーザーは使い慣れている今までと同じダイヤルを使い続けることができます。
管理者は次の 3 つの方法で、ユーザーに場所のプロファイルを割り当てることができます。
  • グループ ポリシーを使って Office Communicator 2007 を使用しているユーザーに場所のプロファイルを定義する。
  • ユーザーが Office Communicator Phone Edition から場所のプロファイルを選択できるようにする。
  • ホーム プールに場所のプロファイルを割り当てる。そのプールをホームとして使用しているユーザーには、自動的にその場所のプロファイルが割り当てられます。
番号計画を定義するには、ボイス ポリシー、電話ルーティング、および正規化ルールを使用した場所のプロファイルの作成が必要になります。ボイス ポリシーは、ユーザーが使用できる通話アクセスの種類を定義します。Office Communication Server 2007 では、どの電話ルーティングによって PBX/PSTN に通話をルーティングするかを決定します。電話番号は、さまざまな方法でダイヤルされるので、場所のプロファイルの正規化ルールでは、ダイヤルされた電話番号を E.164 形式に変換する方法を定義します (変換された番号は、ルーティングされます)。
エンタープライズ ボイスが有効になっているすべてのユーザーは、管理者によってボイス ポリシーが関連付けられます。ボイス ポリシーは、ユーザーに割り当てられた通話の権限を定義します。通話の権限は、ユーザーがどのルートを使用できるのか、つまり、ユーザーがどの番号をダイヤルできるのかを決定します。各ユーザーは 1 つのボイス ポリシーと関連付けられている必要があります。使用可能なポリシーの数は管理者によって作成されます。
各ボイス ポリシーには、電話の同時呼び出しを有効にするのをユーザーに許可/拒否する設定と、電話使用法の番号付きリストがあります。ミーティング ポリシーとよく似たボイス ポリシーは、XML ドキュメントとして定義され、Active Directory に格納された設定の論理コンテナです。このデザインには、Active Directory スキーマを拡張することなく、OCS 2007 の将来のバージョンに拡張して、追加のポリシー設定をサポートできるというメリットがあります。たとえば、ボイス ポリシーがどの電話使用法にも関連付けられていない場合、そのポリシーに割り当てられたユーザーが PBX/PSTN に送信通話を行えなくなるという影響があります。このようなユーザーは IP 間通話しか行うことができません。

電話使用法とルート
電話使用法は、ユーザーに許可されている電話ルーティング特権を定義します。電話使用法は電話ルートの集まりです。これは一意である必要があるキーワード文字列です。つまり、複数の電話使用法に同じ名前を付けることはできません。管理者は必要な数だけ電話使用法を作成することができます。
ボイス ポリシーは、電話使用法ではなく直接 1 つのルートまたは一連のルートに関連付けることができますが、電話使用法キーワードがポリシーとルート間の関連付けを管理する抽象要素は電話使用法キーワードです。ポリシーが直接ルートに関連付られ、効果的に電話使用法の概念を取り除き、管理者がルートの名前を変更した場合、そのルートに関連付けられたすべてのポリシーを更新する必要があります。ポリシーとルート間の関連付けを作成する、ポリシーとルート両方の属性である電話使用法を使うことによって、ポリシーとルート間の関係は、ルートの名前が変わっても維持されます。
ルートには電話番号のパターンとメディア ゲートウェイに接続された仲介サーバーのリストが含まれます。1 つのルートは少なくとも 1 つの電話使用法に関連付けられる必要があります。このパターンとゲートウェイ間の関連付けは、特定のパターンに一致する電話番号をどのようにルーティングするかを指定します。
パターンは一致する電話番号の範囲を指定します。パターンは、電話番号を包含または除外する正規表現として定義されます。エンタープライズ ボイス ルート ヘルパー ツールは、このような正規表現をさらに簡単に構成できるようにするために用意されています。結果として、ダイヤルされた電話番号が、ルートの正規表現パターンに一致すると、その通話はルートに定義されたゲートウェイの 1 つにルーティングされます。
1 つのルートには、1 台以上の仲介サーバー (およびメディア ゲートウェイ) を指定できます。Office Communications Server 2007 は、ゲートウェイを通過するトラフィックのバランスを取るために、仲介サーバーへ総当たりの方法で通話をルーティングします。ゲートウェイが動作しなかったり、保守のため使用できない場合、対応する仲介サーバーは Office Communications Server 2007 に応答を返します。その結果、Office Communications Server 2007 では、すぐに、その通話をルートのリストにある他の仲介サーバー (および別のメディア ゲートウェイ) へのルーティングを試みます。
失敗したメディア ゲートウェイへの通話のルーティングを 10 回試行した後、続いて Office Communications Server 2007 は、メディア ゲートウェイが再び応答するようになるまでメディア ゲートウェイへのトラフィックをスケール ダウンします。メディア ゲートウェイがもう 10 回試行しても応答に失敗した場合、Office Communications Server 2007 では、そのメディア ゲートウェイが再び応答するようになるまで、そのメディア ゲートウェイへの通話のルーティングを中止します。
電話ルートに定義されているメディア ゲートウェイのリストは、ゲートウェイの完全修飾ドメイン名とポート番号で記述されています。電話番号が正規表現パターンに一致しない場合、ユーザーに割り当てられた電話使用法に関連付けられている次のルートに、一致するパターンがあるかどうかをチェックします。一致するパターンが見つからない場合、通話はルーティングされず、送信先に届けられず、ユーザーは通話が完了できなかったという通知を受け取ります。

次のステップ
Office Communications Server 2007 は 3 つのレベルのテレフォニー統合を提供します。テレフォニーの統合を計画するときには、どのレベルが現在と今後のテレフォニー ビジネス ニーズに最も適合しているかを判断する必要があります。これを決定したら、展開を計画できます。計画において大切なことは、Office Communications Server エンタープライズ ボイス展開の番号計画の定義です。これは慎重に検討する必要があります。
Office Communications Server 2007 のエンタープライズ ボイスと関連技術に関する詳細については、補足記事の「OCS 2007 の関連資料」を参照してください。

Jochen Kunert は通信業界で 10 年にわたる経験を持ち、現在はマイクロソフトで Office Communications グループのシニア プログラム マネージャを務めています。彼はまもなくリリースされる『Microsoft Office Communications Server 2007 Resource Kit』という本の共同執筆者です。Jochen の連絡先は jkunert@microsoft.com (英語のみ) です。
Rui Maximo は IT 業界に携わって 14 年のベテランであり、『Pro LCS: Live Communications Server Administration』と『Microsoft Office Communications Server 2007 Resource Kit』という 2 冊の本の共同執筆者です。Rui の連絡先は、ruim@ruimaximo.com (英語のみ) です。


 ハイ パフォーマンス コンピューティング: Windows Compute Cluster Server の概要
ハイ パフォーマンス コンピューティング John Kelbley and Doug Lindsey

Windows Compute Cluster Server の概要
概要:
  • クラスタを使用して複雑な問題を解決する
  • 計算クラスタの一般的な要件
  • Windows ベースの計算クラスタをセットアップする
  • コマンドをリモートで実行する

ハイ パフォーマンス コンピューティング (HPC) とは、応用コンピューティングの分野の 1 つであり、多くの場合、計算を集中的に実行する問題の解決に重点を置いています。数年前の HPC (当時は "スーパーコンピューティング" という呼び名の方が一般的でした) は、
大規模 (かつ高価) な専用システムが主流であり、主に研究センターで使用されていました。しかし、小規模なシステムの計算能力が向上したことで、コストとパフォーマンスの比率が変化し、計算のワークロードがパーソナル コンピュータ規模のシステムと同じレベルまで減少しました。
計算を集中的に実行する問題の多くは、複数の計算を並列に実行して解決できます。つまり、特定の計算や処理を、別の計算や処理の結果に依存せずに完了できる場合があります。このような場合、計算クラスタとして複数の小規模なシステム (ノード) を使用して、大規模な問題を解決できます。以下に、計算クラスタを使用するアプリケーションの例をいくつか示します。
  • 金融モデル : 1 つのアルゴリズムや計算式が、毎回異なる入力に基づいて数千回実行されます。
  • エンジニアリング : 個々の部品で効果のシミュレーションを行い、テクスチャをモデルに適用します。
  • コンピュータ アニメーション : 動画の各フレームにテクスチャや光の効果を適用します。
計算クラスタを使用すると、複雑な問題をコストのかからない方法ですばやく解決できます。これから説明しますが、Windows® Compute Cluster Server 2003 では、計算クラスタの基本機能とサポートが提供されます。
計算クラスタは可用性 (フェールオーバー) クラスタとは異なることを理解する必要があります。Exchange、SQL Server®、または Windows Server® 2003 で実行されるその他のアプリケーションの可用性クラスタについては、既によくご存知でしょう。一般的に、これらの製品は、共有ストレージを使用してアプリケーションの稼働時間の最大化を図ります。計算クラスタの目的は、障害が発生した他のシステムを再開することではなく、すべてのノードが連携して動作できるようにすることです。

計算クラスタの一般的な要件
HPC の関連情報
  • Windows HPC コミュニティ
  • WCCS 2003 を使用したハイ パフォーマンス コンピューティング
  • マイクロソフト 64 ビット コンピューティングの概要
  • マイクロソフト サーバー ホーム ページ
  • Compute Cluster Server TechCenter
  • ハイ パフォーマンス計算クラスタのインストール、構成、およびチューニングに関するステップ バイ ステップ ガイド

最新の HPC システムは、ワークロードの処理を簡略化するためのいくつかの重要な要件を満たしている必要があります。まず、少なくとも 1 つのシステムが必要です。また、各ノードに処理を割り当てるためのスケジューラが必要です。スケジューラは、管理を担当するノード (ヘッド ノード) で実行され、使用可能なリソースを特定してタスクの割り当てと分配を行い、全体的なジョブの状態を追跡します。スケジューラは、システムのクラスタ内のリソースを調整するだけでなく、処理するジョブをユーザーや管理者が送信する場所でもあります。
クラスタにはノード間の通信手段が必要です。作業の種類によっては、メッセージをノード間で交換して処理を調整するために、高速で待ち時間の短い相互接続が必要になる場合があります。少なくとも、すべての計算ノードとヘッド ノードは共通のネットワークに接続されている必要があります。
相互に接続された多数のシステムが連携して複雑な問題を解決する場合も、細心の注意を払い、十分なリソースを供給する必要があります。一貫性のある安定した環境を確保するには、数十から数百、または数千ものシステムの提供、監視、管理、および保守に対応したプロセスやツールが必要です。
最後に、これが最も重要な点ですが、計算クラスタの並列処理機能を利用できるアプリケーションを使用する必要があります。ジョブを分散して複数のコンピュータで処理できるアプリケーションや、"並列デバッガ" がサポートされているツールがなければ、クラスタを使用しても、ただコンピュータ室の温度が上がるだけです。

Windows Server ベースのクラスタリング
2006 年に、マイクロソフトはさまざまな HPC アプリケーションの要件を満たす Windows Server 2003 Compute Cluster Edition (CCE) と Windows Compute Cluster Server 2003 (WCCS) を発表しました。CCE と WCCS は、どちらも使い慣れた Windows Server 2003 を基に構築されています。CCE は、HPC アプリケーションを実行できるライセンスを与えられた Windows Server 2003 のバージョンです。WCCS には Microsoft® Compute Cluster Pack (CCP) が付属していますが、それ以外は CCE とまったく同じです。つまり、既存の Windows Server 2003 システムの管理に使用しているものと同じツールを使用して、Windows Server ベースのクラスタを展開、運用、監視、および保守することができます。
1 つ注意が必要な点は、CCE と WCCS が x64 専用であるということです。これらの製品の 32 ビット (x86) バージョンは提供されていません。CCE と WCCS のハードウェア要件は、Windows Server 2003 Standard x64 Edition と同じです。CCE と WCCS では、パフォーマンスの高いハードウェア (64 ビット アーキテクチャ) のサポートだけでなく、パフォーマンスの高い相互接続 (ギガビット イーサネット、InfiniBand、Myrinet など) をサポートする Remote Direct Memory Access (RDMA) も提供されます。

Compute Cluster Pack
上記で説明した計算クラスタの基本的な要件のいくつかは、Compute Cluster Pack をインストールすることによって満たされます。CCP は、以下のコンポーネントが含まれたスタンドアロンのインストール パッケージです。
  • 統合型のジョブ スケジューラ
  • 業界標準である MPICH2 をサポートする Messaging Passing Interface (MPI)
  • クラスタ リソース管理ツールとユーザー ツール
CCE と WCCS の重要な違いは、この CCP です。計算クラスタにこれらのコンポーネントが必要であるなら、なぜ WCCS にだけ含まれていて CCE に含まれていないのか、疑問に思う方もいらっしゃるでしょう。この理由は、他のジョブ スケジューラや特殊な MPI を使用する (または MPI のサポートが不要な) HPC ソリューションが存在するためです。これらのソリューションに必要なのは、ソリューションを実行する高性能なプラットフォーム (Windows Server 2003 など) のみです。CCP はスタンドアロン パッケージであるため、他の Windows Server 2003 の x64 バージョン (CCE、Standard、Standard R2、Enterprise、および Enterprise R2) にもインストールできます。

展開の基本
WCCS は、Active Directory® やリモート インストール サービス (RIS) など、Windows の基本機能を使用して Windows ベースのクラスタの管理と運用を簡素化します。Compute Cluster Server は、Active Directory を使用してセキュリティを透過的に管理します。Active Directory を使用すると、ユーザーは 1 つの資格情報を使用してジョブをヘッド ノードに送信し、数百ものサーバー ノードに分散して実行することができます。ジョブが 1 つ以上の計算ノードで実行される場合、これらのジョブは、ジョブの送信時に指定されたユーザーの資格情報に基づいて実行され、その後、セキュリティが確保された状態でキャッシュされます。WCCS は Active Directory を使用して、この "単一のログオン ポイント" 機能を提供します。Active Directory を環境内で使用するその他の利点は、グループ ポリシーを使用してサーバーと構成ポリシーを一元管理できることです。
既に IT 組織に Active Directory が展開されている場合、既存のドメインにクラスタを構築すれば、大幅に時間が節約され、管理作業の量が減少します。これは推奨されるシナリオです。
Active Directory が存在しない環境に計算クラスタを展開する必要がある場合は、クラスタ用の Active Directory をホストする専用のドメイン コントローラを 1 台以上展開することをお勧めします。ヘッド ノードを Active Directory ドメイン コントローラにすることは珍しくありません。これは、どのネットワーク トポロジを使用する場合でも、すべてのノードがこのシステムにネットワーク経由で接続できるためです。しかし、ヘッド ノードをドメイン コントローラにすると、ヘッド ノードの負荷が増加するため、大規模なクラスタにはお勧めできません。また、Active Directory の展開と管理を行う際は、一般的なベスト プラクティスに従ってください (複数のドメイン コントローラのインストール、十分なバックアップ、適切なセキュリティの設定など)。

リモート インストール サービス
WCCS では、Microsoft リモート インストール サービス イメージの展開プラットフォームに適した統合型のフロント エンドが提供されます。RIS は、オペレーティング システムのイメージをヘッド ノードから各計算ノードに展開するために使用されます。つまり、RIS を使用して、新しいクラスタ ノードをすばやくインストールできるということです。RIS は便利な機能として WCCS に統合されていますが、必ずしもこれを使用しなければいけないというわけではありません。Windows Server 2003 Automated Deployment Services (ADS) や Windows Server 2003 の手動インストールなど、その他の一般的な Windows Server の展開テクノロジも使用できます。
RIS を使用する場合は、CCP をヘッド ノードにインストールする前に、少なくとも 2 つの論理ディスクが定義されていることを確認してください。RIS には、オペレーティング システムとは別に、サーバー イメージを格納するためのディスクが必要です。RIS のパーティションには、Windows Server イメージの完全なコピーを 1 つ以上格納するための十分なディスク領域を確保する必要があります。
特にネットワーク装置や記憶装置など、新しいサーバー ハードウェアでは、既定の Window Server 2003 イメージには含まれていないプラグ アンド プレイ ドライバが必要になる場合があります。この場合は、必要なドライバを手動でイメージに追加する必要があります。プラグ アンド プレイ ドライバの追加方法については、support.microsoft.com/kb/254078 を参照してください。

クラスタをインストールする
最初の手順は、クラスタの頭脳であるヘッド ノードの構成です。まず、上記で説明したいずれかの Windows Server 2003 の x64 バージョンをインストールします。オペレーティング システムのインストール時には、サーバーを既存のドメインに参加させる (推奨) か、Active Directory をサーバーにインストールする (大規模なクラスタの場合は推奨されません) かを選択します。
オペレーティング システムをインストールしたら、推奨される修正プログラムを Microsoft Update からすべてダウンロードし、インストールしてください。計算ノードのイメージングに RIS を使用する場合は、[コンピュータの管理] の [ディスクの管理] を使用して、少なくとも 2 つの論理ディスクが定義されていることを確認してください。スペースの都合上、この記事では RIS ベースのインストールについては説明しません。
サーバーにログインして更新を完了できたら、CCP のセットアップ プログラムを実行します。CCP のセットアップでは、画面の指示に従って、必要な以下のファイルと更新プログラムをダウンロードおよびインストールします。
  • RIS の修正プログラム (go.microsoft.com/fwlink/?linkid=55167)
  • Microsoft 管理コンソール (MMC) 3.0 (go.microsoft.com/fwlink/?linkid=62400)
  • SQL Server Desktop Edition (Compute Cluster Server 2003 のヘッド ノードのインストール中にインストールされます)
  • Microsoft .NET Framework 2.0
CCP のセットアップ プログラムは、システムがインストール要件を満たしているかどうかを評価するのに非常に役立ちます。このセットアップ プロセスでは、図 1 のように、必要なコンポーネントとインストールされるコンポーネントを通知し、これらをインストールします。
図 1 CCP のインストールに必要なコンポーネント
図 1 CCP のインストールに必要なコンポーネント

作業リスト
CCP のセットアップが完了すると、管理コンソールが起動し、[作業リスト] が表示されます。図 2 に示すように、[作業リスト] にはいくつかのペインが表示されます。それぞれのペインは異なる領域に対応しており、クラスタの構成を完了するための重要な作業が一覧表示されます。
図 2 クラスタの構成に必要な作業が表示される [作業リスト]
図 2 クラスタの構成に必要な作業が表示される [作業リスト]
[作業リスト] を使用すると、ネットワーク トポロジの選択と構成、ノードのインストール プロセス、ユーザー管理モデルなど、配置を決定したクラスタのアーキテクチャを簡単に実装できます。各ペインの右側にタスクが表示され、タスクごとにウィザードが起動します。それぞれのタスクを順番に実行してヘッド ノードの構成を完了すると、既知の計算ノードに RIS イメージを展開できるようになります。また、定義された一連のユーザーがヘッド ノードを管理したり、ヘッド ノードにアクセスしたりできるようになります。
ネットワーク トポロジ WCCS では、HPC に使用される最も一般的な 5 種類のネットワーク トポロジがサポートされています。少なくとも、すべての計算ノードとヘッド ノードが共通のネットワークを共有している必要があります。これらのトポロジでは、複数の種類のノード間の相互接続がサポートされており、トポロジによって利点とコストは異なります。
どのネットワーク トポロジを使用するかは、クラスタのパフォーマンス、セキュリティ、および展開要件によって異なります。たとえば、アプリケーションで高速な相互接続を使用して、企業ネットワークを経由せずにメッセージを送信する必要があるとします。この場合は、RIS を使用する統合型の自動展開機能が適しているでしょう。使用するハードウェアに NIC を 1 つしか搭載できない場合や、ヘッド ノードでインターネット接続の共有 (ICS) を実行して、計算ノードの名前解決やアドレス指定を管理する場合もあります。[作業リスト] から起動するクラスタ ネットワーク トポロジの構成ウィザードでは、一般的な HPC の実装でサポートされている 5 種類のトポロジが提供されます。また、ヘッド ノードと計算ノードの Windows ファイアウォールの構成など、ネットワーク接続の構成を行うこともできます。図 3 は、サポートされているネットワーク トポロジの 1 つを示しています。
図 3 サポートされている WCCS ネットワーク トポロジ
図 3 サポートされている WCCS ネットワーク トポロジ
リモート インストール サービス 既に説明したように、RIS を使用するとクラスタ ノードを自動的に展開できます。
ノード管理 このクラスタの計算ノードとして使用するサーバーのコンピュータ名を指定できます。CCP をノードで実行する場合、ここでノードが参加するクラスタのヘッド ノードを指定します。
ユーザー管理 システム管理者またはクラスタ ユーザーの役割を与える Active Directory ユーザー アカウントまたはグループを指定できます。

ノードをインストールする
RIS の管理ユーティリティや、その他のサポートされている展開方法を使用すると、自動的に計算ノードを展開できます。ヘッド ノードと同様、すべての計算ノードに CCP をインストールする必要があります。図 4 が示すように、計算ノードの場合、CCP セットアップの構成オプションははるかに単純になります。指定する項目を次に示します。
図 4 Compute Cluster Pack のセットアップ
図 4 Compute Cluster Pack のセットアップ
  • サーバーを (ヘッド ノードではなく) 計算ノードとして使用するかどうか
  • サーバーが参加するクラスタのヘッド ノード名
  • 管理ツールとユーザー ツールを計算ノードに追加するかどうか

管理コンソール
ノードとヘッド ノードとの間の通信が確立されると、すべてのシステムの管理作業の大部分を図 5 のような管理コンソールで行うことができます。このコンソールでは、関連付けられているすべてのノードの一覧、重要な管理作業、その他の詳細情報など、クラスタ全体に関する情報が一元的に提供されます。左端のペインにはコンソールの大まかな構造が表示され、ここから [計算クラスタの管理ツール] などにアクセスできます。このツールを選択すると、クラスタの状態やジョブの統計を示す概要画面が表示されます。このコンソールでは、すべてのリモート デスクトップ セッションとシステム モニタ セッションにもアクセスできますが、クラスタの管理に最もよく使用するのは、[ノード管理] です。
図 5 クラスタ全体の情報が提供される管理コンソール
図 5 クラスタ全体の情報が提供される管理コンソール
実際に管理コンソールを確認すると、Windows とクラスタ ノードの一元管理に必要な主要ツールおよび機能へのアクセスが提供されることがおわかりいただけると思います。中央上部のペインに表示されているクラスタ ノードをクリックすると、他のいくつかのペインに情報が表示され、ノードに固有の機能を確認できます。
これらの機能は、右クリックして表示されるメニューから使用することもできるため、簡単に [ノード管理] から計算ノードを一元管理することができます。[ノード管理] を使用すると、ノードの一時停止と再開、クラスタに対するノードの承認、クラスタからのノードの削除、リモート デスクトップ、システム モニタ、イベント ビューアの起動、または CD ドライブからのディスクの取り出し (大規模なクラスタ内の 1 台のコンピュータを物理的に特定する際に非常に役立ちます) を実行できます。

便利な ClusRun
この一覧の中で、単独で最も役立つ機能は [コマンドの実行] です。この機能を使用すると、対象のコンピュータでコマンド プロンプトを操作しているかのように、任意のコマンドをリモートで実行できます。WCCS では、Clusrun.exe というこの機能のコマンド ライン バージョンが提供されます。"ClusRun" という名前は、GUI バージョンとコマンド ライン バージョンの両方を表します。
ClusRun ユーティリティを使用すると、特に大規模なクラスタの場合は、非常に大きな利点が提供されます。ClusRun を使用すると、同じ作業を何度もコマンド ラインから実行する必要がなくなるため、時間を大幅に節約できます。また、多くの場合、複雑な管理用スクリプトを記述する必要がなくなります。
この機能を使用するには、コマンドを実行するコンピュータを一覧から選択して右クリックし、[コマンドの実行] を選択します。これにより、図 6 のようなダイアログ ボックスが表示されます。あとは、実行するコマンドを入力し、[実行] をクリックして、[結果] ウィンドウが表示されるまで待機するだけです。初めて ClusRun を使用する際には資格情報の入力を求めるメッセージが表示されますが、この資格情報をキャッシュして次回から再利用することもできます。
図 6 コマンドは複数のノードで実行できる
図 6 コマンドは複数のノードで実行できる
一般的に、クラスタに修正プログラムを適用したり、自動セットアップ ルーチンが含まれたプログラムをインストールしたりする場合は、これらのプログラムをファイル共有に配置した後、ClusRun を使用してすべての計算ノードで強制的にコマンドを呼び出します。次のコマンドを実行することにより、クラスタ内のすべての計算ノードを再起動できます。
CLUSRUN SHUTDOWN –R –F –T 0

ツール パック
2007 年 5 月に、HPC チームは Compute Cluster Pack Tool Pack をリリースしました (このツール パックは windowshpc.net/resources/Pages/default.aspx からダウンロードできます)。このツール パックでは、Windows PowerShellTM のサポート、接続状態を診断できる MPIPingPong ツール、および非常に単純ながらも役立つグラフィカルなクラスタ モニタが提供されます。
図 7 が示すように、Simple Cluster Monitor では、クラスタのすべてのノードが 1 つの画面に表示され、各ノードで使用されているコアの数、各 CPU の使用率 (明るい緑)、メモリの使用率 (黄色)、およびネットワーク帯域幅の使用率 (オレンジ) が表示されます。これは、管理者がクラスタの稼働状況をひとめで確認できる、すばらしいツールです。
図 7 複数のノードを監視できる Simple Cluster Monitor
図 7 複数のノードを監視できる Simple Cluster Monitor
クラスタ モニタでは "リモート" 機能も提供されます。クラスタ モニタの最初のインスタンスは、ヘッド ノードで実行する必要があります。しかし、クラスタ モニタのインスタンスをヘッド ノードのコンソール セッションで実行した場合、その後ワークステーションからクラスタ モニタのインスタンスを起動し、ヘッド ノードでこれらのインスタンスを参照すると、同じ画面を表示できます。

今すぐ始めましょう
皆さんはもう HPC と Windows Server 2003 Compute Cluster Server について理解しています。CCP のインストール方法や、あらゆる機能が提供される優れたコンソールについて知っており、強力な新しいコマンドとグラフィカル ツールを使用して、同僚やユーザーを感嘆させることもできます。ハイ パフォーマンス コンピューティングに関するその他の資料については、補足記事の「HCP の関連情報」を参照してください。

John Kelbley は、米国北東部にあるマイクロソフトのグローバル ソリューション テクノロジ チームのテクニカル プロダクト マネージャです。John の連絡先は、Johnkel@microsoft.com (英語のみ) です。
Doug Lindsey は、マイクロソフトの HPC チームのプログラム マネージャです。また、実稼働計算クラスタの管理者でもあります (中には www.top500.org の 2007 年 11 月版で 116 位を獲得したクラスタもあります)。Doug の連絡先は Dougli@microsoft.com (英語のみ) です。


 オンライン番外編: ターミナル サービスを使用して 2007 Office system を展開する
オンライン番外編 James D. Silliman

ターミナル サービスを使用して 2007 Office system を展開する
概要:
  • 2007 Office system の展開
  • ユーザー設定の管理
  • 新しいクイック アクセス ツール バー
  • 2007 Office system のカスタマイズ ツール

2007 Microsoft Office system では重要なデザインの変更が行われました。このような変更点については、2007 Microsoft Office system をターミナル サービス サーバー ファームに展開したり、以前のバージョンからアップグレードしたりする前に把握しておく必要があります。また、全文書対象のテンプレート、クイック アクセス ツール バー、
グループ ポリシーの .adm ファイル スナップイン、および Office カスタマイズ ツール (OCT) についても熟知しておく必要があります。これらのツールすべてをあらかじめ理解していれば、スムーズな展開を行うことができます。この記事では、Microsoft® Word を例に、主な変更点について説明します。

Word 2007 を展開する
これまでのバージョンでも、Word では全文書対象のテンプレート ファイルが使用されてきました。2007 Office system では、このファイルは normal.dotm という名前になります。ターミナル サービス環境では、3 とおりの方法で Word と normal.dotm ファイルを展開できます。2007 Office system がインストールされているすべてのターミナル サービス サーバーで、 既定の状態の normal.dotm ファイルを使用すると、ユーザーには、標準的な Word の既定の表示が提供されます。各ターミナル サーバーで、normal.dotm ファイルを開いてカスタマイズすると、ユーザーに Word の既定以外の表示を提供できます。また、ファイル名を変更すると、各ユーザーが独自のファイルを使用できるようになります (ユーザーが Word の設定を変更して、[既定値として設定] をクリックするとテンプレートが変更されます)。
どの方法を使用する場合でも、展開前に使用する方法を決定することをお勧めします。既定の設定を変更しないと、ターミナル サービス サーバー上にある全文書対象のテンプレートによって各ユーザーのプロファイルのテンプレートが上書きされるため、ユーザーは各自の変更を全文書対象のテンプレートに保存できません。テンプレート ファイルを開いてカスタマイズしなければ、ユーザーは、Word 2007 の既定の設定しか使用できません。
しかし、必要に応じてターミナル サービス ファームにある各サーバーのファイルをカスタマイズすることは可能です。この方法を使用した場合に、すべてのユーザーが同じ Word の設定 (既定のフォントとサイズ、段落の間隔、レイアウトなど) を使用するようにするには、全文書対象のテンプレート ファイルを既定のパスの場所に配置する必要があります。また、すべてのユーザーに適用する設定を変更するには、単純に各ターミナル サービス コンピュータ上にある全文書対象のテンプレート ファイルを開いて、Word 2007 のレイアウトに必要な変更を加えて [既定値として設定] をクリックし、変更内容を既定の normal.dotm ファイルに保存します。
ファイルを変更する前に、既定のファイルのバックアップを作成してください。バックアップを作成しないと、元のファイルを入手するのに Word 2007 を再インストールしなければならなくなることがあります。normal.dotm ファイルを変更する際にクイック アクセス ツール バーを変更しても、このツール バーへの変更内容は保存されません。クイック アクセス ツール バーの概要と動作については、この後で説明します。
ユーザーが各自で Word のグローバル設定を管理できるようにする場合はどうでしょうか。このように設定することはできますが、ファーム内のすべてのサーバーで normal.dotm ファイルの名前を normal.dotm.old などに変更する必要があります。Word を終了する際に他のアプリケーションが Word を使用していると、テンプレート エラーが発生することがあるため、この方法を使用することをお勧めします。
このファイルの名前を変更すると、Word 2007 では、グローバル設定を適用せずに、ユーザーが独自の設定を管理できるようにすると認識されます。この結果、ユーザーは各自で設定を変更して保存できるようになります。カスタマイズされた normal.dotm ファイルは各ユーザーのプロファイル パスに配置されます。移動プロファイルを使用する場合、テンプレート ファイルは各ユーザーの "\\ドメイン\共有名\<ユーザー名>\Application Data\Microsoft\Templates" フォルダに格納されます (ただし、パスの設定によっては異なる可能性があります)。
normal.dotm ファイルに保存されないユーザー設定は、クイック アクセス ツール バーに対する変更内容です。このツール バーは 2007 Office system の新機能で、リボン (同じく新機能) 本体から独立しています。クイック アクセス ツール バーは、小さなツール バーで、既定では 2007 Office system の画面の左上隅に配置されます。このツール バーは、図 1 に示すように、2007 Office system のアプリケーションで利用できます。詳細については、support.microsoft.com/kb/926805 を参照してください。
Figure 1 クイック アクセス ツール バーのファイル (Close Figure 1)

Office アプリケーション | 機能の範囲 | ファイル名
Access 2007 | すべて | Access.qat
Excel 2007 | すべて | Excel.qat
Outlook 2007 | 連絡先、予定表、配布リスト、履歴項目、メール、フォルダへの投稿、タスク | Olkaddritem.qat、Olkapptitem.qat、Olkdistitem.qat、Olklogitem.qat、Olkmailitem.qat、Olkpostitem.qat、Olktaskitem.qat
PowerPoint 2007 | すべて | PowerPoint.qat
Word 2007 | すべて | Word.qat
図 1 に記載されているように、クイック アクセス ツール バーでは .qat という拡張子のファイルにカスタマイズした設定が保存されます。これらのファイルは、ファーム内の各ターミナル サービス サーバーの "C:\Documents and Settings\<ユーザー名>\Local Setting\Application Data\Microsoft\Office" (Windows Vista® を実行しているコンピュータでは "C:\Users\<ユーザー名>\AppData\Local\Microsoft\Office") という既定のファイル パスの場所に保存され、移動されません。
このパスから、.qat ファイルは、ターミナル サービス ユーザーのローカルにキャッシュされたプロファイルの Local Settings サブフォルダにあることがわかります。Local Settings は標準的な移動プロファイルのパス構造にないので、このサブフォルダはログオフ時にユーザーの移動プロファイルと同期されません。したがって、残念ながら、グループ ポリシー オブジェクト (GPO) の設定を有効にして、ターミナル サービス サーバーのローカルにキャッシュされたプロファイルを削除すると、ユーザーがカスタマイズした .qat ファイルは失われます。詳細については、サポート技術情報の記事 (support.microsoft.com/kb/274152) を参照してください。
事実、ターミナル サービスの管理者がユーザーのログオフ時にローカル プロファイルを一掃する際には、キャッシュされたプロファイルを削除するという方法が一般的に使用されています。そのため、2007 Office system で加えられた変更は、キャッシュされたプロファイルとクイック アクセス ツール バーに影響するので重要です。わかりやすい解決策は、上記のサポート技術情報の記事で説明している GPO の設定を設定しないことです。ログオフ時にキャッシュされたプロファイルを削除しないよう設定する場合、多くのユーザーが存在している環境では、各ターミナル サービス サーバーの %systemroot% があるローカルのハード ドライブの貴重な空き領域が消費されることになります。この結果、サーバーのハード ドライブの空き領域が不足することがあるので、空き領域を監視する他の手段を講じる必要があります。ローカル プロファイルのサイズは非常に大きくなることがあるので、空き領域の不足が生じるのは珍しいことではありません。
どのような手段を使用する場合でも、ユーザーの .qat ファイルのバックアップを定期的に作成するルーチンをログイン スクリプトに追加して、.qat ファイルが消えた場合や、誤って削除してしまった場合に復元できるようにする必要があります。カスタマイズされたファイルのバックアップを作成することで、ユーザーがファイルを復元するためにローカル ヘルプ デスクに泣きつくという状況を避けられます。
ほとんどのターミナル サービスの管理者は、このようなローカルにキャッシュされたプロファイルのバックアップを作成していません。ネットワークの移動プロファイルのバックアップは作成していますが、既に説明したように、このプロファイルには .qat ファイルのコピーは含まれていません。別の方法としては、ユーザーごとに必須のプロファイルを展開し、各ユーザーの Local Settings に対する変更をネットワーク上の別のフォルダにマップするサードパーティ製品の使用を検討することもできます。

グループ ポリシー スナップイン
かなり以前から、Office 2003 ではグループ ポリシーの .adm ファイルを使用して、Office のポリシーやユーザー エクスペリエンスに対する管理上の制御を強化できました。同様に、2007 Office system でも新しい .adm ファイルが導入されています。このファイルを使用すると、初回起動時に表示されるダイアログ ボックスを無効にしたり、自動保存の設定を変更したりするなど、さまざまなカスタマイズを実行できます。
Office 2003 のグループ ポリシーを既に展開している状態で 2007 Office system に移行する場合、2007 Office system の .adm ファイルを追加する前に既存の Office 2003 の .adm ファイルを GPO から削除する必要があります。グループ ポリシー管理コンソール (GPMC) のインターフェイスを使用して GPO のバックアップを作成することを忘れないでください。バックアップを作成すると、新しいスナップインを追加した後にエラーが発生しても元の構成に戻すことができます。私の知る限りでは、少なくとも 1 人のターミナル サービスの管理者が、Office 2003 スナップインを削除して 2007 Office system の .adm ファイルを GPO に追加する際に、実体のないポリシー エントリが作成されるという問題に遭遇しています。
2007 年 5 月号で私が執筆した記事「ターミナル サービス展開ガイド」 (technetmagazine.com/issues/2007/05/TerminalServices) でも述べたように、Outlook® の古いアイテムの整理、初回起動時のダイアログ ボックスなど、ターミナル サービスのユーザーには表示しない方がよいものがあります。Outlook 2007 を初めて起動すると、既定では 2 つの初回起動時のダイアログ ボックスが表示されます。1 つはプライバシー オプションのダイアログ ボックスで、もう 1 つはデスクトップ サーチのダイアログ ボックスです。1 つ目のダイアログ ボックス (図 2 参照) は、新しい Outlook 2007 の .adm ファイルを使用して GPO の設定を変更したり、Office カスタマイズ ツールを使用したり、レジストリを調整したりするなど、いくつかの方法で非表示にすることができます。
図 2 2007 Office system のプライバシー オプションのダイアログ ボックス
図 2 2007 Office system のプライバシー オプションのダイアログ ボックス
図 3 のダイアログ ボックスは、プライバシー オプションのダイアログ ボックスが表示された直後に表示され (非表示にしていない場合)、他のすべての 2007 Office system アプリケーションでも表示されます。
図 3 2007 Office system のクイック検索機能のダイアログ ボックス
図 3 2007 Office system のクイック検索機能のダイアログ ボックス
Office アプリケーションで Windows® サーチの確認を無効にするには、go.microsoft.com/fwlink/?LinkId=78161 から 2007 Office system の ADM テンプレートをダウンロードして、ドメイン コントローラのハード ドライブに読み込みます。グループ ポリシー エディタで、[コンピュータの構成] または [ユーザーの構成] の下にある [テンプレートの追加と削除] で Office Outlook 2007 のテンプレート (Outlk12.adm) を読み込む必要があります。次に、"ユーザーの構成\管理用テンプレート\Microsoft Office Outlook 2007\ツール | オプション\ユーザー設定\検索オプション" に移動し、[Windows デスクトップ サーチ コンポーネントがインストールされていない場合でもインストールに関するメッセージを表示しない] 設定を有効にします。
2007 Office system では、ユーザー エクスペリエンスを制御する多数のグループ ポリシーの設定が用意されていますが、Word (Word12.adm) や Excel® (Excel12.adm) などアプリケーションごとに、各グループ ポリシーに対応する .adm ファイルを GPO に追加する必要があります。図 4 は、Outlook 2007 の ADM テンプレート (Outlook12.adm) がグループ ポリシーに追加されたときの状態を示しています。
図 4 グループ ポリシーにおける Outlook 2007 の ADM テンプレート
図 4 グループ ポリシーにおける Outlook 2007 の ADM テンプレート

その他の変更点
Office 2003 では、カスタム インストール ウィザードをダウンロードして、カスタム変換を作成することができました。2007 Office system の新しい OCT は、別途ダウンロードする必要がありません。[ファイル名を指定して実行] で「Setup /admin」というコマンドを実行すると起動され、2007 Office system のメディア、またはインストール ソースにリダイレクトされます。このコマンドをインストールのソース ファイルに対して実行し、各設定を必要に応じて変更すると、.msp ファイルが作成されます (これは、Office 2003 の .mst ファイルに相当するファイルです)。後でこのファイルを展開する際には、コマンド ライン オプションを指定する必要はありません。カスタマイズした .msp ファイルをネットワーク インストール ポイントのルートにある Updates フォルダに配置するだけで、自動的に任意の設定で展開されます。
Outlook 2007 には他にも以前のバージョンの Outlook より優れた点があります。LAN 環境内で起動すると、Exchange Server 2007 サーバーが自動的に検索され、サービス接続ポイント (SCP) クエリが Active Directory® に直接送信されます。このクエリにより、展開されている Exchange Server 2007 のインフラストラクチャに簡単に接続できます。詳細については、go.microsoft.com/fwlink/?linkid=76177 を参照してください。
マイクロソフトでは、展開ツールの簡素化、新しい .adm ファイル スナップインの追加、およびインターフェイスの効率化により、ターミナル サービス環境での 2007 Office system の動作に関する重要なデザインの変更を行いました。Office アプリケーションを展開およびアップグレードする前に、この記事で説明した重要な概念の一部を理解しておくと、アップグレードに関する理解が深まり、前もって重要なデザインの方針を決定することができます。現時点ではアップグレードを予定していない場合は、2007 Office system 互換機能パックのダウンロードを検討することをお勧めします。互換機能パックを使用すると、2007 Office system にアップグレードしているユーザーから送信された添付ファイルを開くことができます。互換機能パックは、go.microsoft.com/fwlink?LinkID=77512 からダウンロードできます。
この記事を使用すれば、2007 Office system を正しく展開する準備が整います。必ず、ポリシーのバックアップを作成し、すべての推奨設定をラボ環境でテストしてから、ユーザーの運用環境に展開してください。

James D. Silliman は、MCSE 所持者で、ターミナル サービスの展開を専門とし、マイクロソフトに注目している技術者です。現在は ASP に勤務し、小規模企業向けの IT ソリューションの構築に取り組んでいます。James の連絡先は、jsilliman@gmail.com (英語のみ) です。


 編集長から: 膨大な量の情報に対処する
編集長から
膨大な量の情報に対処する
Joshua Hoffman

今月の 主な 2 つのトピックである SharePoint と Office Communications Server について考えてみると、相互の関連付けに関する問題がよく発生するのは、実際にはそれほど驚くべきことではありません。というのも、私がこの文章を書いているとき (皆さんがこの記事を読む 1 か月ぐらい前でしょう)、ニューヨーク市は完全な休暇モードでした。そして偶然にも、TechNet Magazine の本部は、そのニューヨーク市の休暇モードを最もよく表わしている、ロックフェラーセンター内にあります。ここは街の中でも、多くの点で本当にすばらしい場所ですが、毎年約 1 か月間は、"挑戦" とでも言うべき期間が訪れます。壮大な超高層ビルを背景に、買い物、ショー見物、またはアイススケートをする目的で国中および世界中からやってくる観光客によって、ただでさえ多い人口がさらに増加します。しかし、多くのニューヨーカーたちは慌てて逃げ出します。
逃げ出したくなるのは、観光客が歩道の真ん中で止まって写真を撮るので、後ろのニューヨーカーたちが突然止まったり観光客にぶつかったりしてイライラするからだと言う人もいます。しかし、そうではありません (実際には、皆さんが来て写真をたくさん撮ってくれるのは嬉しいことです)。単に混み過ぎているだけなのです。ニューヨークはもともと人が多くせわしない街であり、人口密度がピークに達し、手に負えない状態になっているだけです。
これを踏まえて私たちの業界について考えてみると、ほぼ同じ傾向が見られます。組織は成長し続けており (これは私たちが望んでいることでしょう)、その結果として毎日生み出される情報の量も増え続けています。ファイル共有やデータベースは情報でいっぱいになっています。電子メールについては説明するまでもないでしょう。GB (ギガバイト) が大きな記憶域だったのはそれほど昔のことではありません。現在は、家庭用のパソコンでさえ TB (テラバイト) が一般的です。多くのデータセンターは PB (ペタバイト) 規模にすることを念頭に置いて設計されています。世の中には多くの情報があふれているため、この考えには賛成できます。しかし、それは便利なことなのでしょうか。それともただ "あふれ返っている" というだけのことなのでしょうか。これらの情報は構造化されていて、分析および共有しやすくなっているでしょうか。
やはり、情報の量が膨大であるため、情報の関連付けが難しいのは当然です。しかし、この作業はもっと簡単になる可能性があります。今月は、このトピックについて説明します。今月号の記事では、SharePoint の機能を活用し、より簡単かつ系統立った方法で企業のデータ収集を行う方法を紹介します。また、迅速にアンケートを作成してユーザー (または顧客) からデータを収集する方法や、カスタム コンテンツ タイプを定義して、より意味のある情報を収集できるようにする方法も紹介します。そして最後に、Office Communications Server を使用して、このような重要な接続を確立する方法を紹介します。結局のところ、データを共有する人がいなければ、こうしたデータの存在は意味を成しません。 —Joshua Hoffman

次のマイクロソフト技術支援スタッフに心より感謝します。Ed Banti、Susan Bradley、Byron Hynes、Michael Murgolo、Ken Oien、Jim Truher、Kay Unkroth


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

ActiveX インストーラ サービスが利用できるかどうかについて
2007 年 7 月号の記事「Windows Vista の ActiveX インストーラ サービス」(technetmagazine.com/issues/2007/07/AxIS) を拝読しました。このサービスが、現在利用できるようになったかどうかを教えてください。
- Eugene Y

はい。現在、ActiveX® インストーラ サービスはご利用いただけます。このサービスは、Windows Vista® のコントロール パネルにある "プログラムと機能" ユーティリティの [Windows の機能の有効化または無効化] オプションを使用して簡単に有効にできます。
ActiveX インストーラ サービスは、Windows Vista Ultimate、Enterprise、および Business エディションでのみ提供されているオプション コンポーネントです。ActiveX インストーラ サービスによる ActiveX のインストールを許可するサイトのリストは、グループ ポリシーで管理されています。このリストは、グループ ポリシー オブジェクト エディタの、"コンピュータの構成\管理用テンプレート\Windows コンポーネント" ノードの [ActiveX インストーラ サービス] に保存されています。

Active Directory のツール
2007 年 9 月号の記事「Active Directory の管理に不可欠な 11 個のツール」を拝読しました。この記事で紹介されていた dsrm ユーティリティで次のコマンド ラインを使用して Active Directory® からユーザーを削除したいのですが、うまくいきません。
          dsquery user -samid <samid> | dsrm
dsrm への入力の形式が正しくないことを示すエラー メッセージが表示されますが、コマンドは個別に実行すると問題なく使用できます。何が問題なのかを教えてください。
- Keith E

該当記事の執筆者である Laura Hunter に問い合わせたところ、dsquery の結果を dsrm にパイプするときには –noprompt スイッチを指定する必要があるという指摘を受けました (これは dsrm 側の要件です)。そのため、次のコマンド ラインを使用する必要があります。
dsquery user -samid <samid> | dsrm -noprompt
この情報が 2007 年 9 月号の記事に明記されていなかったことをお詫びいたします。オンラインで公開している記事には、この情報を加筆修正するようにいたします。

パズルの解答について
既に認識されていて、他の読者からも指摘を受けているかもしれませんが、2007 年 11 月号の「Dr.Script のスクリプト パズル」には 2 とおりの回答があると思います。1 行目と 2 行目の 4 文字の変数が nnde で、3 行目と 5 行目の 5 文字の変数が iamex の場合も、パズルは解けます (これは些細な違いで、公開されている解答の方がスクリプトが読みやすいということもわかっていますが)。
バリエーション豊かなパズルを用意していただきありがとうございます。いつも楽しませていただいてます。
- Stan A

別の解答をお知らせいただきありがとうございます。また、Scripting Guys で新しく導入したパズルをお楽しみいただいているようで光栄です。TechNet Magazine の定期的なコーナーとしてパズルをお届けできることを嬉しく思っています。

Windows Vista への移行について
TechNet Magazine の 2007 年 11 月号の記事「Windows Vista でオフライン ファイル機能に加えられた変更点」(technetmagazine.com/issues/2007/11/Offline) では、Windows Vista のオフライン ファイルに関するメリットがわかりやすく説明されていて重宝しました。Windows XP Professional を使用していたときにはオフライン ファイルに関して多くの問題が発生していたので、Windows® Vista への移行を決断するのに役立ちました。どうもありがとうございました。
- Daniel Z

ありがとうございます。この記事がお役に立ったようで光栄です。

落丁について
TechNet Magazine は、楽しく情報収集をできる媒体として重宝していますが、私の手元にある 2007 年 12 月号には 49 ～ 64 ページがありません。60 ページに掲載されているコンピュータ フォレンジックに関する記事 (「基本的なコンピュータ フォレンジック ガイド」、Tom Cloward/Frank Simorjay 共著) に興味があったのですが、このデータを入手することはできますか。また、この記事がオンラインで提供されている場合は、URL を教えてください。
- Dave S

2007 年 12 月号の印刷工程では問題が発生し、ごく一部の読者の方には 49 ～ 64 ページがないものが発送されてしまいました。TechNet Magazine チームを代表しまして、このような事態が発生したことを深くお詫び申し上げます。
ご指摘の記事を含め、2007 年 12 月号のすべての記事は technetmagazine.com/issues/2007/12 でご覧いただけます。


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

ファイルのロックを解除する
Unlocker
ccollomb.free.fr/unlocker
なんらかの自動化されたプロセスが操作の途中でハングし、ファイルに書き込みロックがかけられて操作できなくなったことにより、ファイルのコピー、移動、書き込み、または削除を実行できなくなり、別の操作が失敗するという状態を、皆さん経験したことがあるでしょう。また、ファイルをロックしているプロセスはわからなくても、どのファイルがロックされたかはわかる場合があります。このような場合、どうしたらよいでしょうか。
エクスプローラと連携し、ファイルがロックされる問題をすばやく簡単に解決できるツールとして、Cedrick Collomb によって作成された無料の Unlocker ツールがあります。エクスプローラと統合されているため、ロックされている 1 つのファイル (または複数のファイル) を右クリックし、コンテキスト メニューから [Unlocker] を選択するだけで、ロックをかけているプロセスを見つけることができます。ロックを検出したら、問題のあるプロセスの終了、ファイルにかけられているロックの解除 (ハンドルを閉じる)、ファイルの削除、ファイルの移動、ファイルの名前の変更など、さまざまな操作を実行できます。また、ロックされているファイルを現在の状態のまま別の場所にコピーすることもできます。
Unlocker には完全なアプリケーション インストーラが実装されているため、DLL を手動で登録または登録解除したり、ツールを起動するためにシステムを再起動したりする必要はありません。また、(しばしば自宅に電話がかかってくることが気にならない皆さんは) 自動更新通知を利用して、常に最新のバージョンを使用することもできます。
Unlocker では、自動化に最適なコマンド ラインでの実行もサポートされています。このため、たとえば、ログ配布プロセスの構成を簡単に変更して、ロックされた .zip ファイルがログの移動中に検出された場合に、自動的にハンドルを閉じて圧縮プロセスを終了することができます。これで、早朝に起きて手動で問題を解決する必要が生じることはなくなるでしょう。
また、このユーティリティには Unlocker Assistant と呼ばれるシステム トレイ ツールが含まれています。このツールを使用すると、ロックされているファイルの移動、名前の変更、または削除を実行しようとしたときに、Unlocker のインターフェイスが自動的に起動されます。このため、ファイルを探し、右クリックして表示されるコンテキスト メニューから [Unlocker] を選択する操作を行う必要がなくなるため、何回かクリックを行う手間が省けます。Unlocker は、Windows Vista® を含むほとんどの Windows のバージョンと互換性があります。

価格 : 無償
ロックされているファイルをすばやく検出してロックを解除できる Unlocker

ネットワーク トラフィックを分析する
Wireshark
wireshark.org
優れたネットワーク プロトコル アナライザを使用すると、インフラストラクチャ上のネットワーク トラフィックに関する基本的な情報を取得し、相互接続型アプリケーションのすべての層で実際に何が起こっているかを確認することができます。最もよく知られているオープン ソース アナライザはおそらく Wireshark でしょう。このツールは Windows 用のオープン ソース ライブラリである WinPcap パケット キャプチャ ライブラリを利用しており、Ethereal を基に開発されました。Gerald Combs は現在でもこのプロジェクトに関わっています。
Wireshark を使用すると、ネットワーク インターフェイスを通過するトラフィックを簡単にキャプチャし、使いやすいグラフィカル インターフェイスで各パケットの詳細を確認することができます。新しいパケット キャプチャ セッションを開始するには、インターフェイスを選択して開始ボタンをクリックするだけです。GUI では、色分けされたフレーム内にキャプチャされたパケットが表示され、時間、送信元、送信先、プロトコル、およびイベントに関する定義済みの説明がほぼリアルタイムで詳しく表示されます。伝送内容をクリックすると、その詳細が反転表示され、わかりやすい詳細ウィンドウにパケットに関するデータが表示されます。その下に、未処理のパケット データが 16 進文字および ASCII 文字で表示されます。
もちろん、分析に必要なデータセットが取得できたら、そのセッションを後で分析するために保存したりエクスポートしたりすることもできます。Wireshark はさまざまな異なるプロトコルを解読することが可能であり、ほとんどのトラブルシューティングのニーズに対応しています。
ネットワークとの間で送受信されるパケットは大量に存在するため、これらすべてのデータにフィルタをかけることができるように、このアプリケーションには優れた式ベースのフィルタ機能が用意されており、プロトコルの各パラメータを使用して検索対象を絞り込むことができます。たとえば、ネットワーク内の特定の IP アドレスとの間で送受信された、BitTorrent に関連するトラフィックを除くすべてのトラフィックをフィルタによって選択することができます。また、フィルタを使用すると、偽のブロードキャスト メッセージを大量に送信してネットワークに悪影響を及ぼしているコンピュータを簡単に見つけることができます。
さらに、このインターフェイスでは、確認のために簡単にパケットをマークしたり、特定の伝送内容をキャプチャ内の時間の基準点として設定したりすることもできます。Wireshark で私が気に入っている機能の 1 つは、TCP パケットを右クリックしたときに表示されるコンテキスト メニューのオプションを選択することによって、TCP ストリームを追跡できる機能です。このオプションを選択すると、新しいウィンドウに TCP ストリームの内容が色分けおよび書式設定されたテキストとして表示されます。これは、Web アプリケーションのエラー、偽の HTTP ヘッダー、またはその他の TCP 通信に関する問題の検出に役立ちます。また、このウィンドウから簡単に通信内容を印刷または保存して、後から確認したりデモンストレーションに使用したりすることもできます。
ここでは、このアプリケーションの機能をほんの少しだけ取り上げました。Wireshark は GPL ライセンスに基づいてリリースされており、Windows 用だけでなく、ほとんどの Linux および FreeBSD のバージョン用にコンパイルされたバイナリも提供されています。

価格 : 無償
ネットワーク プロトコル全体を分析できる Wireshark
ネットワーク プロトコル全体を分析できる Wireshark

Windows PowerShell を強化する
PowerShell Community Extensions
codeplex.com/PowerShellCX
Windows PowerShellTM で実際に作業をしたことがある方なら、おそらくいくつかの実行パターンが繰り返されることに気付いて、コマンドレットやエイリアスがあった方が便利だと感じていると思います。これを受けて、オープン ソース コミュニティの Windows PowerShell ユーザーおよび支持者のグループが、PowerShell Community Extensions プロジェクトを立ち上げ、よく使用される機能を配布可能な一連のコマンドレット、エイリアス、プロバイダ、関数、フィルタ、およびスクリプトにまとめました。
このパッケージに含まれているコマンドレットをいくつか紹介すると、まずクリップボード バッファのデータを追加および取得できる Get-Clipboard および Write-Clipboard があります。また、Get-DomainController を使用すると現在のドメイン内で利用可能なドメイン コントローラの一覧を取得でき、Write-GZip および Write-Zip を使用すると GZIP ファイルまたは ZIP ファイルに書き込みを行うことができます。
Windows Vista または Windows Server® 2008 では、New-Symlink および New-Junction を使用して、新しいシンボリック リンクや接合ポイントを作成できます。Active Directory® や AssemblyCache などの LDAP サーバーへのアクセスを提供する便利な DirectoryServices プロバイダを使用すると、Microsoft .NET Framework のグローバル アセンブリ キャッシュおよびそのキャッシュ内のアセンブリにアクセスすることができます。
また、さまざまな優れたスクリプトも提供されます。Set-Writable スクリプトおよび Set-ReadOnly スクリプトを使用すると、ファイルの読み取り専用状態を簡単に変更できます。Get-Url を使用すると、WebRequest を作成し、WebResponse を文字列として取得できます。また、Export-History を使用すると、コマンドの履歴を .clixml ファイルにダンプして後で再利用できます。Get-DiskUsage スクリプトを使用すると、ディスク使用量に関する情報を取得できます。また、興味深いことに、Out-Speech コマンドを使用すると、コンピュータに話をさせることもできます。他にも、コマンド ラインの入力を簡略化できる Quote-List や、指定した環境に一連のパスを追加できる Add-PathVariable など、便利な関数が多数含まれています。
このプロジェクトにより、標準の Windows PowerShell 環境に、非常に便利な一連の拡張機能が追加されます。また、Windows PowerShell の上級者の皆さんは、ぜひこのプロジェクトに参加していただければと思います。

価格 : 無償
よく使用する機能が提供される PowerShell Community Extensions
よく使用する機能が提供される PowerShell Community Extensions

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


 SQL に関する Q&amp;A: 非クラスタ化インデックスと権限の保持
SQL に関する Q&A
非クラスタ化インデックスと権限の保持
Saleem Hakani and Dan Carollo

非クラスタ化インデックスの概要と用途
質問 - 非クラスタ化インデックスとは何ですか。また、非クラスタ化インデックスを使用した場合のメリットとデメリットについても教えてください。
回答 - 非クラスタ化インデックスは、一般的な書籍の巻末にある索引のようなものです。書籍に記載されているすべての情報は、索引でトピックごとに記載されています。また、書籍のどこに、その情報が記載されているのかを示す道しるべとしてページ番号が明記されています。また、書籍の索引に記載されているデータの順序は、書籍の本文に記載されている順序とは異なります。この点は非クラスタ化インデックスも同じです。テーブルにクラスタ化インデックスを作成すると、アイテムの順序を指定できます。クラスタ化インデックスがない場合、アイテムの順序を指定することはできません。
非クラスタ化インデックスには 2 つの制限事項があります。1 つ目はインデックスに含められる最大列数が 16 列であること、2 つ目はインデックス キーの最大サイズが 900 バイトであることです。これはどういうことでしょうか。MovieList サンプル データベースの Movie テーブルの列にインデックスを作成する場合について考えてみましょう。インデックスの作成対象となる列は、MovieTitle NVarchar(50)、DirectorName NVarchar(50)、および ShortStory NVarchar(400) です。
次のステートメントを発行してテーブルを作成したとします。
Use MovieList;
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName, ShortStory);
このステートメントを実行すると、"警告: 最大キー長は 900 バイトです。インデックス 'Movie_IDX' の最大長は 1000 バイトです。大きな値の組み合わせの一部では挿入操作または更新操作が失敗します。" というエラー メッセージが表示されます。このメッセージは、nvarchar データ型が 1 文字あたり 2 バイトを消費し、上記の 3 列を含むインデックスが 900 バイトのサイズの制限を超えたことが原因で表示されます。
SQL Server® 2005 では、INCLUDE 句に列を追加することで、この問題を回避できるようになりました。これは、サイズと列の両方の制限を回避する必要がある場合に非常に有益です。非クラスタ化インデックスの制限を回避するには、次のステートメントを実行します。
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName) INCLUDE (ShortStory);
インデックスの作成時に INCLUDE 句を使用する場合、データベース エンジンでは、インデックス キー列の数やインデックス キーのサイズを計算するときに、キー列以外が考慮されないことに注意する必要があります。
非クラスタ化インデックスに関する詳細情報については、「非クラスタ化インデックス」(msdn2.microsoft.com/aa174537) と「非クラスタ化インデックスを使用する」(msdn2.microsoft.com/aa933130) を参照してください。また、インデックスの最適化に関するヒントについては、sql-server-performance.com/optimizing_indexes.asp を参照してください。

権限に関するデータを保持する
質問 - サブスクリプションが初期化されたときに、権限が失われることを回避する方法を教えてください。スナップショットが再初期化されると、許可されたすべての権限が失われるという問題に何度も遭遇しています。
回答 - 既定では、サブスクリプションが初期化されると、サブスクリプション データベースにあるすべてのオブジェクトは削除され再作成されます。ただし、このシナリオに対応する方法が 2 つあります。
1 つ目の方法は、再初期化された後に、すべての権限を再度適用することです。権限を手動で設定する場合は、スクリプトを使用してオブジェクト レベルとステートメント レベルの権限を取り出して、個別に格納し、サブスクリプションの再初期化後に利用できるようにする必要があります。
2 つ目の方法は、サブスクリプションの再初期化時にオブジェクトが削除されないようにサブスクリプションを構成することです。これには、SP_CHANGEARTICLE システム ストアド プロシージャを使用して、PRE_CREATION_CMD の @PROPERTY パラメータの値と、NONE、DELETE、または TRUNCATE の @Value パラメータの値を構成します。
アーティクルのプロパティ ダイアログ ボックスの [対象オブジェクト] で、[既存のオブジェクトを変更せずに保持します]、[アーティクルに行フィルタがある場合は、フィルタに一致するデータのみを削除します]、および [既存のオブジェクト内にあるすべてのデータを切り捨てます] を選択します。この設定はテスト環境でお試しください。サポートや詳細情報が必要な場合は、最新版の SQL Server Books Online で最新情報を参照してください。

Saleem Hakani は、データベース システムに関して 14 年の経験を持つシニア データベース エンジニア兼シニア プロブレム エンジニアで、世界規模で展開している Microsoft SQL Server コミュニティで積極的に情報を発信しています。また、SQL Server に関する外部のコミュニティ Web サイト (sqlcommunity.com) でも同様に積極的に情報を発信しています。Saleem の連絡先は Saleem@sqlcommunity.com (英語のみ) です。
Dan Carollo は、マイクロソフトの Windows Anti-Malware Research and Response チームと協力して作業をしていて、オペレーション エンジニアと SQL Server DBA を兼任しています。また、SQL Server の MCT 認定資格を取得しています。


 ユーティリティ スポットライト: ADMX Migrator
ユーティリティ スポットライト
ADMX Migrator
Lance Whitney
この記事で使用しているコードのダウンロード: ADMX Migrator (2765KB)

グループ ポリシーを 利用したことがある方は、管理用テンプレートを使用してオペレーティング システムやアプリケーションの設定を構成する作業には当然慣れ親しみがあると思います。Windows® や重要なソフトウェア (Microsoft® Office など) に含まれている ADM ファイルは、最も一般的なデスクトップ構成を対象としています。ただし、カスタム設定を組み込むには、独自の ADM テンプレートを作成しなければならない場合があります。ADM には固有の構文があり、テキスト エディタを使用して作成する必要があるため、ADM をゼロから設計するのは面倒な作業になることがあります。しかし時間をかけて経験を積んだことによって、多くのグループ ポリシーのプロフェッショナルは、独自の ADM ファイルを作成する作業に熟練しました。
Windows Vista® では、グループ ポリシー テンプレートの形式を XML ベースの構造に変更しました。この ADMX という新しい形式によって、多言語サポート、すべてのテンプレートを一元管理できる保存場所など、従来の ADM ファイルにはないいくつかのメリットが提供されます。
これは朗報ですが、独自の ADMX ファイルを作成する必要があるのに XML がわからないという場合はどうしたら良いでしょうか。そしてさらに重要なことですが、何年もかけて独自に作成した ADM はどうなるのでしょうか。この点については、幸運にも、ADMX Migrator ユーティリティが役に立ちます。FullArmor Corporation が開発し、マイクロソフトにライセンスが付与された、この無償のツールを使用すると、2 つの主なメリットが得られます。1 つは独自の ADMX ファイルを作成できること、もう 1 つは従来の ADM ファイルを ADMX ファイルに変換できることです。
ADMX Migrator のグラフィカル インターフェイス
ADMX Migrator のグラフィカル インターフェイス
ADMX Migrator には、新しい形式のテンプレートを作成するエディタとしてグラフィカル ユーザー インターフェイスをサポートする ADMX Editor が用意されているので、テキスト エディタを使用する必要はありません。すっきりして使いやすいインターフェイス内で、プルダウン メニューやドロップダウン リストを使用してテンプレートを作成できます (上記の図を参照してください)。まず、[New Template] (新しいテンプレート) をクリックし、テンプレート ファイルの名前を指定して、ファイルを分類するカテゴリを入力します。次に、ポリシーを適用するレジストリ キー、レジストリ値の名前、およびポリシーが作用するクラス (User (ユーザー)、Machine (コンピュータ)、または両方) を入力して、ポリシー設定を作成します。また、ポリシーの内容の説明を追加することもできます。
以上の操作が完了したら、新しいテンプレートを ADMX 形式で保存します。新しく作成したテンプレートは ADMX ファイルと ADML ファイルの両方の形式で保存されます。ADMX ファイルには実際のポリシー設定が含まれています。ADML ファイルには、そのポリシーの言語固有の情報が含まれています。これらのファイルを作成したら、ドメインの適切なディレクトリにコピーして、グループ ポリシーに組み込みます。
新しい形式を活用するために、ADM ファイルを ADMX ファイルに変換することをお勧めします。ADMX Migrator では、エディタを使用する方法とコマンド ライン プログラムを使用する方法の 2 とおりの変換方法が提供されています。ADMX Editor で [Generate ADMX from ADM] (ADM から ADMX を作成する) をクリックします。ADM ファイルがある場所に移動してファイルを選択すると、ファイルはすばやく自動的に変換されます。その後、変換したファイルをエディタで開いて、値やプロパティを確認して、必要に応じて変更できます。ADMX Migrator のコマンド ウィンドウは少し複雑で、プロンプトで非常に長いコマンド文字列を入力して変換を実行する必要があります。ただし、コマンド ウィンドウには、GUI エディタでは使用できないオプションや柔軟性があります。
ADMX Migrator は Microsoft 管理コンソール (MMC) スナップインです。そのため、MMC 3.0 だけでなく Microsoft .NET Framework 2.0 も必要になります。このユーティリティは、Windows XP SP2、Windows Server® 2003 SP1、および Windows Vista で実行できます。このソフトウェアは go.microsoft.com/fwlink/?LinkId=77409 からダウンロードできます。

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


 The Cable Guy: IEEE 802.1X ワイヤード認証
The Cable Guy
IEEE 802.1X ワイヤード認証
Joseph Davies
この記事は、Windows Server 2008 のプレリリース版に基づいています。記載されている内容は変更されることがあります。

ネットワーク管理者は、IEEE 802.11 ワイヤレス ネットワークにおける IEEE 802.1X 認証の普及に伴い、この標準をワイヤード ネットワーク接続にも使用することを考えるようになりました。ワイヤレス クライアントでは、検証対象となる一連の資格情報を送信しないとイントラネットにワイヤレス フレームを転送できません。これと同様に、
IEEE 802.1X ワイヤード クライアントでも、スイッチ ポートを使用するには認証が必要です。IEEE 802.1X 認証を使用すると、イントラネットに新たなセキュリティの防壁が設けられます。これにより、正常に認証されないゲスト コンピュータ、悪意のあるコンピュータ、または管理されていないコンピュータがイントラネットに接続することを回避できます。
IEEE 802.1X 認証は、ワイヤード スイッチで既にサポートされている可能性が高いので、必要な作業は、この認証を有効にして構成するだけです。通常、802.1X 対応のスイッチでは、ワイヤード接続の認証と承認にリモート認証ダイヤルイン ユーザー サービス (RADIUS) プロトコルを使用して、Windows Server® 2008 ベースのネットワーク ポリシー サーバー (NPS)、Windows Server 2003 インターネット認証サービス (IAS) サーバーなどの RADIUS サーバーに接続要求情報を送信します。
RADIUS のスイッチを構成したら、802.1X 認証を要求する前に、ワイヤード コンピュータで 802.1X 認証を有効にして構成する必要があります。ワイヤード ネットワーク接続での IEEE 802.1X 認証は、Microsoft® Windows® XP 以降の Windows 製品でサポートされています。ただし、Windows XP と Windows Server 2003 では、各ワイヤード クライアントで 802.1X 認証の設定を手動で構成する必要がありました (この操作は、[ネットワーク接続] フォルダからアクセスできるネットワーク接続のプロパティ ダイアログ ボックスの [認証] タブで行います)。残念なことに、これらの以前のオペレーティング システムでは、ワイヤード クライアントの 802.1X 認証の設定を一元的に構成したり、スクリプトで管理したりすることはできません。
しかし、さいわいにも、Windows Vista® と Windows Server 2008 では、グループ ポリシーによるワイヤード クライアントの設定がサポートされ、Netsh ツールでスクリプトの使用がサポートされているので、ワイヤード クライアントの 802.1X 認証の設定が容易に展開できるようになりました。

グループ ポリシーによるワイヤード ネットワークの設定
ワイヤード自動構成サービスを使用する
Windows XP と Windows Server 2003 では、ワイヤード接続での 802.1X 認証の動作は Wireless Zero Configuration サービスで制御されます。これらのオペレーティング システムでは、Wireless Zero Configuration サービスが既定で有効になっており、ワイヤード ネットワーク接続はパッシブ リッスン モードで、スイッチが認証を開始するのを待機していました。
Windows Vista と Windows Server 2008 でも、ワイヤード接続での 802.1X 認証の動作は ワイヤード自動構成サービスで制御されますが、このサービスは既定で無効になっています。つまり、ワイヤード自動構成サービスを開始するまで、ネットワーク接続のプロパティ ダイアログ ボックスには [認証] タブが表示されません。
Windows Vista または Windows Server 2008 を実行しているワイヤード クライアントでは、サービス スナップインを使用してワイヤード自動構成サービスを開始し、サービスが自動的に開始するように構成できます。ワイヤード自動構成サービスが開始されると、ワイヤード ネットワーク接続がアクティブなリッスン モードで動作します。このモードでは、ネットワーク接続により、スイッチでの認証が開始されます。
Active Directory ドメインの設定を変更する場合は、グループ ポリシーを使用してワイヤード自動構成サービスが自動的に開始されるように構成できます。グループ ポリシー管理エディタ スナップインを使用して、[コンピュータの構成]、[Windows の設定]、[セキュリティの設定]、[システム サービス] を順に展開し、ワイヤード自動構成の設定を自動スタートアップ モードとして構成します。

Windows Server 2008 と Windows Server 2003 の Active Directory® ドメイン サービスでは、ワイヤード ネットワーク設定の構成の一元管理と自動化を実現するために、グループ ポリシーでワイヤード ポリシーの設定をサポートしています。この設定により、ドメイン ベースのグループ ポリシー オブジェクトの [コンピュータの構成] グループ ポリシーの一環として、ワイヤード ネットワークの設定を構成できます。
このワイヤード ポリシーの設定を使用すると、Windows Server 2008 または Windows Vista を実行しているワイヤード クライアントの認証方法や他の 802.1X 認証の設定を指定できます。これらのオペレーティング システムでは、ドメインへの参加時と起動時、また起動後は定期的に、ワイヤード グループ ポリシーの設定が自動的にダウンロードされて適用されます。ただし、Windows Server 2003 の Active Directory ドメインでは、これらの新しいポリシーをサポートするように拡張する必要があることに注意してください。Windows Server 2003 の Active Directory ドメインの拡張方法については、technet.microsoft.com/bb727029 を参照してください。
ワイヤード ポリシーは、グループ ポリシー管理エディタ スナップインの [コンピュータの構成]、[Windows の設定]、[セキュリティの設定]、[ワイヤード (有線) ネットワーク (IEEE 802.3) ポリシー] ノードを順に展開して構成できます。既定では、ワイヤード (有線) ネットワーク (IEEE 802.3) ポリシーは存在しません。新しいポリシーを作成するには、コンソール ツリーで [ワイヤード (有線) ネットワーク (IEEE 802.3) ポリシー] を右クリックし、[新しい Windows Vista ポリシーの作成] をクリックします。
Windows Vista ワイヤード ポリシーのプロパティ ダイアログ ボックスには、[全般] タブと [セキュリティ] タブがあります。図 1 は、既定の [全般] タブを示しています。[全般] タブでは、ポリシーの名前と説明を設定し、ワイヤード接続での 802.1X 認証の動作を制御するワイヤード自動構成サービスを使用するかどうかを指定できます。詳細については、このコラムの補足記事「ワイヤード自動構成サービスを使用する」を参照してください。
図 1 Windows Vista ワイヤード ポリシーの既定の [全般] タブ
図 1 Windows Vista ワイヤード ポリシーの既定の [全般] タブ
図 2 は、Windows Vista ワイヤード ポリシーの既定の [セキュリティ] タブを示しています。[セキュリティ] タブでは、複数の操作を行えます。802.1X 認証の有効/無効を切り替えたり、拡張認証プロトコル (EAP) 認証方法を選択して設定したり、認証モード (ユーザーの再認証、コンピュータのみ、ユーザー認証、またはゲスト認証) を選択したり、認証が中止されるまでの試行回数を設定したり、次回接続用にユーザー情報をキャッシュするかどうかを設定したりすることができます。キャッシュが無効になっていると、ユーザーがログオフしたときに、ユーザー資格情報データがレジストリから削除されます。そのため、ユーザーは次回ログオン時に資格情報 (ユーザー名やパスワードなど) を入力する必要があります。
図 2 Windows Vista ワイヤード ポリシーの既定の [セキュリティ] タブ
図 2 Windows Vista ワイヤード ポリシーの既定の [セキュリティ] タブ
[セキュリティ] タブの [詳細設定] ボタンをクリックすると、802.1X 認証とシングル サインオンの詳細設定を構成できます。図 3 は、Windows Vista ワイヤード ポリシーの既定の [セキュリティの詳細設定] ダイアログ ボックスを示しています。[セキュリティの詳細設定] ダイアログ ボックスでは、図 4 に示す 802.1X 認証の設定を構成できます。
Figure 4 [セキュリティの詳細設定] ダイアログ ボックスの 802.1X 認証の設定 (Close Figure 4)

設定 | 説明
EAPOL 開始メッセージの最大数 | 最初の EAP over LAN (EAPOL) 開始メッセージに対する応答がない場合に続けて送信される EAPOL 開始メッセージの数。
保持期間 | 先に送信された EAPOL 開始メッセージに対する応答がない場合に EAPOL 開始メッセージを再送信する間隔。
開始期間 | 認証クライアントが、認証システムから認証エラーを受信した後に 802.1X 認証処理を実行しない期間。
認証期間 | 認証クライアントが、エンド ツー エンドの 802.1X 認証が開始された後に 802.1X 要求の再送信を待機する期間。
EAPOL 開始メッセージ | ワイヤード クライアントが EAPOL 開始メッセージを送信するかどうかを指定し、送信する場合はその方法を指定します。
図 3 Windows Vista ワイヤード ポリシーの既定の [セキュリティの詳細設定] ダイアログ ボックス
図 3 Windows Vista ワイヤード ポリシーの既定の [セキュリティの詳細設定] ダイアログ ボックス
Windows Server 2008 を実行しているワイヤード クライアントでは、ワイヤード接続でシングル サインオンがサポートされます。この機能は、間もなくリリースされる Windows Vista Service Pack 1 でもサポートされる予定です。詳細については、technetmagazine.com/issues/2007/11/CableGuy を参照してください。
シングル サインオンの設定には、ユーザー ログオン プロセスの前または後にユーザー レベルの 802.1X 認証を実行する設定と、ユーザー ログオン プロセスを開始するまでのユーザー レベルの 802.1X 認証の待機時間を指定する設定があります。Windows ログオン画面で、統合された入力フィールド以外に、ユーザー レベルの認証用のダイアログ ボックスを表示するかどうかを指定できます。たとえば、ある EAP の種類で、認証中に RADIUS サーバーから送信された証明書をユーザーが確認する必要がある場合、その EAP の種類ではダイアログ ボックスを表示できます。
また、ユーザー レベルの認証の実行後に、システムで、ワイヤード アダプタの TCP/IP 構成の動的ホスト構成プロトコル (DHCP) 更新が行われるように指定することもできます。コンピュータ レベル認証およびユーザー レベル認証のワイヤード クライアントに対して個別の仮想 LAN (VLAN) があり、それらが異なる IPv4 サブネットまたは IPv6 サブネットの場合は、このオプションを選択します。

Netsh ツールでのスクリプト サポート
Windows Server 2008 と Windows Vista では、Netsh ツールの netsh lan コンテキストでコマンドを使用して、ワイヤード設定を構成したり、ワイヤード プロファイルをエクスポートまたはインポートしたりすることがサポートされます (ワイヤード プロファイルとは、名前付きの XML 形式の一連のワイヤード設定です)。ワイヤード設定をコマンド ラインから構成できることにより、グループ ポリシーを使用しなくても、ワイヤード設定を構成する自動スクリプトを作成することで、ワイヤード ネットワークをより簡単に展開できます。[ワイヤード (有線) ネットワーク (IEEE 802.3) ポリシー] グループ ポリシー設定は、Active Directory ドメインにのみ適用されます。グループ ポリシー インフラストラクチャがない環境では、ワイヤード プロファイルを使用してワイヤード接続を自動的に構成するスクリプトを手動または自動 (たとえば、ログオン スクリプトの一部として) で実行できます。
Windows Vista または Windows Server 2008 を実行しているワイヤード クライアントをコマンドラインから構成するには、適切なパラメータを指定して netsh lan コマンドを実行します。たとえば、次のコマンドを実行すると、Local Area Connection という名前のネットワーク接続でのシングル サインオンが有効になり、ユーザー ログオンの前にユーザー認証を実行するようにシングル サインオンが構成されます。
netsh lan set profileparameter interface="Local Area Connection" ssomode=prelogon
netsh lan コマンド構文の詳細については、technet.microsoft.com/aa905084 を参照してください。
XML 形式のワイヤード プロファイルは、Netsh ツールを使用して、Windows Server 2008 または Windows Vista ワイヤード クライアントからエクスポートし、Windows Server 2008 または Windows Vista ワイヤード クライアントにインポートできます。ワイヤード プロファイルをエクスポートするには、netsh lan export profile というコマンドを使用します。また、ワイヤード プロファイルをインポートする場合は、netsh lan add profile というコマンドを使用します。ワイヤード プロファイルの実用的な例については、msdn2.microsoft.com/aa816372 を参照してください。
コマンド ラインと XML 形式のプロファイルのサポートにより、802.1X 認証が採用されている組織のワイヤード ネットワークにワイヤード クライアントをブートストラップできます。ドメインのメンバでないワイヤード クライアント コンピュータは、コンピュータの資格情報を使用してワイヤード ネットワークに接続することはできません。また、コンピュータは、一度ワイヤード ネットワークに正常に接続しないと、ドメインに参加できません。ただし、コマンド ラインと XML 形式のプロファイルのサポートにより、ワイヤード コンピュータは、ユーザーの資格情報を使用して組織のワイヤード ネットワークに接続し、ドメインに参加することができます。詳細については、technet.microsoft.com/bb727031 を参照してください。

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


 Windows PowerShell: シェルでアクセス許可を操作する
Windows PowerShell
シェルでアクセス許可を操作する
Don Jones
この記事で使用しているコードのダウンロード: PowerShell2008_02.exe (151KB)

Windows PowerShell の話をするときに、アクセス許可についての質問をよく受けますが、特に多いのは、アクセス許可の変更操作をシェルによって自動化できる状況とその方法についての質問です。ディレクトリやレジストリのアクセス許可についての質問もよく寄せられますが、おそらく最も多いのはファイルのアクセス許可についての質問だと思います。アクセス許可と
ほぼすべてのコマンド ラインやスクリプト インターフェイス (Windows PowerShellTM や VBScript など) との関係については、良い面と悪い面の両方があります。
悪い面は、Windows® のアクセス許可は本質的に複雑であり、これを解決するために Windows PowerShell ができることはあまりないということです。この問題の原因は、Windows オペレーティング システムにはアクセス許可に関するさまざまなオブジェクトが存在することです。これは、ファイル システム、Active Directory®、レジストリなど、ほぼすべての要素に当てはまります。
まず、ディレクトリ オブジェクト、ファイル、フォルダなど、リソースそのものが存在します。次に、リソースに関連付けられているアクセス制御リスト (ACL) オブジェクトが存在します。ACL は、1 つ以上のアクセス制御エントリ (ACE) オブジェクトで構成されています。ACE は、基本的にセキュリティ プリンシパル (ユーザーまたはグループ) をアクセス許可 (読み取りやフル コントロール) と許可または拒否の状態と結び付けています。このセキュリティ プリンシパルもオブジェクトです。これで、5 つものオブジェクトが存在することになります。つまり、リソース、ACL、ACE、プリンシパル、およびアクセス許可です。
すべての種類のリソースにさまざまな種類のアクセス許可があるということが、アクセス許可をさらに複雑にしています。たとえば、ディレクトリ オブジェクトには、個々のオブジェクト属性へのアクセスを管理する複雑なアクセス許可があります。それに比べると、ファイルのアクセス許可は比較的単純です。
また、厳密に言えば、監査について考慮すると、この複雑さは 2 倍になります。実際には、各リソースには ACL が 2 つあります。1 つ目は、リソースへのアクセスを管理する随意 ACL (DACL) です。そして 2 つ目は、リソースの監査を制御するセキュリティ ACL (SACL) です。これらのアクセス許可を操作するということは、かなり複雑そうな大量のプログラミング オブジェクトについて理解する必要があることを意味します。これを簡略化するために Windows PowerShell のようなシェルにできることは限られているのです。

.NET Framework による制限
まだ物足りませんか
検索可能なコマンドレット ライブラリなどの Windows PowerShell の関連リソースを利用したり、Don Jones やその他の Windows PowerShell の専門家と連絡を取るには、www.PowerShellCommunity.org を参照してください。

Windows PowerShell の性質によって、作業はもう少し複雑になります。Windows PowerShell は Microsoft® .NET Framework に基づいて構成されており、基になっている .NET Framework のクラスを使用してアクセス許可を表示および操作します。これらの .NET Framework クラスは、ソフトウェア開発者がアクセス許可をより細かく厳密に制御できるように設計されています。もちろん、"より細かく厳密に" ということは情報が多いということであり、"非常に複雑である" と言い換えられることもしばしばあります。
また、.NET Framework では、アクセス許可を表現するクラスがすべての種類の Windows リソース用に提供されているわけではありません。たとえば、ファイル セキュリティを操作できるクラスは提供されていますが、共有フォルダのセキュリティを操作できるクラスは提供されていません。このため、Windows PowerShell は、すべての種類の Windows リソースのアクセス許可を操作することはできません。簡単に言えば、Windows PowerShell の機能は、.NET Framework によって提供される機能に限定されます。

シェルでアクセス許可を操作する
Windows PowerShell では、2 つのコマンドレットを使用してアクセス許可を管理できます。これらは、Get-ACL と Set-ACL です。ご想像のとおり、Get-ACL はリソースから ACL を取得します。その後、必要に応じて ACL を変更し、Set-ACL を使用して変更後の ACL をリソースに書き込みます。これらのコマンドレットはどちらも汎用的であり、Windows PowerShell システムの PSDrive プロバイダに依存しています。したがって、これら 2 つの ACL コマンドレットは、特定の種類のリソースを理解できる PSDrive プロバイダと、そのリソースのアクセス許可を変更できる PSDrive プロバイダが存在すれば、理論的にはどんな種類のリソースでも操作できます。Windows PowerShell に含まれている FileSystem PSDrive プロバイダと Registry PSDrive プロバイダでは、これら 2 つの ACL コマンドレットを使用したアクセス許可の管理がサポートされています (その他の PSDrive プロバイダでは、この操作がサポートされていない場合があります)。
図 1 のサンプル スクリプトを使用すると、開始ディレクトリ、セキュリティ プリンシパル、およびアクセス許可を指定することができます。このスクリプトは、プリンシパルに指定したアクセス許可を、指定したディレクトリ内のすべてのファイルとフォルダに適用します。また、繰り返し処理によってサブディレクトリにもアクセス許可を適用します。
Figure 1 プリンシパルのアクセス許可をディレクトリ内のファイルとフォルダに適用するコード (Close Figure 1)
#ChangeACL.ps1
$Right="FullControl"

#The possible values for Rights are
# ListDirectory, ReadData, WriteData
# CreateFiles, CreateDirectories, AppendData
# ReadExtendedAttributes, WriteExtendedAttributes, Traverse
# ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes
# WriteAttributes, Write, Delete
# ReadPermissions, Read, ReadAndExecute
# Modify, ChangePermissions, TakeOwnership
# Synchronize, FullControl

$StartingDir=Read-Host "What directory do you want to start at?"
$Principal=Read-Host "What security principal do you want to grant" `
"$Right to? `n Use format domain\username or domain\group"

#define a new access rule.
#note that the $rule line has been artificially broken for print purposes.
#it needs to be one line. the online version of the script is properly
#formatted.
$rule=new-object System.Security.AccessControl.FileSystemAccessRule
($Principal,$Right,"Allow")

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  $acl=get-acl $file.FullName

  #Add this access rule to the ACL
  $acl.SetAccessRule($rule)

  #Write the changes to the object
  set-acl $File.Fullname $acl
  }
このスクリプトで重要なのは、変数 $rule でアクセスに関する新しい規則を定義している部分です。この操作には、.NET Framework クラスを "そのまま" 使用しています。ここがおそらく Windows PowerShell を使用したアクセス許可の管理において最も複雑な部分です。次にスクリプトは Get-ACL を使用して ACL を各ファイルとフォルダから順番に取得し、ACL の SetAccessRule メソッドを使用して新しい規則を適用します。その後、Set-ACL を使用して、変更後の ACL をリソースに書き込みます。
ACL から ACE を削除する操作など、さらに複雑な操作になるともっとややこしくなってきますが、実は上記の操作はそれほど複雑ではありません。個人的な意見ですが、この操作が複雑そうに見えるのは多くの手順が実行されるためです。つまり、ACL の取得、規則の定義、ACL の変更、および ACL の書き込みという手順です。サンプル スクリプトのコマンドは、単独ですべての処理を一度に実行できるようなすっきりとしたコマンドではありません。また、複数のファイルの ACL を変更する必要があったため、foreach ループ内にすべてのコードを記述し、Get-ChildItem を使用して実際にすべてのファイルとフォルダにアクセスする必要がありました。

最も簡単な方法を選択する
今月のコマンドレット : Get-QADUser
Active Directory を管理している皆さんにとっては必携のコマンドレットです。Windows PowerShell には組み込まれていませんが、無償でダウンロードできる Quest Software の ActiveRoles Management Shell for Active Directory (www.quest.com/activeroles-server/arms.aspx) に含まれています。
スナップインをインストールしたら、Get-QADUser を使用してディレクトリからユーザー オブジェクトを取得できます。もちろん、単純にコマンドレットを実行するとすべてのユーザーが返されますが、それでは多くの管理作業にはあまり役立ちません。しかし、このコマンドレットを使用すると、フィルタ条件を指定してドメイン コントローラに適用できるため、目的のユーザーのみが実際に Windows PowerShell に返されるようにすることができます。これは、最初にすべてのユーザーを取得してから Where-Object コマンドレットを使用してフィルタをかけるよりもかなり手間のかからない手法です。たとえば、Get-QADUser -l Redmond では、単に "1" という属性に "Redmond" が含まれているユーザーが返されます (ちなみに、属性 "l" は地域を表しており、GUI に都市として一覧表示されます)。その後、それらのユーザーを他のコマンドレットに渡して、HTML レポートの生成、グループへのユーザーの配置、ユーザーの削除などを行うことができます。

私の例が複雑だとは思いませんが、多くの管理者はさらに簡単な方法でアクセス許可を操作したいと思っているでしょう。おそらく、図 1 のような複数の段階から成るスクリプトを記述しなくても、一連のフォルダから特定のユーザー グループを一度に削除できる方法を望んでいるのではないでしょうか。
幸運なことに、Windows PowerShell ではアクセス許可を操作するための簡単な方法が提供されています。さらに、皆さんはおそらくその方法を既に使い慣れていると思います。
Windows PowerShell では、信頼できる従来の方法も使用することができます。たとえば、Dsacls.exe、Cacls.exe、Xcacls.exe などのコマンド ライン ツールを使用できます。これらは、より簡単にさまざまな種類のアクセス許可を操作できるように設計されています。これらのツールの構文は、Windows PowerShell コマンドレットで使用されるような標準化された構文とはまったく異なりますが、従来の cmd.exe シェルで使用されていたように、コマンド ラインを場当たり的に使用する必要はなくなります。Windows PowerShell を使用すると、これらのユーティリティを自動化することができます。
Windows PowerShell 内で旧式のコマンド ライン ユーティリティを使用するのは何となく良くないと言う人たち (私は純粋主義者と呼んでいます) もいます。私はその理屈をまったく理解できません。大事なのは作業を完了することであり、10 年前から使用されているコマンド ライン ユーティリティを使用するのが最も簡単な方法であるなら、それを使用します。"純粋だから" という理由だけで、多くの時間を費やしてまで特定の方法を使用するつもりはありません。マイクロソフトの Windows PowerShell チームも同じ考え方です。既存のツールで作業を完了できるのであれば、Windows PowerShell のシェル内でそのツールを使用できます。無駄な労力を使う必要はないでしょう。
図 2 は、私の著書である『Windows PowerShell: TFM』(SAPIEN Press、2006 年) から引用した短いスクリプトです。このスクリプトでは Windows PowerShell を使用して Cacls.exe をオートメーション起動しています。このスクリプトは単なるデモンストレーションであるため、本格的なオートメーション ツールにするには手を加える必要があります。しかし、Windows PowerShell スクリプトがどのように情報を収集し、その情報を使用して、"ネイティブの" Windows PowerShell コマンドであるかのように Cacls.exe を起動しているかはおわかりいただけると思います (このスクリプトは情報を収集する際に情報の入力をユーザーに要求していますが、パラメータをファイルやデータベースから読み込むこともできます)。
Figure 2 Cacls.exe をオートメーション起動するコード (Close Figure 2)
#SetPermsWithCACLS.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir=Read-Host "What directory do you want to start at?"
$Right=Read-Host "What CACLS right do you want to grant? Valid choices are F, C, R or W"
Switch ($Right) {
  "F" {$Null}
  "C" {$Null}
  "R" {$Null}
  "W" {$Null}
  default {
    Write-Host -foregroundcolor "Red" `
    `n $Right.ToUpper() " is an invalid choice. Please Try again."`n
    exit
  }
}

$Principal=Read-Host "What security principal do you want to grant?" `
"CACLS right"$Right.ToUpper()"to?" `n `
"Use format domain\username or domain\group"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Right.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

 foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  #display filename and old permissions
  write-Host -foregroundcolor Yellow $file.FullName
  #uncomment if you want to see old permissions
  #CACLS $file.FullName

  #ADD new permission with CACLS
  CACLS $file.FullName /E /P "${Principal}:${Right}" >$NULL

  #display new permissions
  Write-Host -foregroundcolor Green "New Permissions"
  CACLS $file.FullName
 }
}

アクセス許可を適切に操作できましたか
Windows PowerShell はアクセス許可の操作に向いていないという意見を聞いたことがあります。簡単で汎用的なアクセス許可の管理を提供するネイティブ コマンドレットが提供されないことがその理由だそうです。私はその意見に同意できません。まず、このような意見を持っているのは主に UNIX 環境に携わっている管理者がほとんどです。実は、Windows のアクセス許可のシステムは UNIX で使用されているものよりも非常に複雑です。この複雑なシステムを操作する場合、Windows PowerShell を使用した作業も複雑になります。しかし、これは Windows PowerShell の問題ではありません。
また、Windows PowerShell では、ここで紹介したような古き良きコマンド ライン ユーティリティと同じ形式で、簡素化されたツールを使用できます。確かに、Windows プラットフォーム全体にわたるすべてのアクセス許可を管理するには、.NET Framework を拡張する必要があります。しかし全体的に見れば、Windows PowerShell はどちらの利点も与えてくれます。つまり、アクセス許可を簡単に管理でき、きめ細かく精密な管理ツールも利用できるということです。

Don Jones は TechNet Magazine の編集に携わっており、『Windows PowerShell: TFM』(SAPIEN Press、2007 年) の共著者でもあります。また、彼は Windows PowerShell に関するトレーニングの講師も務めています (www.ScriptingTraining.com を参照)。www.ScriptingAnswers.com で公開されている Web サイトから、彼と連絡を取ることができます。


 Hey, Scripting Guy!: 競技会へのお誘いと XML 関連のスクリプト
Hey, Scripting Guy!
競技会へのお誘いと XML 関連のスクリプト
The Microsoft Scripting Guys
この記事で使用しているコードのダウンロード: HeyScriptingGuy2008_02.exe (151KB)

ご存知のとおり、 人々がスポーツ界の伝説について語るときはいつも同じ名前が出てきます。それは、ベーブ ルース、ペレ、モハメド アリ、ウォルター ペイトン、ScooterK と MrRat、ジョニーなどです。
あはは、それはおかしいですね。えっ、本当ですか。ScooterK と MrRat のことを本当に知らないのですか。ということは、当然皆さんは Winter Scripting Games (2 月 15 日から 3 月 3 日まで TechNet スクリプト センターで開催されます) についてあまりご存知ないでしょう。Winter Scripting Games については、microsoft.com/technet/scriptcenter/funzone/games を参照してください。ScooterK と MrRat は、2007 Winter Scripting Games の 1 つ以上の部門で満点を獲得した伝説的な競技者です。
本当にすばらしいのはここからです。現実的に考えて、ペレのような伝説的なサッカー選手になれる可能性はあるでしょうか。おそらくないでしょう。ボクシング世界ヘビー級王者になれる可能性はあるでしょうか。Scripting Guys の中にはヘビー級の要素を満たしているような人もいますが、ボクシング王者になることはやはり困難です。しかし、第 2 の ScooterK や MrRat になることは非常に簡単です。
注 : 理論的には、第 2 のベーブ ルースになることも可能です。ダブルヘッダーの 1 試合目と 2 試合目の間に 24 個のホットドッグを食べることができればよいだけの話です。
気楽にいきましょう。今日は、どうすれば第 2 の ScooterK や MrRat (さらには、第 2 の Bizzy や H2Data) になることができるかについてお話します。その方法は、スクリプト センターにアクセスして、Scripting Games に参加するだけです。2 月 15 日に 10 個の異なる競技 (10 個のスクリプト課題) が公開され、皆さんにそれらのすべてまたはいずれかをクリアしてもらいます。公開された問題を解決するためのスクリプトを作成し、Scripting Guys に電子メールでお送りください (詳しい説明については、Scripting Games のホーム ページを参照してください)。お送りいただいたスクリプトをテストし、問題が解決された場合はポイントを進呈します。見事に 10 個すべての競技をクリアすれば、皆さんもスポーツ界の伝説的人物になるでしょう。少なくとも、スクリプト スポーツ界では伝説的人物になります。これは、スポーツ界の伝説的人物になることとほぼ同じです。
Scripting Games (2 月 15 日から 3 月 3 日まで開催されます) は、楽しく取り組みがいのある競技会です。何より、Scripting Games にはだれでも参加できます。システム管理スクリプトにまだあまり詳しくない方は、初級部門に参加してください。VBScript、Windows PowerShellTM、および Perl (今年新設されました) での初心者向けの競技がそれぞれ用意されています。初級部門が少し簡単だと感じる方は、上級部門に挑戦してみてください。この部門でも、VBScript、Windows PowerShell、および Perl の競技が用意されています。
この競技会 (2 月 15 日から 3 月 3 日まで開催されることはお伝えしたでしょうか) は、まさにスクリプト シーズンの一大イベントです。お見逃しのないようにしてください。スクリプト センターのホーム ページにアクセスして、競技に向けたトレーニングのヒントとテクニックを参照し、正式に競技会が開始される 2 月 15 日になったらもう一度アクセスしてください。
念のためもう一度お伝えしておきます。競技会は 2 月 15 日から 3 月 3 日までです。
何でしょうか。そうですね、同感です。1 か月のうちに Scripting Games に関するお知らせだけでなく、新しい Hey, Scripting Guy! コラムも公開するというのは楽しみが多すぎますね。しかし、TechNet Magazine のすばらしい仲間たちが幸せでいられるように (言うまでもなく、これが私たちの第一の目標です)、あえて新しいコラムを公開することにしました。
ちょうど 1 年前 (もうそんなにたちましたか)、スクリプトを使用して XML ファイルを読み取る方法が記載されたコラムを公開しました。そのコラムでは、スクリプトを使用して XML ファイルの作成や変更、および XML ファイルへの書き込みを行う方法は紹介しませんでした。今月はその方法を紹介します。XML ファイルを作成するためのスクリプトをどのように記述すればよいかを知りたいんですよね。それならそう言ってくださればよかったのに。私たちにそう言ってから、1 年間回答を待ってくださればよかったんです。図 1 のスクリプトがその回答です。確かに複雑に見えますが、これからこのスクリプトのしくみについて詳しく説明していきます。
Figure 1 XML ファイルの作成 (Close Figure 1)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName

Set objDate = _
  xmlDoc.createElement("AuditDate")
objDate.Text = Date
objRecord.appendChild objDate

Set objIntro = _
  xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)

xmlDoc.Save "C:\Scripts\Audits.xml"
まず、Microsoft.XMLDOM オブジェクトのインスタンスを作成します。ご想像のとおり、このオブジェクトによって XML ファイルの操作が可能になります。目標は、図 2 のような単純な XML ファイルを作成することです。
図 2 目標とする単純な XML ファイル
図 2 目標とする単純な XML ファイル
この XML ファイルを作成するには、まずルート ノード (ITChecklist) を作成する必要があります。この操作を行うにはどうすればよいでしょうか。次のコードを使用します。
Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot
とても簡単ですね。createElement メソッドを呼び出し、ルート ノードに付ける名前を createElement に渡しただけです。次に appendChild メソッドを呼び出し、唯一のメソッド パラメータとして新しい要素 (objRoot) へのオブジェクト参照を渡しています。これでルート ノードが作成されました。
しかしまだ続きがあります。次は、ComputerAudit ノードを作成します。ComputerAudit ノードは、1 台のコンピュータの情報を表す、ITChecklist ノードの子ノードです。次のように、ComputerAudit ノードを作成するためのコードは、ルート ノードの作成に使用したコードと似ています。
Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord
唯一異なるのは、ルート ノードの作成時には、XML ドキュメント自体に対して appendChild を呼び出したということです (xmlDoc というオブジェクト参照に注目してください)。ルート ノードに新しい子ノードを追加するには、XML ドキュメントではなく、ルート ノード (objRoot) に対して appendChild を呼び出します。とても簡単ですね。
ComputerAudit の子ノードとして ComputerName ノードと AuditDate ノードを追加する操作も同じくらい簡単です。ここでも、同様の手順を実行します。つまり、createElement を呼び出して新しいノードを作成し、appendChild を呼び出してこの新しいノードをファイルに追加します。
(ここでクイズです。この場合はどこから appendChild を呼び出すでしょうか。そうです、objRecord から呼び出します。objRecord は、先ほど作成した親 (ComputerAudit) ノードです)
ComputerName ノードと AuditDate ノードには値が含まれている必要があるため、これらのノードをドキュメントに追加する直前に各ノードの Text プロパティの値を指定することも重要です。
実際に ComputerName ノードを作成する次のコードをご覧になれば、上記で説明したことがおわかりいただけると思います。
Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName
ご想像のとおり、AuditDate を作成するコードもほとんど同じです。createElement を呼び出すときに別のノード名を指定し、Text プロパティに別の値を代入する必要があるだけです。
あまりに簡単だと思いませんか。
最初の (そして、この場合は唯一の) レコードのノードを作成したら、次のような単純で短いコード ブロックを実行します。
Set objIntro = _
 xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)
上記のコードを実行すると、ファイルの先頭に <?xml version="1.0" ?> タグが挿入されます。これは、適切な形式の XML ドキュメントを作成するための操作です。
後は次のように、Save メソッドを呼び出し、C:\Scripts\Audits.xml という名前で新しいファイルを保存するだけです。
xmlDoc.Save "C:\Scripts\Audits.xml"
これで、新しい XML ドキュメントが作成されます。
スクリプトを使用して新しい XML ファイルを作成する方法を知っていると、実際とても役立ちます。もちろん、まったく新しい XML ファイルの作成が必要になることはほとんどありませんが、既存のファイルへの新しいデータの追加が必要になることはあります。Scripting Guys はその方法を皆さんに紹介するでしょうか。
最初は、既存の XML ファイルに新しいデータを追加する方法は紹介しないつもりでした。しかし、心優しく気前のよい Scripting Guys は、TechNet Magazine の読者の皆さんとある取引をすることにしました。この TechNet Magazine を読んでいる皆さんが全員 2008 Winter Scripting Games に参加していただけるなら、それと引き換えに、スクリプトを使用して XML ファイルにデータを追加する方法を説明します。ということで、皆さん Scripting Games に参加していただけますか。
あなたのご参加をお待ちしています。そう、ミネソタ州ロチェスターのあなたです。
そうこなくっちゃ。Scripting Games では、だれもが必ず楽しい時間を過ごすことができます。本当ですよ。お約束します。
では、約束は約束なので、既存の XML ファイルにデータを追加できるスクリプトを紹介しましょう。図 3 をご覧ください。
Figure 3 XML ファイルへの追加 (Close Figure 3)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set objRoot = xmlDoc.documentElement

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objFieldValue = _
  xmlDoc.createElement("ComputerName")
objFieldValue.Text = "atl-ws-100"
objRecord.appendChild objFieldValue

Set objFieldValue = _
  xmlDoc.createElement("AuditDate")
objFieldValue.Text = Date
objRecord.appendChild objFieldValue

xmlDoc.Save "C:\Scripts\Audits.xml"
ご覧のとおり、XML ファイルを作成したスクリプトとそれほど変わりません。まず、Microsoft.XMLDOM オブジェクトのインスタンスを作成し、Async プロパティを False に設定しています。これで、非同期ではなく同期を取ってドキュメントが読み込まれるようになります。このことは、どのような影響を及ぼすのでしょうか。非同期にドキュメントを読み込むと、ドキュメントが完全に読み込まれていない場合でもスクリプトは続行されます。言うまでもなく、まだ存在しないドキュメントで作業を実行しようとすると、その直後に問題が発生する可能性があります。同期を取って XML ファイルを読み込むようにすると、ファイルが完全に読み込まれてからスクリプトが続行されます。
"完全に読み込まれてから" といっても気にしないでください。この処理は自動的に行われます。次に、Load メソッドを呼び出して C:\Scripts\Audits.xml ファイルを開きます。ファイルを開いたらすぐに、次のコード行を使用して documentElement クラスのインスタンスを作成します。これにより、ドキュメントのルートにバインドされます。もちろん、この場合は ITChecklist がルート ノードです。
Set objRoot = xmlDoc.documentElement
ここからは簡単です。ComputerAudit ノードの新しいインスタンスを作成し、appendChild メソッドを使用して、ファイルにこの新しいノードを追加します。その後、ComputerName ノードと AuditDate ノードの新しいインスタンスを作成し、新しい各ノードに適切な値 (それぞれ atl-ws-100 と現在の日付) を指定します。その後、先ほど作成した新しい ComputerAudit ノードにこれらのノードを追加し、Save メソッドを呼び出してファイルを保存します。これで、今度の Scripting Games 用のスクリプトを作成する作業に戻ることができます。
念のためもう一度お伝えしておきます。Scripting Games は 2 月 15 日から 3 月 3 日まで TechNet スクリプト センターで開催される予定です。
ここまでは順調ですね。新しい XML ファイルを作成し、そのファイルに新しいレコードを追加できました。これはとてもすばらしいことですが、まだ長い道のりがあります。たとえば、XML ファイルの既存のレコードを変更するにはどうすればよいでしょうか。図 4 に示すように、少なくとも 1 つはこの作業を行う方法があります。
Figure 4 XML の変更 (Close Figure 4)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
このスクリプトで重要なのは、selectNodes メソッドを呼び出す部分です。selectNodes は、クエリによって返されるレコードを決定するメソッドです。ご覧のとおり、selectNodes メソッドの呼び出し時に 2 つの条件を指定しています。ここで必要なのは、ComputerName 属性が atl-ws-100 であるレコード、およびそのレコードの AuditDate 属性のみです。
注 : このスクリプトのしくみがわからないとおっしゃいましたか。その場合は、XML ファイルを使用した作業について初めて説明したときの記事 (technetmagazine.com/issues/2007/02/HeyScriptingGuy) を参照してください。selectNodes クエリ構文についてのさらに詳しい説明が記載されています。
いつもどおり、selectNodes からは指定した条件を満たすすべての XML レコードのコレクションが返されます。つまり、AuditDate 属性 (必要な唯一の属性) の値を更新する操作は、次のように For Each ループでコレクションのすべての項目を 1 つずつ処理し、その処理の中で AuditDate に新しい値を代入すれば完了します。
For Each objNode in colNodes
   objNode.Text = Date
Next
何でしょうか。一度に複数の属性を変更できるかですって。もちろん、できます。しかし残念ですが、今日は説明しません。これについては今後のコラムで説明します。
まだ質問がありますか。ファイル内に列挙されているすべてのコンピュータの監査日を更新するにはどうすればよいか、ですね。これは簡単です。図 5 のスクリプトを使用します。
Figure 5 監査日の変更 (Close Figure 5)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
このスクリプトには、前述の XML を変更するためのスクリプトと異なる部分が 1 つだけあります。このスクリプトでは、ComputerName が atl-ws-100 であるレコードのみを表示するように指定していません。その条件を除外すると、既定ですべてのレコードが返されます。
最後にもう 1 つスクリプトを見てみましょう。たとえば、長年使用した atl-ws-100 が最後にソリティアを実行し、空の彼方にある大きなコンピュータ墓地へと足を引きずりながら向かっていったとします。
神学に関する注 : コンピュータは動作しなくなったらどこに行くのでしょうか。おわかりのとおり、たいがいはいずれかの Scripting Guy に引き渡されます。たとえば、このコラムを執筆している Scripting Guy は、ラップトップ コンピュータを受け取ったことがあります。その理由は、マイクロソフトのためになることをたくさん行っているので、ラップトップ コンピュータを所有した方がよいということだそうです。この気前のよい申し出にも 1 つだけマイナス面がありました。それは、コンピュータが壊れていて、電源を入れることができなかったということです。しかし、かえって好都合だったかもしれません。ハード ディスクも搭載されていなかったのですから。
このシリコンチップの偉大なライフ サイクルを完結させるには、XML ファイルから atl-ws-100 を削除する必要があります。そのためにはどうすればよいでしょうか。図 6 をご覧ください。
Figure 6 XML ファイルからの削除 (Close Figure 6)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")

For Each objNode in colNodes
  xmlDoc.documentElement.removeChild _
    (objNode)
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
ご覧のとおり、このスクリプトは、AuditDate プロパティを変更した前述のスクリプトに似ています。違いは 2 つだけです。1 つは、前述のスクリプトでは、selectNodes クエリでプロパティ値を指定しなかったということです。次のようにプロパティ値を指定すると、atl-ws-100 の XML レコード全体が返されます。
Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")
もう 1 つは、次のように、For Each ループ内で removeChild メソッドを呼び出して、ComputerName が atl-ws-100 であるすべてのレコードを削除しているということです。
xmlDoc.documentElement.removeChild _
  (objNode)
これで作業は完了です。さようなら、atl-ws-100。変わり果てた atl-ws-100。
まだ今月のコラムを読んでいる TechNet Magazine の編集者はいらっしゃいますか。そうですか、毎月恒例のスクリプト パズルに全員が取り掛かかっていますか。それはよかったです。覗き見している編集者はいないようなので、ここで言わせてください。今していること (たとえば、この TechNet Magazine を読むこと) をやめて、スクリプト センターにアクセスし、Scripting Games の準備を始めましょう。どうせ TechNet Magazine はしばらく公開されているのですから。Scripting Games は 1 年に 1 回この時期にしか開催されず、しかも期間が限定されています (具体的に言うと、2 月 15 日から 3 月 3 日までです)。どうぞお見逃しなく。
注 : そういえば、TechNet Magazine を読むのをやめてくださいと言うのが、皆さんがこのコラムを読み終えた後になってしまいましたね。さあ、どうしてそうなってしまったかはわかりません...

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

2008 年 2 月 : 謎の記号
コンピュータのキーボードには、見慣れないさまざまな種類の記号があります。さらに厄介なことに、これらの記号のほとんどは、VBScript または Windows PowerShell スクリプト言語の特定の用途に使用されます。各記号とスクリプトでの用途を組み合わせてみてください。1 問目は回答済みです。

Dr. Scripto のスクリプト パズル
解答 : 謎の記号 (2008 年 2 月)

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


 セキュリティ ウォッチ: 島巡り : 望ましくない依存関係を軽減する
セキュリティ ウォッチ
島巡り : 望ましくない依存関係を軽減する
Jesper M. Johansson

先月のセキュリティ ウォッチの記事では、USB フラッシュ ドライブを使用したネットワークの攻撃の発端となる手続きについて説明しました。ネットワークへの攻撃は、ウイルスに感染した USB フラッシュ ドライブが 1 台のコンピュータに接続されることで開始され、その後、自動的に、またはユーザーのわずかな手助けによって (簡単なソーシャル
エンジニアリングを利用します) 悪意のあるコードが実行されるということを説明しました。この攻撃はワークステーションのローカルだけにとどまりましたが、マルウェアがネットワークに蔓延する可能性は十分にあります。このようなネットワーク上で行われる攻撃については、近日出版予定の私の著書『Windows Server 2008 Security Resource Kit』(Microsoft Press®、2008 年) で詳しく説明しています。この記事では、その章の一部を変更してお届けします。
当然のことですが、保護対策の選択肢の 1 つは、リムーバブル ドライブの使用を禁止することです。これは賢明な対策であるように思えますが、このような対策を講じようとするものなら、駐車場で待ち伏せしているだれかに襲撃される可能性が高いでしょう。それに、このような行為を咎めるのも難しいかもしれません。重要度の高い機密データを保持しているほぼすべての環境において適切な対策は、その環境がはらんでいるリスクを管理して、危険にさらされるのを阻止することです。
また、クライアント コンピュータを危険にさらす方法は、リムーバブル ドライブだけではありません。「セキュリティに関する 10 の鉄則」(microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx) を覚えていますか。鉄則 3 の文言は、ここでも当てはまります。つまり「悪意のある攻撃者があなたのコンピュータに対して物理的なアクセスを無制限に行える場合、もはやそれはあなたのコンピュータではない」ということです。この説明の状況では、攻撃者があなたのコンピュータにアクセスした場合、そのコンピュータは危険にさらされたと考えられるということです。攻撃者があなたのコンピュータでコードを実行できる場合、リモートからでも危害を与えることができます。これについては、「セキュリティに関する 10 の鉄則」の鉄則 1 として認識されている方がいらっしゃるかもしれませんね。つまり「悪意のある攻撃者の誘惑に乗って、攻撃者のプログラムをあなたのコンピュータで実行した場合、もはやそれはあなたのコンピュータではない」ということです。
この鉄則が有効であるのは間違いないでしょう。鉄則には順応性があることがわかっていますし、コンピュータのしくみが根本的に変わるまでは、著しく変化する可能性は高くないでしょう。そのため、既に説明したシナリオで、この鉄則がどのように当てはまるのかを考えると、リムーバブル ドライブを無効にすることは、非常に重要です。リムーバブル ドライブは、レジストリを調整することで無効にすることができます。
もちろん、追加の保護対策を講じる必要もあります。クライアント コンピュータの多くが、既に危険にさらされている、または組織でセキュリティに最も関心があり常時注意を払っているユーザーによって操作されているとは限らないと考えるのが妥当でしょう。つまり、このようなコンピュータのネットワークに対する影響を軽減する必要があるということです。そして、この必要性により、セキュリティの依存関係を理解、分析、および軽減することの重要性が高まります。

セキュリティの依存関係を定義する
セキュリティの依存関係は、あるコンピュータのセキュリティが別のコンピュータのセキュリティに依存する場合に起こります。「ドメイン コントローラ (DC) がハッキングに遭った場合、ネットワーク全体がハッキングされたことになる」と言われているのはご存知でしょう。これは、すべてのドメイン メンバのセキュリティは、DC に依存していることを簡潔に表しています。DC のセキュリティが確保されていなければ、メンバ コンピュータのセキュリティも確保されません。攻撃者がドメインのセキュリティ構成を変更できる場合は、たとえば、メンバ コンピュータの Administrators グループに新しいアカウントを追加することによって、ドメイン内のあらゆるコンピュータを乗っ取ることができます。管理者がコンピュータを危険にさらすことができるという脆弱性は、興味深いということでは済まされません。管理者は管理しているものなら何でも完全にアクセスできるのです。
コンピュータ システムの依存関係は避けることができません。実際には、依存関係は一般的で望ましい場合が多いです。ただし、だからと言ってすべての依存関係が許容されるものだというわけではありません。今月の記事では、許容される依存関係と許容されない依存関係の種類について説明します。また、依存関係の種類を分析して軽減する方法についても説明します。『Windows Server 2008 Security Resource Kit』では、特定の依存関係の詳細や依存関係を管理する方法について説明しています。

許容される依存関係
一般的に、セキュリティを確保するために、重要度の低いシステムが、より重要度の高いシステムに依存するという依存関係は許容されます。コンピュータとシステムは、一般的に重要度に基づいて分類することができます (ここで重要なのは、継承できる分類があるということなので、特定の環境における一連の分類は一般的な説明からは除外します)。説明の便宜上、ここではワークステーションと DC という 2 つの分類があるとします。このシナリオでは、セキュリティを確保するために、ワークステーションが DC に依存するのは許容される依存関係です。DC コンピュータは、ワークステーション コンピュータよりも機密性が確実に高いため、DC のセキュリティはワークステーションよりも強化されている必要があります。
ユーザー アカウントに関しても同じことが言えます。ユーザーが所有しているデータに管理者がアクセスするのは許容範囲です。これは、管理者は、より大きな責任があり、コンピュータとコンピュータ上のすべてのものに対して自由に (必ずしも直接または明示的にというわけではありませんが) アクセスできるからです。この点を理解してコンピュータを適切に管理すれば、この依存関係に問題はありません。
ソフトウェアについても同じように分析できます。セキュリティを確保するために、Web ブラウザなどの重要度の高くないソフトウェアが、オペレーティング システムなどの重要度の高いソフトウェアを使用して依存することは、もちろん許容される依存関係です。OS にバグがある場合、Web ブラウザも新しい問題に対して脆弱になるということは当然の結果です。しかし、一番の関心は OS や他の重要なアプリケーションとデータにあるため、Web ブラウザの脆弱性は緊急課題リストの下位項目として位置付けられるでしょう。これは、バグの修正方法や修正プログラムの適用箇所に関連しています。つまり、バグはできるだけ問題の根源で修正する必要があります。そうすることで、修正プログラムによる保護対象範囲を最大限にすることができます。そのため、Web ブラウザの問題に対処するよりも OS 自体の問題を修正する必要があるのです。
また、設計を変更することで依存関係をなくすこともできます。たとえば、Web ブラウザを書き換えて OS への依存度合いを軽減することができます。重要度の低いコンポーネント (たとえば、Web ブラウザ) が、セキュリティが厳重に確保されているコンポーネント (この場合は OS) の機能が、意図されていない用途に使用されている場合は、設計を変更するという後者のアプローチが適切です。

許容されない依存関係
許容される依存関係について説明したので、許容されない依存関係の定義はもう明らかでしょう。基本的に、セキュリティを確保するために、重要度の高いシステムが重要度の低いシステムに依存するようなことがあってはなりません。
ワークステーションが危険にさらされることが DC のセキュリティ侵害になる場合、セキュリティ上の重大な問題を抱えていることになります。ネットワークの総合的なセキュリティが、そのネットワーク上の個々のコンピュータに依存している場合、ネットワークを保護することは不可能です。
次の例を統計的に考えてみましょう。ネットワーク上のすべてのコンピュータが、稼動時間の 99.999% の間 "保護されている" 場合、安全なネットワークだと思われるかもしれません。実際、この割合は、今日の最も小規模なネットワークを除くネットワークの実状よりもはるかに高い数値でしょう。しかし、ネットワークに 40,000 台のコンピュータがあり、個々のコンピュータが稼働時間の 0.001% の間脆弱である場合を考えてみてください。ネットワーク全体は、その稼働時間のうち最大 40% の間、安全ではないと言えます。
依存関係が管理されていない場合、ネットワーク全体を危険にさらすのに必要なのは、そのたった 0.001% の脆弱な時間に 1 台のコンピュータに攻撃を加えるだけです。この場合、ネットワークはどのくらい安全でしょうか。機密性の高いシステムを機密性の高くないシステムから保護することが最も重要であるのは明白です。
ユーザー アカウントやソフトウェアについても、同じことが言えます。たとえば、Windows® の新しいターミナル サービス クライアントでは、ユーザー名とパスワードを保存して、ユーザーがターミナル サービスのログオン操作を意識しないようにすることができます。このような資格情報は、Credential Manager API (資格情報マネージャの API) を使用して保存され、最初のログオン セッションで使用される資格情報によって保護されています。
このような構成により、セキュリティの依存関係が生じます。ネットワーク管理者が自分のワークステーションにログオンしている場合について考えてみましょう。この管理者は、このワークステーションを使用して、電子メールやインターネットを閲覧したり、インフォメーション ワーカーが抱えている一般的な作業をしたりしています。もちろん、この用途には、権限の低いアカウントを使用しています。
1 日のうちのある時点で、彼女は DC の 1 つに接続して管理作業を行います。この作業には、ターミナル サービス クライアントを使用し、今後、簡単に接続できるようにパスワードを保存するようにしています。この構成により、少なくとも 1 つ、場合によっては 2 つの許容されないセキュリティの依存関係が生じます。1 つ目はドメイン管理者アカウントの資格情報が、権限の低いインフォメーション ワーカーの資格情報で保護されているということです。この権限の低いユーザー アカウントが危険にさらされると、ドメインの管理権限を持つユーザー アカウントも危険にさらされることになり、ドメイン全体に危害が加えられることになります。
2 つ目の依存関係は、ドメイン コントローラではないコンピュータでドメイン管理者の資格情報を入力したことにより生じます。管理者個人が使用しているワークステーションが、(おそらく、そのようなことはないでしょうが) 少なくとも DC と同レベルで保護されている場合を除き、DC のセキュリティが、ワークステーションのセキュリティに依存するという依存関係が生じます。たとえば、職場で不満を抱いている従業員がネットワーク管理者のワークステーションにキーストローク ロガーをインストールすると、ドメイン管理者の資格情報が取得されてしまいます。ドメイン コントローラではないコンピュータでドメイン管理者の資格情報を入力すると、ドメイン全体が、ドメイン コントローラではないコンピュータのセキュリティ上の欠陥にさらされることになります。
ドメイン管理者が、現在ログオンしている、ログオンしたことがある、またはログオンするであろうコンピュータに、攻撃者がリムーバブル ドライブを接続したとします。そのドメイン管理者は危険にさらされ、その結果、ドメイン全体も危険にさらされることになります。このような状況を回避するには、この状況を理解することが必要不可欠です。もちろん、ある特定のタスクを実行するために、安全性の高いアプリケーションが、安全性の低いアプリケーションの機能に依存する場合、ソフトウェアでも同じ事態が起こり得ます。

攻撃を分析する
悪意のあるリムーバブル ドライブをコンピュータに接続すると、どのようなことが起こるのかについては既に説明しました。ただし、何が起こるかが明確なのは、このようなリムーバブル ドライブが接続されたコンピュータについてだけだと思うので、その後の影響についても説明しましょう。では、図 1 に示すように、問題のコンピュータがドメインに参加しているとします。
図 1 理想的なドメインの依存関係
図 1 理想的なドメインの依存関係
この図は理想的な依存関係を表しています。矢印は依存関係の方向を表し、依存関係の継承元を指し示しています。たとえば、ワークステーションのセキュリティは DC のセキュリティに依存し、ユーザーのセキュリティはワークステーションのセキュリティに依存しています。攻撃者はワークステーションに侵入して、ユーザーがワークステーションに格納している情報を危険にさらすことはできるかもしれませんが、侵入はそこで食い止められます。
しかし、ワークステーションにログオンしたユーザーが、サーバーのローカルの Administrators グループのメンバである場合はどうでしょうか。また、このドメイン管理者が、サーバーに頻繁にログオンするとしましょう。この場合の依存関係は、図 2 のようになります。
図 2 危険にさらされるドメインの依存関係
図 2 危険にさらされるドメインの依存関係
問題のコンピュータにログオンした人が変わるだけで、ネットワーク全体のセキュリティが危険にさらされてしまいます。ドメイン管理者は、サーバーにログオンするので、DC とドメイン全体のセキュリティは、そのサーバーのセキュリティに依存します。
サーバーで DC と同レベルのセキュリティが確保されていれば、これは許容される依存関係です。ただし、この場合、ワークステーションにログオンしたユーザーは、サーバーの Administrators グループのメンバなので、サーバーのセキュリティはワークステーションのセキュリティに依存します。つまり、ドメイン全体のセキュリティがワークステーションのセキュリティに依存するということになります。そして、このワークステーションで、攻撃者が用意したツールをユーザーが間違って実行してしまったら、どうなるでしょうか。
今日の情報セキュリティにおいて、セキュリティの依存関係を把握することよりも重要な概念は、ほとんどないと言えるでしょう。ネットワークの分析を始めて依存関係を把握しようとすれば、ほぼ間違いなく、許容されない依存関係に遭遇するでしょう。最悪のシナリオは、皆さんが考えるよりもありふれているものですが、ネットワーク全体のセキュリティがネットワーク全体に依存している場合です。つまり、個々のコンピュータのセキュリティがなんらかの方法で他のすべてのコンピュータのセキュリティに依存しているという場合です。このような環境では、依存関係を制御できず、その複雑さは理解し難いので、どのような種類の現実的で理にかなったリスク管理戦略も立てることはできません。この場合の解決策は、依存関係を分析して管理することです。
今月の記事では、依存関係の概略と、依存関係を分析して軽減する方法について簡単に説明しました。詳細については、私の著書『Windows Server 2008 Security Resource Kit』をご覧いただければ、と思います。この本には、管理者アカウントの管理などのありふれた手法だけでなく、サーバーとドメインの分離などの高度な技術を併用し、依存関係を分析および軽減することによるネットワークの保護に関するトピックに特化した章があります。
このコラムの基になった荒削りのアイデアを形作るのに協力してくれた David LeBlanc 氏に感謝します。

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


 デスクトップ ファイル: Windows XP と Windows PE 2.0 によるデュアル ブート
デスクトップ ファイル
Windows XP と Windows PE 2.0 によるデュアル ブート
Wes Miller
この記事で使用しているコードのダウンロード: Desktop2008_02.exe (151KB)

「デスクトップ ファイル」の以前の記事で、Windows PE を回復ツールとして使用できるようになったことについて説明し、それを 2 つ目のパーティションから使用する方法を示しました。最近あった問い合わせから、このことについて新たな説明を加える価値があると思い、Windows PE 2.0 と Windows XP を共に使用するという新しい方法について説明することにしました。
というのも、皆さんの多くは、しばらく前から Windows® XP を使用しているでしょうし、Windows PE 2.0 は、マイクロソフトが開発を推し進めているバージョンです (Windows PE 1.x は、今後更新の予定がないことに注意してください)。
Windows PE 1.x と Windows PE 2.x の重要な違いの 1 つは、Windows PE 2.x は、標準のブート インターフェイスを使用してブートできる点です (これに対して Windows PE 1.x では特殊な方法を使用する必要があります)。Windows PE 1.x と 2.x は、2 つ目のパーティションからブートできます。しかし、オペレーティング システムがインストールされているパーティションと同じブート パーティションでブートするという便利な方法を使用することで、多くのメリットがもたらされます。まず、このメリットについて説明します。

Windows の 2 種類のブート方法
Windows NT® では、デュアル ブートに対して比較的高い安定性が確保されていました。しかし、拡張ファームウェア インターフェイス (EFI) ベースのコンピュータが、従来の IBM の PC/AT BIOS に取って代わられ始めるにつれて、マイクロソフトでは、EFI とより適切に動作するように、またすべてのアーキテクチャで 1 つのブート メカニズムを使用できるように、Windows ブート メカニズムを変更しています。Windows Vista® で導入された Windows の新しいブート メカニズムは、ブート構成データベース (BCD) と呼ばれます (詳細については、microsoft.com/whdc/system/platform/firmware/bcd.mspx を参照してください)。ただし、従来の boot.ini であろうと新しい BCD メカニズムであろうと、Windows では、ブート プロセスが別のブート ローダーに移管することになっても、一般に別のオペレーティング システムをブートできます。
詳しい説明をする前に、注意事項があります。Windows PE 2.0 は、Advanced Configuration and Power Interface (ACPI) に完全に準拠し、384 MB (理想的には 512 MB) の RAM が搭載されているシステムでしか動作しません。5 月号の記事 (technetmagazine.com/issues/2007/05/DesktopFiles) で説明したように、ACPI に準拠していないシステムでは、Windows PE 2.0 をブートできません。また、Windows PE 2.0 は、RAMDisk からブートされる必要があるため、RAMDisk、スクラッチ領域、およびすべての RAM ワーキング セットを保持するのに十分な RAM が必要になります。システムに 384 MB 未満の RAM しか搭載されていない場合は、この方法は使用せずに、Windows PE 1.6 を使用してください。Windows PE のサイズを縮小することに長けている場合でも、256 MB の RAM しかないシステムで動作させることはできません。

解決できる問題
では、Windows PE 2.0 を Windows XP と同じパーティションからブートすることで、解決できる可能性がある問題について見てみましょう。
完全なシステム回復 - これは、Windows PE を Windows XP と同じパーティションから直接ブートすることで実行できるようになったタスクの 1 つです。Windows PE 2.0 (その前は Windows PE 1.6) は、完全に RAMDisk からブートできるため、ディスク全体のイメージを再作成できます。また、パーティション全体のイメージを再作成する必要がないため、ImageX を使用して Windows XP ファイルを自体で復元できます。
ユーザーがスタートアップ時に Windows PE をブートできるようにすることで、リモートで作業している場合でも、各自のシステムを回復できます。イメージは、2 つ目のパーティション、ネットワーク共有 (モバイル ユーザーがいない場合)、回復用の DVD、または USB ハード ディスクから展開できます。また、ImageX を使用している場合には、回復を実行しているパーティションにイメージを保存することもできます。このようなオンディスクの回復は、多くの問題にとって優れたソリューションです (ただし、ディスクの物理的な破損は除きます)。ユーザー データの復元に関しては、そもそもそのデータが保護されていて、回復処理の一環として復元されない限り、この方法が適していないことは明らかです。ユーザー データの損失を回避するには、移動プロファイルを使用し、PC のデータをバックアップする必要があることに注意してください。また、使用する回復メカニズムにより、データ損失の可能性を抑えられるかどうかを確認する必要もあります (データの損失には、EFS 暗号化キーの再設定によるものも含みます)。
ファイルの回復 - Windows PE では、最初にインストールされた Windows がブートされない場合でも、システムを稼働して維持するためのメカニズムも提供されます。その場合、ユーザーがすぐに作業を再開できるように、ブートとユーザー データの回復は、別のシステム (ユーザーが使用できるバックアップ システムが稼働中の場合) または別の場所で実行されます。
システムの修復 - Windows XP で Windows PE をブートすることで、トラブルシューティング用の一連のスクリプトを実行するか、ユーザーによる操作を必要とする簡単な修復アプリケーションや回復アプリケーションを実行して、システムを修復することができます。このプロセスは、完全なシステム回復のプロセスと似ていますが、範囲がより絞り込まれています (そのため、ユーザー データ破損のリスクがありません)。
Windows PE を Windows XP と同じパーティションでブートする場合のメリットについて理解できたところで、次に、目的のソリューションにプロセスを適用できるよう、その詳細について見てみましょう。

Windows Vista の登場以前
まず、Windows Vista の登場以前、BIOS およびマスタ ブート レコード (MBR) ベースのシステムのブート方法を説明しましょう。BIOS が、ブート デバイスを指定していました (ハード ディスクの場合は、ディスクの MBR を指定します)。MBR が、ブートするパーティションを指定するコードを実行します。ブートされるパーティションは、アクティブ フラグが設定された最初のパーティションであることに注意してください。初期の DiskPart では、パーティションを非アクティブにすることができませんでした (つまり、アクティブ フラグを削除できませんでした)。この制限を修正するため、DiskPart にはスイッチが追加されました。スイッチを使用しない場合、アクティブ フラグが設定されるのは、パーティション テーブルの順序の最初のパーティションになります。パーティションには、次に実行するコードを指定するブート セクタが含まれます。Windows NT から Windows Server® 2003 までの環境では、実行するコードは、ntldr という名前のファイル (ファイル拡張子なし) にあります。ディスクをフォーマットし、Windows をインストールしていない状態でブートしようとすると、"NTLDR not found" というエラー メッセージが表示されます。
興味深いことに、ntldr には、完全な下位互換性があります。そして、当然のことですが上位互換性はありません。つまり、Windows XP の ntldr では Windows 2000 をブートできますが、その逆はできないということです。そのため、デュアル ブートの構成にする場合は、必ず最も古いオペレーティング システムを最初にインストールすることが重要です。ntldr にはバージョン番号が付けられていないため、この順番を変更しないことがより重要となります。
ntldr は、NTDetect.com を実行するリアル モード (16 ビット) アプリケーションです。NTDetect.com により、基本的なデバイス検証が実行され、カーネル ntoskrnl.exe が実行されます (ntoskrnl.exe は、複数ファイルの 1 つである場合がありますが、必ず ntoskrnl.exe という名前に変更されます)。カーネルは、Windows ブート プロセスの重要なコンポーネントです。
ここで説明したブート プロセスの概要は、いくらか単純化しています。Win32® の初期化についてはすべて省略しましたが、ここでの説明には関係がないので問題ありません。詳細については、Mark Russinovich と David Solomon 共著の『Windows Internals, Fourth Edition』(Microsoft Press®、2004 年) を参照することをお勧めします。
もう 1 つ注目すべき点は、CD からブートするとき、Windows セットアップと Windows PE では、ntldr ではなく setupldr.bin が実行されることです。実は、このファイルには、若干異なるブート コードが含まれています。そのため、ntldr ではできない CD からのブートが可能になります。Windows PE 1.x をブートするために、setupldr.bin の名前を ntldr に変更してディスクに配置するのは、このことが理由です。また、このファイルがその後 boot.ini ファイルを読み込めない理由も同様です (setupldr.bin は CD ブート専用にデザインされていて、boot.ini は必要ないとされているからです)。

Windows Vista 以降
Windows Vista では、このプロセスの多くの部分が変更されました。Windows Server 2008 では、このプロセスがさらに変更され、(Itanium ベースではないシステムでは使用できなかった) EFI からのブートで IA32 (32 ビットのサポート) が使用されます。BIOS ベースのシステムに関しては、ブート プロセスの初期手順の大部分は変更されていません。主な変更点は、BOOTMGR が、初期化されるブート ローダーで、次の手順を実行する点です。
BOOTMGR は、ブート ディレクトリで BCD ファイルを検索します。検索する場所は、実質的には BOOTMGR 自体のレジストリ ハイブです。BCD には、ブートするブート エントリ (既定のエントリを含む) が含まれます。イメージの種類 (実行可能なファイルの種類) については 図 1 を、実行する具体的なアプリケーションの種類については 図 2 を参照してください。これらのエントリの 1 つ (または複数) は、ntldr を参照できます。これらのうち 1 つだけが、ntldr の読み込みに使用される既知の GUID を実際に参照できます (図 3 の 5 行目参照)。BOOTMGR は、その後、次に読み込むエントリを判断します。それは、システムがブート中か、休止状態か、ntldr または別のブート マネージャからブートしているか (この場合、別のブート セクタを参照してそのローダーを使用します) によって異なります。これは、Windows 以外のオペレーティング システムとデュアル ブートしている場合に最も一般的です。詳細については、microsoft.com/whdc/system/platform/firmware/bcd.mspx を参照してください。
Figure 3 標準のアプリケーション オブジェクト (Close Figure 3)

説明 | BCDEdit の ID | GUID
Windows ブート マネージャ | {bootmgr} | 9dea862c-5cdd-4e70-acc1-f32b344d4795
ファームウェアのブート マネージャ | {fwbootmgr} | a5a30fa2-3d06-4e9f-b5f4-a01df9d1fcba
Windows メモリ テスタ | {memdiag} | b2721d73-1db4-4c62-bf78-c548a880142d
Windows の再開アプリケーション | エイリアスなし | 147aa509-0358-4473-b83b-d950dda00615
従来の Windows ローダー | {ntldr} | 466f5a88-0af2-4f76-9038-095b170dc21c
現在のブート エントリ | {current} | fa926493-6f1c-4193-a414-58f0b2456d1e
既定のブート エントリ | {default} | 定義済み GUID なし
Figure 2 アプリケーションの種類 (Close Figure 2)

アプリケーション | 値 | 説明
ファームウェアのブート マネージャ | 0x1 | EFI システムにのみ適用されます。
Windows ブート マネージャ | 0x2 | ブート フローを制御します。デュアル ブート システムでは、ユーザーにブート選択のメニューを表示します。
Windows ブート ローダー | 0x3 | 特定のバージョンまたは構成の Windows を読み込みます。
Windows の再開アプリケーション | 0x4 | コンピュータが休止状態から再開したときに、Windows を実行状態に復元します。
Windows メモリ テスタ | 0x5 | メモリの診断アプリケーションです。
Ntldr | 0x6 | PC/AT BIOS のシステムにのみ適用されます。Windows Vista 以前のバージョンの Windows を読み込みます。
ブート セクタ | 0x8 | 16 ビットのリアル モード アプリケーションです。PC/AT BIOS のシステムにのみ適用されます。ブート プロセスの再開と、Windows 以外のオペレーティング システムの読み込みに使用できます。
Figure 1 イメージの種類 (Close Figure 1)

説明 | 値
ファームウェア アプリケーション | 0x1
ブート アプリケーション | 0x2
Ntldr ベースのローダー オブジェクト | 0x3
リアル モード アプリケーション | 0x4
Windows Vista で改良されたブート インフラストラクチャは、以前のバージョンよりもはるかにまとまっていることがわかります。BOOTMGR を除き、ブート コードは、ルート レベルの \BOOT ディレクトリに存在し、BCD の指定に応じて Windows 固有のバイナリに渡されます。

Windows XP と Windows PE 2.0 のブート
ここまで読み進めれば、Windows PE が Windows Vista のブート マネージャを使用して仲介役としてどのような役割を果たしているのか、おわかりになり始めたでしょう。この役割により、統合された回復ツールに Windows PE 2.0 を追加しながら、Windows XP またはそれ以前のバージョンの Windows も引き続きブートすることが可能になります。
もちろん、ブート プロセスに別の手順を追加することになりますが、それはマイクロソフトによってデザインされた手順です。新しい BOOTMGR のインフラストラクチャは、既存の ntldr と他のサードパーティ製ブート マネージャとの下位互換性を維持する必要があることが認識されていたため、BOOTMGR は、そうしたソリューションをサポートするように意図的に構築されています。
Windows のブート方法と新しい BCD の動作方法がわかったところで、この 2 つを組み合わせて、Windows PE 2.0 を既存の Windows XP で使用するにはどうするのでしょうか。Windows Vista のブート セクタ (システムに BOOTMGR の起動を指示するブート コード) を変更するには、2 つの方法があります。その 1 つは、DiskPart を使用して、Windows PE 2.0 で新しいパーティションの作成とフォーマットを実行する方法です。ただし、既存の Windows XP の破損や移動を回避するため、ここでは使用しません。代わりに、次のプロセスを使用してください。
  1. Windows PE 2.0 のブート CD に、bootsect.exe と bcdedit.exe のコピーがあることを確認します (いずれも Windows Vista のインストール DVD にあります)。
  2. Windows XP システムを、Windows PE 2.0 の CD からブートします。
  3. ブートしたら、次のコマンドを実行します。
    bootsect.exe /NT60 ALL
このコマンドにより、ブート セクタが、BOOTMGR の起動方法を認識する Windows Vista 対応のブート セクタとして設定されます。
4. ブート マネージャをハード ディスクにコピーします。
    xcopy BOOTMGR C:\BOOTMGR /I
5. BOOT.SDI ファイルを、ハード ディスクの \BOOT ディレクトリにコピーします。このファイルは、Windows PE の実行中にはロックされてコピーできないため、ブート前にコピーする必要があります。
    xcopy BOOT.SDI C:\BOOT\
必要に応じてソース パスを修正します。
6. BOOT.WIM を、ハード ディスクにコピーします。.SDI と同様、セカンダリ コピーが必要です。次のコマンドでは、実行中のファイルのコピーは作成できません。
    xcopy BOOT.WIM C:\BOOT\BOOT.WIM
必要に応じてソース パスを修正します。
7. 次に、新しい BCD ストアを作成します。
    bcdedit /createstore
8. 続いて、Windows PE を読み込むための BCD エントリを作成します。
    bcdedit /create {ramdiskoptions} /d
    "Boot Windows PE"
    bcdedit /set {ramdiskoptions}
    ramdisksdidevice partition=c:
    bcdedit /set {ramdiskoptions}
    ramdisksdipath \boot\boot.sdi
    bcdedit /create /d "Windows PE" /
    application
    OSLOADER
9. 最終行によって、GUID が返されます。{YOURGUID} を、返された実際の GUID に置き換えます。図 4 に示すように、これらはハード ディスクから Windows PE をブートする RAMDisk のエントリです。
Figure 4 ハード ディスクから Windows PE をブートする RAMDisk のエントリ (Close Figure 4)
bcdedit /set {YOURGUID} device ramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} path \windows\system32\winload.exe
bcdedit /{YOURGUID} osdeviceramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} systemroot \windows
bcdedit /set{YOURGUID} winpe yes
bcdedit /set {YOURGUID} detecthal yes
10. 次に、ブート マネージャが起動されるように、BOOTMGR のエントリを作成します。
    bcdedit /create {bootmgr} /d
    "Boot Manager"
    bcdedit /set {bootmgr} device boot
11. 最後に、既存の Windows 用の BCD エントリを設定します (表示テキストは Windows XP ではなく、ブート マネージャのブート メニューに表示する任意のテキストに変更します)。また、最後のコマンドでは、このエントリが、ブート メニューの最初の (既定の) エントリとして設定されます。
    bcdedit /create {ntldr} /d "Windows XP"
    bcdedit /set {ntldr} device partition=C:
    bcdedit /set {ntldr} path \ntldr
    bcdedit /displayorder {ntldr} /addfirst
12. これで、システムを再起動して、ブート メニューの適切なエントリを選択することで、既存の Windows または Windows PE 2.0 のいずれかを起動できるようになります。図 5 は、bcdedit /enum all を実行した場合の出力の一例です。このコマンドは、エントリを追加した後の BCD のエントリをすべて一覧表示します (これは Windows PE 1.6 内から実行できます)。
出力例
私は、このタスクを自動的に実行できるスクリプトの作成に取り組んできました。現時点では、ハード ディスクへのブート ファイルのコピーと、BCD エントリの設定のみ実行できます。Windows の実行中に、ブート セクタを新しい Windows Server 2008 対応のブート セクタとして設定することはできません。その作業は、Windows PE 環境を使用してオフラインで実行する必要があります。このスクリプトは、TechNet Magazine Web サイト (technetmagazine.com) のコード ダウンロード セクションで提供しています。このスクリプトを実行するには、次のものが、実行する VBScript と同じディレクトリにある必要があります。
  1. BCDEdit
  2. BOOTMGR
  3. \BOOT\ ディレクトリ (Windows Vista または Windows PE 2.0 メディアからコピーすること)
  4. \SOURCES\ ディレクトリ(有効かつブート可能な Windows PE 2.0 の BOOT.WIM ファイルを含む)
これにより、BCD が作成され、適切なブート ファイルがコピーされます。Windows PE のブートおよび bootsect の実行後、デュアル ブートできるようになります。

デュアル ブートを元に戻す
デュアル ブートを元に戻すことは、構成するよりも簡単です。必要な作業は、次のコマンドを実行して、ブート セクタを、Windows Vista 以前のブート セクタに復元するだけです。
bootsect.exe /NT52 ALL
復元したら、BOOTMGR と \BOOT ディレクトリを削除できます。次回の再起動時に、ブート セクタでは ntldr が実行され、Windows PE 2.0 と Windows Vista のすべてのブート バイナリがブート フローから完全に削除されます。

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


 フィールド ノート: PC を寄付する
フィールド ノート
PC を寄付する
Jim Lynch

一般的に コンピュータを廃棄するのに最もコスト効率が良い方法は、2003 年に The Gartner Group の Frances O'Brien が執筆した調査報告書「PC の 廃棄 : TCO の実態」にまとめられているとされています。この PC の廃棄に関して比較分析を行った調査では、コンピュータを廃棄する方法として 6 つの方法が挙げられていますが、コンピュータ機器を寄付することが最もお金のかかる廃棄方法だとされています。その理由は、コンピュータを寄付として受け付けている適切な慈善団体を見つけるのに時間がかかるというものでした。
寄付に関するヒント
TechSoup.org では、寄付する場合と寄付を受ける場合に関する他のヒントも紹介しています。詳細については、techsoup.org/recycle を参照してください。寄付する場合に考慮する必要があることには、次のようなものがあります。
  • 新しいハードウェアにアップグレードしたら以前の IT 機器は手放しましょう。コンピュータ機器を再利用する価値があるのは 5 年間と言われています。また、一般的に、携帯電話の寿命は 3 年間と言われています。
  • 購入してから 5 年未満の IT 機器は慈善団体や学校に直接寄付するのではなく再利用業者に寄付しましょう。
  • キーボード、マウス、プリンタ、モデム、ソフトウェア ディスク、マニュアルなど、コンピュータ機器の付属品も併せて提供しましょう。
  • ご自身の記録として寄付したもののメモを残し、受領書を発行してもらいましょう。非営利の再利用業者にコンピュータ機器を寄付すると税額控除の対象となります。米国では、法人として寄付した場合はコンピュータの原価未償却分に相当する金額の控除を、個人として寄付した場合はコンピュータの現在の市場価格に相当する金額の控除を受けられます。コンピュータの適正市場価格については、「Used Computer Evaluator」(servlets.edeal.com/servlets/PcEval) を参照してください。

現在、まったく別の事態が発生しています。たとえば、最近、米国の EPA では「Do the PC Thing」という推進事業を展開し、古くなったハードウェアを再利用する際に必要な情報とリソースの一覧を提供しています。これは、EPA が電子機器のリサイクルと再利用に関する国民意識を高めるためのサイトとして公開している「Plug-In To eCycling」(epa.gov/plugin/) の一環として行っているものです。Reuse It! というリンクをクリックして、一般消費者向けの記事または法人向けの記事をご覧ください。
このサイトでは、ハードウェアを寄付またはリサイクルする際の最重要事項は、自衛であることが説明されています。「Do The PC Thing」推進事業では、ハード ドライブのデータ消去、データのセキュリティと機密性に関する法的必要条件に関する基本方針について説明しています。耐久年数を経たリサイクルと再利用のどちらの目的でコンピュータを廃棄する場合も、パスワード、ドキュメント、クレジット カード情報、電子メール メッセージ、Web ページのログなどの機密情報は削除する必要があります。
多くの電子機器のリサイクル業者、再利用業者、資産管理企業では、ハード ドライブを廃棄するか、データを上書きして元のデータを復元できないようにするディスク クリーニング ソフトウェア ユーティリティを使用することで、データのセキュリティを確保するサービスを提供しています。再利用するコンピュータのハードウェアの構成は変更しないのが望ましい状態です。
信頼性の高いディスク クリーニング ソフトウェアは、米国の国防総省が規定した仕様 5220.22-M が採用されているものです。このようなソフトウェアを使用したデータ消去では、ハード ドライブ上のアドレス指定可能な全領域に対して体系的に文字を上書きし、上書き処理を承認します。その後、ランダムな文字を使用してアドレス指定可能な全領域にデータを再度上書きします。2004 年に、米国の国家安全保障局 (NSA Advisory LAA-006-2004) は、国防総省が規定した仕様に準拠したソフトウェアを使用してデータを 1 回上書きすれば、電子ファイルが復元できない状態になることを突き止めました。
自分自身でデータを処理することは簡単になりました。無料で使用できるソフトウェアで定評のあるものには、Active@ Kill Disk Hard Drive Eraser (killdisk.com/eraser.htm)、Darik's Boot and Nuke (dban.sourceforge.net) などがあります。複数のコンピュータのデータを消去する必要がある場合は、Blancco Data Cleaner (blancco.com) や WipeDrive (whitecanyon.com) などのより堅牢な商用アプリケーションの使用を検討することをお勧めします。
使用している IT 機器が購入してから 5 年以上経過していたり、損傷がひどい場合、Gartner の調査結果に記載されている 6 つの廃棄方法のうち適切なのは、耐久年数を経たリサイクルです。米国では、900 社以上もの企業がコンピュータを廃棄するサービスを提供しています。古くなった IT 機器を適切にリサイクルするには、Electronic TakeBack Coalition (www.computertakeback.com/the_solutions/recyclers_map.cfm) に掲載されている信頼できるリサイクル業者の一覧を参照してください。

Jim Lynch は TechSoup.org でコンピュータのリサイクルと再利用についてのプログラム ディレクタをしています。TechSoup はサンフランシスコに拠点を置くハイテク関連の非営利組織で、世界各国の慈善団体を対象にハードウェア、ソフトウェア、ノウハウをとても安く供給することを使命としています。


 Windows 秘話: 不要になった機能を廃止する
Windows 秘話
不要になった機能を廃止する
Raymond Chen

頻繁にではありませんが 、製品チームからの多大なる賞賛を受けて古い機能が廃止されることがあります。たとえば、Windows® XP では、デスクトップ パターンを設定するインターフェイスが廃止されました。基になる機能自体は存在するので、SystemParametersInfo(SPI_SETDESKPATTERN) を呼び出すプログラムを記述できれば、この機能を引き続き使用することは可能ですが、組み込みのインターフェイスはありません。コントロール パネルからデスクトップ パターンが削除されたのはなぜでしょうか。
調査を行ったところ、デスクトップ パターンを使用しているユーザーがほとんどいないということがわかりました。メモリが現在よりも高価で、ユーザーが 1 MB の壁紙のビットマップを使用することでコンピュータ メモリの 1/4 を無駄に消費するようなことはしたくないと考えていたころは、デスクトップ パターンは今より需要がありました。当時は、非常に小さな 8 × 8 サイズのモノクロ パターンを画面に繰り返し表示することで、コストを大幅に抑えながら、640 × 480 の解像度のディスプレイをある程度カスタマイズすることができました。
しかし、ここ数年の変化により、デスクトップ パターンは、徐々に魅力を失いました。その変化の 1 つは、言うまでもなく、コンピュータに搭載されているメモリの容量が 1983 年当時よりも大きくなったことです。もう 1 つは、(これも当然のことですが) モニタの解像度が 1983 年当時よりも高くなったことです。小さな 8 × 8 サイズの千鳥格子パターンは、1600 × 1200 の解像度のモニタで表示すると、灰色の汚れのように見えます。
お払い箱になった機能はこれだけではありません。もう 1 つの廃止された機能はスクラップです。Windows 95 で導入されたスクラップは、ファイルにキャプチャされるドキュメントの断片のようなもので、このファイルの断片の実体は OLE オブジェクトです。たとえば、ワード プロセッサで選択したテキストをデスクトップにドラッグすると、スクラップが作成され、その後、ワード プロセッサや他のプログラムにそのスクラップをドラッグして、スクラップの作成に使用したテキストを新しいドキュメントに挿入できるようにする機能として開発されました。この機能は、クリップボードに一時的にデータを格納するのではなく、ファイルにデータを保存するという点以外は、コピーと貼り付けの操作に似ています。
このようなスクラップ ファイルを作成しても、このファイルに対して行える操作は、別のドキュメントにドロップすることだけでした。これは、クリップボードの内容に対して行える操作が、どこか別の場所に貼り付けることだけであるのと同様です。ある時点で、スクラップ ファイルをダブルクリックすると、そのスクラップ ファイルの作成に使用されたアプリケーションで開かれる機能が追加されました (スクラップ ファイルの内容は何でもかまわなかったので、スクラップを表示するには、そのスクラップの作成に使用されたプログラムを使用する必要がありました)。
この機能は、デバッグ ツールとして追加されたのか、ユーザーがスクラップをドロップするダミー ドキュメントを作成しなくてもスクラップの内容を確認できるようにするために追加されたのかは定かではありません。理由はなんであれ、この "最初にスクラップを作成したアプリケーションを開く" という機能はウイルス作成者にとって好ましいものでした。というのも、彼らはスクラップ ファイルを作成し、そのファイルに作成元のアプリケーションが cmd.exe で、ドキュメントの断片がバッチ ファイルであることを指定するデータを格納できたからです。ユーザーがファイルの内容を確認するために、このようなウイルス作成者が作成したスクラップ ファイルをダブルクリックすると、スクラップ ビューアによってコマンド プロセッサにバッチ ファイルが渡され、バッチ ファイルを開いてユーザーに表示するように指示されました。
シェル チームは、スクラップの歴史を考慮して、Windows Vista® でこの機能を廃止することにしました。そのためには、スクラップの需要を調査する必要がありました。そして、スクラップについての問い合わせ件数を特定するために、製品サポート グループが所有する記録を集めてもらうように依頼しました。これは、需要の高い機能はサポートへの問い合わせも多く、需要の低い機能は (だれも使用していないので) 問い合わせも少ないという論理に基づいて行った調査です。特に、スクラップは単純明快な機能というわけではないので、サポートへの問い合わせの件数が少ないからといって、「この機能はとてもわかりやすいので、サポートに問い合わせる必要がない」という言い逃れはできません。
製品サポート グループからの回答は次のようなものでした。過去 1 年の問い合わせ件数は合計で 4 件で、そのすべてが「おかしなファイルを作成してしまったので、これがどういうファイルで、このようなファイルが作成されないようにする方法を教えてほしい」という内容だったそうです。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍 (Addison-Wesley、2007 年) で、Windows の歴史と Win32 プログラミングについて扱っています。前回の記事を執筆してから随分時間がたっており、皆さんが元気にしているかどうか気になっています。