7 月号 2008 7 月号 2008
IIS: IIS 7.0 での運用を開始する
インターネット インフォメーション サービス 7.0 のリリースによって、新しい標準が設定され、基盤が強化されると同時に、Web 環境を統合するための新機能が導入されます。この記事では、最も重要な機能強化を紹介し、Web アプリケーションを IIS 7.0 に移行するためのテスト、ステージング、および本番の作業について詳しく説明します。 Fergus Strachan
コミュニケーションとコラボレーション: ユニファイド メッセージングへの移行を計画する
従来のボイスメール システムからユニファイド メッセージング プラットフォームに移行する作業は非常に簡単であり、適切な計画を立てれば、エンド ユーザーの作業をほとんど中断することなく作業を完了できます。この記事では、組織で移行を計画し、新しいシステムをテストし、ユニファイド メッセージングを実装するために必要な情報を提供します。 Jeff Goodwin
コミュニケーションとコラボレーション: 音声が OCS 2007 にもたらす力
Microsoft Office Communication Server によって、企業のテレフォニーに重要な変化がもたらされます。この記事では、音声通話を構成する各層のしくみ、通話がさまざまなエンドポイントにルーティングされる処理のしくみ、および OCS 通信における会話の重要性について説明します。 Rajesh Ramanathan
コミュニケーションとコラボレーション: Groove と SharePoint で強いつながりを作る
Microsoft Office Groove と SharePoint Server は、両方とも強力なコラボレーション機能を提供します。2 つの製品の違いと相補性を示し、Groove と SharePoint の統合により異なる場所にいるユーザーをサポートする容易で柔軟性のあるコラボレーション ソリューションが提供されることを説明します。 Alan Maddison
Windows の管理: Windows Server 2008 フェールオーバー クラスタリングの概要
Windows Server のクラスタリング作業は複雑過ぎるという苦情がユーザーから長年にわたって寄せられていました。Windows Server 2008 のリリースによって、クラスタリングは全面的に改良されました。この記事では、新しいフェールオーバー クラスタリングで行われたいくつかの重要な改良点を検証し、新しいクラスタリングの実装によってクラスタのセットアップと保守が大幅に簡素化されたことを確認します。 Chuck Timon
Columns
編集長から: 印刷物の消滅: | レター: 読者の皆さんからの声: | ツールボックス: IT プロフェッショナル向けの新製品:
Exchange Queue & A: 負荷分散、エッジ トランスポートなど: Exchange について何か疑問に思っていることはありますか。今月の記事では、Exchange と SharePoint の併用、スタンバイ連続レプリケーションを使用した作業、Windows Server 2008 への Exchange 2007 メールボックス サーバーのインストールなどに関する質問に回答します。Henrik Walther | ユーティリティ スポットライト: Microsoft SharedView: 別の街にいるだれかと手軽にコラボレートする方法をお探しですか? それなら無償のユーティリティ Microsoft SharedView をお試しください。小グループのメンバ間で、離れた場所にいてもドキュメントとデスクトップを簡単に共有できます。Greg Steen | SHAREPOINT の内部: Office アプリケーションを統合する: このコラムでは、Microsoft Office アプリケーションが SharePoint とどのように統合され、どのようにして両者間の通信が行われるか、およびこの原則に基づいて、サードパーティ製のアプリケーションをどのようにして SharePoint と統合できるかについて説明します。Pav Cherny
Windows PowerShell: ドロップ ボックス: Don Jones がフィルタ処理関数、パイプライン、カスタム オブジェクト、そしてピンポン球を使用して Windows PowerShell を理解する方法について説明します。Don Jones | Hey, Scripting Guy!: アドレナリンの大量分泌: Scripting Guys が、アドレナリンが大量分泌されること間違いなしのスクリプトについて説明し、Windows Vista と Windows Server 2008 で新しく導入されたブート構成データ ストアにスクリプトからアクセスする方法を紹介します。Microsoft Scripting Guys | デスクトップ ファイル: Windows のネットワーク ブートを実行する: この記事では、リモート インストール サービス (RIS) の歴史と、マイクロソフトで使用されているその他の PXE 関連のテクノロジについて詳しく説明します。Wes Miller
セキュリティ ウォッチ: パスワードとクレジット カード、第 1 部: 3 回シリーズの 1 回目は、一般に知られているセキュリティ関連のアドバイスや習慣が時代遅れで、実は、セキュリティ向上の妨げになっている事実について解説します。Jesper M. Johansson | フィールド ノート: Ensure Election Accuracy: 現在米国で使用されている選挙システムの脆弱性と、暗号化を使用して完全に検証可能な選挙結果を作成する方法について説明します。Josh Benaloh | Windows 秘話: 歴史が空き領域を埋める: Microsoft Bob は、皆さんが思っているよりもはるかに普及しています。この記事では、Microsoft Bob がどのようにして何百万もの家庭に配布されたかについて、Raymond Chen が説明します。Raymond Chen


IIS
IIS 7.0 での運用を開始する
Fergus Strachan
概要 :
  • Web ファーム環境で IIS 7.0 を展開する
  • セキュリティとパフォーマンスの向上
  • ASP.NET Web アプリケーションを IIS 6.0 から IIS 7.0 に移行する
  • PHP Web アプリケーションを IIS 7.0 に移行する

目次
まずはテストから
テスト環境を構築する
IT 管理者にとって重要な機能強化
IIS のアーキテクチャ
統合モードとクラシック モード
モジュールと機能
Web アプリケーションを移行する
まとめ
マイクロソフトの IIS チームは、インターネット インフォメーション サービス (IIS) 7.0 は IIS 史上最大のリリースだと述べています。このバージョンによって、新しい標準が設定され、基盤が強化されると同時に、
Web 環境を統合するための新機能が導入されます。IIS 7.0 は Windows Server® 2008 と Windows Vista® SP1 に付属しており、既に Microsoft.com の運用に使用されています。また、いくつかの Web ホスティング企業は、既存の Web アプリケーションを新しい Web サーバー プラットフォームに移植する必要がある Web デザイナや開発者向けに、IIS 7.0 を使用したホスティングの提供を既に開始しています。
この記事では、IT プロフェッショナルにとって最も重要な IIS 7.0 の主な機能強化について説明した後、ASP.NET Web アプリケーションと PHP Web アプリケーションの移行について詳しく説明します。ただし、まずは基本的な運用環境に類似したテスト ラボの概要について説明します。
これは重要な作業です。IIS 7.0 を運用サーバーに展開する前に、時間をかけてラボ環境で徹底的にテストを行い、新しい Web サーバーで Web アプリケーションをスムーズに実行できるようにする必要があります。

まずはテストから
このテスト ラボには、Windows Server 2003 と IIS 6.0 を実行し、ASP.NET アプリケーションをホストするシステム、および Ubuntu 7.10 Linux ディストリビューションと Apache HTTP Server 2.2 を実行し、PHP ベースの Web アプリケーションをホストするサーバーが配置されています。ここでの最終的な目標は、Windows Server 2008 をステージング環境と運用環境のシステムに展開した後、複雑なアプリケーションを移行して、IIS 6.0 と Apache のインスタンスを IIS 7.0 に置き換えることです。
このテスト ラボでは、DotNetNuke 4.7 と osCommerce 3.0a4 という 2 つの重要な Web アプリケーションが実行されます。DotNetNuke は ASP.NET 2.0 と Microsoft® SQL Server® に基づいた Web アプリケーション フレームワークです。もう一方の osCommerce は、完全な機能を備えた電子商取引ソリューションの最新のアルファ版で、PHP と MySQL に基づいています。では、これらの高度なアプリケーションを IIS 7.0 に移行しましょう。
この記事の目的はもちろん、ソフトウェアのバージョン、製品、またはプラットフォームを比較することではありませんが、Windows Server 2008 と IIS 7.0 を基盤として使用することには数多くの利点があることをお伝えしておく必要があります。具体的に言うと、管理作業の複雑さが軽減され、実行する Web サーバーの総数を最小限に抑えることができます。
図 1 は、この記事の説明に使用したテスト ラボの概要を示しています。記事の内容を各自のテスト環境で再現する場合は、TechNet Magazine Web サイト (technetmagazine.com) のコード ダウンロード セクションからダウンロードできる付属リソースに、必要なソフトウェア コンポーネントの入手先、および詳細なインストール手順へのリンクが記載されているので、これらを参照してください。
図 1 IIS 7.0 を展開するためのテスト環境 (画像をクリックすると拡大表示されます)
この記事の執筆を完了したのと同じくらいの時期に、Web アプリケーションを IIS 6.0 と IIS 7.0 に展開、同期、および移行できるコマンド ライン ツール (MSDeploy.exe) がマイクロソフトからリリースされました。このツールを試してみることをお勧めします。詳細については、マイクロソフトの Web 展開チームのブログ (go.microsoft.com/fwlink/?LinkId=118272) を参照してください。

テスト環境を構築する
この記事の執筆時点では、Windows Server 2008 はまだプレリリース版だったので、ドメイン コントローラやデータベース サーバー上の Windows Server 2003 は Windows Server 2008 に置き換えませんでした。Windows Server 2008 が公式にリリースされたら、Active Directory® インフラストラクチャの移行も検討することをお勧めします。また、この記事では、SQL Server® 2005 および MySQL データベースを SQL Server 2008 に移行する作業についても取り上げません。
ステージング サーバーには、SQL Server 2008 を展開しました。その主な理由は、SQL Server 2005 Service Pack 2 をインストールするよりも手間が少ないからです。SQL Server 2008 データベースを使用した場合でも、DotNetNuke は問題なく実行できました。また、Windows Server 2008 への MySQL 5.0 のインストールは簡単で、複雑な作業はありませんでした。
IIS 7.0 は Server Core 上でも使用できますが、ここでは特定のテスト要件のために Server Core インストールを使用しませんでした。まず、このステージング サーバーは、今回の最も重要なテスト システムだったので、完全インストールを実行する必要がありました。また、Server Core 上では Microsoft .NET Framework を使用できないことも、完全インストールを実行した理由の 1 つです。
PHP は Server Core 上で正常に動作しますが、今回の目標は ASP.NET アプリケーションと PHP アプリケーションを統合することです。したがって、Server Core を選択肢の 1 つに数えることはできません。Server Core 上で .NET Framework がサポートされるまでは、完全インストールを実行して ASP.NET アプリケーションをサポートする必要があります。テスト環境の詳細なインストール手順を示すガイドラインについては、付属リソースの 01_install_testlab.htm ファイルを参照してください。
今回は、既存のサーバーをアップグレードするのではなく、Windows Server 2008 のクリーン インストールを実行することにしました。何より、クリーン インストールを実行すると、図 2 のような段階的な移行シナリオを簡単に実装できるようになります。基本的な戦略は、関連する Web アプリケーション コンポーネントのテストがステージング サーバー上で成功し、新しい IIS 7.0 の Web ファームに移行されるまで、既存の Web ファームを実行し続けることです。
図 2 IIS 7.0 への段階的な移行 (画像をクリックすると拡大表示されます)
環境の複雑さに応じて、既存の Web アプリケーションを一度にすべて移行することも、段階的に移行することもできます。Web アプリケーションまたはサイトごとに、新しい Web ファームでの最終的な受け入れテストが完了したら、ブラウザによって新しい IIS 7.0 Web ファームが参照されるように、関連する DNS レコードを変更して、移行を完了できます。このような方法を取ることによって、ダウンタイムと中断を最小限に抑えることができます。

IT 管理者にとって重要な機能強化
MSDN® Magazine には、Mike Volodarsky によって執筆された「Windows Vista 用 Web サーバーの新機能」(msdn2.microsoft.com/magazine/cc163453.aspx) というすばらしい記事が掲載されています。この記事では、IIS 7.0 の機能強化が簡単に紹介されています。
もう 1 つの優れた資料としては、Microsoft.com の運用チームによるブログ記事「ドッグフードの中に隠れたごちそう」(go.microsoft.com/fwlink/?LinkId=117436) を挙げることができます。この記事には、IIS 7.0 を使い始めた当初のチーム メンバの経験がまとめられています。簡単に述べると、このチームは IIS 7.0 の機能強化を次のように順位付けています。
  1. セットアップの単純化
  2. 高い互換性
  3. メタベースの排除
  4. UNC 共有に配置された applicationHost.config ファイルによる構成の一元化
  5. アプリケーション ディレクトリの web.config ファイルを使用した構成の委任
  6. 管理ツールの強化
  7. 失敗した要求トレース
  8. URLScan を必要としない要求フィルタ
  9. UNC 共有によって単純化されたコンテンツ同期
  10. 動的コンテンツの出力のキャッシュ
セットアップの簡略化は、私の中でも確実に上位に入っています。Microsoft.com の運用チームはブログ記事で、1 つのコマンド ラインを使用して IIS 7.0 のすべての機能 (または、もちろん必要な機能のみ) を展開する方法を示しています。この方法は、早速図 3 のようなコマンド ラインを使用して、テスト ラボの構築手順に組み込んであります。
確かに、このコマンドはかなり長いですね (このコマンドをコピーする場合は、手作業で再入力せずに、TechNet Magazine Web サイトからコピーして貼り付けることをお勧めします)。このコマンドを実行すると、利用できるすべてのモジュールが IIS 7.0 コンピュータにインストールされますが、これには PHP は含まれません。IIS 7.0 では PHP は提供されません。インターネット経由で Debian パッケージをダウンロードしてインストールするという考えは、Windows® パッケージ マネージャ (pkgmgr.exe) には取り入れられていません。このような場合は、Windows 自動インストール キット (AIK) を使用します。
図 3 単一のコマンド ラインを使用して IIS 7.0 の機能を展開する
start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).
AIK を使用すると、IIS 7.0 と PHP 5 を含む Windows Server 2008 用のカスタム インストール DVD を作成できます。MySQL や Web アプリケーションのファイル、および展開に必要なその他のコンポーネントを含めることもできます。すべてのコンポーネントは Windows Server 2008 のセットアップに含めることができるので、すべての Web サーバーに一貫したカスタマイズを適用できます。このため、コマンド ラインも構成ファイルの編集も不要です。
また、完全な無人インストール用のカスタム DVD を作成することもできます。AIK に付属しているドキュメントとツールを使用して AutoUnattend.xml ファイルを作成し、このファイルを DVD のルート フォルダに保存します。一連の手順については、付属リソースに含まれている Custom Image Deployment.htm ファイルを参照してください。
互換性が重要な機能強化であることは、多くの管理者も認めています。テストを開始するとき、私は DotNetNuke と osCommerce の互換性に関する問題がいくつか発生することを予想していましたが、IIS 7.0 への移行はかなり簡単でした。どちらの Web アプリケーションにもフォーム認証、検索エンジンに対応した URL などの高度な機能が含まれていたので、この結果には驚きました。
DotNetNuke については、64 ビット プラットフォーム上の UNC 共有にコンテンツを格納する、複雑な Web ファームのシナリオに進むまで、問題は発生しませんでした。ただし、発生したのは非常に小さな問題です。結局は、互換性がこのように強化されたことによって、Web アプリケーションを IIS 7.0 上で実行するときにかかる時間が短縮されました。
Web アプリケーションで互換性の問題が発生した場合、新しく組み込まれた、診断とトレースのサポートをすぐに気に入ると思います。詳細な診断情報は非常に役立ち、提示される解決策も便利なだけでなく実際に効果があります。
図 4 は、DotNetNuke 4.7 を統合モードの IIS 7.0 で実行したときに表示される診断情報です。この例では、選択肢が 3 つ提供されています ([Things you can try] (対処方法) セクションに注目してください)。DotNetNuke の開発者にとっては、おそらく統合モードをサポートするようにアプリケーションを変更するという選択肢が最も適しています。エラーを無視すると、おそらく良い結果はもたらされません。私のお勧めは、Web アプリケーションを Classic .NET AppPool に切り替えてクラシック モードを有効にする、3 つ目の選択肢です。その理由は、変更を加えることなく DotNetNuke 4.7 を IIS 7.0 で実行する必要があるためです。
図 4 統合モードで実行されている DotNetNuke の診断情報 (画像をクリックすると拡大表示されます)

IIS のアーキテクチャ
統合モードとクラシック モードとは何か、また、なぜ ASP.NET アプリケーション (DotNetNuke) はこれらのモードの影響を受け、PHP アプリケーション (osCommerce) は影響を受けないのか、疑問に思う方もいらっしゃるでしょう。この点をよく理解するには、まず IIS 7.0 のアーキテクチャを学習する必要があります。以前のバージョンでは、主に ISAPI 拡張 (aspnet_isapi.dll) を使用して、中核となる Web サーバーに ASP.NET ランタイムを統合していました。一方、IIS 7.0 を使用すると、ManagedEngine というグローバル レベルの HTTP モジュールを使用して、中核となる Web サーバーに直接、ASP.NET モジュールを追加できるようになります。
ネイティブ モジュールでは、IIS Web Server Core API を使用して、BeginRequest、AuthenticateRequest、AuthorizeRequest、ExecuteRequestHandler など、パイプライン内の特定のイベントが登録されます。ManagedEngine では、ASP.NET モジュールを要求パイプラインに統合するために必要なサポートも提供されます。この新しい IIS 7.0 のアーキテクチャによって、ネイティブ モジュールと ASP.NET モジュールを、要求されたコンテンツの種類に関係なく要求処理のどの段階でも呼び出すことができるようになります。
例として、ASP.NET のユーザー認証について考えてみましょう。IIS 6.0 では、ASP.NET ベースの HTTP モジュールを使用して、OnAuthenticate イベント (FormsAuthentication.OnAuthenticate、WindowsAuthentication.OnAuthenticate など) を登録し、現在の HttpContext でユーザーの ID を設定できます。この処理は ASP.NET ランタイム内では適切に機能しますが、この ASP.NET コードを使用して、PHP ベースの Web アプリケーション経由で公開されたリソースを保護することはできません。
IIS 6.0 では、スクリプトマップの構成に従って、ASP.NET コンテンツの要求が aspnet_isapi.dll に転送されますが、PHP コンテンツの要求は、この ASP.NET の ISAPI 拡張には転送されません。そもそも ASP.NET では PHP コードが処理されませんが、これは PHP ページが要求された場合に ASP.NET 認証コードが実行されないという意味でもあります。したがって、IIS 6.0 を使用する場合は、PHP アプリケーション専用の認証メカニズムを実装する必要があるので、同じ認証ロジックをもう 1 つ用意する必要があります。
IIS 7.0 では、イベント駆動型の処理モデルが使用されます。このモデルでは、要求パイプライン内の個々のモジュールを組み合わせることができます。IIS 7.0 に付属するコンポーネントには、要求パイプラインで AuthenticateRequest イベントが発生したときに OnAuthenticate イベントを生成する、マネージ モジュールの WindowsAuthentication や FormsAuthentication などがあります。IIS 7.0 では、RequestFilteringModule や IpRestrictionModule などのネイティブ モジュールを使用して、BeginRequest イベントの発生時に、致命的な問題がある要求をできる限り早く拒否できます。その後、AuthenticateRequest イベントの発生時にカスタムの ASP.NET 認証コードを実行し、ExecuteRequestHandler イベントの発生時に FastCgiModule で PHP スクリプト エンジン (php-cgi.exe) を実行して、PHP ページを処理できます。
このようにアーキテクチャが統合された結果、Web 開発者は共通のビジネス ロジックを実装するために、同じコードを繰り返し使用する必要がなくなりました。カスタムの ASP.NET 認証コードを使用して、PHP アプリケーションを含むすべての IIS リソースを保護できます。また、ASP.NET モジュールを使用して、URL の書き換え、カスタム トレース、エラーのログ記録など、その他の前処理および後処理のタスクを実行できます。

統合モードとクラシック モード
この新しいアーキテクチャの欠点は、既存の ASP.NET アプリケーションのコードや構成を変更する必要が生じる場合があることです。変更を実装するアプリケーション開発者は、実装した変更によって、要求パイプラインでモジュールの競合が発生しないようにする必要があります。ただし、既存の Web アプリケーションをすぐに移植できない場合は、アプリケーション プールでクラシック モードを有効にし、クラシック モードのワーカー プロセスで Web アプリケーションを実行できます。IIS 7.0 では、クラシック モードのワーカー プロセスに ManagedEngine が読み込まれません。したがって、要求パイプラインで ASP.NET モジュールを解決したり呼び出したりすることはできません。その代わり、IIS 7.0 では IsapiModule (aspnet_isapi.dll) に基づいた多くの ISAPI ハンドラが実行され、IIS 6.0 と同じように ASP.NET コンテンツが処理されます。これは、applicationHost.config ファイルの system.webServer の下にある handlers セクションを分析するとわかります。既定では、applicationHost.config ファイルは %WinDir%\System32\InetSrv\Config フォルダにあります。
たとえば、文字列 aspx を検索すると、あるエントリでは PageHandlerFactory-Integrated (preCondition="integratedMode" という設定に従って、統合モードのアプリケーション プールで実行されるワーカー プロセスに読み込まれます) が指定され、他のエントリでは PageHandlerFactory-ISAPI-2.0 および PageHandlerFactory-ISAPI-2.0-64 (preCondition="classicMode" という設定に従って、クラシック モードのアプリケーション プールで実行されるワーカー プロセスに読み込まれます) が指定されていることがわかります。
パイプラインのモードはアプリケーション プール レベルで設定されるので、IIS 7.0 では、ある Web アプリケーションを統合モードで実行するのと同時に、他の Web アプリケーションをクラシック モードで実行できます。ワーカー プロセスだけは異なるアプリケーション プールで実行する必要がありますが、これらのプロセスは同じサーバー上でホストできます。
統合モードとクラシック モードの影響を受けるのは、IIS 7.0 で ASP.NET がどのように要求パイプラインに統合されるかという点のみであることに注意してください。これらのパイプラインのモードは、PHP アプリケーションには直接影響を与えません。FastCgiModule とその他のすべてのネイティブ モジュールは、パイプラインのモードの前提条件にかかわらず、統合モードとクラシック モードの両方で必ず読み込まれます。FastCGI は、PHP スクリプト エンジンを IIS 7.0 で実行するのに適したインターフェイスです。FastCGI を使用せずに、CGI で PHP スクリプト エンジン用のハンドラ マッピングを作成したり、IsapiModule を PHP-ISAPI (php4isapi.dll) と組み合わせて使用したりすることもできます。
ただし、FastCGI を使用するとパフォーマンスと安定性が大幅に向上するので、私の考えでは、IIS 6.0 形式の構成方法はもう時代遅れです。CGI を使用した場合、HTTP 要求が発生するたびに IIS で新しい CGI プロセスを初期化する必要があるので、処理に時間がかかります。一方、FastCGI では、複数の要求に対して CGI プロセスが再利用されます。ISAPI ではスレッド セーフな PHP ビルドが要求されるので、スレッド セーフではない PHP ビルドを実行する場合よりもオーバーヘッドが増加します。
さらに重要なのは、すべての PHP 拡張がスレッド セーフなバージョンで入手できるわけではないことと、スレッド セーフではない拡張を ISAPI と共に実行するのは、サーバーの安定性が低下する可能性があるので好ましくないことです。これに対して、FastCGI は CGI のような単一の同時実行環境です。スレッド セーフではない PHP の実行に FastCGI を使用した場合でも、安定した高速な処理が実現されるので、IIS 7.0 で PHP 5 を実行する場合に FastCGI が適していることは明らかです。IIS 7.0 に移行する準備がまだ整っていない場合は、IIS 6.0 でも FastCGI を使用できます。

モジュールと機能
IIS 7.0 の特徴は、高度にモジュール化されたアーキテクチャ (IIS 開発者の表現では、コンポーネント化された機能セット) です。これは、IIS 7.0 によって使用されるメモリのサイズと、IIS 7.0 が攻撃を受ける危険性を最小限に抑える必要がある Web 管理者にとっては朗報です。さまざまなモジュールを有効にしたり、さらには標準的なモジュールをカスタム モジュールで置き換えたりすることによって、Web サーバー上の IIS 7.0 の機能を完全に制御できます。
ASP.NET を統合モードまたはクラシック モードで実行するだけでなく、PHP アプリケーションも同じサーバー上で実行するには、要求の処理、サーバーの構成、ASP.NET、ISAPI、および CGI (FastCGI モジュールを含む) がサポートされるように、少なくとも Web サーバーの役割と主要なモジュールをインストールする必要があります。この作業は、次のコマンド ラインを使用して行うことができます。
start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI
私は基本的に、すばやく Web アプリケーションを起動して実行できるように、提供されているすべてのオプションを IIS 7.0 と共にステージング サーバーにインストールして、すべてのコンポーネントと管理ツールを使用可能な状態にすることを好みます。戦略としては、アプリケーションが正常に動作することを確認できたら、役割サービスをアンインストールしたり、モジュールを無効にしたりして、構成を絞り込みます。アプリケーションが正常に動作しなくなった場合は、削除した役割サービスやモジュールを再度追加します。
パッケージ マネージャ (pkgmgr.exe) や IIS 7.0 のコマンド ライン ツール (appcmd.exe) を使用したり、applicationHost.config ファイルの globalModules セクションを直接編集したりすることもできますが、個人的にはグラフィカル ツールが非常に便利だと思います。RequestFilteringModule、StaticCompressionModule などの一部のモジュールは、厳密に言えば Web アプリケーションの実行には必要ありませんが、これらは非常に役立ちます。アプリケーション プールに必要なモジュールを削除した後、Web アプリケーションにアクセスすると、HTTP エラーが表示されます (図 5 参照)。
図 5 IsapiModule が存在しないことによってクラシック モードで実行できない ASP.NET アプリケーション (画像をクリックすると拡大表示されます)
注 : この場合のベスト プラクティスは、すべての IIS 7.0 サーバーに同じ組み合わせのモジュールがインストールされ、それらが有効になっているかどうかを確認することです。インストールされているコンポーネントを確認するには、HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ のレジストリ キーを確認します。NetFxEnvironment や CGI などのレジストリ キーで REG_DWORD の値が 0000 0001 になっている場合は、対応するコンポーネントがインストールされています。

Web アプリケーションを移行する
理論の説明は終わりました。では、Web アプリケーションを IIS 7.0 に移行する作業に取りかかりましょう。既に説明したとおり、このテスト環境のステージング サーバーでは、IIS 7.0 を、すべての利用可能なコンポーネント、および FastCGI に登録されたスレッド セーフではない PHP 5 と共に実行します。作業を始める前に、次の基本事項を確認する必要があります。
  • Web アプリケーションには SQL Server や MySQL などのデータベース管理システムが必要であるかどうか。
  • ODBC 接続、COM オブジェクト、SSL 証明書などの追加のコンポーネントをインストールしたり構成したりする必要があるかどうか。
  • Web アプリケーションでは、ファイル共有などのリソースを操作するために、特別なサービス アカウントや、昇格したローカルまたはリモートのアクセス許可が必要であるかどうか。
  • URL の書き換え用 Apache モジュール (mod_rewrite) など、IIS 7.0 では利用できない、プラットフォーム固有の機能に依存しているかどうか。
上記の基本事項を確認することは、Web アプリケーションを IIS 7.0 で高速に実行するのに役立ちます。たとえば、mod_rewrite を使用する Apache 2.2 から PHP アプリケーションを移行しようとしている場合 (検索エンジンに対応したり、インライン フレームを使用してリンクされた画像によって帯域幅が占有されるのを防いだりするため)、互換性のあるカスタムの URL 書き換えソリューションを IIS 7.0 に実装しない限り、問題が発生します。さいわい、osCommerce は IIS 7.0 上で mod_rewrite 機能を必要としませんが、一部の検索エンジン最適化パッケージでは必要になる場合があります。
これで、ステージング サーバーに必要な追加のコンポーネントを確認してインストールできたので、Web アプリケーションを起動して実行する準備が整いました。ここで今度は、次の事項を確認する必要があります。
  • Web アプリケーションのサポートに使用できる最も単純な構成は、どのような構成であるか。
  • 運用環境では、現在どのような構成が使用されているか。
  • 新しいプラットフォームで Web アプリケーションの構成を最適化できるかどうか。
  • Web アプリケーションを目的の構成で動作させるには、どの役割サービスとモジュールが最低限必要であるか。
Web アプリケーションを最も単純な構成で実行すると、アプリケーションが動作するかどうかを簡単に確認できます。問題なく動作するようであれば、既存の運用環境と同様の構成を適用し、運用環境のデータをテスト環境のデータベースにインポートします。もちろん、一部の問題は、詳細な構成を適用するまで表面化しない場合があります。
また、運用環境の構成をテスト ラボで再現すると、改善できる部分に気が付くこともあります。applicationHost.config ファイルを UNC 共有に配置すると、複数の Web サーバーの構成を一元化できるので、非常に便利です。冗長性とコンテンツの同期によってフォールト トレランスを強化するには、分散ファイル システム (DFS) レプリケーションの実装を検討します。この機能は、Windows Server 2003 R2 と Windows Server 2008 で使用できる、状態ベースのマルチマスタ レプリケーション エンジンです。さらに、Web アプリケーションのコンテンツ ファイルを UNC 共有に配置すると、Web フロントエンドのストレージ要件を最小限に抑えることができます。
この他には、セキュリティや動的キャッシュに関連する最適化が考えられます。セキュリティとパフォーマンスの最適化は、この記事の説明範囲を超えるので、このテスト ラボでは行っていません。また、インストールするサーバーの数を抑えるため、DFS も構成していません。付属リソースに含まれている一連の手順では、applicationHost.config ファイルと Web コンテンツを UNC 共有でホストする方法の簡単な例が提供されます。図 6 は、DFS を使用する UNC ベースの Web ファームを実装する方法を示しています。
図 6 applicationHost.config ファイルと Web コンテンツが UNC 共有に配置された Web ファームの展開 (画像をクリックすると拡大表示されます)

まとめ
IIS 7.0 は優れた Web サーバー プラットフォームです。IIS 7.0 は、中核となるアーキテクチャの設計が変更されているにもかかわらず、IIS 6.0 との下位互換性がほぼ完全に確保されていることを特徴としています。ほとんどの ASP.NET Web アプリケーションは、変更を加えずに実行できますが、アーキテクチャが大幅に変更されたことを考えると、互換性の問題が発生しないとは言い切れません。
ASP.NET Web アプリケーションと PHP Web アプリケーションのどちらを IIS 7.0 に移行する場合でも、段階的な方法を使用し、計画、準備、テスト、およびコードと構成に加える変更の文書化に力を入れて取り組むことをお勧めします。
IIS 7.0 には、手間をかける価値があります。セキュリティ、パフォーマンス、構成可能性、柔軟性など、さまざまな機能強化が提供されており、これらをすべて説明するには、書籍 1 冊分のスペースが必要になるでしょう。UNC 共有に基づいた構成の一元化とコンテンツの共有、アプリケーション ディレクトリ内の web.config ファイルを使用した構成の委任、管理ツールの強化、詳細な診断情報と失敗した要求トレース、および動的な出力のキャッシュは、必ず Web 管理者の心をつかむはずです。
要求パイプラインでネイティブ モジュールとマネージ モジュールを組み合わせて使用できることは、ASP.NET 開発者にとって役立ちます。また、IIS 7.0 の FastCGI によって実現されるパフォーマンスと安定性の向上は、PHP アプリケーションの開発者にとってすばらしいことです。
もう 1 つ、IIS 7.0 を使用して IT プロフェッショナルが成功を収めるうえで役立つ重要なリソースを紹介しておきます。それは、マイクロソフトの IIS コミュニティ ポータル (www.iis.net) です。このサイトには、必要な情報がすべて揃っています。たとえば、新しいアーキテクチャについての詳しい記事、IIS 7.0 モジュールの作成方法がわかる、C++ 開発者と ASP.NET 開発者向けのソース コード、PHP アプリケーションを起動して実行するための順を追った説明が提供されます。ぜひこのサイトにアクセスしてみてください。IIS に関する疑問の答えを探している場合は、まずこのサイトを参照すると便利です。

Fergus Strachan は、Maestra Ltd London の創立者であり、取締役を務めています。このコンサルティング企業は、IT インフラストラクチャの設計とプロジェクト管理のサポートを専門とし、英国の国際銀行と教育機関にサービスを提供しています。彼はマイクロソフトのサーバー テクノロジについての記事を執筆しており、『Integrating ISA Server 2006 with Microsoft Exchange 2007』の著者です。また、『Microsoft Exchange Server 2003 Resource Kit』の共著者でもあります。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved. 許可なしに一部または全体を複製することは禁止されています。


コミュニケーションとコラボレーション
ユニファイド メッセージングへの移行を計画する
Jeff Goodwin
概要 :
  • ボイスメールの簡単な歴史
  • 移行を計画する際の考慮事項
  • 移行戦略
  • 複数のサイトが直面する課題

目次
ボイスメールの簡単な歴史
移行を計画する
実際的な移行戦略
移行のチュートリアル
計画に従うことの重要性
従来のボイスメール システムからユニファイド メッセージング プラットフォームへの移行は、厄介なプロジェクトになる場合があります。ただし、適切に計画を立てることによって、エンド ユーザーの作業が中断される可能性を最小限に抑えつつ、非常に簡単にこの移行作業を完了できます。実際、
このような移行プロジェクトを遂行する際は、サービスの中断を最小限に抑えることが最も重要です。
移行作業を行ううえで、何を計画すればよいかを把握するには、まず、なぜボイスメールが企業でミッション クリティカルなアプリケーションと考えられているかを理解する必要があります。この基本的な情報は、ユニファイド メッセージングへの移行時に実装する必要がある機能や、それらの機能が管理者にとってなぜ重要であるかを理解するのに役立ちます。

ボイスメールの簡単な歴史
旅の出発点がわからなければ、目的地にたどり着くための計画を立てることはできません。まず過去にさかのぼり、ボイスメール システムの概要を簡単に説明します。具体的には、ボイスメール システムの起源、およびボイスメール システムがどのように設計されたかを紹介します。ボイスメール システムを最初に開発した人物については議論が分かれていますが、最初に市販されたボイスメール システムは VMX と呼ばれるもので、この正式名称は Voice Message Exchange でした。
当初 VMX は、現在使用されている電子メールと同じように、企業内にいる他の従業員と音声でコミュニケーションを取るための手段として設計されました。このシステムでは、メッセージの送信、メッセージの転送、メッセージへの返信などのコマンドが提供されました。メッセージが録音された場合は、そのことがユーザーに通知されました。通知方法には、発信 (特定の電話番号を使用してユーザーを呼び出す) や未再生のメッセージがあることを知らせるライト (ユーザーの電話機に組み込まれているインジケータが光る) など、さまざまな方法がありました。
VMX の評判が高まるにつれて、組織ではボイスメール システムどうしをネットワーク経由で接続するようになりました。これによって、従業員が全社規模の配布リストにブロードキャスト メッセージを送信できる、全社規模のボイスメール ソリューションが提供されました。
もちろん、ボイスメール システムとの対話方法を提供するために、タッチトーン ユーザー インターフェイス (TUI) を作成する必要がありました。これらの TUI は長年の間に変化を遂げ、残念ながら現在では、ボイスメール用の標準的なインターフェイスは存在しません。携帯電話にボイスメール機能が備わっている場合、「ボイスメールを聞くには 1 を押してください」のようなメッセージを耳にしたことがあるでしょう。ボイス ユーザー インターフェイス (VUI) を使用する音声主導型のボイスメール システムの普及に伴い、TUI 自体の重要性は以前よりも低くなっています。ただし、ユーザーが使用する特定のインターフェイスには、TUI が付属していることもあるので、これらを軽視しないようにしてください。
現在普及しているエンタープライズ ボイスメール システムでは、分散型と集中型という 2 つのアーキテクチャが使用されています。図 1 のシアトル、ニューヨーク、およびオースティンのオフィスでは、分散型ボイスメール アーキテクチャが使用されています。このアーキテクチャでは、各サイトにボイスメール システムが配置されます。これに対して、ロンドン、パリ、およびグラスゴーのオフィスでは、集中型のモデルが使用されています。このアーキテクチャでは、PBX インフラストラクチャがネットワーク経由で接続され、ロンドンの集中管理された場所にすべての通話がルーティングされます。どちらのモデルにも長所と短所はありますが、分散型モデルでも、ボイスメール システムどうしをネットワーク経由で接続して、サイト間でメッセージを配信できることに注意してください。
図 1 2 つの一般的なボイスメール アーキテクチャ モデル (画像をクリックすると拡大表示されます)
組織で分散型モデルを使用する理由は、主に 3 つあります。それは、ローカルでの可用性を確保する必要があること、使用する異種 PBX システムをネットワーク経由で接続できないこと、およびダイヤル プランを統一すると制限が発生することです。
組織によっては、ネットワーク障害が発生した場合でも、ローカルの PBX とボイスメール システムを引き続き正常に実行し、サイト内でボイスメール システムの機能をすべて提供できるようにする必要があります。また、その場合、音声自動応答装置 (IVR) システムも問題なく動作し、外部のユーザーも引き続きメッセージを録音できる必要があります。つまり、実質的にはエンド ユーザーに一切影響を与えず、通常どおり動作を継続するということです。この説明には聞き覚えがあるかもしれません。上記の理由は、多くの組織で、Microsoft® Exchange Server を実行するサーバーをローカルに配置するのと同じ理由です。組織でリスク評価を実施して、ローカルでサービスを提供する必要があるかどうかを判断することをお勧めします。
買収によって組織が拡大すると、多くの場合、リモート サイトには、インフラストラクチャの残りの部分にネットワーク経由で接続できない PBX プラットフォームが残ります。この場合、組織では PBX を別の機器に変更するか (これはコストのかかるプロジェクトになる可能性があります)、サイトの環境を変更せずにボイスメール プラットフォームをネットワーク経由で接続することによって、シームレスなボイス メッセージ交換を提供できます。また、サードパーティ製のサーバーを使用して、異種ボイスメール システムどうしをネットワーク経由で接続することもできます。
PBX どうしをネットワーク経由で接続するには、統一されたダイヤル プラン (UDP) が必要です。UDP を使用すると、電話とボイスメールの内線番号の重複を防ぐことができます。図 1 では、シアトル、ニューヨーク、およびオースティンで使用されている内線番号の範囲が重複しています。この理由は、米国内サイト用の UDP が存在しないからです。内線番号の範囲を 7 桁または 10 桁に拡張して UDP を作成することもできますが、これによって他の問題が発生します。
まず、各電話のダイヤル テンプレート、PBX のすべてのユーザーの内線番号、およびボイスメール システムと連動するすべてのアプリケーションを変更することが必要になる場合があります。また、従業員は、すぐそこにいる同僚に電話をかける場合でも、7 桁または 10 桁の番号を思い出してダイヤルしなければならないので、フラストレーションの発生につながる可能性があります。
このような基本的な機能や設計上の問題点は、長い年月をかけて改善されてきましたが、ボイスメールの基本原理は変わっていません。メッセージ交換、ネットワーク、通知方法、ユーザー インターフェイス、およびアーキテクチャはすべて重要な要素であり、移行を計画する際には、これらを考慮する必要があります。

移行を計画する
ユニファイド メッセージングに移行すると、ユーザーがボイスメールを使用する方法から、アーキテクチャの設計方法、管理者が行う管理作業に至るまで、組織のあらゆる部分に変化がもたらされます。ユニファイド メッセージング システムに移行する際は、これらすべての変化に対処する必要があります。移行を計画する際に考慮する必要がある項目のチェックリストを次に示します。
メッセージ ネットワーク 従来のボイスメール プラットフォームから Exchange ユニファイド メッセージングに移行する組織では、共存期間を設ける必要があります。既にメッセージ ネットワーク (異なる複数のボイスメール システムを相互運用するシステム) が組織に展開されている場合は、既存のシステムにユニファイド メッセージング システムを追加するだけで済みます。複数の場所に個別のボイスメールまたは PBX システムを展開している組織では、メッセージ ネットワークを使用することを強くお勧めします。
インフラストラクチャ ユニファイド メッセージングのインフラストラクチャを設計する場合、ネットワーク要件、テレフォニーの統合、サーバーの配置などについて決定を下す必要があります。基本的な展開戦略に詳しくない場合は、以前の記事「Exchange Server 2007 を使用してユニファイド メッセージングを展開する」(technet.microsoft.com/magazine/cc137737) を参照してください。
自動応答 多くのシステムには、たとえば、日中と夜間、および部門間で異なる、複数の自動応答機能が備わっています。従来のボイスメール システムの自動応答を反映するには、組織の通信チームと協力して作業を行う必要があります。
未再生メッセージの通知 実装するソリューションで、未再生のメッセージがあることを知らせるインジケータを使用しなくても問題ないと思われるかもしれませんが、ユーザーがこの機能を必要とする可能性は大いにあります。そのため、メッセージがあることを通知するこの赤色のライトとユーザーをどのように関連付けるかも重要です。さいわい、数社の企業によって、Exchange Server 用のメッセージ インジケータ アプリケーションが開発されました。
FAX のサポート 多くの従来のボイスメール プラットフォームでは、FAX の受信がサポートされています。Exchange ユニファイド メッセージングでも FAX の受信機能がサポートされているので、新しく展開するシステムでもこの機能をサポートすることをお勧めします。
音声自動応答装置 一部の従来のボイスメール プラットフォームでは、Exchange ユニファイド メッセージングで再現できない音声自動応答装置 (IVR) アプリケーションがサポートされています。適切な代替システムが見つかるまでは、このシステムを残しておくことをお勧めします。
管理 Exchange ユニファイド メッセージングは、Active Directory® と Exchange メールボックス サーバーの役割に依存します。このため、ユニファイド メッセージングの展開が、管理作業やシステム要件などにもたらす影響を考慮する必要があります。
ユーザー インターフェイス 新しい UI を展開する際は、ユーザーを対象としたトレーニングを実施する必要があります。Exchange ユニファイド メッセージングでは、多くの携帯電話プロバイダとよく似たインターフェイスが使用されるので、ほとんどのユーザーが直感的に操作を行うことができます。また、音声認識機能も使用されるので、ユーザーはタッチトーンを使用する必要がありません。Exchange Server では、この機能を Outlook® Voice Access と呼んでいます。
トレーニング ユニファイド メッセージングに移行すると、ユーザーがコミュニケーションを取る方法やボイスメールを使用する方法が一新されます。ユーザー向けのトレーニングを実施し、UI だけでなくベスト プラクティスについても説明することによって、ユーザーがより効率的な新しい方法を使用してコミュニケーションを行うことができるようにする必要があります。たとえば、ユーザーは、電子メールの受信トレイにあるボイスメールをどのように操作したらよいかや、ユニファイド メッセージングに関するいくつかの詳細設定をどのように構成したらよいかを理解していない場合があります。

実際的な移行戦略
大規模な組織でユニファイド メッセージング ソリューションへの移行作業を行う場合、いくつかの課題に直面するに違いありません。ただし、私はユニファイド コミュニケーションに 10 年間携わっており、組織の要件が非常に具体的である複雑な移行作業でさえ、無事に成功するのを目の当たりにしてきました。
組織のサイトが 1 つであるか複数であるかにかかわらず、次の 5 つの基本手順に従って移行戦略を考えると役立ちます。
  1. ソリューションを計画および設計します。
  2. ユニファイド メッセージング サーバーの役割をインストールして構成します。
  3. パイロット グループを移行します。
  4. パイロット グループから返されたフィードバックに基づいて設計を変更します。
  5. ユーザーを移行します。
もちろん、複数のサイトを所有する組織は、通常 1 つのサイトのみを所有する組織は遭遇することがない、いくつかの課題に直面します。これらの課題については、補足記事「複数のサイトが直面する課題」で別途説明します。
ソリューションの計画と設計は、移行プロセスの最も重要な段階です。このプロジェクトは、ユニファイド メッセージング チームに任命することをお勧めします。ユニファイド メッセージング チームには、通信、Active Directory、Exchange、ネットワーク、セキュリティ、トレーニング、プロジェクト管理などに関する専門知識を持つ、組織のさまざまな部門の代表者を含める必要があります。これによって、組織の既存の PBX、ボイスメール、および電子メール インフラストラクチャの詳細を把握できます。
設計が完了したら、ユニファイド メッセージング サーバーの役割をインストールして構成できます。ユニファイド メッセージング サーバーは、既存のボイスメール システムと共存させる形でインストールできます。文書化されたベスト プラクティスに従って、作業を進めるようにしてください。
これで、ユニファイド メッセージング サーバーをテストする準備ができたので、小規模なパイロット ユーザー グループを指定して、新しいシステムに移行します。このグループは、25 ～ 50 人のユーザーで構成することをお勧めします。グループに含めるユーザーは慎重に選択してください。IT 部門と通信部門のスタッフから、部門管理者と販売員に至るまで、さまざまなグループのユーザーで構成されるパイロット グループを作成するようにします。このように広い範囲のユーザーを含めることによって、設計が目的に合っているかどうか、どのような要件を考慮すればよいか、ユーザーにはどのようなトレーニングが必要であるかなどの判断をより適切に下すことができます。
パイロット グループからフィードバックを受け取ったら、テスト中に発見されたすべての問題に対処できるように、設計を変更する必要があります。具体的には、考慮事項に関するセクションで説明した項目を再度確認し、組織の要件に合わせて、これらの項目に適切に対処します。通常、この段階で最もよく発生するのは、トレーニングに関連する変更であることに注意してください。
最後に、ユーザーを移行します。システムを完全な運用環境に移行する方法については、多くの考えと戦略があります。主な 2 つの方法論は、段階的な移行とフラッシュ カットです。
数週間から数か月にわたってユーザー コミュニティを段階的に移行すると、従来のボイスメール システムのユーザーとユニファイド メッセージングのユーザーとの間にどこにも接続されないボイスメールが生まれます。これにより、ユーザーどうしがボイスメールを使用してメッセージを転送できなくなります。また、設計にメッセージ ネットワーク ソリューションを含めなかった場合、一部のビジネス コミュニケーションが中断されます。これらのコミュニケーションが必要である場合は、初期設計にメッセージ ネットワーク ソリューションを含めることをお勧めします。
フラッシュ カット移行の場合、すべてのユーザーを一度に移行します。一般に、組織ではこのような移行を週末に行います。これは、システムをテストし、構成を変更し、深刻な問題が発生した場合は移行前の環境に戻すことができる時間を確保するためです。
どちらの方法を使用する場合でも、パイロット グループから挙げられた一般的な質問と回答に基づいて、ヘルプ デスク スタッフのトレーニングを実施するようにしてください。また、ヘルプ デスク スタッフが、ユーザーの有効化、ユーザーが有効であるかどうかの確認、パスワードの変更など、主要な作業を確実に行うことができるようにする必要があります。

移行のチュートリアル
これから移行のサンプルを紹介しますが、環境をユニファイド メッセージングに正常に移行するうえで最も重要なのは、内部および外部ユーザーの作業をできる限り中断することなく、ユーザーのボイスメール ボックスを従来のボイスメール プラットフォームからユニファイド メッセージングに移行することです。
図 2 は、組織のアーキテクチャを詳しく示しています。ここでは、この混合型 Exchange アーキテクチャには変更を加えません。米国に拠点を置くオフィスのプライマリ データセンターは、シアトルにあります。オースティンの IT アプリケーションはすべてシアトルから提供され、ニューヨーク オフィスではローカルの Exchange サービスが提供されます。米国のオフィスでは、異種 PBX インフラストラクチャが使用されているので、オフィスごとに異なるボイスメール システムが展開されています。技術的に考えると、PBX インフラストラクチャをネットワーク経由で接続して、集中管理された場所からボイスメールを提供することはできません。一方、ヨーロッパのオフィスの場合は、集中管理されたデータセンターがロンドンにあります。ヨーロッパの IT アプリケーションと通信アプリケーションは、すべてこのデータセンターから提供されます。
図 2 移行前のサンプル アーキテクチャ (画像をクリックすると拡大表示されます)
ボイスメール インフラストラクチャ全体は、Octel (現在は Avaya) プラットフォームに基づいています。すべてのボイスメール システムは、Octel Analog Networking (OAN) を使用して、ネットワーク経由で接続されています。OAN は、アナログ電話回線と長距離電話を使用して、ネットワーク経由でボイスメール メッセージを送信するための専用ネットワーク プロトコルです。このアーキテクチャを使用すると、サイト間、つまり全社規模のボイス メッセージングが可能になります。
複数のサイトが直面する課題
複数のサイトで構成される組織は、ユニファイド メッセージングを展開する際、非常に多くの課題に直面します。さいわい、既に他の組織が直面したいくつかの課題から、解決策を導き出すことができます。この記事ですべての課題を取り上げることはできませんが、さまざまな組織の作業にかかわった際に遭遇した最も一般的な課題について説明します。
集中管理された Exchange Server アーキテクチャと混合テレフォニー環境を使用している
分散環境の設計は簡単です。これを行うには、ユニファイド メッセージング サーバーを配置し、それを各サイトのローカル PBX と統合します。では、集中管理された環境、さらには混合環境の場合はどうでしょうか。サイトでローカルのユニファイド メッセージング サービスを提供する必要があるかどうかを考えてみてください。ローカルでユニファイド メッセージング サービスを提供すると、集中管理された Exchange サーバーにそのサイトから接続できなくなりますが、引き続き自動応答機能が提供されるので、外部のユーザー (おそらくその多くは顧客です) はメッセージを録音できます。どちらを取るかは、そのサイトがどの程度ミッション クリティカルであるか、およびソリューションをどれくらい簡単に管理できるかによって異なります。
サイトでローカルのサービスを提供する必要がある場合は、サイトにリモート ユニファイド メッセージング サーバーを配置することをお勧めします。また、その必要がない場合は、ローカル サイトに SIP ゲートウェイをインストールできます。Exchange ユニファイド メッセージングには柔軟性があり、PBX インフラストラクチャをネットワーク経由で接続する必要はありません。また、統一されたダイヤル プランも必要ありません。
現在 Exchange アーキテクチャをアップグレードしている最中である
多くの顧客は、Exchange インフラストラクチャをアップグレードしている最中にユニファイド メッセージングへの移行を開始することをためらいます。ユニファイド メッセージングに移行することが既に決定している場合は、Exchange サーバーのアップグレード中に移行に踏み切ることをお勧めします。アップグレード計画に従って作業を進めれば、プロジェクトが大幅に複雑になることはありません。
10 人未満のメンバで構成される小規模なサイトが多数あり、その一部のサイトには PBX が配置されていない
ローカルに PBX が配置されている小規模なサイトでは、ローカル サイトに SIP ゲートウェイをインストールすれば問題ありません。ローカルに PBX が配置されていないサイトでは、テレフォニー技術を使用して、集中管理された PBX に通話を転送することによって、ユニファイド メッセージング システムに通話をルーティングできます。つまり、ほとんど費用をかけずに、組織の小規模なリモート サイトにユニファイド メッセージング サービスを展開できます。
重要なことを 1 つ述べておくと、実はこのような小規模なサイトは、移行の優れた実験台になります。一般的な移行戦略の 1 つに、ネットワークの境界から中核となる部分に向かって移行を進める方法があります。まず小規模なサイトを移行してから、ユニファイド メッセージング チームと協力して事後分析を実施し、どの部分が正常に機能したか、およびどのような問題が発生したかを把握します。これによって、次のサイトを移行する際に、この結果を反映できます。
ユニファイド メッセージング チームは、ネットワークの境界から中核となる部分に向かって移行を進めることにしました。どのサイトでも、ユニファイド メッセージング サーバーを配置する際は、Exchange Server アーキテクチャに従うというベスト プラクティスに基づいて作業を行います。チームでは、考慮事項に関するセクションで説明した項目を考慮しながら、サイトごとに独自の計画ドキュメントを作成します。このドキュメントは、サーバーのインストールと構成、ユーザーのトレーニング、移行戦略の計画などに使用します。
チームは、サイトごとにユーザーをユニファイド メッセージング システムにフラッシュ カットし、今後も使用を続ける IVR アプリケーションをサポートするために、代替ソリューションが見つかるまで従来のプラットフォームをそのまま使用する計画を立てました。また、あるサイトの移行後、30 日間待ってから、次のサイトを移行することにしました。この期間は、さらに多くのユーザーを移行し、ヘルプ デスク サポートへの問い合わせが増える前に、各サイトを新しいプラットフォームに適合させることを目的としています。
まずは、オースティン オフィスを移行します。オースティンの電子メールはシアトルから提供されるので、チームは、ユニファイド メッセージング サーバーの役割をシアトルにインストールし、オースティンに SIP ゲートウェイをインストールして PBX 統合を提供します。従来のボイスメール プラットフォームはネットワーク経由で接続されているので、メッセージ ネットワーク サーバーをインストールすることによって、ユニファイド メッセージング プラットフォームをネットワーク経由で接続する必要があります。その後、ユーザーが新しいシステムに関するトレーニングを受け、移行がスムーズに進行したので、次はニューヨーク オフィスを移行することにしました。
ニューヨーク オフィスには、独自のメールボックスとハブ トランスポート サーバーが配置されています。そのため、ベスト プラクティスに従うと、ニューヨークにユニファイド メッセージング サーバーをインストールする必要があります。このサーバーは、移行計画のドキュメントに従ってインストールします。インストールしたサーバーは、メッセージ ネットワーク サーバー ノードとしてボイスメール ネットワークに追加されます。このオフィスのユーザーもトレーニングを受け、ユニファイド メッセージングにスムーズに移行できました。
シアトル オフィスには、オースティンの移行段階で展開したユニファイド メッセージング サーバーが既に配置されています。チームは、シアトル オフィスとオースティン オフィスをサポートするのに十分なボイスメール ポートがサーバーに実装されていると判断しました。シアトルのユーザーもトレーニングを受け、ユニファイド メッセージングに移行できました。
ヨーロッパのアーキテクチャは、はるかに簡単に設計できます。PBX インフラストラクチャをネットワーク経由で接続し、Exchange を集中管理します。ユニファイド メッセージング サーバーをロンドンに展開し、各サイトを小規模なサイトから順に移行します。図 3 は、最終的なアーキテクチャを示しています。
図 3 移行後のサンプル アーキテクチャ (画像をクリックすると拡大表示されます)

計画に従うことの重要性
私はこれまでに何度も、ユニファイド メッセージングへの移行が失敗した原因を解明するよう依頼されたことがあります。これらの組織の多くでは、1 つ以上の重要な規則が守られていませんでした。
まず、ユニファイド メッセージングは、単なるボイスメール システムではないことを忘れないでください。これはミッション クリティカルなアプリケーションなので、それを意識して移行作業に取り組む必要があります。また、ユーザーは、ボイスメール テクノロジを使用して情報交換を行います。ユニファイド メッセージングはビジネス アプリケーションなので、この記事で説明したすべての考慮事項を念頭に置いて移行を計画してください。
ユニファイド メッセージングに移行する際は、必ず通信チームの協力を仰ぐ必要があります。通信チームは、企業のインフラストラクチャに統合されているテレフォニー アプリケーションに最も精通しています。
ユニファイド メッセージングに移行する際は、これがエンタープライズ ソリューションであることを前提とした計画を立ててください。最初の段階で 1 つのサイトを実装している場合でも、常に全体像を念頭に置いて作業する必要があります。たとえば、1 つのサイトを実装する際に、他のサイトにメッセージ ネットワークをインストールしなかった場合、ユーザーどうしのコミュニケーションに影響を及ぼすことがあります。もちろん、これはたいへんな作業になるので、すべての IT アプリケーションを考慮したアーキテクチャを設計する際は、専門家に相談することをお勧めします。
最後に、トレーニングの重要性を軽視しないでください。ユニファイド メッセージングに移行すると、ユーザーがコミュニケーションを取る方法やボイスメールを使用する方法が一新されます。自分にとって直感的に理解できるものでも、他の人が同じように理解できるとは限りません。最もスムーズに移行を完了するには、適切なトレーニングを実施する必要があります。

Jeff Goodwin は、The VIA Group のシニア テクノロジストです。専門分野は、Exchange とユニファイド メッセージングの設計と展開です。連絡先は jgoodwin@theviagroup.com (英語のみ) です。


コミュニケーションとコラボレーション
音声が OCS 2007 にもたらす力
Rajesh Ramanathan
概要 :
  • OCS 2007 で通話を行う
  • 通話のセキュリティ保護のしくみ
  • OCS でのマルチモーダルな会話
  • Exchange UM と連携してボイスメールを提供する

目次
基本的な音声通話
電話番号を使用する
セキュリティで保護された通話
NAT とファイアウォールを通過する
電話番号に基づいてルーティングを実行する
着信ルーティング
品質報告とトラブルシューティング
すべての側面を一元管理する
マルチモーダルな動作と会話
ボイスメール
まとめ
Microsoft Office Communication Server (OCS) 2007 に関するこのシリーズの第 1 部では、優れた機能を提供する Live Communication Server (LCS) 2005 を基に OCS がどのように構築されたかについて説明しました。
この LCS を基に構築された OCS では、強化された企業規模のインスタント メッセージング (IM) 機能とプレゼンス機能、および高度なメディア機能と電話機能が提供されます。詳細については、TechNet Magazine 2008 年 2 月号の記事 (technet.microsoft.com/magazine/cc194409) を参照してください。この記事では、その続編として、OCS とボイス オーバー IP (VoIP) とのかかわりについて詳しく説明します。具体的には、OCS システムで行われる単純な音声通話のしくみを取り上げ、そのテクノロジを構成する各層について説明します。各コンポーネントの詳細については、対応する機能と共に説明します。
以前の記事でも説明したように、OCS では、次のようなさまざまな構成を使用するユーザーにテレフォニーを提供できます。
エンタープライズ ボイス PBX を使用する必要なく、OCS を Microsoft® 仲介サーバーと共に使用する、完全なユニファイド コミュニケーション ソリューションです。このシステムでは、Exchange ユニファイド メッセージング (UM) によってボイスメール機能が提供されます。この記事の残りの部分では、このサービスを使用するユーザーを "UC ユーザー" と呼びます。また、この構成を使用するクライアントを "UC エンドポイント" と呼びます。
PBX 統合を利用したエンタープライズ ボイス この構成によって、ユーザーはデスクトップ上で既存の PBX 電話を使用し、それと同時にユニファイド コミュニケーションのメリットを得ることができます。また、OCS と PBX を並列に構成できるので、着信通話で Office Communicator エンドポイントと PBX エンドポイントの両方を同時に呼び出すことができます。さらに、PBX によって、通話のルーティング機能とボイスメール サービスも提供されます。
リモート通話コントロール この機能によって、ユーザーは PBX 電話を通常の電話として使用し、その電話を Office Communicator クライアントから制御できるようになります。

基本的な音声通話
ここでは、エンタープライズ ボイス ユーザーの動きに注目します。単純な音声通話は、RFC 3261 で定義されているように、OCS システム内で SIP INVITE メカニズムを使用してセットアップされます。OCS サーバーは、ポストマスタの役割に似たプロキシとして機能し、クライアント (またはエンドポイント) 間でメッセージを中継します。リアルタイムのセッション (通話セッションやインスタント メッセージング セッションなど) が作成されるたびに、クライアントによって新しい SIP INVITE が生成されます。INVITE が確認され、応答が返される (つまり、リモート エンドポイントから 200 OK 応答が送信される) と、通話が確立されます (図 1 参照)。
図 1. INVITE の形式と 200 OK
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**
図 2 では、Alice が Office Communicator (OC) 2007 で [Communicator での通話] をクリックして Bob を呼び出します。そして、OC 2007 から Bob の SIP URI (Uniform Resource Identifier) である sip:bob@example.com に INVITE が送信されます。この INVITE には、Alice が音声を受信できるメディア エンドポイントの音声セッション記述子 (SDP、これは Session Description Protocol の略語としても使用されます) が含まれます。OCS は、INVITE を Bob の登録済みの SIP エンドポイント (Communicator Phone Edition や Communicator デスクトップなど) に分岐します。INVITE には、sip:alice@example.com という値を持つ From ヘッダーが含まれます。Bob のクライアント エンドポイントは、このヘッダーを使用して名前の後方参照 (RNL) を実行し、着信通話の通知に使用する名前 (Alice) を検索します。
図 2 複数のエンドポイントへの通話のルーティング (画像をクリックすると拡大表示されます)
各エンドポイントは、Globally Routable User Agent URI (GRUU) を保持しています。GRUU は、SIP エンドポイントを一意に識別するための URI で、登録処理中に OCS サーバーから取得されます。GRUU のアドレスは、SIP メッセージのルーティングに役立ちます。一度エンドポイントが通話に応答すると、それ以降、通話中に実行されるその他の処理に関する SIP 通知は、GRUU アドレスを使用して、直接エンドポイント間で送信されます。
図 3 は処理の続きを示しており、Bob が Communicator デスクトップから応答しています。Bob の OC は 200 OK メッセージを送信し、音声を受信できる場所を通知します。OCS プロキシは、あるエンドポイントからの応答を検出するとすぐに、別の Communicator Phone Edition エンドポイントへの通話を取り消します。Alice の Communicator エンドポイントが 200 OK 応答を受信すると、両方の Communicator エンドポイントが、メディアを起動するために必要な情報 (IP ポートや暗号化パラメータなど) を保持します。
図 3 あるエンドポイントからの応答 (画像をクリックすると拡大表示されます)

電話番号を使用する
ここまでは、ユーザーが [Communicator での通話] をクリックしたときに招待を作成する処理のしくみについて説明しましたが、ユーザーが電話番号を選択または入力した場合は、少し異なる処理が実行されます。
  • クライアントは、まず電話番号を正規化し、それを電話 URI として表します。電話 URI は、RFC 3966 で定義されているように、電話番号によって識別されるリソースを示します。
  • OCS サーバーは SIP URI のみを認識するので、クライアントは、ドメイン サフィックスと user=phone タグを追加して、電話 URI を対応する SIP URI に変換します。
  • 番号が内部ユーザーと一致する場合、OCS は招待を直接ルーティングします。番号が内部ユーザーと一致しない場合、招待は最も近い SIP-PSTN ゲートウェイにルーティングされます。
公衆交換電話網 (PSTN) 番号への一部の通話では、通話への応答が返される前に、メディア パスが設定される必要があります。これは、通話を完了するために、リモートのアナウンスを再生したり、追加の数字を収集したりすることを目的としています。このようなシナリオでは、PSTN ゲートウェイが、音声 SDP を含む 183 Session Progress インジケータを送信します。Communicator は、この情報を使用して、リモート ユーザーが通話に応答する前に、1 つの通話先エンドポイントとの間に双方向のメディア パスを設定します。
初期メディア パスの設定を完了すると、Communicator でデュアル トーン多重周波数 (DTMF、電話のトーン信号) キーパッドを使用できるようになります。これによって、ユーザーは、リモート システムが必要とする追加の数字を入力できます。入力された DTMF の数字は、RFC 2833 パケットとしてメディア パスに送信されます。PSTN ゲートウェイでは、PSTN 側の適切な DTMF トーン信号が生成されます。
Bob が携帯電話への同時呼び出しを有効にしている場合、OCS プロキシによって通話がゲートウェイにルーティングされ、それと同時に Bob の他の Communicator エンドポイントが呼び出されることに注意してください。このようなシナリオでは、分岐処理が有効になっていることが、OCS プロキシからの 183 Session Progress 応答によって通知されます。その後、Communicator によって、PSTN ゲートウェイとの間に受信専用メディア チャネルが確立されます。

セキュリティで保護された通話
OC によってセットアップされる音声通話の重要な機能の 1 つは、RFC3711 で定義されているように、Secure Real-Time Transport Protocol (SRTP) を使用することによって、メディアが既定で暗号化されることです。SRTP によって、機密性、メッセージの認証、および再生の保護が RTP トラフィックに提供されます。通話のセットアップ中、クライアントは、他のクライアントとの間でセキュリティ機能のネゴシエーションを行い、INVITE メカニズムの一環として暗号化キーを交換します。
OC は、通話を "任意で" 暗号化できるように既定で設定されています。これにより、2 つの OC エンドポイント間で、暗号化されたメディア チャネルを設定できます。管理者は、組織の規制遵守要件に基づいて、この設定を調整できます。たとえば、制限を厳しくしてすべての通話で暗号化を強制したり、それらをまとめて無効にしたりできます。

NAT とファイアウォールを通過する
OCS システム内のクライアントは、既存の NAT コンポーネントに変更を加える必要なく、Interactive Connectivity Establishment (ICE) テクノロジを使用して、ネットワーク アドレス変換 (NAT) デバイスとファイアウォールの外側にいるユーザーにメディア接続を提供します。ICE テクノロジは、現在、インターネット技術標準化委員会 (IETF) によって標準化されています。各クライアントは、音声ビデオ (A/V) エッジ サーバーを検出します。これは、インバンド プロビジョニングというメカニズムを使用して ICE テクノロジを提供し、サインオン中に A/V エッジへの認証済みの接続を維持するサーバーです。
クライアントは、通話を開始する前に、A/V エッジ サーバー (メディア リレー用)、NAT、またはホスト クライアント自体が保持する "候補" (接続する可能性のあるアドレスとポート) にリソースを割り当てます。セッション開始プロトコル (SIP) の INVITE が送信されるときに、この接続情報が INVITE の一部として含まれます。同様に、200 OK 応答には、ピアの候補に関する情報が含まれます。各エンドポイントがピアの候補の一覧を取得すると、複雑なランク付けおよび確認メカニズムによって、2 つのピア間におけるメディアの正常な処理を保証する最適なパスが選択されます。

電話番号に基づいてルーティングを実行する
電話番号に基づいたルーティングは、基本的な通話メカニズムよりも多少複雑です。この複雑さを生む要因を次に示します。
  • 組織が複数の異なるダイヤル プランを用意し、そのダイヤル プランを内部で短縮ダイヤル用に展開している可能性があります。
  • 番号が標準的でない形式で保存されている可能性があります (ユーザーが 7 桁の数字を Microsoft Office Outlook® で保存した場合など)。
  • 異なる発信番号に異なるポリシーがマップされている可能性があります。たとえば、特定のユーザーによる国際電話番号への発信がブロックされる場合があります。
OCS システムで正常に電話番号をルーティングするには、電話番号が RFC 3966 の電話 URI 形式に従っている必要があります。この形式に従っていない番号は、クライアントが INVITE を送信する前に変換されます。図 4 は、OCS システム内で発生するこの処理のしくみを示しています。
図 4 電話番号のルーティング (画像をクリックすると拡大表示されます)
クライアントが使用できる番号は、さまざまなソースから提供される可能性があります。アドレス帳サービス (ABS) からは、事前に正規化された番号が提供されます。ABS では、管理者が定義した正規化ルールを使用して、番号を正規の E.164 形式に変換できます。この正規化された番号にクライアントから SIP INVITE が送信されると、OCS は変換処理を適用して、番号を内部ユーザーにマップします。
  • 手順 1 は、OCS システムで受信する番号が、一意である (E.164 番号計画に従って正規化されている) か、場所を識別する電話のコンテキストを含むことを示しています。これらの番号は、SIP INVITE の一部としてサーバーに送信されます。OCS は、INVITE を変換処理にルーティングします。
  • 変換処理 (手順 2) では、サーバー側の RNL を使用する UC エンドポイントへの電話番号のマッピングが試行されます。この変換処理では、受信した番号から発信ルーティングまたは UC ユーザーへのルートが識別されます。番号を正常に変換できなかった場合、この通話は失敗し、4xx コードが返される可能性があります。
  • 番号が非 UC または外部の番号に変換された場合、その番号は発信ルーティング コンポーネントに送信されます。このコンポーネントによって、発信者に関連付けられた番号を対象とするポリシーが適用された後、その後の処理を実行するために、INVITE が適切な SIP-PSTN ゲートウェイにリダイレクトされます (手順 3A)。発信ルーティングでは、必要に応じて、ゲートウェイ間での通話の負荷分散や、代替ゲートウェイへのフェールオーバーが実行されます。特定の番号へのアクセスが禁止されている場合、発信ルーティング処理では、通話が失敗するか拒否され、SIP 403 応答コードが返されます。発信ルーティングは、発信者が UC ユーザーである場合にのみ適用されることに注意してください。発信者が UC ユーザーでない場合、OCS は、その URI 用に設定されたゲートウェイへの静的ルートを使用することを試みます。
  • 番号が UC ユーザーの番号に変換された場合、そのユーザーの SIP URI に INVITE がルーティングされます (手順 3B)。着信ルーティングは、UC ユーザーと、SIP URI に発信された通話のみに適用される OCS の機能です。この後説明しますが、着信ルーティングでは、UC ユーザーの呼び出しのタイムアウト、通話の転送、およびボイスメールの転送に関するルールが適用されます。
正規化処理によって生成される番号は、クライアントの場所によって異なる可能性があることに注意してください。管理者は場所のプロファイルを構成し、特定の場所に固有の番号変換ルール (その場所での 4 桁のダイヤルの処理方法など) を割り当てることができます。各 UC ユーザーには、場所のプロファイルが割り当てられます。システム内のすべてのクライアントは、インバンド プロビジョニングを使用し、割り当てられた場所のプロファイルに固有のルールをダウンロードします。次は、着信ルーティングについて詳しく説明します。

着信ルーティング
着信ルーティングのルールでは、システム内に登録されたクライアントが応答可能である場合とそうでない場合に、どのように通話をユーザーにルーティングするかが指定されます。着信ルーティング コンポーネントでは、着信通話にもプレゼンスに基づくルールが適用されます。たとえば、ユーザーがプレゼンス状態を [応答不可] に設定している場合、着信通話はボイスメールに送信されます。着信ルーティングではプレゼンス コンテナのレベルが認識され、ブロックされたコンテナに属するユーザーからの通話が自動的に拒否されます。図 5 は、OCS 着信ルーティング コンポーネントによってサポートされる機能の概要を示しています。
図 5. 着信ルーティング機能
機能 | コメント
着信転送までの時間 | 既定値は 20 秒です。設定可能な最大値は 60 秒です。通話は、このタイムアウト時間が経過したら、不在時の着信用の場所に転送されます。
ボイスメールへの不在時の着信のルーティング | ユーザーのボイスメールが有効になっている場合に、既定で設定される機能です。通話は着信ルーティングのルールに従ってルーティングされます。
通話がボイスメールに到達する前に発信者が通話を終了したときに生成される不在着信通知 | このような不在着信を Exchange UM に通知します。
通話のブロック | ブロックされた発信者からの通話を拒否します (SIP ID を持つユーザーからの通話のみをブロックできます)。
応答不可 | 通話をボイスメールにルーティングします。ユーザーがこのモードに設定されている場合、同時呼び出し先は呼び出されません。
割り込み許可リスト | ユーザーの状態が [応答不可] に設定されていても、発信者がチーム コンテナに属していれば、通話を許可します。
同時呼び出し | PSTN 電話番号だけでなく、Communicator および Communicator Phone Edition クライアントも呼び出すように、着信通話を構成します。
通話の直接転送 | 着信通話を別のユーザー、PSTN 電話番号、またはボイスメールに直接転送します。
不在時の着信の転送 | 不在時の着信を別のユーザー、PSTN 電話番号、またはボイスメールに転送します。
稼働時間 | ユーザーの通話転送設定を有効にするために、Outlook の予定表で構成された稼働時間を使用します。
着信ルーティングのルールは、XML スキーマ形式で、ユーザーのセルフ プロビジョニング情報の一部としてサーバーにアップロードされます。図 6 は、着信ルーティングのしくみを示しています。OCS システム内のユーザーへの着信通話では、既定でユーザーが呼び出されます。既定では、着信転送までの時間が経過する前に、そのユーザーが通話に応答しなかった場合、不在時の着信がボイスメールに送信されます。ユーザーは、既定の構成を変更し、電話番号、別のユーザー、またはボイスメールに通話を直接転送することもできます。
図 6 通話のルーティング (稼働時間中) (画像をクリックすると拡大表示されます)
別のユーザーまたは番号に通話が直接転送された場合、そのユーザーまたは番号用の着信ルーティングのルールが適用されます。ユーザーは、別の番号またはユーザーに不在時の着信を転送するように設定することもできます。
ユーザーが転送ルールの [Apply only during my Outlook Working Hours] (Outlook で指定した稼働時間中にのみ適用する) チェック ボックスをオンにすると、図 6 のルールは稼働時間中に適用され、それ以外の時間に、登録済みのエンドポイントを呼び出す既定の動作が適用されます。この動作を提供するには、組織に Microsoft Exchange Server 2007 および Outlook 2007 クライアントが展開されている必要があることに注意してください。Communicator は、Exchange 2007 可用性 Web サービスから提供される稼働時間情報を使用します。また、Outlook 2007 の自動検出サポートを活用して、サーバーの場所を取得します。

品質報告とトラブルシューティング
OCS 2007 システムのクライアントでは、次世代のオーディオ コーデックである RTAudio が使用されます。このコーデックは、ジッターやパケット損失などの不完全なネットワーク状態に対処できます。ただし、管理者が潜在的なホットスポットを見つけて修正できるように、監視は必ず行う必要があります。OCS 2007 システムのクライアントは、各通話の終了時に、それぞれの通話品質と詳細な統計情報を、一元管理された Quality of Experience (QoE) サーバーに報告します。具体的には、帯域幅、損失、ジッター、平均オピニオン評点 (ユーザーの認識を調査するための評価尺度)、使用されたデバイスなどの情報を提供します。この報告は、ペイロードを SIP SERVICE 要求で QoE サーバーに送信することによって行われます。QoE サーバーのアドレスは、インバンド プロビジョニング メカニズムを使用して自動的に取得されます。
すべてのクライアント エンドポイントが、個別に通話品質を QoE サーバーに報告することに注意してください。シグナリングのエラーが原因で通話が失敗した場合、クライアントは同じ内容を OCS にも報告します。これにより、クライアントで作成されたすべてのエラーのリポジトリが提供されます。

すべての側面を一元管理する
ここまで、番号の入力、着信ルーティングと発信ルーティング、接続の確認など、通話の設定に関するいくつかの側面について説明しました。次は、この処理を全体的な視点から見ていきましょう。図 7 は、ユーザーが通話を開始した時点からの処理の流れを示しています。OCS システムのクライアントは、通話のセットアップにおいて重要な役割を果たし、このセットアップ処理全体を取り仕切っています。また、OCS は通話の最初のルーティングに関与し、エッジ サーバーは、クライアントがメディアの最適なルートを検出する処理を支援します。では、その次の処理、つまり会話について見ていきましょう。
図 7 エンド ツー エンドの通話の流れ (画像をクリックすると拡大表示されます)

マルチモーダルな動作と会話
会話は、OCS システムの最も重要な概念です。会話は 2 人以上のユーザー間で発生するマルチモーダルなセッションで、音声、ビデオ、IM に加え、セッション中のファイル転送、Outlook の電子メール、Microsoft Office OneNote® に保存されたノートなど、さまざまなアイテムを同時に使用できます。
次に示す会話のいくつかの側面は、OCS クライアント システムの設計に影響を与える可能性があります。
  • 会話に関連するすべてのモダリティでは、同じウィンドウが使用されます。たとえば、音声会話に追加されたインスタント メッセージは、音声会話と同じウィンドウに関連付けられます。
  • 会話はさまざまなデバイス間で発生します。ユーザーは、Communicator Phone Edition で音声を使用し、同時に Communicator デスクトップで IM を使用できます。
  • すべてのモードが同時に会議に昇格します。昇格が発生した場合、現在デバイスでどのモダリティを使用しているかにかかわらず、会話のすべてのモダリティが同時に昇格します。たとえば、Communicator Phone Edition で音声モードが有効になっており、Communicator デスクトップで同じ会話の IM モードが有効になっている場合、会議への昇格が発生したときに、音声と IM の両方でその会話に必ず同じ参加者が含まれます。
  • 会話 (個々のセッション単位ではありません) はログに記録されます。通話ログには、会話中に取ったメモの詳細、インスタント メッセージの交換、音声の継続時間など、会話に関する情報がすべて記録されます。これによってユーザーは、Outlook で通話ログを開いて、会話の内容全体をまとめて簡単に確認できます。
  • 会話のログから会話を続行できます。OCS クライアントは、会話 ID (デバイスとアプリケーション間の会話を一意に識別する番号) を使用して会話どうしを関連付けます。新しい会話が古い会話の履歴ログから開始されると、複雑なメカニズムによって会話の差分が計算されます。また、同じ会話 ID が電子メールの ID として Outlook に保存されます。
会話 ID は、SIP INVITE に含まれるカスタム プロパティ Ms-Conversation-Id として送受信されます。図 8 は、最初に音声が追加され、次に IM が追加されるトランザクションを示しています。マルチモーダルな会話の最後に、同じ会話 ID を持つ履歴ログが Outlook に保存されることに注意してください。
図 8 マルチモーダルな会話と会話 ID (画像をクリックすると拡大表示されます)

Exchange UM は、OCS 2007 に対応したボイスメール システムです。OCS は、UC に対応したユーザーの通話のみを Exchange UM にルーティングします。OCS では、Exchange UM との連動に必要ないくつかの機能が提供されます。
  • ユーザーは、Communicator の電話 UI で [ボイス メールの呼び出し] をクリックすると (図 9 参照)、PIN を入力する必要なく、UM メールボックスの管理、案内応答の変更などの操作を行うことができるようになります。その理由は、このユーザーが既に認証されているためです。
  • ユーザーは、Communicator の UI に表示される、未開封のメッセージを示すインジケータ (図 10 参照) を使用して、Outlook でボイスメール フォルダを開くことができます。また一方で、Communicator Phone Edition のインジケータを使用して、直接電話から音声メッセージを再生することもできます。
  • 通話を Communicator の UI からボイスメールに転送できます。
  • 拒否された通話は、自動的にボイスメールにルーティングされます。
  • Outlook でボイスメール アイテムの [電話で再生] を使用して、Office Communicator クライアントを直接呼び出すことができます。
図 9 Communicator の [ボイス メールの呼び出し]
図 10 未開封のメッセージを示す Communicator のインジケータ
OC がボイスメール通知を受信するメカニズムは、Communicator Phone Edition とは異なります。OC は、新しいメールが届いたことを示す通知を Outlook のボイスメール検索フォルダに登録し、このフォルダで新しいメッセージを報告します。また、Communicator では不在着信した会話と通話ログも使用されます。

まとめ
この記事では、いくつかの RFC を利用した SIP を基に構築されたシステムである OCS 2007 の音声通話のしくみについて説明しました。クライアント エンドポイントは、OCS での通話の管理において中心的な役割を果たします。すべての音声通話は、既定で安全に暗号化されます。また、OCS によって、番号の操作とシステム全体のフロー制御を可能にする柔軟なコンポーネントが提供されます。
会話は、音声、IM、およびビデオが関連する、OCS の中心的な概念です。OCS は Exchange UM と連動しているので、Communicator エンドポイントにボイスメールに関する通知を送信したり、Communicator エンドポイントで Outlook を使用してボイスメールにアクセスしたり、サーバーから直接ボイスメールにアクセスしたりできます。

Rajesh Ramanathan は通信業界に 14 年間携わっており、Office Communicator 2007 の音声プロトコル、ユーザー エクスペリエンス、音声、および会議を設計しました。現在はマイクロソフトで Office Communicator チームのリード プログラム マネージャを務めています。連絡先は rajeshra@microsoft.com (英語のみ) です。


コミュニケーションとコラボレーション
Groove と SharePoint で強いつながりを作る
Alan Maddison
概要 :
  • SharePoint ドキュメント ライブラリを作成する
  • Groove ワークスペースを作成する
  • Groove と SharePoint を同期する
  • ワークスペースへのアクセスを許可する

目次
Groove と SharePoint を併用する
概要
承認の制御を設定する
Groove ワークスペースを作成する
Groove と SharePoint を同期する
ワークスペースへのアクセスを許可する
まとめ
IT プロフェッショナルは、Microsoft Office Groove 2007 (Groove) と Microsoft Office SharePoint Server 2007 (SharePoint) が明らかに似ていることを不思議に思うことがよくあります。また、
それぞれの製品がどのような状況に適しているか判断できません。一見、これらの 2 つの製品は、両方ともコラボレーション機能を提供するという点でよく似ているように見えます。ただし、アーキテクチャを詳しく見ると、これらの製品の違いがわかります。
SharePoint® は、構造化ワークフローをサポートする、堅牢でスケーラブルなコンテンツ管理フレームワークとコラボレーション ツールセットを提供します。一方、Groove™ は、迅速なワークスペースの展開を可能にするコラボレーション ツールセットで、IT オーバーヘッドはほとんど発生しません。ドキュメント コラボレーション、スレッド化されたディスカッション、予定表などの機能のサポートにより、Groove はセキュリティで保護された動的なアドホック コラボレーションに最適なフレームワークを提供します。つまり、ほとんどのユーザーは、最終的にはこれらの製品をさまざまな方法で使用できます。
さらに、Groove 2007 のリリースにより、SharePoint ファイル ツールを使用した SharePoint との統合のサポートが組み込まれました。このツールを使用すると、Groove ワークスペースを SharePoint ドキュメント ライブラリと同期することができます。また、これから説明するように、組み込みの統合とは、両方の製品を容易かつ最大限に活用できることを意味します。実際、Groove の柔軟性や動的性質を SharePoint の高度な機能や能力と組み合わせることで、多くのユーザーは大きな利点を得られます。
Groove と SharePoint を併用する
今日の IT 世界では、組織とそのパートナーやベンダのコラボレーションがますます増えています。しかし、SharePoint などの製品を使用して実装される強力なコラボレーション ソリューションは、内部チームと、情報を組織全体で使用できるようにする必要性に大きな重点を置く傾向があります。このような場合は、管理とセキュリティの両方の観点から、組織の外部のユーザーにアクセスを許可することが重要な課題になります。この課題に直面すると、ユーザーに外部パートナーへのアドホック アクセスを可能にすることが目標になってきます。
Groove と SharePoint を組み合わせることで、まさにこのソリューションが実現されます。SharePoint には、組織内コラボレーション、コンテンツ検索、およびワークフロー フレームワークの機能が用意されています。Groove を追加すると、企業はこれらの機能を拡張して組織間コラボレーションを容易に実現できます。Groove では、ユーザーは企業の境界を越えたコラボレーション ワークスペースをすばやく設定できます。さらに、192 ビット Advanced Encryption Services (AES) の対称キーのサポートにより、コラボレーションがセキュリティで保護されます。実際には、Groove のセキュリティは組み込みで常に有効になっているため、ユーザーがセキュリティの構成を気にする必要はありません。
Groove のセキュリティ アーキテクチャは、これらのワークスペースとそのコンテンツを、ローカルに保存するときもネットワーク送信中にも高度に保護します。SharePoint ファイル ツールを使用すると、この情報を SharePoint ドキュメント ライブラリと双方向で同期できるため、中央の情報に社内から簡単にアクセスできます。具体的な例を使用して、このプロセスの動作を確認しましょう。
概要
多くの場合、組織は毎日のビジネス アクティビティで多くの企業と協力します。一般に、これには外部の組織だけでなく、財務部、企業広報部、法務部など、定期的に共同作業するとは限らない部門の個人も含まれます。したがって、これらの組織は、共同作業を行う臨時の内部チームを編成し、共同作業に参加しないが最終的な成果物にアクセスする必要のある組織または個人がこの共同作業の成果を利用できるようにする必要があります。SharePoint と Groove を併用すると、これらを簡単に達成できます。
Groove ワークスペースと同期する SharePoint ドキュメント ライブラリがない場合は、まずドキュメント ライブラリを作成します。これを行うには、SharePoint に接続し、[すべてのコンテンツの表示] をクリックします。このページが読み込まれたら、[作成] をクリックし、図 1 に示すように [ライブラリ] 列の [ドキュメント ライブラリ] をクリックします。
図 1 SharePoint ドキュメント ライブラリの作成 (画像をクリックすると拡大表示されます)
新しいドキュメント ライブラリのページには、構成する多数の設定が表示されます。ライブラリの名前と説明、ライブラリをクイック リンク セクションに含めるかどうか、バージョン管理を有効にするかどうか、ライブラリで直接作成された新しいドキュメントの既定の形式などを指定します。ドキュメントのバージョン履歴は既定では無効になっていますが、環境でバージョン管理が必要な場合は、この機能を有効にします。SharePoint の機能で、Groove と SharePoint の実装の一部として利用できる高度な機能についても検討する必要があります。このような拡張機能には、次のようなものがあります。
  • バージョン履歴
  • 承認の制御
  • チェックアウトの手続き
  • ワークフローの制御
  • ドキュメントの保持期間ポリシー
  • 監査
  • RSS (Really Simple Syndication)
SharePoint で使用できるこれらの追加機能は、Groove と併用すると価値がきわめて高くなります。この記事の例では、この追加機能、特に承認の制御が非常に有用であることがわかります。たとえば、チーム メンバが Groove 内で共同作業を行ってドキュメントの下書きを作成するとします。最終的な下書きのレビューの準備が完了すると、下書きは SharePoint と同期され、承認プロセスの対象になります。

承認の制御を設定する
この機能を構成するには、ドキュメント ライブラリから [設定] メニューをクリックし、設定項目をクリックします。構成とカスタマイズのすべてのオプションを表示できます。承認を構成するには、[権限と管理] の [ワークフロー設定] をクリックして、[ワークフローの追加] ページを表示します。ここでワークフロー テンプレート (この記事の例では承認テンプレート) を選択し、ワークフローの名前を入力します。次に、既存のタスク リストを使用するか、または新しいタスク リストを作成するかを指定する必要があります。新しいタスク リストを作成した方が機密性は高くなりますが、この例では機密性は問題ではないので既定の設定をそのまま使用します。
タスク リストを選択したら、承認プロセスの開始方法を指定する必要があります。ここでは、正しいアクセス許可を持つ認証済みユーザーに承認プロセスの開始を許可することで、承認プロセスを手動にします。その他のオプションを使用すると、バージョン管理、ドキュメント ライブラリで承認プロセスを有効にするかどうか、新しいドキュメントを追加するか既存のドキュメントを変更するか、などの設定に基づいて承認プロセスを自動化できます。
[次へ] をクリックしてこれらの構成オプションを受け入れたら、最終的な構成情報を入力する必要があります。構成する最初のオプションは、タスクの割り当て方法です。承認プロセスには複数の人が関与できるため、承認者を順次割り当てるか、複数の承認者を同時に割り当てることができます。順次割り当てる場合は、ある承認者がドキュメントを承認すると、そのドキュメントは次の承認者に渡されます。同時に割り当てる場合は、常にだれでもドキュメントを承認できます。次に、承認者に他の承認者へのタスク割り当てを許可するかどうか、および承認者にタスクの完了前に変更の要求を行うことを許可するかどうかを指定する必要があります。
次の手順では、実際の承認者を選択し、タスクの完了期限を指定します。最後に、ワークフローが完了するタイミングを指定します。既定のオプションでは、ワークフローはすべてのタスクが終了したときに完了します。最後の構成オプションでは、ワークフローの完了時に承認ステータスを更新するかどうかを指定します。[OK] をクリックすると、承認プロセスが作成され、ドキュメントの承認プロセスを開始できます。

Groove ワークスペースを作成する
SharePoint ドキュメント ライブラリを作成したら、次に Groove ワークスペースを作成します。これを行うには、まず、Groove アカウントと少なくとも 1 つの ID を持っていることを確認します。ID は、Groove 内のプレゼンスと通信の基本です。各 Groove アカウントに複数の ID を関連付けることができます。各 ID には一意の連絡先ファイルが関連付けられているため、使用する ID ごとに連絡先情報をカスタマイズできます。Groove アカウントおよび関連付けられている ID をエクスポートして、複数のコンピュータで使用することもできます。
アカウントと ID を作成したら、システム トレイの Groove アイコンをダブルクリックして、Groove 起動バーを開きます。[新しいワークスペース] オプションをクリックし、ワークスペースの適切な名前を入力します。次に、標準タイプのワークスペースを選択します。Groove 標準ワークスペースを使用すると、ワークスペース メンバのプレゼンス、通知、およびロールの割り当てが容易になります。[OK] をクリックすると、ワークスペースが作成され、表示されます。図 2 は、ファイル ツールにファイルが追加された新しいワークスペースを示しています。この時点では、ワークスペースは機能し、通知を構成するか必要なツールを追加することでセットアップを完了できます。
図 2 新しい Groove ワークスペース (画像をクリックすると拡大表示されます)
通知は、ツール、ワークスペース、または個々のファイル レベルで構成できます。通知には、なし、中、高、自動という 4 つのレベルがあります。中に設定すると新しいコンテンツが強調表示され、高または自動に設定するとオーディオ ファイルが再生されます。ユーザーが特定のワークスペースにアクセスしたときに知らせるように通知を構成することもできます。通知を構成するには、[オプション] メニューの [通知の設定] をクリックします。個々のファイルに対する通知は、ファイル自体のプロパティで設定します。これを行うには、ワークスペースでファイルを右クリックし、[プロパティ] をクリックします。
ドキュメント コラボレーション用のファイル ツール、既定の標準ワークスペースに含まれるスレッド化されたディスカッション用のディスカッション ツールに加え、予定表、フォーム、案件管理、会議、スケッチパッド、そして言うまでもなく SharePoint ファイル ツールなど、他にも多くのツールがあります。それぞれのツールに、有用な追加コラボレーション機能が用意されています。ツールを追加するには、ワークスペースの右下にある [このワークスペースにツールを追加します] をクリックし、図 3 に示すように追加するツールをクリックします。ツールはいつでも簡単に削除できます。
図 3 Groove ワークスペースへのツールの追加 (画像をクリックすると拡大表示されます)

Groove と SharePoint を同期する
SharePoint ファイル ツールを追加したら、同期するドキュメント ライブラリが含まれている SharePoint サイトの URL を設定する必要があります。これを行うには、Groove ワークスペース画面の下部にある [SharePoint ファイル] タブをクリックし、図 4 に示す Groove ワークスペースの [設定] をクリックするだけです。
図 4 SharePoint ファイル ツールの設定 (画像をクリックすると拡大表示されます)
URL を入力すると、その SharePoint サイトにある利用可能なすべてのライブラリが表示されます。次に、図 5 に示すように、使用するライブラリを選択します。Groove がライブラリに接続し、自動同期を開始します。つまり、SharePoint ライブラリ内のドキュメントがダウンロードされ、Groove ワークスペースで使用できるようになります。図 6 に例を示します。
図 5 URL の設定後、Groove で使用可能になる SharePoint ライブラリ (画像をクリックすると拡大表示されます)
図 6 Groove と SharePoint の同期 (画像をクリックすると拡大表示されます)
ドキュメントはダウンロードされたばかりなので、Groove ワークスペースに未読として表示されます。SharePoint と同期されたすべてのファイルは、SharePoint のチェックイン/チェックアウト機能を利用できます。さらに、ファイルをチェックアウトする場合、ドキュメントの編集中に他のユーザーが変更できないようにすることもできます。
SharePoint ファイル ツールには双方向の同期機能が用意されています。したがって、Groove を使用してファイルを SharePoint ファイル ツールに追加すると、そのファイルは SharePoint ドキュメント ライブラリと同期されます。既定では同期が自動的に行われるように設定されていますが、[今すぐ同期] をクリックして手動で同期を開始することもできます。手動で同期を開始すると、図 7 に示すように、同期が必要なファイルの変更の概要と、関連付けられているアクション (SharePoint からの取得または SharePoint への送信) が表示されます。
図 7 手動同期後に表示される変更の概要 (画像をクリックすると拡大表示されます)
覚えておく必要がある重要なポイントは、Groove 標準ワークスペースの一部として展開されたファイル ツールは、SharePoint ファイル ツールとは異なるということです。Groove ファイル ツールは SharePoint と同期しないため、必要に応じて削除できます。ただし、SharePoint と同期しないことから、プロジェクトの過程でチームがアクセスする必要がある一時ファイルの保存場所として、ツールが使用されている場合があります。ここに格納されたファイルはワークスペース メンバの間で同期されます。

ワークスペースへのアクセスを許可する
これで基本的なコラボレーション インフラストラクチャを展開したので、ワークスペースへのユーザー アクセスを許可できます。ただし、まず電子メールや Groove インスタント メッセージングを使用してユーザーを招待する必要があります。または、Groove で招待文をファイルにエクスポートすることもできます。.grv という拡張子の付いたこのファイルは、既定では Groove アプリケーションに関連付けられ、Web サイトに配置したり受信者に招待のダウンロードを許可するなど、さまざまな方法で配布できます。
Groove インスタント メッセージングにはセキュリティ チェック機能が用意されているため、受信者だけが招待メールを読み取ることができます。電子メールまたは招待ファイルを使用して招待する場合は、[承諾の確認を必要とする] チェック ボックスをオンにして、ワークスペースに参加するユーザーが、自分が招待したユーザーであることを再確認する必要があります。これにより、ワークスペースのセキュリティがさらに強化されます。保留中の招待をキャンセルできることもできます。
ユーザーをワークスペースに招待するときに、各受信者のロールを選択する必要があります。管理者、参加者、ゲストの 3 つのロールがあり、既定では参加者が割り当てられます。各ロールにはワークスペースにおける特定の権限があります。一般に、管理者ロールは、ワークスペース内のすべての権限 (ツールを削除する権限など) を本当に必要とするユーザーにのみ割り当てる必要があります。ワークスペースの作成者には既定で管理者ロールが割り当てられますが、割り当てられているロールはいつでも変更できます。
この記事のプロジェクトは暫定的なものであるため、すべての処理が完了したら最後のタスクとして Groove ワークスペースを削除します。ワークスペースが SharePoint ライブラリと同期されたことを確認したら、ワークスペースを開き、[ファイル] メニューの [ワークスペースの削除] をクリックします。次に、[このコンピュータから] または [メンバ全員を対象] をクリックします。各ユーザーは自分のコンピュータにワークスペースのコピーを保存しているため、メンバ全員を対象に削除しない限り、そのコピーは永続的に使用できます。
プロジェクトが無事完成すると、Groove と SharePoint の相補的性質を活用できるようになります。ドキュメントの最後の同期が行われると、SharePoint の情報管理ポリシーの設定を利用できる最適な状況になります。特に、データの有効期限を有効にすると、アーカイブしたデータを自動的に管理できます。
有効期限を有効にすると、データを保存する期間を指定できます。この保存期間の終了時に、SharePoint は自動的にデータを削除するかワークフロー プロセスを開始します。この機能により、Groove データを会社の情報ライフサイクル管理ポリシーに組み込むことができます。データの保存期間ポリシーはいつでも構成できます。実際、ライブラリを最初に構成したときに保存期間ポリシーを構成しなかった場合は、今すぐ構成できます。
有効期限を有効にするには、ドキュメント ライブラリから [設定] メニューをクリックし、[ドキュメント ライブラリの設定] をクリックします。[権限と管理] に [情報管理ポリシーの設定] オプションが表示されます。[情報管理ポリシーの設定] をクリックすると、定義する新しいカスタム ポリシーを指定するか、サイト レベルで定義されているポリシーをドキュメント ライブラリで使用するようにできます。
カスタム ポリシーを定義する場合は、構成情報を入力する必要があります。この記事の例では、有効期限を有効にし、保存期間と保存期間の終了時に実行するアクションを選択します。
Groove は、機能豊富なコラボレーション クライアントで、セキュリティで保護された動的かつ直感的なフレームワークをアドホック コラボレーション用に提供します。豊富なツールセットにより、組織内または異なる組織間で容易に使用できる、軽量で適応性の高いコラボレーション プラットフォームを提供します。
会社で既に SharePoint を使用して堅牢で強力なコンテンツ管理フレームワークとコラボレーション ツールセットを実装している場合は、SharePoint を Groove と組み合わせることで、非常に魅力あるソリューションが提供されることをおわかりいただけると思います。これらの 2 つの製品は相補性が高いため、併用することでコラボレーション チームの生産性を大幅に向上できます。

Alan Maddison は、Brocade の 1 部門である Strategic Business Systems のシニア コンサルタントです。


Windows の管理
Windows Server 2008 フェールオーバー クラスタリングの概要
Chuck Timon
概要 :
  • フェールオーバー クラスタの管理スナップイン
  • 新機能と強化点
  • バックアップおよび復元機能
  • Windows Server 2003 からの移行

目次
新しい管理インターフェイス
構成プロセスの強化
検証手順の組み込み
新しいクォーラム モデル
セキュリティ機能の強化
ネットワーク機能の強化
記憶域との対話における信頼性の向上
組み込みの障害回復プロセス
新しいバックアップおよび復元機能
Windows Server 2003 サーバー クラスタからの移行
Windows NT 4.0 Enterprise Edition に最初にクラスタリングが導入されて以来、「セットアップが難しく、保守はさらに難しい」という苦情がユーザーから寄せられています。クラスタを管理するには、
クラスタの構成要素を理解するだけでは足りません。管理者は、ストレージ テクノロジについて、またクラスタ サービスがさまざまなストレージ ソリューションとやり取りする方法について、詳細な知識を要求されます。高可用性ソリューションを稼働し、保守するために必要な総合的なスキルを得ることは、多くの企業にとって難題でした。
クラスタリング技術はここ数年で向上していますが、まだまだ十分と言えるレベルには達していません。そうした中、マイクロソフトは Windows Server® 2008 の開発を開始しました。マイクロソフトの開発チームは、こうした状況を考慮し、簡易性の実現を第一目標に置いて、クラスタリングの再設計を開始しました。Windows Server 2008 では、Microsoft® Cluster Services (MSCS) を全面的に見直し、名称もフェールオーバー クラスタリングに変更されました。
だからといって、フェールオーバー クラスタリングの実装では簡易性だけが考慮されたというわけではありません。マイクロソフトは数年にわたり、ユーザー企業からクラスタリング ソリューションに関する要望について価値あるフィードバックを受け取り、多くの教訓を学んできました。フェールオーバー クラスタリングは、ユーザーから報告された主要な問題点の大半を解決しているだけでなく、いくつかの興味深い新機能が追加され、非常に魅力的な製品になっています。この記事では、Windows Server 2008 フェールオーバー クラスタリングの新しい機能をいくつか紹介します。

新しい管理インターフェイス
フェールオーバー クラスタリングをインストールすると、管理ツール内で、または Cluadmin.msc を実行することで、フェールオーバー クラスタ管理インターフェイスにアクセスできます。フェールオーバー クラスタの管理スナップインは、Windows Server 2008 の他の管理インターフェイスと同様、Microsoft 管理コンソール (MMC) 3.0 スナップインです。従来のクラスタ環境に慣れたユーザーがフェールオーバー クラスタの管理スナップインを初めて起動すると、まるで地図も持たずに外国に置き去りにされたような気持ちになるでしょう。
新しいインターフェイスは 3 つのペインで構成されています (図 1 参照)。左側のペインには、組織内のすべての Windows Server 2008 フェールオーバー クラスタが一覧表示されます。中央のペインには、左側のペインで選択したクラスタ構成部分の詳細が表示されます。右側のペインには、実行可能なアクションが表示されます。
図 1 フェールオーバー クラスタの管理スナップイン (画像をクリックすると拡大表示されます)
たとえば、左側のペインで [記憶域] をクリックすると、中央のペインには、クラスタでプロビジョニングされている記憶域、および現在使用可能な記憶域について詳細な情報が表示されます。図 1 からわかるように、クラスタは、記憶域の監視ディスク部分、ファイル サーバー用にプロビジョニングされた記憶域、および使用可能な記憶域から成ります。右側のペインには、記憶域の追加などの関連するアクションが一覧表示されます。フェールオーバー クラスタの管理スナップインを使用して旧バージョンの Microsoft クラスタサービスを管理することはできない点に注意してください。

構成プロセスの強化
フェールオーバー クラスタの構成作業は非常に簡単です。クラスタを構成、再構成、および管理するためのほとんどの作業には、ウィザードが用意されています。これらのウィザードを使用すると、管理者は、各種リソースが正しく構成されているかどうかや、それらが正しい順番でオンライン状態になるかどうかを心配する必要がなくなります。
図 2 に、高可用性ウィザードを示します。この例では、ファイル サーバーを構成しています。左側には、ウィザードによって実行された手順が一覧表示されます。プロセスが完了すると、サマリー ページが表示され、レポートを確認できます。
図 2 高可用性ウィザード (画像をクリックすると拡大表示されます)

検証手順の組み込み
旧バージョンの Windows Server では、サポートされているクラスタ ソリューションであると見なされるには、Windows Server Catalog にクラスタ ソリューションとしてハードウェア構成が表示されていなければなりませんでした。マルチサイト クラスタも同様ですが、こちらは Geographically Dispersed (地理的に分散した) カテゴリに別表示されていました。ハードウェア ベンダは、自社製品が Windows Server Catalog に表示されるようにするために、Windows Hardware Quality Lab (WHQL) テストを実行し、その結果をマイクロソフトに送信する必要がありました。これはベンダにとって手間のかかる作業であり、Windows Server Catalog データベースの保守も容易ではありませんでした。
Windows Server 2008 では、フェールオーバー クラスタリングに検証プロセスが組み込まれています。このプロセスは、図 3 に示した 4 つの主要カテゴリに分類される一連のテストから成ります。
図 3 フェールオーバー クラスタ検証テストのカテゴリ (画像をクリックすると拡大表示されます)
この例では、[ネットワーク] カテゴリが展開され、実行されるテストが表示されています。各カテゴリは一連のテストで構成されます。[記憶域] は、4 つのカテゴリの中で最も重要なものであり、Windows Server 2008 フェールオーバー クラスタに新たに導入された要件に記憶域が準拠していることを確認するテストが含まれています。
具体的には、ハードウェア ベンダは Microsoft Storport ドライバに準拠したドライバを使用する必要があり、さらに SCSI-3 Persistent Reservation (永続的な予約) もサポートする必要があります。また、デバイス固有のマルチパス ソフトウェア モジュールを使用する場合は、Microsoft Multi-Path Input/Output 標準に準拠している必要があります。
この検証プロセスが組み込まれたことで、サポート モデルも変更されました。すべてのハードウェアに Windows Server 2008 ロゴを貼付することが義務付けられ、すべての検証テストに合格することが要求されます。ただし、各サイトにそれぞれ個別のストレージ エンクロージャを使用しており、Exchange Server 2007 クラスタの連続レプリケーションを実装している (共有記憶域を使用していない) マルチサイト クラスタは対象外です。

新しいクォーラム モデル
Windows Server 2008 のフェールオーバー クラスタリングではクォーラム モデルも変更されました。旧システムでは、クォーラムとは、クラスタ構成と一部のレプリケートされたファイルが置かれた共有ディスクを指していました。それは、クラスタの単一障害点でした。このため、クォーラム ディスクで障害が発生すると、クラスタ サービスは停止し、高可用性は失われていました。
Windows Server 2003 サーバー クラスタでは、マジョリティ ノード セット (MNS) クォーラムと呼ばれる 2 つ目のタイプのクォーラムが提供されました。このタイプのクォーラムは通常、マルチサイト クラスタで実装され、共有記憶域を必要としません。マジョリティ ノード セット (MNS) クォーラムは、各クラスタ ノードのシステム ドライブ上に存在するファイル共有で構成されます。このタイプのクォーラムに対する接続は、サーバー メッセージ ブロック (SMB) 接続によって行われます。それでも、クラスタが機能するためには、ノードの大部分がクラスタに参加している必要がありました。
Exchange Server 2007 でクラスタ連続レプリケーション (CCR) が導入されると、Windows Server 2003 サーバー クラスタに、ファイル共有監視 (FSW) 機能が追加されました。これにより、FSW への接続によってマジョリティが達成されている限り、単一の Exchange 2007 CCR クラスタ ノード (または任意のマルチサイト クラスタ) でサービスを提供し続けることができるようになりました。
Windows Server 2008 フェールオーバー クラスタリングでは、クォーラムが本当にコンセンサスを意味するようになりました。クォーラム、つまりコンセンサスは、クラスタを稼働させるのに十分な票を獲得することによって達成されます。十分な票を獲得するには、クォーラムの設定に応じていくつかの方法があります。Windows Server 2008 フェールオーバークラスタには 4 つのクォーラム モードが用意されています (図 4 を参照)。4 つのモードのうち、最初の 2 つ ([ノード マジョリティ] と [ノードおよびディスク マジョリティ]) だけは、クラスタ作成プロセス中に自動的に選択できます。どちらを選択するかは次のロジックに従います。
  • クラスタが奇数個のノードで構成されている場合は、[ノード マジョリティ] モードを選択します。
  • クラスタが偶数個のノードで構成されており、共有記憶域が接続されていてアクセス可能な場合は、[ノードおよびディスク マジョリティ] モードを選択します。
図 4 クラスタ クォーラム構成ウィザード (画像をクリックすると拡大表示されます)
使用可能な記憶域から監視ディスクを選択するには、容量が 500 MB 以上で、NTFS パーティションが構成されている最初のディスクを選択します。残りの 2 つのクォーラム モードは、クラスタ クォーラム構成ウィザードを実行して手動で選択します。[ノードおよびファイル共有マジョリティ] オプションは通常、マルチサイト クラスタ構成または Exchange 2007 CCR クラスタで使用します。最後のオプション [非マジョリティ: ディスクのみ] オプションは、旧バージョンのクラスタの共有クォーラム モデルと等価です。これは単一障害点となるため、一般に使用ないことをお勧めします。
監視リソースには、物理ディスクとファイル共有の 2 種類しかありません。クラスタに監視リソースを構成することで、コンセンサスを達成することができます。
監視ディスクは、クラスタ サービスがオンラインにできる記憶域です。このディスクは、クラスタ コア リソース グループ内に、クラスタ ネットワーク名および対応する IP アドレス リソースとまとめて管理されています。監視ディスクを構成すると、そのディスク上に Cluster フォルダが作成され、クラスタ構成の完全なコピー (クラスタ ハイブまたはレプリカ) が格納されます。
FSW は、(理想的な状況では) ネットワーク上のクラスタに属さないサーバー上に存在するネットワーク共有です。FSW に対して SMB 接続が確立され、FSW には監視ログ ファイルのコピーが保持されます。このファイルには、クラスタ構成のバージョン情報が保管されています。
1 つのクラスタに構成できる監視リソースは 1 つだけです。クラスタがクォーラムを達成するためにあと 1 票が必要な場合は、このリソースがその 1 票を投票します。言い換えると、クラスタがあと 1 票 (つまり 1 ノード) でコンセンサスを達成できる場合は、監視リソースをオンラインにしてクォーラムを達成できます。クラスタがコンセンサスを達成するのに 2 票以上が必要な場合、監視リソースは単独を維持し、クラスタは休止状態のまま、別のクラスタ ノードの参加を待機します。

セキュリティ機能の強化
フェールオーバー クラスタでは、いくつかセキュリティ面での強化が行われています。その中でも最も重要なのが、クラスタ サービス アカウント (CSA) 要件の削除です。旧バージョンの Microsoft クラスタ サービスでは、構成プロセス時にドメイン ユーザー アカウントが必要でした。クラスタ サービスを起動するときに使用されるこのアカウントは、クラスタの各ノードのローカル管理者グループに追加され、クラスタ サービスが正常に機能するために必要なローカル ユーザー権限を与えられます。CSA は、ドメイン ユーザー アカウントとして、クラスタ ノードに適用できる多数のドメイン レベル ポリシーに従います。これらのポリシーは、クラスタ サービスに障害を引き起こして高可用性を低下させる可能性があります。
現バージョンより、クラスタ サービスは、ローカル クラスタ ノード上で正常に機能できるように特定の権限セットが与えられたローカルのシステム アカウントの下で、実行されるようになりました。クラスタのセキュリティ機能はクラスタ名オブジェクト (CNO) に移行されました。CNO は、クラスタを最初に作成したとき、既定では Active Directory® の Computers コンテナ内に作成されるコンピュータ オブジェクトです。クラスタが正常に作成され、Active Directory 内に CNO が存在していれば、クラスタのインストールと構成に使用したユーザー アカウントを残しておく必要はなくなりました。
Active Directory の Computers コンテナ内には、フェールオーバー クラスタに関連する別のコンピュータ オブジェクトも作成されます。これらのオブジェクトは仮想コンピュータ オブジェクト (VCO) と呼ばれ、クラスタ内にクライアント アクセス ポイント (CAP) の一部として作成されるクラスタ ネットワーク名リソースと等価です。クラスタ内のすべての VCO の作成を担当する CNO は、Active Directory 内のシステム アクセス制御リストに追加されます (図 5 参照)。
図 5 Active Directory 内の VCO によるセキュリティ (画像をクリックすると拡大表示されます)
CNO は、自身が作成したすべての VCO についてドメイン パスワードの同期も行います。このプロセスは、パスワードのローテーションに関する構成済みのドメイン ポリシーに従って実行されます。また、CNO (コンピュータ アカウント) は、クラスタ内の VCO に関連付けられたすべてのコンピュータ オブジェクトの作成を行うため、VCO が作成されたコンテナ (既定では Computers コンテナ) 上にコンピュータ オブジェクトを作成するためのドメイン レベルの権限を保有している必要があります。
さらに、Kerberos が既定の認証方式として使用されるように変更されました。コンピュータ アカウントが Active Directory 内に定義されたため、こうしたセキュリティ機能の向上が可能になりました。ただし、認証に Kerberos を使用できないアプリケーションがクラスタ リソースにアクセスする必要がある場合、クラスタは NT LAN Manager (NTLM) 認証を使用できます。
クラスタ プロセスを直接処理するクラスタ ノード間の通信についてもセキュリティが向上しています。既定では、すべてのクラスタ内通信が署名されます。このクラスタ プロパティは、cluster.exe 共通言語インターフェイス (CLI) を使用して、ノード間のすべての通信が暗号化されるように変更できます。これにより、セキュリティ レベルをさらに高めることができます。

ネットワーク機能の強化
フェールオーバー クラスタの新しいネットワーク機能を使用すると、高可用性および障害復旧ソリューションの柔軟な設計が可能になります。同時に、これらのネットワーク機能の強化によって、クラスタ内ノード間の接続の信頼性も向上しています。
ユーザーからの要望が最も多かった機能として、別のネットワーク上のクラスタ ノードの検索機能があります。現バージョンでは、この機能が実現されています。クラスタ ネットワーク ドライバは、クラスタ内の各ノードが少なくとも 2 つの異なるネットワーク経路で接続されている場合に、ノード間で信頼性の高いフォールト トレラントな通信を実現するように全面的に書き換えられました。
クラスタ ネットワーク ドライバは、クラスタのスタートアップ プロセス中に提供された接続情報に基づいて、固有の内部ルーティング テーブルを作成します。この接続情報には、ローカルの接続情報、およびクラスタ構成データベース (クラスタ レジストリ ハイブ) 内で提供されている情報が含まれます。
クラスタ検証プロセスには、ネットワーク接続性の検出プロセスが含まれています。異なるルーティング ネットワーク上にあるクラスタ ノードを検索できるようになったため、マルチサイト クラスタのネットワーク要件が緩和されました。これにより、企業は、より簡単に低コストでクラスタを展開できます。また、iSCSI 記憶域が、フェールオーバー クラスタ向けのストレージ ソリューションとして、より魅力的な存在になります。
クラスタ ノードは、DHCP (動的ホスト構成プロトコル) を介して IP アドレス情報も取得できます。これにより、自社環境でサーバーの動的アドレス指定を使用することを承諾する場合には、ネットワーク管理者の負担が軽減されます。
クラスタ ノードのネットワーク インターフェイスの構成によって、各ネットワークで静的 IP アドレスと動的 IP アドレスのどちらが使用されるのかが決まります。DHCP サーバーからクラスタの IP アドレス リソースを取得している場合でも、フェールオーバー クラスタの管理スナップイン内で静的 IP アドレスに変更できます。
これまでは、すべてのクラスタ通信にユーザー データグラム プロトコル (UDP) ブロードキャスト (場合によってはマルチキャスト) を使用していました。現バージョンより、マルチキャスト機能は廃止され、クラスタ通信に UDP ユニキャストが使用されるようになりました (3343 番ポートは、依然として、Microsoft クラスタによって使用される共通ポートです)。ブロードキャストが使用されなくなったことについては、多くのネットワーク管理者が満足するでしょう。しかし、この変更点がクラスタにもたらす本当の利点は、クラスタ サービス自身の内部で行われる新しいメッセージング処理と関連しています (この点はこの記事で取り扱う範囲を超えているので触れません)。クラスタ内通信は、トランスポート層には UDP が使用されているものの、より信頼性の高い TCP 通信の性質を備えたものになっています。

記憶域との対話における信頼性の向上
フェールオーバークラスタが記憶域と対話する方法は、大きく変更されています。クラスタ ディスク ドライバ (clusdisk.sys) は全面的に書き直され、本当の意味でプラグ アンド プレイ (PnP) ドライバになりました。また、同ドライバが記憶域と対話する方法も変更されています。
Windows Server 2003 では、クラスタ ディスク ドライバは記憶域へのパスに直接連結されていました。しかし、Windows Server 2008 では、クラスタ ドライバは、記憶域と対話するために、パーティション マネージャ (partmgr.sys) ドライバと通信します。この 2 つのアプローチを、図 6 に示します。
図 6 Windows Server 2008 における記憶域スタックの変更 (画像をクリックすると拡大表示されます)
パーティション マネージャの主な仕事はクラスタ ディスク リソースを保護することです。共有記憶域バス上のすべてのディスクは、最初にクラスタ ノードにマッピングされるとき、自動的にオフライン状態になります。これにより、クラスタが作成される前に、クラスタ内のすべてのノードに同時に記憶域をマッピングできます。ノードを 1 つずつブートして、ディスクを準備したらそのノードをシャットダウンして別のノードをブートし、ディスク構成を確認するなどの作業を行う必要はなくなりました。
ただし、記憶域のテストは行う必要があります。記憶域のテストはクラスタ検証プロセスの一部として実行され、ディスクの初期化を行います。この処理は、検証プロセスを実行する前にクラスタのいずれかのノードで行うことができます。クラスタに記憶域が追加されると、それらのディスクは [ディスクの管理] インターフェイスに [予約済み] ステータスであると表示され、必ず保護されている状態になります。
もう 1 つの変更点は、SCSI コマンドに関するものです。Windows Server 2003 では、SCSI-2 Reserve\Release コマンドによって、クラスタ ディスク ドライバがディスク上のセクタに書き込んでいました。Windows Server 2008 では、SCSI-3 PR (Persistent Reservation) コマンドを使用する必要があります。クラスタ ノードから記憶域上に予約を行うにはクラスタ ノードを登録する必要があります。登録されたクラスタ ノードは Reservation Defense Protocol (予約ディフェンス プロトコル) を使用して自分の予約を定期的に保護します。
検証プロセスの記憶域テストの 1 つでは、この機能を確認します。SCSI-3 (PR) コマンドをサポートしていない記憶域を、フェールオーバー クラスタで使用することはできません。
多くの企業では、記憶域接続時の冗長性を確保するため、マルチパス ソフトウェアを使用しています。マルチパス ソフトウェアはサポートされているだけでなく、ベストプラクティスとして推奨されています。ただし、サードパーティ製のマルチパス ソフトウェア、つまりデバイス固有のモジュールをフェールオーバー クラスタで使用するには、Microsoft Multi-Path Input/Output 標準に準拠するように書き直す必要があります。これにより、パスがアクティブかどうかに関係なく、すべての SCSI-3 PR コマンドが、記憶域へのすべてのパスに同時に送信されます。この機能も検証プロセスで確認されます。
他にも強化された記憶域関連機能として、チェック ディスク (chkdsk.exe) プロセスの改善、組み込みのディスク修復機能 (旧バージョンではクラスタ サーバー回復ユーティリティとして提供されていた機能)、および自己復旧ディスクがあります。フェールオーバー クラスタでは、クラスタ ディスク リソースを識別するとき、ディスク署名と LUN ID の両方を使用します。どちらか一方が変更されると、クラスタ構成が更新されます。これにより、物理ディスク リソースの属性が変更されただけでエラーになるケースが減少し、可用性が向上します。

組み込みの障害回復プロセス
上記のディスク修復機能は明らかに、組み込み障害回復機能の 1 つです。別の障害回復機能として、Active Directory 修復機能があります。CNO を表すコンピュータ オブジェクトが削除されると、クラスタ CAP に関連付けられたコンピュータ オブジェクトを作成できなくなります。しかし、最初に直面する問題はおそらく、可用性の高いアプリケーションやユーザーが、セキュリティ トークンを取得できないためにクラスタ外部のリソースにアクセスできなくなることです。
削除された CNO は、2 段階の処理で復元できます。最初に、ドメイン管理者に依頼して、Active Directory の DeletedObjects コンテナから、削除されたコンピュータ オブジェクトを復元してもらいます。次に、オブジェクトが復元され再度有効化されたら、フェールオーバー クラスタの管理スナップインの Active Directory オブジェクトの修復プロセスを実行します。
Windows Server 2003 サーバー クラスタでは、%systemroot%\cluster サブディレクトリにあるクラスタ構成ファイルが破損したために、そのファイルを置き換えなければならないことがありました。フェールオーバー クラスタでは、自己復旧機能を使用できます。あるノード上でクラスタ サービスが起動されたとき、構成データベースが破損していると、HKLM\System\CCS\Services\ClusSvc\Parameters レジストリ キーに格納されている情報を用いて最小限の構成テンプレートがロードされます。このノードが既に形成されているクラスタへの参加を試み、成功すると、クラスタ レジストリ ハイブの新しいコピーがノードにプッシュされます。クラスタへの参加に失敗すると、クラスタ サービスは停止します。

新しいバックアップおよび復元機能
フェールオーバー クラスタリングには、固有のボリューム シャドウ コピー サービス ライタが付属しています。このライタは、クラスタ データベースおよび物理ディスク リソース上に存在するデータのバックアップと復元に重要な役割を果たします。クラスタ構成のバックアップは、それほど複雑な操作ではありません。システムの状態がバックアップに含まれている限り、クラスタ構成を復元することはできます。ただし、クラスタのバックアップは、クラスタがクォーラムを保有している場合だけ実行するようにします。そうすることで、最新のクラスタ構成がバックアップされることが保証されます。
クラスタの回復には、権限のある回復と権限のない回復の 2 つのタイプがあります。権限のない回復では、Windows Server Backup またはサードパーティ製のバックアップ アプリケーションを使用して、選択したバックアップから回復を実行します。一方、クラスタ ノードの権限のある回復を実行するには必ず、Windows Server Backup CLI (wbadmin.exe) を使用する必要があります。
権限のある回復では、基本的に、バックアップが実行された時点にクラスタ構成を戻します。権限のある回復を実行するには、回復が実行されるノードを除くすべてのノード上でクラスタ サービスを停止します。回復が完了し、回復したノード上でクラスタ サービスが起動されると、回復したクラスタ構成が正式に新しいクラスタ構成になります。その後、残りのノードでクラスタ サービスが再起動されると、回復したクラスタ構成が、クラスタへの参加プロセス中に各ノードにプッシュされます。
この手法を用いることで、いくつかのシナリオで、コストと時間を大幅に節約できます。たとえば、複数の印刷スプーラ リソース (スプーラあたり 1,500 台のプリンタをサポート) をホストする印刷クラスタを構成している場合に、1 つの印刷スプーラ リソースを誤って削除し、多数のユーザーが印刷を実行できなくなったとします。このような場合は、すべてのプリンタを手動でクラスタ構成に戻すよりも、クラスタ構成の権限のある回復を行った方がずっと早く復旧できます。それには、もちろん、堅牢なバックアップおよび回復戦略が実施されていることが前提となります。

Windows Server 2003 サーバー クラスタからの移行
Windows Server 2008 フェールオーバー クラスタリングでは、ここまで説明したとおりさまざまなアーキテクチャ上の変更が行われているため、Windows Server 2003 からのインプレース アップグレードまたはローリング アップグレードを行うことはできません。Windows Server 2000 クラスタから Windows Server 2003 へのアップグレードでは、多くの組織がクラスタ内の各ノードを順番にクラスタから除去し、オペレーティング システムのクリーン インストールを実行した後、ノードをクラスタ内に戻すという作業を行いました。しかし、この方法は、Windows Server 2008 への移行では使用できません。というのは、Windows Server 2003 と Windows Server 2008 のクラスタ ノードを同じクラスタ内に混在させることはできないからです。
さいわいにも、Windows Server 2008 への移行を支援するため、ウィザード ベースの移行プロセスが用意されています。それでも、Windows Server 2008 フェールオーバー クラスタへの移行は、ある程度計画的に行う必要があります。基本的には、次の 3 つの移行シナリオが考えられます。
  • サーバーおよび記憶域ともに、移行前と同じものを使用する。
  • 移行前と同じサーバーを使用するが、記憶域は新しく用意する。
  • サーバーおよび記憶域ともに、新しく用意する。
どのシナリオでも、ハードウェアが Windows Server 2008 ロゴ プログラムによって認定されていること、およびフェールオーバー クラスタの検証プロセスが実行され、すべてのテストに合格していることを確認する必要があります。これらの手順が完了して初めて、移行プロセスを次の段階に進めることができます。
Windows Server 2003 サーバー クラスタ内のすべてのリソースを移行できるわけではありません。ネットワーク名、IP アドレス、物理ディスク、ファイル共有、分散ファイル共有 (DFS) ルート、DHCP、WINS は移行できます。また、汎用サービス、汎用アプリケーション、汎用スクリプト リソースも、制限はあるものの移行できます。
一方、Microsoft Exchange、SQL Server® などのアプリケーションは、フェールオーバー クラスタに移行するために特別な手順を実行する必要があります。プリンタを Windows Server 2008 に移行するには、まず (プリント サーバーの役割と共にインストールされる) 印刷の管理スナップインを使用してプリンタをエクスポートしてから、新しく構成した高可用性プリント サーバーにインポートします。サードパーティ製リソース タイプは、移行の対象にはなりません。
移行プロセスでは、データは一切移行されません。クラスタ構成設定が、Windows Server 2003 から Windows Server 2008 に移行されます。
移行されたリソースはすべて、移行プロセスが完了した時点で、まずオフライン状態になります。これは、追加の手順が必要になることがあるためです。したがって、クラスタを稼働する前に、移行完了レポートを表示して必要な追加手順 (新しい記憶域に移行する場合のデータの移行を除く) を確認することが重要です。たとえば、DHCP サーバーを移行する場合は、クラスタ内のすべてのノードに DHCP サーバーの役割をインストールする必要があります。WINS サーバーを移行する場合は、クラスタ内のすべてのノードに WINS サーバーの機能をインストールする必要があります。

Chuck Timon は、マイクロソフトのサポート エスカレーション エンジニアとして、クラスタとセットアップ テクノロジのサポートを担当しています。Windows Server 2008 フェールオーバー クラスタのトレーニング コースを作成した経験があり、現在、Hyper-V のトレーニング コースの作成に取り組んでいます。


編集長から 印刷物の消滅
Joshua Hoffman

印刷物は消滅しました。完全には消滅していないとしても、ほぼ消滅したと皆さんもお思いでしょう。現在は無限の情報があり、それらの情報はさまざまな形で、いつでもどこからでも、無数の優れたデバイス上で入手できます。このような時代に、のりでくっつけられた紙の束がどこに存在できるというのでしょう。そのような時代はもう終わったのではないでしょうか。雑誌や新聞はスミソニアンの機関にお任せしましょう。そうすれば、圧縮された木とインクを持ち歩かなくてはならなかった時代がどうだったかについて、いつの日か感傷に浸れるでしょうから。
少し芝居がかっているでしょうか。そうですね。でも、おわかりだと思いますが、私はこの考えとは正反対の意見を持っています (これは、マイクロソフトでの自分の職を確保するためだけではありません。マイクロソフトでは多くのことを実現できるのです)。私は、印刷物が簡素であるにもかかわらず (または、おそらく簡素であるために)、信じられないほど深みのある優れたエクスペリエンスを提供するという考えを固く信じています。長文の記事を読み始めるときは、コンピュータの画面を見るのではなく、必ず印刷物を手に取ります。私にとっては、単に印刷物の方が魅力的なのです。古臭い考え方でしょうか。そうかもしれませんが、読者調査によると 9 割の方が同じように感じています。
なにも現実から目を背けましょうと提案しているのではありません。私はかなりのオタクで、テクノロジが大好きです。でも、TechNet Magazine などの出版物は、オンライン、オフライン、紙そのものなど、さまざまな形式で総体的なエクスペリエンスを提供することが可能であり、またそうあるべきです。もちろん、Mark Russinovich の長くて難しい技術的な記事を読む場合は、印刷されたものを読みたいと考えます。ただし、Mark の講演を聞いたり、彼が説明する技術のデモンストレーションを見たりすることも有益だと考えています。
この考えは、TechNet Magazine の基本理念となっています。毎月雑誌を発行することにも誇りを持っていますが、これまでに発行した雑誌に記載されているコンテンツは、すべてインターネット上でも公開されています。そして近いうちに、インターネット上で提供されている独特なプラットフォームを利用してご覧いただけるコンテンツをさらに増やす予定です。たとえば、先月号の記事では、Don Jones の Windows PowerShell コラムでスクリーンキャスト シリーズをスタートしました。このスクリーンキャスト シリーズによって、Don がその月のコラムのトピックについて説明しているビデオを視聴できるようになりました。また、TechNet Magazine Web サイトでは、新たに持続可能なコンピューティングに関するコラムも公開されます。このコラムでは、IT が環境に与える影響や、IT プロフェッショナルが責任ある地球市民になるために何ができるかを専門に扱っています。
いつものお願いですが、これまでと同様に TechNet Magazine を優れたメディア エクスペリエンスとして提供していくためには、皆さんからのフィードバックが非常に重要です。ぜひ tnmag@microsoft.com (英語のみ) までご意見およびご感想をお寄せください。
—Joshua Hoffman

次のマイクロソフト技術支援スタッフに心より感謝します。Ed Banti、Avronil Bhattacharjee、Nino Bilic、Mai-lan Tomsen Bukovec、Eric Charran、Elden Christensen、Trina Gorman、Scott Landry、Michael Murgolo、Sanjeev Nair、Hugh Pyle、Amritansh Raghav、Jez Sadler、Jim Truher


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

Active Directory ドメイン サービス
2008 年 3 月号の TechNet Magazine をとても楽しく拝見しました。この号は、もう 12 回くらい読んだと思います。特に Gil Kirkpatrick 氏による「Active Directory ドメイン サービスの新機能」の記事を非常に楽しく読ませていただきました。この記事で、Kirkpatrick 氏は Microsoft® 監査コレクション サービスという製品について触れていますが、この製品は現時点で入手可能ですか。また、この製品はスタンドアロン アプリケーションとして機能しますか。
—Erasmo M

Microsoft 監査コレクション サービス (ACS) は、System Center Operations Manager (SCOM) の一部として提供されている製品です。SCOM は、以前は Microsoft Operations Manager (MOM) と呼ばれていました。ACS はスタンドアロン製品としては使用できません。ACS は、SCOM の一部としてご利用いただく必要があります。
—Gil Kirkpatrick、NetPro 社最高技術責任者および TechNet Magazine 著者

署名
2008 年 4 月号の TechNet Magazine の Windows PowerShell コラム「署名をお願いします」(technet.microsoft.com/magazine/cc434702) の第 2 段落で、著者 Don Jones 氏は「署名という語は、これから説明するテーマを表す正しい専門用語ですが、その語自体は、実際の処理を適切に表していません。スクリプトに署名するということは、契約を結ぶときやクレジット カードを使用するときのように、それを承認または許可するということではありません」と書かれています。
契約を結ぶときやクレジット カードを使用するときに署名することは、必ずしもそれを承認または許可するということでもないと言えるのではないでしょうか。署名という行為は、その環境をより大きな視点で捕らえた場合にのみ意味があります。たとえば、私は小さいころに、父親が経営していたガソリン スタンドでクレジット カードの伝票で遊んだことがありますが、このときに不正請求した伝票の代金を回収しようとする人はいませんでした。
適切に構成された Active Directory® ネットワーク実装では、署名はまさに実行されるスクリプトを承認するものです。署名されているということは、署名した人が署名したものについて責任を引き受けるということを示します。また、署名の存在により、クレジット カード会社への請求や、ネットワークによる信頼できるコードの受け入れなど、さらなる活動が行われることもあります。
TechNet Magazine は非常に役に立つ情報源ですので、これからも楽しみにしています。
—Jeremy P

Jeremy さん、フィードバックをお寄せいただきありがとうございます。TechNet Magazine の記事を、読者の皆さんがこのようによく観察し、するどい批評眼を持って注目してくださっているのを嬉しく思います。

SharePoint Services
Microsoft Office SharePoint Server ではなく、Windows® SharePoint® Services (WSS) を実行する場合、ユーザーが Web サイト インターフェイスや URL からアクセスするには、追加の CAL ライセンスが必要ですか。
—Douglas M

このトピックに関するドキュメントはいくつかあります。役立つサイトの一例としては、msmvps.com/blogs/cgross/archive/2005/04/02/40723、microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx、windowsserver/sharepoint/bb684457 などがあります。
—Pav Cherny (コラムニスト、TechNet Magazine「SharePoint の内部」担当)

「SharePoint の内部」への提案 (その 1)
最近、2008 年 5 月号の TechNet Magazine に掲載されている SharePoint コラム (technet.microsoft.com/magazine/cc462809) を読みました。このコラムではトピックに関する提案を読者に求めていらっしゃいましたが、SharePoint を Project、および Project Server と統合することに関する特集記事を組んでいただけると嬉しいです。
—Phil H

Project と Project Server についてというのは、すばらしいご提案ですね。このトピックについては、確実に今後のコラムに掲載することを検討します。ご提案をいただきありがとうございました。

「SharePoint の内部」への提案 (その 2)
インターネット上には、標準的な SharePoint UI または SharePoint Designer を使用した、サイトのカスタマイズに関する大量のドキュメントが出回っていますが、サイト定義に関するドキュメントはほとんどありません (また、世の中に出回っているドキュメントの内容は基本的すぎて、実際の問題に対応する場合には、ほとんど役に立ちません)。運用中に発生する問題については多くの人が調査を始めていますが、現在提供されている大量の How-To 記事は、SharePoint の導入時にしか役立ちません。具体的には、私の会社では次のトピックに関して苦労しました。
  1. サイト定義でリストにカスタム許可を設定すること
  2. サイト定義のカスタム リスト アイテム フォーム
  3. サイト定義から Web パーツに接続すること
  4. サイト定義が増分配信されるしくみ
—Adam C

ご提案をいただきありがとうございます。このようなフィードバックをお待ちしておりました。このフィードバックを考慮して、このコラムのコンテンツを継続的に発展させて行きたいと思います。


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

管理タスクを自動化する
Automise 2
automise.com/automise.aspx
考える必要のない反復タスクは、退屈で、面倒で間違いが生じやすいものです。このようなタスクを自動化することは管理を適切に行うための鍵であり、仕事に対する満足度も向上します。面白みのないバッチ ファイルやカスタム VBScript を使用してタスクを自動化するだけでなく、Windows® 用のマクロに似た多くのユーティリティやカスタム スクリプト言語の学習が必要なユーティリティなど、多数の手段があります。そしてもう 1 つの方法があります。VSoft Technologies の Automise 2 です。Automise 2 を使用すると、ドラッグ アンド ドロップ操作による自動化ルーチンの作成、GUI のカスタマイズなどを行うことができます。
このアプリケーションのインターフェイスは、使い慣れたオプションを備えた単純なプログラミングの IDE によく似ています。デザイナ画面にドラッグする項目が含まれるツールボックス、コードをステップごとに検証できるデバッグ コントロール、さまざなプロジェクトのビュー、出力実行ログ、履歴、プロパティ ウィンドウなどが用意されています。ただし、Automise では、"コード" は実際には自動化されたタスクのワークフローを表現したものを指します。
Automise のツールボックスはアクションで構成され、各アクションは自動化プロセスの単一のステップを実行します。380 個のアクションが用意されており、.zip ファイルの作成から IIS の再起動に至るまで、あらゆる操作を行うことができます。
タスクを設計するときに、これらのアクションを階層構造にして、定期的に実行する多くの管理プロセスを自動化できます。さらに、try/catch ブロック、例外の発生、if-then-else ステートメント、ループ、スイッチ、遅延、非同期アクション グループなどのフロー制御アクションでアクションをつなぐことができます。
各自動化プロジェクトに他のプロジェクトを含めて、マスタの制御フローをサブタスクから分離することもできます。文字列と XML データの操作、変数の設定、プロセスとコマンドの待機などのアクションもあります。これらのあらゆるフロー制御オプションを使用することで、さらに複雑な操作を自動化できます。
Automise では、スケジュールされたタスクの作成、実行、編集、および削除を行うことができます。つまり、Automise を使用して既存のプロセスも管理できます。スペースが足りないのですべてのアクションを記述することはできませんが、その他の注目すべきアクションとして、グローバル アセンブリ キャッシュ (GAC) への DLL の登録、SQL Server® インデックスの再構築、chkdsk の実行、レジストリの編集、イベント ログのバックアップ、Active Directory® ユーザーの編集、ボリュームのマウント、復元ポイントの作成、仮想ディレクトリの作成などがあります。組み込みのアクションで目的の処理を実行できない場合は、カスタム スクリプト、コマンド、およびアドホック SQL 実行アクションを使用できます。
全体として見れば、Automise は自由に使用できる便利なツールです。ネットワーク インフラストラクチャではなく独自の Windows ワークステーションだけを自動化する場合は、Automise Lite をお試しください。Automise Lite では、多くの機能が省かれていますが、パワー ユーザーのほとんどのニーズに対応できます。
価格 : 1 ユーザー ライセンスあたり 195 ドル～ (直販)
Automise 2 を使用した視覚によるタスクの自動化 (画像をクリックすると拡大表示されます)

リアルタイムにログを監視する
BareTailPro
baremetalsoft.com/baretailpro
ログ ファイルは至るところに存在します。しかし、ログ ファイルを活用することは、本当に難しいものです。アプリケーションでトランザクションのログを生成できるのはすばらしいことですが、ログ集計ツールを使用する以外に、発生していることをリアルタイムに監視できる方法はあるでしょうか。その 1 つのソリューションとして、Bare Metal Software の立証済み BareTailPro があります。2006 年以来更新されていませんが、この単純なユーティリティは、昔ながらの *nix コンソール コマンドの "tail -f" を Windows 用に拡張したものです。
わかりやすい GUI が用意されており、任意のサイズの複数のログ ファイルを同時に監視して、それらのログ ファイルに書き込まれた内容をリアルタイムに透過的に確認できます。ファイルを切り替えるには、タブをクリックするだけです。また、非常に優れた機能として、各ログ ファイルの状態 (ファイルに現在書き込みが行われているか "tail" が停止しているかを示す) アイコンが各タブに表示されます。
ほとんどのアプリケーションはログを記録しますが、通常、その方法は大きく異なります。さいわい、BareTailPro は Unicode、UTF-8、ANSI、および ASCII ファイルを読み取ることができ、行が CR/LF の組み合わせ、単一の LF、および null で終わるファイルにも対応できます。特定の種類のログ ファイルが最適に表示されるように、行の折り返しとタブ拡張の両方を容易に構成できます。さらに、フォント サイズ、種類、文字間隔、および行間を構成して、ログ ファイルを読みやすくすることもできます。
もう 1 つの優れた機能として、ログ ビューに適用できる構成可能な強調表示があります。テキストの文字列に基づく前景色や背景色のコーディング ルールをいくつでも設定できます。たとえば、エラーを赤色、警告を黄色で強調表示したり、特定の IP アドレスまたはホストの参照が含まれるすべての行を強調表示できます。また、行の太字や斜体の指定、テキストの文字列の大文字小文字の区別を無視する選択も可能です。
テキストを強調表示しても、ログ ファイルに頻繁に書き込みが行われる場合は、tail ビューがあふれてしまうため、目的のイベントを見つけるのが困難です。BareTailPro には別の役立つ機能が用意されています。正規表現とテキスト検索機能を使用すると、関心のある行を管理可能なサブセットに分離できるため、ログの表示をすばやく縮小できます。BareTailPro で使用する正規表現構文は、Java、Perl、および PHP で使用する標準の表記のサブセットで構成されています。その標準の表記に詳しくない場合は、製品 Web サイトのクイック リファレンスを参照してください。
このユーティリティは、タイムスタンプ、行番号、定義済みのキャプチャ グループの結果などの便利な列と元の行ソースを追加して、フィルタした結果を表形式で表示します。フィルタされたビューでは、これらの列を並べ替えることもできます。
私は、必要とする結果を見事に取得した "魔法" の正規表現構文でさえもなかなか覚えておくことができません。そのため、ツールのパターン保存機能を本当に高く評価しています。この機能を使用すると、パターンに名前を付けたり、編集、保存したりして後で使用できます。フィルタしたビューに重要な行が表示されたら、それらの結果をカスタマイズした形式でファイルまたはクリップボードにエクスポートできます。たとえば、幅、配置、プレフィックス、およびサフィックスを結果の各列に設定できます。
この小さなユーティリティは、1 つの小さな実行可能ファイルに格納されているため、持ち運びが可能で、使用中の環境に与える影響はわずかです。ログ ファイルの監視のみ必要で、正規表現を使用したフィルタ処理、検索パターンの保存、および検索結果やフィルタ結果のエクスポートが必要ない場合は、BareTail という無料バージョンで十分です。
価格 : 1 ユーザー ライセンスあたり 35 ドル～
BareTailPro によるネットワークの監視 (画像をクリックすると拡大表示されます)

システムのインベントリ情報を取得する
Total Network Inventory
softinventive.com
システム管理を適切に行うための重要な要素は、環境全体にわたるコンピュータに関する詳細情報にすばやくアクセスできることです。この情報を持つスプレッドシートやベンダ リストは、完全な状態を保持するのが困難で、すぐに情報が古くなります。
必要なときに必要な情報を提供する動的なツールを使用して、インストールされたものとそのインストールを実施したユーザー、および実行されているハードウェアの種類に関する情報を収集すると非常に便利です。このようなツールは、ユーザーによってコンピュータに何が追加されたかを把握するうえでも優れた手段となります (もちろん、これは、グループ ポリシーでインストール権限がまだ制限されていない場合、または特定のソフトウェア パッケージのインストール ベースに基づいて必要なライセンス数が特定されていない場合です)。このような詳細情報を得るために最適なツールの 1 つとして、Softinventive Lab の Total Network Inventory があります。
Total Network Inventory をインストールすると、スキャン ウィザードを使用してインベントリ プロセスを開始できます。このウィザードでは、手順に従ってネットワーク内のノードを検出できます。指定した IP アドレス範囲またはネットワーク プレースのコンピュータ参照を使用してすぐにスキャンを実行するか、ログオン スクリプト スキャンを使用してコンピュータがドメインにログオンしたときに情報を収集できます。
Total Network Inventory は、Windows Management Instrumentation (WMI) (IPC$\ADMIN$ または RPC/DCOM) とローカル アカウント用の標準の共有を利用してスキャンを実行します。そのため、Total Network Inventory は管理者アカウントで実行する必要があります。
スキャンが完了すると、コンピュータを参照するか特定のコンピュータを検索して、その資産のインベントリ情報を収集できます。収集したインベントリ情報は、[Hardware](ハードウェア)、[Software](ソフトウェア)、および [Other information](その他の情報) の 3 つの領域に分類されます。[Hardware](ハードウェア) セクションには、プロセッサ、マザーボードとチップセット、メモリ、ビデオ サブシステム、記憶域 (物理デバイスと論理デバイスを含む)、ネットワーク アダプタの種類と構成、周辺機器、およびシステムにインストールされているその他のデバイスに関する詳細情報が含まれます。
[Software](ソフトウェア) セクションには、プロダクト キー、シリアル番号、システム ディレクトリ、インストールされているサービス パックなどの OS 情報が含まれます。修正プログラムとそれぞれのサポート技術情報の記事番号、インストールされているウイルス対策ソフトウェアやデータベース アプリケーションなどに関する詳細情報もあります。また、インストールされているプログラムの一覧、Program Files ディレクトリの内容 (標準のプログラムの追加と削除の一覧には表示されないアプリケーションを確認できます)、および自動実行アプリケーションの一覧も表示されます。
最後に、[Other information](その他の情報) セクションには、ユーザーやシステム変数などのシステム環境、共有リソース、実行中のプロセス、インストールされているサービス、およびローカル ユーザー アカウントに関する詳細情報が含まれます。
Total Network Inventory を使用すると、資産監査、ライセンス確認、アップグレードの見積もり、およびパフォーマンス評価を行うために必要な情報が提供されます。このツールの最も優れた機能は、Report Builder コンポーネントです。この機能を使用すると、クイック リファレンスから監査記録に至るまで、わかりやすくまとめられた複数の詳細レポートを作成できます。集計レポートと 1 台のコンピュータに関するレポートがあります。私が特に便利だと思う機能は、[Software and Licenses Accounting](ソフトウェアとライセンスの数) タブです。環境全体にインストールされている各種ソフトウェアの合計数が表示されるため、ベンダ契約を順守できます。
価格 : 25 ノード ライセンスあたり 95 ドル～
スキャン ウィザードによるネットワーク ノードの検出 (画像をクリックすると拡大表示されます)

ブック レビュー
Mastering Microsoft Exchange Server 2007
sybex.com
好き嫌いにかかわらず、電子メールは円滑に業務を行う組織の主要なコンポーネントです (ただし、電子メールを使用する前に、ユーザーは文書による効果的なコミュニケーションに関する講習を受ける必要があると思うことがあります)。この数年で、音声通信、予定表機能、リソース スケジュール、統一されたクライアント アクセス、およびメール フィルタ処理 (スパム、ウイルスなどに対応) を統合したいという要望が非常に明白になりました。そこで、Microsoft® Exchange Server 2007 の登場です。
最新バージョンの Exchange では、これらのすべてのコンポーネントがスケーラブルで堅牢なソリューションに円滑に統合されています。ただし、あらゆる機能が網羅されているため、管理者、設計者、およびサポート スタッフが動的な電子メッセージング ソリューションの計画、展開、管理、および保守を行うには、いくつかの優れた参考文献が必要です。
私は前回の「ツールボックス」コラムで『Microsoft Exchange Server 2007 Administrator's Companion』について説明しました。検討する価値のあるもう 1 つの優れた参考文献として、『Mastering Microsoft Exchange Server 2007』(Sybex、2007 年、Barry Gerber/Jim McBee 著) があります。これは、Exchange Server のライフサイクルが明確に説明されているガイドです。
この書籍の最初の 3 つの章 (「Understanding and Planning」セクション) では、Exchange Server 2007 の基本コンポーネントと実装要件について説明されています。Exchange の以前のバージョンを利用したことがある場合は、重視または実装されなくなった機能に関するセクションをお読みください。さまざまなサーバーの役割および Exchange Server 2007 を構成するコンポーネントの説明は、すべての方の役に立ちます。このような複雑なサーバーを展開するには事前の考慮が必要であり、拡張、ディスク領域の要件、および Active Directory 統合の計画に関するセクションを注意深く読む必要があります。
次のセクションでは、クリーン インストールと Exchange Server 2000 または Exchange Server 2003 からのアップグレード (Exchange Server 5.5 から直接アップグレードすることはできません) について詳しく説明されています。各 Exchange Server のさまざまな役割 (エッジ トランスポート、クライアント アクセス、ハブ トランスポート、メールボックス、ユニファイド メッセージング、管理ツールなど) の詳細情報も記載されています。
次に、パフォーマンスの監視方法、メールボックス格納域の追加方法など、スケーラビリティに関する説明に移ります。ここでは、ローカル連続レプリケーションという非常にすばらしい新機能をご覧ください。この機能を使用すると、メール ストアのローカル バックアップを常に最新の状態に保つことができます。メイン データベースに何か問題が発生した場合は、迅速にバックアップに切り替えることができます。他の有効性が低く最新状態ではないバックアップから復元する必要はありません。
次のセクションには、Exchange Server 2007 に用意されているさまざまな管理タスクやツールの概要が記載されています。これには、Windows PowerShell™ をベースにした Exchange 管理シェルなどのツール、Windows PowerShell エンジンを利用する Exchange 管理コンソール GUI などがあります。このセクションを通じて、メールボックス、アドレス リスト、およびユーザー アカウントの管理方法がわかります。メッセージング レコード管理、メッセージの分類の管理、ジャーナル、およびトランスポート ルールに関する説明もあります。
4 つ目のセクションには、可用性と信頼性に関する詳細な情報が記載されています。ビジネスは電子メッセージングに依存するようになったので、このセクションを注意深く読むことをお勧めします。
ここでは、負荷分散、サーバーの冗長性、記憶域の冗長性、ネットワークの冗長性、およびクラスタリングの基礎を学習します。スケジュールされたメンテナンス、バックアップの実行、および障害回復のベスト プラクティスが簡単に説明されています。基本的には、問題発生時にも会社の電子メッセージング システムを効率的に機能させることを認識しておく必要があります。
次の 2 つのセクションでは、Microsoft Office Outlook® 2007、Outlook Web Access、IMAP、POP3 などのクライアント アクセスについて説明されています。最後に、Exchange 管理者にとって非常に重要な、セキュリティと監査に関するセクションがあります。このセクションでは、基本的なセキュリティや予防措置、および自由に使用できるさまざまな監査ツールについて説明されています。総括として、この詳細な参考文献を読むことで、必要な情報を得ることができ、Exchange を正しく展開できます。
価格 : 49.99 ドル (直販)

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


ユーティリティ スポットライト Microsoft SharedView
Greg Steen

私はよく地球の裏側にいるスタッフとチームを組んで仕事をします。そのとき、「チームのメンバ全員が同じデスクトップを見ながら対話できたら、お互いの意見をはるかに効率的に図や言葉で伝えることができるのに」と思うことがよくあります。
たとえば、出張中の販売部門のスタッフがネットワークを介して集まって、迅速に情報交換したり、見積もりを確認したり、重複作業を減らしたりする必要がある場合を考えてみます。このようなとき、Microsoft® Office Excel® の同じスプレッドシートや Word の同じ文書を全員が同時に見ながら編集することができれば、すぐに変更されメンバ間で同期が取れなくなってしまう可能性のあるドキュメントをメールでやり取りするよりもはるかに生産的です。今回、まさにそれを可能にする軽量のコラボレーション ツールがリリースされました。それが Microsoft SharedView 1.0 です。
Microsoft SharedView を使用すると、最大 15 人の参加者が会議用ホストのデスクトップを同時に共有できます。これは、各参加者が同じデスクトップを見ているのと変わりません。このように書くと、15 人が同じデスクトップのコントロールを同時に取得したら、大混乱になるだけではないかと思うかもしれません。しかし、実際には、デスクトップのコントロールが各参加者の間で受け渡されるため、混乱は起こりません。
デスクトップのコントロールを取得している人には、他の参加者のマウスの動きが見えます (各参加者にはそれぞれ固有の形状のマウス ポインタが割り当てられます)。ですから、他の参加者はドキュメントやアプリケーション上の項目をマウスで指し示すことができます。残念ながら、SharedView には音声機能は組み込まれていませんが、Windows Live™ Messenger のオーディオ クライアントや好みのボイス オーバー IP (VoIP) クライアントを使用して、デスクトップを共有しながら会議を進めることは可能です。
Microsoft SharedView で会議用ホストのデスクトップを同時に共有 (画像をクリックすると拡大表示されます)
SharedView のインストールは簡単です。また、クライアントの操作は直感的に行えるため、技術にあまり詳しくないユーザーでもすぐに使いこなせるようになります。Windows Live のアカウントでサインインしたら、数回のクリック操作で SharedView セッションを開始できます。セッションに参加するのも簡単です。接続するセッションの名前 (通常は、ホストの Live ID) とパスワードを入力するだけです。参加希望者に招待状を送るには、電子メールを使用するか、作成した招待文を IM クライアントに貼り付けます。
SharedView には他にも、リモートでのコピーと貼り付け (セッション ユーザーがローカルのワークステーションからホスト コンピュータにテキストを追加できるようにする) の有効化または無効化を行う、Word 内の変更追跡を直接有効にして参加者による共有ドキュメントの変更がわかるようにする、明示的なブロック リストによって特定の Windows Live ID を持つユーザーの参加を禁止するなどのオプション機能が用意されています。また、優れた資料配布機能によって、セッションの参加者に補助資料ファイルを提供できます。1 つのセッションにつき、最大 25 ファイルまたは 200 MB 分の資料を用意できます。
また、参加者に対するブロードキャスト メッセージを入力して、参加者の接続セッションの最上部に表示することもできます。最初からすべてを共有することもできますし、会議の進行に応じてホスト コンピュータからウィンドウの共有を開始したり、公開したくない事柄が出てきたら共有をやめたりすることもできます。全体的に見て、手軽で簡単なコラボレーション ツールをお探しなら、Microsoft SharedView は、まず間違いなく目的にかなうツールといえるでしょう。
試してみたい方は、TechNet Magazine Web サイト (technetmagazine.com) のコード ダウンロード セクションで Microsoft SharedView をダウンロードしてください。

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


SharePoint の内部 Office アプリケーションを統合する
Pav Cherny

目次
Office アプリケーションを統合する
SharePoint UI を拡張する
Office OpenDocuments コントロールを使用する
SharePoint と通信する
カスタム OpenControl ソリューションを実装する
まとめ
Microsoft Windows SharePoint Services (WSS) 3.0 と Microsoft Office SharePoint Server (MOSS) 2007 は、2007 Microsoft Office system のデスクトップ アプリケーションとシームレスに統合されており、これによって、ドキュメント、スプレッドシート、予定表、連絡先情報などを使用した共同作業を簡単に行うことができます。この非常にシームレスな統合が、
統一されたオフィス ソリューション プラットフォームとしての 2007 Office system の機能を支えていると言えます。
このことは、主に Microsoft® Office テクノロジを使用してインフォメーション ワーカーの生産性向上を図っている組織にとっては朗報です。ただし、多様な Office アプリケーションのポートフォリオを所有している組織には、最初から優れた相互運用性が提供されるわけではありません。必要な統合機能は 2007 Office system によって提供されますが、文書化されているインターフェイスやコンポーネントは非常に少ないので、対応できない状況もあります。このため、サードパーティ ベンダが SharePoint® テクノロジを自社のアプリケーションに組み込むのは困難であり、これらのベンダの顧客が統一された操作性をインフォメーション ワーカーに提供するのはさらに困難です。
このコラムでは、Office アプリケーションが SharePoint とどのように統合され、どのようにして両者間の通信が行われるか、およびこの原則に基づいて、サードパーティ製のアプリケーションをどのようにして SharePoint と統合できるかについて説明します。ただし、その前に、シームレスな統合に必要なサーバー構成の設定、クライアント側コンポーネント、および通信プロトコルについて簡単に説明します。
これらの詳細を明らかにしたところで、SharePoint のサポートが組み込まれていないアプリケーションの統合について説明します。この作業は、通常のように IFilter コンポーネントを実装することによって、検索機能を拡張したり、SharePoint サーバーにカスタム アイコンを追加したりするだけにとどまりません。適切なアイコンによって検索機能を拡張して結果を返すだけでは、アプリケーションの完全な統合は実現されません。ユーザーが、これらのドキュメントを SharePoint ユーザー インターフェイス内から直接開くことができれば、より便利になります。
ここから話は複雑になります。ワークステーションに Office を展開していない場合はクライアント側コンポーネントが必要ですが、このコンポーネントは簡単には入手できません。また、Office が展開されていても、SharePoint サイトのトポロジと構成によっては、このコンポーネントが正しく動作しない場合があります。
今回、この問題を解決するために、Office を展開する必要なく、メモ帳、Adobe Reader、Autodesk AutoCAD など、任意のアプリケーションを統合できるカスタム ソリューションを作成しました。このカスタム ソリューションを使用すると、一部の状況で、標準的な Office コンポーネントに基づいてアプリケーションを統合できない理由もわかります。このソリューションと、その展開および構成方法に関する一連の手順は、このコラムの付属リソース (TechNet Magazine Web サイトのコード ダウンロード セクションからダウンロードできます) として入手できます。

Office アプリケーションを統合する
ユーザーの観点から見ると、SharePoint のメニューは Windows® の [スタート] メニューのように動作します。ドキュメント ライブラリ内で新しいドキュメントを作成する作業は単純で、[新規] をクリックし、[新しいドキュメント] をクリックすると、Microsoft Office Word 2007 が起動します。既存のドキュメントを編集する作業も同じく単純で、ドキュメント上にマウス ポインタを移動し、編集コントロール ボックス (ECB) ドロップダウン メニューを開いた後、[Word で編集] をクリックするだけです。ユーザーは、Web ページから JavaScript を使用して Word 2007 を起動したこと、アプリケーションをローカルで実行しているが、ドキュメントは遠隔地の SQL Server® データベースに格納されていること、および Web サーバーがデータ アクセス パス内に存在することにはほとんど気が付きません (図 1 参照)。
図 1 SharePoint での Word 文書を使用した作業 (画像をクリックすると拡大表示されます)
このような複雑な動作が発生するにもかかわらず、2007 Office system がインストールされた Windows ワークステーションではシームレスなユーザー エクスペリエンスが提供されます。SharePoint ライブラリ内でのドキュメントを使用した作業は、ローカル ファイルやネットワーク共有上のファイルを使用した作業に似ています。
ただし、Office 2003 や 2007 Office system がインストールされていない Windows ワークステーションでは、異なる UI が表示されます。[新しいドキュメント] や [Word で編集] をクリックすると、Windows SharePoint Services と互換性のあるアプリケーションを使用できないことを通知するダイアログ ボックスが表示されます。
これはそれほど驚くべきことではありません。統一感のある操作性を Office ユーザーに提供するには、いくつかの要素が連携する必要があります。まず、[新規] メニューと ECB メニューのコマンドを表示するには、ドキュメント ライブラリ内で管理されているコンテンツ タイプが SharePoint によって認識されなければなりません。また、これらのコマンドをクリックしたときに、関連付けられたアプリケーションを起動し、該当するドキュメントのパスをそのアプリケーションに渡す JavaScript コードが実行される必要があります。JavaScript コードはローカルで実行されるので、この動作はワークステーションの構成には依存しません。さらに、この関連付けられているアプリケーションは、ファイルを読み取ったり、場合によってはファイルにデータを書き込むために、SharePoint と通信する必要があります。アプリケーションを SharePoint と統合するには、これらすべての要素が連携しなければなりません。
一方、SharePoint とデータベースの通信や、検索速度の向上を目的として Web サーバー上で実行されるインデックス作成処理は、アプリケーションによって認識される必要はありません。このため、この記事ではこれらの側面について詳しく説明しませんが、マイクロソフト サポート技術情報の記事「Microsoft Filter Pack を Windows SharePoint Services 3.0 に登録する方法」(support.microsoft.com/kb/946338) で、Microsoft Filter Pack について確認しておくことをお勧めします。ではここからは、コマンドの追加、必要なクライアント側コンポーネントの実装、およびアプリケーションによって行われる通信の単純化について説明します。

SharePoint UI を拡張する
SharePoint のユーザー インターフェイスと機能は、さまざまな方法で拡張できます。たとえば、サイトのデザインを変更する、ASP.NET ページをカスタマイズする、Web パーツを開発する、WSS と MOSS に含まれている JavaScript コードを変更してアプリケーションを直接起動するなどの方法が考えられます。
Ows.js ファイル (SharePoint フロントエンド サーバーの COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 フォルダにあります) をテキスト エディタで編集したり、createNewDocumentWithProgIDCore、editDocumentWithProgIDNoUI、および DispDocItem 関数の動作を変更したりすることもできますが、このようにサポートを受けられない方法で WSS コード ベースを変更しなくても済む方法があります。これには、ドキュメント タイプのマッピングとコンテンツ タイプを使用します。
TechNet Magazine 2 月号の「カスタム コンテンツ タイプを使用してデータ管理を標準化する」(technet.microsoft.com/magazine/cc194408.aspx) には、グローバル コンテンツ タイプとサイト固有のコンテンツ タイプを作成することによって、SharePoint ドキュメント ライブラリおよびリスト内のドキュメントやその他のコンテンツを管理する方法が記載されています。また、この記事の付属リソースとして提供される Text Content Type.pdf ワークシートには、.text ファイル用の新しいコンテンツ タイプを作成し、そのコンテンツ タイプをドキュメント ライブラリと関連付ける方法が記載されています。この方法を使用すると、Word 文書用のドキュメント コマンドを選択するときと同じように、[新規] メニューの [Text Content] (テキスト コンテンツ) を選択できるようになります (図 2 参照)。
図 2 SharePoint UI に表示されたカスタム コンテンツ タイプ (画像をクリックすると拡大表示されます)
同様に、ECB メニューも拡張可能です。ECB メニューがコンテンツ タイプに対応していることを期待した方もいらっしゃると思いますが、WSS の現在のバージョンでは、そのような ECB メニューの実装は提供されていません。このため、Docicon.xml 内にドキュメント タイプを登録する必要があります。このファイルは、各 SharePoint フロントエンド サーバーの %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml フォルダにあります。
たとえば、Docicon.xml の <ByExtension> セクションに、次のようなドキュメント タイプのマッピングを追加すると、SharePoint に [Edit in Notepad] (Notepad で編集) コマンドが表示されます (詳細な手順については、Text Content Type.pdf ファイルを参照してください)。
<Mapping Key="text" Value="ictxt.gif"
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>
Key パラメータはファイル名拡張子を指定し、Value パラメータはユーザー インターフェイスに表示されるドキュメント アイコンを指定しています。また、EditText パラメータは、SharePoint の [～で編集] コマンド内に含まれる文字列を指定し、OpenControl パラメータはクライアント側 COM コンポーネントの ProgID を指定しています。SharePoint JavaScript 関数は、この ProgID を ActiveX オブジェクトの呼び出しに渡して、COM オブジェクトのインスタンスを作成します (詳細については、Ows.js を参照してください)。この COM オブジェクトは、アプリケーションそのものの場合もあれば、関連付けられているファイルの種類に基づいてそのアプリケーションを起動するヘルパ コントロールの場合もあります。
SharePoint 製品およびテクノロジ Web サイト

  • SharePoint 製品およびテクノロジ Web サイト
  • Windows SharePoint Services TechCenter
  • Windows SharePoint Services デベロッパー センター
  • Microsoft SharePoint 製品およびテクノロジ チームのブログ
SharePoint.OpenDocuments という名前の OpenControl は、Office の最新バージョンで提供される ActiveX® コントロール (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll) を参照することに注意してください。このファイルがワークステーション上に存在し、Value パラメータで指定されたドキュメント アイコンが SharePoint サーバーの %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images フォルダに格納されていれば、統合に必要な作業はほぼ完了します。
Windows SharePoint Services 3.0 SDK には、OpenDocuments コントロールなど、2007 Office system に付属しているクライアント側 API に関する情報が含まれています。詳細については、「クライアント側 API リファレンス」(msdn2.microsoft.com/ms440037) を参照してください。

Office OpenDocuments コントロールを使用する
OpenDocuments コントロールを使用すると、アプリケーションの統合に関する最も重要な要件に対処できますが、このコントロールは Office 2003 または 2007 Office system を必要とし、その機能にも若干の制限があります。[新規] メニューのコマンドは常に正しく機能するわけではなく、場合によっては、誤解を招く通知がユーザーに表示されることもあります。
OpenDocuments コントロールによって、必要なアプリケーションが正しくインストールされていないこと、またはテンプレート ファイルを開くことができないことがユーザーに通知されます (図 3 参照) が、どちらの通知の内容も誤っています。また、"～で編集" 機能にも問題があります。図 3 の一番手前に表示されている 2 つ目のエラー メッセージは、よく見かけるメッセージです。私は、SharePoint の専門家でさえも誤解するこのメッセージを非常に気に入っています。詳細については、この後すぐに説明します。
図 3 OpenDocuments コントロールによって表示される誤解を招きやすいエラー メッセージ (画像をクリックすると拡大表示されます)
上記のような問題はありますが、Office の最近のバージョンがすべてのワークステーションにインストールされている環境では、OpenDocuments コントロールが役立ちます。特に大きなメリットは、コンテンツ タイプを [新規] メニューに表示しないようにできることです。これを行うには、[Document Library Settings] (ドキュメント ライブラリの設定) を表示し、[新規ボタンの順序と既定のコンテンツ タイプの変更] をクリックして、問題のあるすべてのコンテンツ タイプの [表示] チェック ボックスをオフにします。この操作を行うと、ユーザーに 1 つ目のエラー メッセージが表示されなくなります。また、サイトのトポロジを単純に保つことによって、Web 分散オーサリングとバージョン管理 (WebDAV) 通信に関する問題を回避できるので、2 つ目のエラー メッセージも表示されなくなります。

SharePoint と通信する
この記事の前半では、SharePoint UI を拡張し、場合によっては OpenDocuments コントロールを使用してアプリケーションを起動しましたが、このアプリケーションには、SharePoint と通信して、SharePoint のデータにアクセスする方法も必要です。SharePoint では、この操作を行う方法も複数サポートされています。たとえば、Microsoft Office FrontPage® Server Extensions、WSS リモート プロシージャ コール (RPC)、WebDAV、Web サービスを利用できます。実際に、Word 2007 などの Office アプリケーションでは、ドキュメントへのアクセス方法に応じて、これらのうちいくつかまたはすべての通信方法が使用されます。このアクセス方法には、Web フォルダ、割り当て済みのネットワーク ドライブ、SharePoint UI などがあります。
SharePoint クライアントと SharePoint サーバーの間で通信を行う場合、必ず HTTP プロトコルが基盤として使用されます。たとえば、FrontPage および WSS RPC では、SharePoint サーバーの %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI フォルダとそのサブフォルダ内にある ISAPI 拡張への HTTP POST および HTTP GET 要求が使用されます。
最も重要な ISAPI 拡張の 1 つは、リストとドキュメント ライブラリを操作する機能が実装された Owssvr.dll です。図 4 は、SharePoint の保存ダイアログ ボックスが Word 2007 に表示された画面 (左側) と、同じダイアログ ボックスが URL 要求 http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx を通じてブラウザ内で直接開かれた画面を示しています。2 つの画面が似ていることがおわかりいただけると思います。
図 4 Word 2007 と Internet Explorer に表示された SharePoint の保存ダイアログ ボックス (画像をクリックすると拡大表示されます)
その他の重要な ISAPI 拡張には、ドキュメントのアップロード、名前変更、削除といったクライアント側の編集操作を行うための FrontPage および WSS RPC が実装された Author.dll、サイトを管理したり、その他の多くの管理タスクを実行するための Admin.dll、HTML フォームの送信をサポートするための Shtml.dll などがあります。
一般に、ソース コードにアクセスすることなく、FrontPage および WSS RPC のサポートを追加して、メモ帳や Adobe Reader などの既存のアプリケーションをサポートすることは不可能です。ただし、Windows に含まれている Web クライアント機能を使用して、必要な通信機能を提供できます。
SharePoint でも、Httpext.dll を通じて WebDAV がサポートされます。このファイルは %WINDIR%\System32\Inetsrv\ フォルダに格納されていますが、ここではクライアント側の視点から説明します。Windows Server® 2008 または Windows Vista® を実行しているコンピュータには、既定で Web クライアント機能がインストールされています。コントロール パネルの [管理ツール] で [サービス] アプレットを開くと、対応する WebClient サービスを確認できます。Windows XP と Windows Server 2003 には、Web クライアントを明示的にインストールする必要があります。いずれの場合も、WebClient サービスを開始し、[スタートアップの種類] を [自動] に設定するようにしてください。
図 5 は、Web クライアントのアーキテクチャを示しています。WebClient サービスは、ユーザー モード DLL (Webclnt.dll) 内に実装されており、Svchost.exe ホスト プロセス内でサービス コントロール マネージャによって読み込まれます。Webclnt.dll では、I/O 以外の操作 (たとえば、WebDAV に準拠したアクセスを実行するユーザーを認証する、SharePoint サイトをネットワーク ドライブとしてマウントする、SharePoint サイト、リスト、およびドキュメント ライブラリをネットワーク リソースとして列挙する、マウントされたドライブの接続を解除する) を行うためのネットワーク プロバイダ インターフェイスが提供されます。
図 5 WebDAV クライアント リダイレクタのアーキテクチャ (画像をクリックすると拡大表示されます)
Webclnt.dll は、この操作を完了するために、実際のリダイレクタ機能を提供する、カーネル モードのファイル システム ドライバと通信します。WebDAV クライアント リダイレクタ ドライバ (Mrxdav.sys) は、Redirected Drive Buffering Subsystem (RDBSS) に基づいており、I/O マネージャとその他のカーネル コンポーネントと連携して、リモート ファイル システムのサービスを提供します。また、Mrxdav.sys には WebDAV 通信機能が実装されており、これによって、SharePoint サイトおよびドキュメント ライブラリへのファイル システム レベルのアクセスがサポートされます。
ネットワーク リダイレクタを経由して SharePoint サイトおよびドキュメント ライブラリにアクセスできるので、ユーザー アプリケーションで FrontPage および WSS RPC をサポートする必要がなくなります。また、ネットワーク ドライブをドキュメント ライブラリにマップしたり (net use x: http://wss/doclib/Shared%20Documents など)、UNC パスを使用して SharePoint リソースにアクセスしたりできるようになります。
URL http://wss/doclib/Shared%20Documents は、\\wss\doclib\Shared%20Documents にマップされます。このため、アプリケーション内でドキュメントを開くときに、複数の選択肢が提供されます。たとえば、あるドキュメントをメモ帳で開くときに、HTTP パス http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt を使用することも、UNC パス \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt を使用することもできます。
残念ながら、Web クライアント機能にはいくつか制限があります。カスタム プロパティや、カスタム TCP ポートを使用する Web アプリケーションにアクセスすることはできません。また、ユーザーが階層内の親サイトにアクセスできない場合、Windows Vista に付属している Web クライアントの処理は失敗します。詳細については、付属リソースの WebDAV Access.pdf を参照してください。
パス http://sharepoint/HR/Administration/Shared%20Documents/ には、存在しないルート サイト (http://sharepoint) が含まれていますが、Web クライアントは、このルートにアクセスできなければ Web サーバーの機能を特定できません。Web サーバーは、Web クライアントの OPTIONS 要求を拒否し、アクセスが承認されなかったことを示す状態コード 401 を返します。その結果、ユーザーがサイト コレクション sharepoint/HR とそのコレクション内のすべてのサイトに管理者としてアクセスできるにもかかわらず、Web クライアントはユーザーの資格情報を要求し続けることになります (図 6 参照)。
図 6 WebDAV に準拠したアクセスの失敗 (画像をクリックすると拡大表示されます)
Web クライアントが、OpenDocuments コントロールを使用してドキュメントを開くことができなかった場合、図 3 のようなエラー メッセージが表示されます。このアプリケーションは使用可能であり、ドキュメント タイプのマッピングも適切に実装されています。つまり、WebDAV リダイレクタを経由してもアクセスできないドキュメントが存在します。

カスタム OpenControl ソリューションを実装する
一般に、Web クライアントの欠点に対処する方法は 2 つあります。それは、更新された Web クライアントのバージョンがマイクロソフトから提供されるのを待つか、現在の状況に対処できるカスタム OpenControl ソリューションを実装することです。カスタム OpenControl の実装は簡単な作業ではありませんが、これによって、ワークステーションに Office をインストールする必要がなくなります。また、[新規] メニューの [～で編集] 以外のコマンドでも便利な動作を提供したり、Web クライアントの処理が失敗する状況に対処したりできます。
これらの効果に魅力を感じた方は、付属リソースに含まれている AppStart のソース コードを参照してください。このコードは、Microsoft .NET Framework アセンブリに OpenControl COM インターフェイスを公開し、このインターフェイスを SharePoint JavaScript コードから呼び出すことができるようにします。また、ファイルにアクセスできるかどうかを確認し、WebDAV を経由して直接アクセスできない場合は、HTTP を経由してそのファイルをローカル コンピュータにダウンロードします。さらに、[新規] メニューのコマンドから発行された要求に応じて、該当するコンテンツ タイプに関連付けられたテンプレートをローカル コンピュータにダウンロードし、ユーザーがそのドキュメントを使用して作業を開始できるようにします。Text Content Type.pdf および Adobe Reader Support.pdf ワークシートには、この OpenControl ソリューションを展開する方法の概要が記載されています。
図 7 は、AppStart のアーキテクチャを示しています。カスタム OpenControl コンポーネント (Biblioso.dll) は、まったく同じ 2 つの COM インターフェイスを公開します。SharePoint JavaScript は、これらのインターフェイスを呼び出して、新しいドキュメントを作成したり、編集用に既存のドキュメントを開いたりします。
図 7 AppStart のアーキテクチャ (画像をクリックすると拡大表示されます)
編集用にドキュメントを開く場合、Biblioso.dll は、そのドキュメントが存在するかどうかを確認し、ドキュメントに関連付けられているアプリケーションを起動します。WebDAV を経由してドキュメントに直接アクセスできる場合は、そのドキュメントのパスを指定してアプリケーションを起動します。ドキュメントにアクセスできない場合、Biblioso.dll は、アウト プロセス COM サーバーを起動し、OpenDocsUtility.dll を読み込みます。OpenDocsUtility.dll は、HTTP 経由でドキュメントをダウンロードし、ダウンロードしたドキュメントのパスを指定してアプリケーションを起動します。
このアウト プロセス COM サーバーを使用すると、ソリューションを Internet Explorer® とは異なるプロセスで実行できます。保護モードの Internet Explorer のプロセスでは、インターネット一時フォルダへのダウンロードが制限されますが、ユーザーは、保護モードの制限を受けることなくファイルをダウンロードできる必要があります。アプリケーション ブローカとして機能するアウト プロセス COM サーバーによって、この動作が可能になります。
.NET で動作するアウト プロセス COM サーバーの開発はサポートされていないので、C と C++ を使用してこの実行可能ファイルを作成することにしました。C++ では、必要最小限の [名前を付けて保存] ダイアログ ボックスのみを実装しました。ソリューションをできるだけ単純に保ち、開発作業のオーバーヘッドを低く抑えるために、.NET アセンブリ (OpenDocsUtility.dll) 内に実際のダウンロード コードを配置し、別の COM インターフェイスから呼び出すことができるようにしました。
また、簡単に展開作業を行うことができるように、セットアップ プロジェクトをソリューションに追加しました。特に重要なのは、このセットアップ ルーチンが、HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart にすべての COM コンポーネントを登録し、アプリケーション固有の設定を書き込むことです。最も重要なパラメータは、AllowedApps と AllowedFileTypes です。AppStart ソリューションは、これらのパラメータで明示的に指定されたアプリケーションとファイルの種類のみを処理します。
このセットアップ ルーチンでは、アウト プロセス COM サーバーの昇格ポリシーも作成されるので、Internet Explorer のプロセス内で実行される Biblioso.dll は、セキュリティ警告を表示させることなく、AppBrokerEngine.exe を起動できます。Internet Explorer の保護モードについて、およびアプリケーション開発でこの動作モードに対処する方法については、Marc Silbey と Peter Brundrett によって執筆された「保護モードの Internet Explorer の理解と機能」(msdn2.microsoft.com/bb250462) を参照してください。
AppStart のコンポーネントを使用するときは、このソリューションが単なるデモンストレーション用に開発されたものであり、運用環境では使用できないことに注意してください。今回は時間が足りなかったので、徹底的にコードを最適化し、ソリューションをテストすることも、ソース コード内のコメント以外にドキュメントを用意することもできませんでした。
このソリューションは、各自の責任で実行してください。独自のソリューションを作成するために、このソース コードの内容を確認するには、まず Biblioso コード プロジェクトの AppStart.cs を開きます。このファイルには、OpenControl COM インターフェイスと、Ows.js からの JavaScript 呼び出しに使用するエントリ ポイントが実装されています。
まとめ
WSS 3.0 と MOSS 2007 によって提供される、拡張性の高いアプリケーションの統合機能を使用すると、ユーザーが SharePoint ドキュメント ライブラリおよびリスト内のドキュメントやその他の項目を使用して作業するときに、シームレスな操作性が提供されます。この効果は 2007 Office system のデスクトップ アプリケーションで顕著に表れますが、Office 以外のアプリケーションでも同程度の統合とユーザビリティを提供できます。
アプリケーションの統合機能のアーキテクチャにおいて中核となるのは、COM コンポーネントです。SharePoint JavaScript 関数は、これらのコンポーネントを使用し、ドキュメントのパスを指定して、アプリケーションを起動します。2007 Office system では、特定の Office アプリケーションの要件に合わせて最適化された、いくつかの COM コンポーネントが提供されますが、Office OpenDocuments コンポーネントを再利用して、マイクロソフト以外のアプリケーションを統合することもできます。OpenDocuments コントロールによって、最も基本的な要件は満たされます。アプリケーションの統合要件がさらに複雑な場合は、カスタム コントロールを実装します。
アプリケーションを完全に SharePoint と統合するには、IFilter コンポーネントとドキュメント アイコンをインストールして検索および表示機能を拡張するだけでなく、SharePoint サーバー上にカスタム コンテンツ タイプとドキュメント タイプのマッピングを作成して、SharePoint ユーザー インターフェイスで適切な [新規] メニューのコマンドと [～で編集] コマンドを提供する必要があります。これらのコマンドによって呼び出された JavaScript 関数は、OpenControl コンポーネントを通じて公開されたメソッドを呼び出します。この OpenControl コンポーネントは、ワークステーション上でも使用できる必要があります。
もう 1 つの重要な要素は、Windows Vista に既定で提供およびインストールされる Web クライアントです。この Web クライアントには、WebDAV リダイレクタおよびリモート ファイル システム ドライバが実装されているので、どのアプリケーションでも、ネットワーク上のファイル共有に似た SharePoint リストおよびドキュメント ライブラリ内のリソースにアクセスできます。Windows Vista に付属している Web クライアントには欠点もありますが、この Web クライアントはアプリケーションの統合にとって重要な役割を果たします。
WebDAV のサポートによって、Windows 以外のワークステーション上で実行されるアプリケーションと SharePoint の相互通信も可能になります。通常、COM および ActiveX コントロール テクノロジは、これらのオペレーティング システム上では提供されないので、OpenControl コントロールを使用しても自動的にアプリケーションを起動できませんが、ほとんどのオペレーティング システムには WebDAV リダイレクタが含まれているので、ユーザーは少なくとも、ドキュメント ライブラリ内のファイルをローカルのワークステーションにダウンロードすることなく、これらのファイルに直接アクセスできます。
WSS 3.0 と MOSS 2007 は、2007 Office system の成功を支えるソリューションであり、サードパーティ製の Office ベースのアプリケーションを使用するユーザーは、2007 Office system を使用した場合と同様のメリットを SharePoint から得ることができます。この統合機能によって、Office のメリットがさらに増幅します。SharePoint を最大限に活用することによって、Office とサードパーティ製のソフトウェアで同様のユーザー エクスペリエンスを提供する、統一されたオフィス ソリューションを構築でき、その結果、インフォメーション ワーカーの生産性を向上させることができます。

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


Windows PowerShell ドロップ ボックス
Don Jones

目次
コマンドレット
フィルタ処理関数
物理的考察
実践的応用
遊ぶ時間を作る
私が最近講師を務めた Windows PowerShell のあるクラスで、数人の受講者がシェルのパイプラインを理解するのに苦労していました。パイプラインの概念は直感的に理解できるとは言えないため、視覚的に理解しようとする受講者がパイプラインを正確に把握するのは困難です。私が
パイプラインで直接機能するフィルタ処理関数の概念を説明したとき、受講者の表情から間違いなく数人の受講者を失うだろうと思いました。
受講生をサポートするために、翌日、私は箱、名前シール、そしてピンポン球を持って行きました。これで、Windows PowerShell® が楽しいはずがないと言う受講者はいなくなりました。私は次のコマンド ラインを使用してデモンストレーションを実施することにしました。
Get-Process | Where { $_.VM –gt 1000 } | Sort VM
–descending | Export-CSV C:\Procs.csv

コマンドレット
同窓会などのイベントで身に着ける「こんにちは。私の名前は...です。」のような名札シールを使用して、コマンドレット名を各受講者に割り当てました。ピンポン球は Windows® プロセス オブジェクト (具体的には、System.Diagnostics.Process 型のオブジェクト) を表すことを説明しました。その後、受講者にプロセス オブジェクトを生成する可能性が最も高いコマンドレット名を私に伝えるように言いました。
受講生は互いの名札を見回して、Get-Process という明白な選択に落ち着きました。これは、Windows PowerShell のコマンドレット名を私が本当に好きな理由の 1 つを示しています。つまり、ほとんどの場合、一目瞭然であるということです。
Get-Process の名札を付けた受講生は、すべてのピンポン球をつかみ、段ボール箱に入れました。箱はシェルのパイプラインを表し、受講生が行った操作がまさにコマンドレットの処理です。コマンドレットは 1 つ以上のオブジェクトを生成し、それをパイプラインに渡します。
パイプラインの次のコマンドレットが処理を引き継ぎます。この例では、Where-Object コマンドレットの名札を付けた受講者がすべてのピンポン球を拾い上げ、1 つずつ調べてピンポン球の VM プロパティが 1,000 より大きいかどうかを確認しました。シェルでは、"VM" は仮想メモリを表します。この演習では、私は各ピンポン球にマーカーで仮想メモリのさまざまなサイズを記入しました。
VM が 1,000 以上のすべてのピンポン球 (つまりプロセス) を箱 (パイプライン) に戻し、1,000 未満のピンポン球を再び現れないようにゴミ箱に捨てました (実際には、私はこれらのピンポン球を今後のクラスで使用できるようにゴミ箱の中から拾いだしました)。
次に、Sort-Object の名札を付けた受講生がピンポン球の箱を調べて、VM プロパティに基づいてピンポン球を順番に並べました。正直に言うと、この部分の演習は、考慮が足りませんでした。ピンポン球があちこちに転がらないようにするのに注意が必要でした。次のクラスでは四角いピンポン球を探すか、卵のケースを手元に置いておく必要があるようです。
最後に、Export-CSV の名札を付けた受講者がピンポン球を拾い上げて、その情報を CSV ファイルに書き込みました。実際には、これは CSV ファイルで代用したフリップ チャートにプロセスのプロパティを書き込むことになります。

フィルタ処理関数
簡単なパイプラインから少し離れて、もう少し複雑なフィルタ処理関数を考察することにしました。私は図 1 に示すフィルタ処理関数とコマンド ラインを提示しました。
図 1 フィルタ処理関数とコマンド ラインのサンプル
Function Do-Something {
 BEGIN { }
 PROCESS {
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty "TimeStamp" (Get-Date)
  $obj | Add-Member NoteProperty "ProcessName" ($_.Name)
  Write-Output $obj
 }
 END {}
}
Get-Process | Do-Something | Format-Table *
まず、フィルタ処理関数が行う処理について簡単に説明します。この関数には BEGIN、PROCESS、および END という名前の 3 つのスクリプト ブロックがあります。
パイプラインで関数を使用すると、まず BEGIN スクリプト ブロックが実行されます。このスクリプトは、データベース接続を開くなどのセットアップ タスクを実行することがあります。
次に、PROCESS スクリプト ブロックが関数に渡されたオブジェクトごとに 1 回実行されます。PROCESS スクリプト ブロック内では、$_ 変数に現在のパイプライン オブジェクトが自動的に格納されます。したがって、10 個のオブジェクトが渡された場合、PROCESS スクリプト ブロックは 10 回実行されます。
最後に、渡されたすべてのオブジェクトの実行後、END スクリプト ブロックが実行され、データベースを閉じるなどの必要な後処理が実行されます。
これらのスクリプト ブロック内では、Write-Output を使用して書き込まれたすべてのものがパイプラインで次のコマンドレットに渡されます。Write-Output を使用して書き込まれなかったものはすべて破棄されます。
コマンドで Get-Process が開始されると、受講生はすべてのピンポン球を集めて (少し休憩した後、ピンポン球はなぜか部屋中に転がっていました。不思議です)、それをパイプラインの箱に入れました。作業が完了すると、"Do-Something" フィルタ処理関数の名札を付けた受講者が引き継ぎました。
彼は、まず BEGIN スクリプト ブロックを実行しました。ブロックは空だったので、あまり手間はかかりませんでした。次に、彼はすべてのパイプライン オブジェクト (ピンポン球) をつかみ、1 つずつ確認し始めました。1 ダースほどのピンポン球を膝の上に置いてバランスをとろうとしていた彼はとても愉快でした。あなたもその場にいたらよかったのに。
とにかく、彼はプロセス オブジェクトを 1 つずつ拾い上げて PROCESS スクリプト ブロックを実行しました。そのスクリプト ブロックによって新しいカスタム オブジェクトが作成されました。私はこのために特別な黄色いピンポン球を使用しました。これは地元のスポーツ用品店で簡単に見つけられるものではありません。彼はこれらの新しいピンポン球に、現在の日時と現在確認しているプロセス オブジェクトの名前を記入しました。
この新しいカスタム オブジェクトはパイプラインに書き込まれました。つまり、彼は黄色のピンポン球を箱の中に入れました。元のプロセス オブジェクトのピンポン球は破棄されました。彼は箱に入っている合計 1 ダースほどのプロセス オブジェクトのピンポン球それぞれに対してこの操作を行いました。操作が完了すると、白の各ピンポン球が黄色のカスタム オブジェクトのピンポン球に置き換えられました。最後に、彼は END スクリプト ブロックを実行しました。このブロックは空だったので時間はかかりませんでした。
締めくくりに、Format-Table の受講生が処理を引き継ぎました。彼女は箱の中のすべてのピンポン球 (この時点ではすべて黄色の "カスタム" オブジェクト) を拾い上げ、各ボールに書き込まれた両方のプロパティを使用して表を作成し始めました。フリップ チャートに書き込んだところ、TimeStamp と ProcessName の 2 つの列を持つ行が 12 行ほどある表ができました。

物理的考察
この演習のパイプラインとフィルタ処理関数は、クラスの受講生全員の心を捉えました。ピンポン球は、オブジェクトを表すという大きな役割を果たしました。オブジェクトは、シェルについてただ話をするときは抽象的になりがちです。
コマンドレットがこれらのオブジェクトを操作する方法、結果がパイプラインに渡される方法、および次のコマンドレットが結果を取得し、さらにオブジェクトを操作する方法を全員が理解できました。PROCESS スクリプト ブロックが入力オブジェクトを 1 つずつ処理する手法と同様に、フィルタ処理関数のイベント シーケンスはさらに明白でした。
これは、新しいカスタム オブジェクトを作成し、パイプラインに渡す方法も示しました。さらに、単純なテキストではなくカスタム オブジェクトを作成する利点も示しました。利点とは、新しいカスタム オブジェクトは Format-Table などの他のコマンドレットでも使用できるため、後でデータを柔軟に使用したり表示したりできるということです。

実践的応用
受講生からの明白な質問は、デモンストレーションで示したパイプラインとこれらのフィルタ処理関数を実際のアプリケーションでどのように使用できるか、ということでした。私にとってその答えは簡単でした。最近開催された会議のためにいくつかの例を作成していたからです (これらの例は scriptinganswers.com/essentials/index.php/2008/03/25/techmentor-2008-san-francisco-auditing-examples からダウンロードできます)。
ある例は、複数のコンピュータから Windows Management Instrumentation (WMI) の Win32_UserAccount クラスのプロパティ一覧を取得することを目的としています。コンピュータ名の一覧が C:\Computers.txt にある場合は、次の単純なコマンドでこの処理を行うことができます。
Gwmi win32_useraccount –comp (gc c:\computers.txt)
問題は、Win32_UserAccount クラスに各インスタンスを呼び出したコンピュータを通知するプロパティが含まれていないということです。したがって、多くのコンピュータのアカウントが混在する役に立たない一覧が生成されます。私はこの問題を解決するために、呼び出し元のコンピュータ名を含む新しいカスタム オブジェクトを作成し、必要なクラス プロパティを選択します。このカスタム オブジェクトのコードを図 2 に示します。
図 2 カスタム オブジェクトを使用したコンピュータ名の収集とプロパティの選択
function Get-UserInventory {
  PROCESS {
    # $_ is a computer name
    $users = gwmi win32_useraccount -ComputerName $_
    foreach ($user in $users) {
      $obj = New-Object
      $obj | Add-Member NoteProperty Computer $_
      $obj | Add-Member NotePropertyPasswordExpires ($user.PasswordExpires)
      $obj | Add-Member NoteProperty Disabled ($user.Disabled)
      $obj | Add-Member NotePropertyFullName ($user.FullName)
      $obj | Add-Member NoteProperty Lockout ($user.Lockout)
      $obj | Add-Member NoteProperty Name ($user.Name)
      $obj | Add-Member NotePropertyPasswordRequired ($user.PasswordRequired)
      $obj | Add-Member NotePropertyPasswordChangeable ($user.PasswordChangeable)
    }
  }
}

Get-Content c:\computers.txt |
  Get-UserInventory |
  where { $_.PasswordRequired -eq $False } |
  selectComputer,Name |
  Export-Csv c:\BasUsersBad.csv
最後のコマンド ラインは、すべてのコンピュータ名をフィルタ処理関数に渡してカスタム オブジェクトを作成します。次に、PasswordRequired プロパティが False であるユーザー以外のすべてのユーザーを除外しました (問題のあるアカウントの監査レポートを作成するためです)。そして単純に Computer プロパティと Name プロパティを保持し、無期限のパスワードを持っているため注意が必要なコンピュータ名とアカウント名の一覧が最終的なレポートに含まれるようにします。フィルタ処理関数によって、このマルチコンピュータ レポートの作成が可能になります。フィルタ処理関数は、呼び出し元のコンピュータ名を出力に追加し、表示する必要のないプロパティを削除するからです。
同じようにこのタスクを実行できる方法は他にもありますが、この方法がおそらく最も簡単でしょう。この方法は、重要な概念や手法を示すのにも役立ちます。

遊ぶ時間を作る
パイプラインに慣れている場合でも、ここで学ぶべき教訓があります。物理的なオブジェクトの観点で考察すると、自分が何をしようとしているかを把握するのに役立ちます。
したがって、Windows PowerShell の概念に苦労する場合は、コンピュータから一歩離れて、日常的なものを使用してタスクを再現してみてください。そのためにピンポン球 (または、見つかった場合は四角いピンポン球) を入れた小さなバッグを手元に置いておくことをお勧めします。
今月のコマンドレット : Out-File
> 記号を使用してコマンドレットの出力をファイルにリダイレクトしたことが何回ありますか。つまり、Get-Process > Processes.txt などのリダイレクトです。実際には Out-File コマンドレットを使用していることをご存じですか。上記と同じ機能を実行するコマンドは、Get-Process | Out-File Processes.txt です。
もちろん、入力する文字の数は増えます。では、なぜわざわざ完全な Out-File コマンドレットを入力するのでしょうか。その理由の 1 つは、Out-File の方が読みやすいということです。たとえば 6 か月後に来た人があなたのスクリプトを見て、> が何を表しているのだろうと思うことがあります (やはり、> は古い方法なのです)。
一方、Out-File を使用すると、ファイルが作成されて書き込まれることが一目瞭然です。さらに、-force パラメータや -noClobbe パラメータと共に -append パラメータ (>> と同じ) を使用することで、既存のファイルを上書きするかどうかを指定できます。最後に、Out-File を入力すると -whatif パラメータを使用することもできます。この便利なパラメータは、Out-File の処理内容を実際には処理を行わずに表示します。このすばらしい方法を使えば、ほとんど危険を冒すことなく複雑なコマンド ラインをテストできます。
ビデオ
Don Jones によるこれらのコマンドの実行をご覧ください。

Don Jones は『Windows PowerShell: TFM』の共著者で、Windows PowerShell のクラス (www.ScriptingTraining.com) の講師も務めています。


Hey, Scripting Guy! アドレナリンの大量分泌
Microsoft Scripting Guys

私たちは、TechNet Magazine の記事を執筆する作業は、あらゆる仕事の中で最も名誉とやりがいのある仕事だと確信しています (もちろん、実際に報酬をいただけたら、さらにやりがいは増しますが、それはまた別の話です)。この仕事にはどれほどの名誉があるのか、ですか。次のようにお答えしておきましょう。現在、世界中で、布団にくるまった子供たちが母親を見上げて、「お母さん、おとなになったら TechNet Magazine で月刊のスクリプト コラムを書きたい」と言っています。
注 : もちろん、世界中の人は、このコラムが既に子供によって書かれていると思っているかもしれませんが、それもまた別の話です。
Scripting Guys が TechNet Magazine の記事を執筆することに伴う称賛を喜んで受け入れることは有名です。私たちは、サインをねだられたりパパラッチに追い回されたりすることにも耐えられるようになりました。でも、実のところ、私たちは名声や誇りのためにこの仕事をしているのではありません。私たちは、システム管理スクリプトの記述に伴う、純粋なアドレナリンの大量分泌のためにこの仕事をしているのです。
確かに、"純粋なアドレナリンの大量分泌" という言葉と "システム管理スクリプト" という言葉を同じ文の中で目にすることは、あまりありません (もちろん、"純粋なアドレナリンの大量分泌" の後に "とは無縁の" が付いていれば話は別ですが)。
普通の人は、システム管理スクリプトは非常に便利であるが、おそらくあまり刺激的なものではないと考えています。それどころか、スクリプトは少し退屈だと感じているかもしれません。その理由は、これらの人たちが皆、Windows Vista® や Windows Server® 2008 のブート構成データ スクリプトを記述したことがないからです。
今の話を聞いて心拍数が 1 つか 2 つ上昇したでしょう。このコラムを読んでいる方のほとんどはおそらくご存知だと思いますが、Windows Vista と Windows Server 2008 では、従来の boot.ini ファイルが廃止され、代わりに新しいブート構成データ ストアが導入されました。この新しいデータ ストアが導入されたことにより、強化された機能を使用して、より柔軟にブート処理を管理できるようになりました。
これは非常にすばらしいことです。でも、本当にすばらしいのは、新しい Windows® Management Instrumentation (WMI) プロバイダの登場によって、スクリプトを使用してブート構成データ (BCD) ストアに簡単にアクセスし、このデータ ストアを完全に管理できるようになったことです。
背骨のあたりに奇妙な感覚が走ったと思いますが、心配しないでください。純粋なアドレナリンが大量分泌されると、そういう感じがするものです。BCD スクリプトを使用し始めれば、この感覚にも慣れてくるでしょう。
先に進む前に 1 つお伝えしておきますが、BCD プロバイダを使用して実現できる操作をすべて取り上げるのは、少なくともこの 1 回のコラムでは、まず不可能です (TechNet Magazine の編集者に、ブート構成データ スクリプトの記述方法のみを扱った特別号を発行してもらえるかどうかをメールでたずねましたが、まだ返事は届いていません)。
詳細については、BCD WMI プロバイダのドキュメント (go.microsoft.com/fwlink/?LinkId=116953) を参照してください。とりあえず、このコラムでは、マルチブート コンピュータ (複数のオペレーティング システムがインストールされたコンピュータ) 用に設計されたサンプル コードを紹介します。
これらのスクリプトは Windows Vista と Windows Server 2008 でのみ動作します。この理由は、前述のとおり、現在 BCD はこれら 2 つのオペレーティング システムでのみサポートされているためです。
まずは、現在コンピュータで使用されている OS を通知するスクリプトを紹介します。確かに、これは BCD プロバイダの最も刺激的な使用方法ではありません。BCD プロバイダを使用しなくても、WMI の Win32_OperatingSystem クラスを使用すれば、現在コンピュータで使用されている OS を確認できるためです。ただし、これはかなり単純なスクリプト (少なくとも BCD スクリプトにしては) であり、BCD の操作に必要な基本的な技法を示すのに適しています (控えめに言うと、そうですね、何と言えばいいでしょう、やや "珍しい" 技法ですね)。
それに、私たちは Hey, Scripting Guy! コラムをあまり刺激の強い内容にすることはできません。過度に興奮した、あまりに熱心な Hey, Scripting Guy! コラムのファンが原因で起こったすべての損害の責任は私たちが負うことになると、TechNet Magazine のスタッフに言われているためです。正規表現に関するコラムを公開した後に世界中で勃発した騒動を考えると、もう二度と、あれほどまでに刺激的なことをするわけにはいきません。
注 : ビートルズがファンに取り囲まれているビデオや、ジョン、ポール、ジョージ、およびリンゴをひとめ見ただけで、気絶したり泣いたりしている女の子たちの写真を覚えていますか。新しいコラムを公開するたびに、私たちはほぼこれと同じ状況を経験します。
ええ、まあ、今の話は少し大げさかもしれません。でも、多くの人が (女性だけでなく男性も) Hey, Scripting Guy! コラムを読んだ後にむせび泣くことは確かです。
それはともかく、図 1 のスクリプトをご覧ください。このスクリプトでは、BCD プロバイダを使用して、現在コンピュータで使用されている OS を確認しています。このスクリプトを実行する前に知っておかなければならないのは、管理者として実行する必要があることです。管理者として実行しなかった場合、スクリプトは失敗します。
図 1: 現在使用されているオペレーティング システムの取得
Const BcdLibraryString_Description = &h12000004
Const Current = "{fa926493-6f1c-4193-a414-58f0b2456d1e}"

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.OpenObject Current, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
Wscript.Echo "Current operating system: " & objElement.String
いえ、単に管理者特権が与えられたアカウントでログオンすればよいと言っているわけではありません。[スタート] ボタンをクリックし、[コマンド プロンプト] を右クリックし、[管理者として実行] をクリックしてコマンド プロンプト ウィンドウを開く必要があります。これで、このスクリプトをコマンド プロンプトから実行できます。
このスクリプトのしくみはどうなっているか、ですって。皆さんから、その質問が寄せられるのではないかと心配していたのです。でも、問題ありません。できる限りわかりやすく説明するよう努めます (そうすれば刺激を最小限に抑えることができますね、少なくともしばらくの間は)。
まずは、BcdLibraryString_Description と Current という 2 つの定数を定義します。BcdLibraryString_Description は、ここで取得するオブジェクトを参照する定数です。この場合、現在使用されているオペレーティング システムの説明 (名前) がこのオブジェクトに格納されます。
ちなみに、これは、BCD プロバイダの使用に関する愛すべき特徴の 1 つです。通常は、単純にプロパティの値を取得するのではなく、このような定数値の 1 つ (および GetElement メソッド) を使用して別のオブジェクトを取得し、そのオブジェクトのプロパティの値をエコー バックします。確かに少しばかげた処理ですが、よく言われるように、楽しみの半分は、その目的地に至るまでの道程ですからね。
注 : こう言われると、目的地はどこなんだろうと思ってしまいますね。
定数 Current は、単に現在使用されているオペレーティング システムを表す GUID です。
{fa926493-6f1c-4193-a414-58f0b-2456d1e}
上記の値は "既知の" GUID、言い方を変えれば "よく知られている" GUID と考えられています (これで少なくとも、マイクロソフトの社員が実はユーモアのセンスも持ち合わせていることがおわかりいただけたでしょう)。
この "よく知られている" GUID を、私たちはあえてスクリプトの中に含めました。このコラムを読んでいる方の中に、次の 2 つの値のどちらが正しいかを思い出せない方がいらっしゃるといけないからです。
{fa926493-6f1c-4193-a414-58f0b2456d1e}
{fa926493-6f1c-4193-a414-58f0b2456d1f}
注 : 気になる方のために言っておくと、GUID は "グイッド" または "グーイッド" と発音します。また、上記の GUID は 3 組目の数字が 4 で始まるのでバージョン 1 の GUID であることなど、説明したいことはまだたくさんありますが、刺激は最小限に抑えると約束しましたからね。私たちは、約束は守ります。
ご想像のとおり、BCD プロバイダを使用するときは、ほぼどのような場合でも、定数、16 進値、および GUID を使用する必要があります。これらをすべて今月のコラムで取り上げることはできませんが、詳細については、前述の MSDN® の BCD に関するページ (go.microsoft.com/fwlink/?LinkId=116953) で確認できます。ただし、このページを参照するのは、刺激に耐えられる方だけにしてください。
2 つの定数を定義したら、次は、ローカル コンピュータの WMI サービスに接続します。このスクリプトを使用して、リモート コンピュータのブート構成データを取得することはできるでしょうか。もちろん、できます。
正直なところ、取得できなかったとしたら、この BCD プロバイダを使用したスクリプトの価値はほとんどなくなります。リモート コンピュータからブート構成データを取得するには (この場合も、リモート コンピュータでは Windows Vista または Windows Server 2008 が実行されている必要があります)、以下のように、そのコンピュータの名前を変数 strComputer に代入するだけです。
strComputer = "atl-fs-001"
WMI 接続文字列に含まれているいくつかの重要な項目についても説明しておきます。まず、お気付きかもしれませんが、バックアップ特権と復元特権の両方が接続文字列に含まれています。これを示しているのが {(Backup,Restore)} という構文です。この構文は重要なのでしょうか。そうですね、スクリプトを動作させたいのであれば、非常に重要です。この 2 つの特権を明示的に含めずにスクリプトを実行すると、エラーが発生します。
次に注意する必要があるのは、システム管理スクリプトで最もよく使用される root\cimv2 名前空間に接続しないことです。代わりに、root\WMI 名前空間に接続し、BCDStore クラスに直接バインドします。これを行うのが次のコードです。
"\root\wmi:BcdStore"
この部分はそれほど刺激的ではありません。お楽しみはこれからです。
1 つか 2 つ例外はあるかもしれませんが、ほとんどの BCD スクリプトは、共通する 3 つの手順で始まります。それは、定数を定義し、WMI サービスに接続し、BCD ストアを開くという手順です。1 つ目と 2 つ目の手順は既に完了しました。次のコード行は 3 つ目の手順を示しています。
objStoreClass.OpenStore "", objStore
前述のとおり、ここでは BCD ストアを開いています。BCD ストアは、すべてのブート構成情報が格納されるオペレーティング システム エンティティです。このストアを開くには、単純に OpenStore メソッドを呼び出して、次の 2 つのパラメータを渡します。
  • 空の文字列 ("")。この文字列は、既定のストアを開くことをスクリプトに指示します。
  • objStore。これは、スクリプトに提供する "出力" パラメータです。メソッドに変数名を渡すと、メソッドは感謝のしるしに、その変数名をオブジェクト参照として使用するオブジェクト (この場合は、BCD ストアを表すオブジェクト) を返します。
ストアが開いたら、次のように OpenObject メソッドを使用して、(出力パラメータ objDefault に格納された) もう 1 つのオブジェクトを取得できます。
objStore.OpenObject Current, objDefault
この新しいオブジェクトは何でしょうか。そうです、現在使用されているオペレーティング システムです。これは、OpenObject に、現在使用されているオペレーティング システムを表す既知の GUID である定数 Current を渡していることからわかります。
これで、現在コンピュータで使用されているオペレーティング システムがわかりましたね。まあ、まだ完全にはわかっていませんが。この情報を得るには、次のように GetElement を使用して、このオペレーティング システムの説明を表すオブジェクトを取得する必要があります。
objDefault.GetElement _
  BcdLibraryString_Description, objElement
さて、皆さんは、過度に興奮してなんらかの騒動を起こさないことを約束できますか。そうですか、わかりました。それではお教えします。次のように String プロパティの値をエコー バックすれば、ようやく現在コンピュータで使用されているオペレーティング システムを確認できます。
Wscript.Echo "Current operating system: " _
  & objElement.String
落ち着いてください。騒動を起こさないと約束してくださったじゃないですか。難しいとは思いますが、できる限り努力してください。深呼吸をしましょう。BCD スクリプトを記述するときは、これが一番です。
既に説明したように、コンピュータで使用されているオペレーティング システムを確認するだけでも、非常に手間がかかります。この作業はもっと簡単に行うことができます。ですが、良い面を見ると、これで皆さんは BCD スクリプトのしくみを理解できました。つまり、今までスクリプト作成者にできなかったことをご自分の手で実現できます (落ち着いてください、落ち着いてください)。たとえば、マルチブート コンピュータでは、常に 1 つのオペレーティング システムが "既定" として設定されているので、コンピュータの再起動時には、だれかがそばにいて明示的に指定しない限り、既定のオペレーティング システムが自動的に読み込まれます。Windows Vista (および BCD プロバイダ) が登場するまで、スクリプト作成者は、コンピュータの既定のオペレーティング システムを確認できませんでした。でも今では非常に簡単に確認できます。図 2 のようなスクリプトを実行するだけです。
図 2: 既定のオペレーティング システムの確認
Const BcdLibraryString_Description = &h12000004
Const BootMgrId = "{9dea862c-5cdd-4e70-acc1-f32b344d4795}"
Const DefaultType = &h23000003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
    strComputer & "\root\wmi:BcdStore")
objStoreClass.OpenStore "", objStore

objStore.OpenObject BootMgrId, objBootMgr

objBootMgr.GetElement DefaultType, objDefaultOSIdentifier
objStore.OpenObject objDefaultOSIdentifier.Id, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
WScript.Echo "Default operating system: " & objElement.String
おっしゃるとおり、これはちょっとした騒動を引き起こすかもしれません。でも、ちょっとだけにしておいてくださいよ、いいですね。このスクリプトについては詳しく説明しません。これより前の 10 ～ 12 個の段落を読み飛ばしていなければ、自力でロジックを理解できるはずです。ただし、お気付きかもしれませんが、既定のオペレーティング システムを突き止めるには、OpenObject メソッドを使用してブート マネージャ オブジェクトのインスタンスを開くという中間手順を実行する必要があります。ブート マネージャを開いたら、定数 DefaultType を使用して、既定のオペレーティング システムを表すオブジェクトを取得できます。
確かに、現在使用されているオペレーティング システムを確認することも、既定のオペレーティング システムを確認することもできるとは、かなり刺激的ですね。でも、本当にすばらしいことはまだあります、わかりますか。それは、コンピュータにインストールされているすべてのオペレーティング システムの一覧を取得することです。これは刺激的でしょう。シートベルトを締めて、図 3 をご覧ください。
このスクリプトでは何を行っているのでしょうか。まず、WindowsImages と LegacyImages という 2 つの新しい定数を定義しています。WindowsImages を使用すると、BCD がサポートされているすべての OS (つまり Windows Vista と Windows Server 2008) のインスタンスを取得でき、LegacyImages を使用すると、コンピュータにインストールされているすべての "古い" オペレーティング システムのインスタンスを取得できます。BCD ストアに接続したら、次のように EnumerateObjects メソッドを使用して、コンピュータにインストールされている BCD に対応したオペレーティング システムのインスタンスをすべて取得します。
objStore.EnumerateObjects _
  WindowsImages, colObjects
図 3: コンピュータにインストールされているすべてのオペレーティング システムの検出
Const BcdLibraryString_Description = &h12000004
Const WindowsImages = &h10200003
Const LegacyImages = &h10300006

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore

objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wscript.Echo

objStore.EnumerateObjects LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
EnumerateObjects による処理の後は、コレクション内のすべてのオペレーティング システムを 1 つずつ処理する For Each ループを設定します。このループ内では、次の 2 行のコードを使用して、オペレーティング システムの説明を取得し、その説明を表示します。
objObject.GetElement _
  BcdLibraryString_Description, objElement
Wscript.Echo objElement.String
その後、次のように、コンピュータにインストールされているすべての古いオペレーティング システムに対して同じ処理を繰り返します。
objStore.EnumerateObjects _
  LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement _
  BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
注 : BCD スクリプトを実行するときの興奮は理解できますが、責任を持って実行するようにしてください。おそらく、人間の体が耐えられるアドレナリン大量分泌の回数には限界があります。妊娠中の女性、妊娠するかもしれない女性、妊娠しないかもしれない女性、妊娠したことのある女性、女性ですらない女性 (要するに男性) は、最初に医師の診察を受けてから、BCD スクリプトを実行することをお勧めします。
ええ、まあ、最初に医師の診察を受ける必要はありません。でも、実際に BCD スクリプトの実行についてたずねた場合に、医師が何と言うかは興味深いですね。
では、本当にすごいことに挑戦しましょう。それは、既定のオペレーティング システムを変更することです。たとえば、あるデュアルブート コンピュータで Windows Vista と Windows Server 2008 の両方を実行しており、Windows Vista を既定のオペレーティング システムに設定する必要があるとします。この操作を行うにはどうすればよいでしょうか。図 4 をご覧ください。このスクリプトを使用すると、目的の操作を行うことができます。
図 4: 既定のオペレーティング システムの変更
Const BootMgrId = "{9dea862c-5cdd-4e70-accl-f32b344d4795}"
Const BcdLibraryString_Description = &h12000004
Const DefaultType = &h23000003
Const WindowsImages = &h10200003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 If Instr(objElement.String, "Vista") Then
  objStore.OpenObject BootMgrId, objBootMgr
  objBootMgr.SetObjectElement DefaultType, objObject.ID
 End If
Next
このスクリプトでは、先ほどと同様に BCD ストアを開いた後、EnumerateObjects を使用して、コンピュータにインストールされている、BCD に対応したすべてのオペレーティング システムのコレクションを取得しています。その後、コレクション内のすべての項目を 1 つずつ処理する For Each ループを設定します。各オペレーティング システムの説明を取得するには、次の (もうお馴染みの) コード行を使用します。
objObject.GetElement _
  BcdLibraryString_Description, objElement
特定のオペレーティング システムの説明を取得したら、次のように InStr 関数を使用して、その値に Vista という言葉が含まれているかどうかを確認します。
If Instr(objElement.String, "Vista") Then
おっしゃるとおり、この方法は少し野暮な感じがします。より洗練された方法は、コンピュータにインストールされているすべてのオペレーティング システムを列挙し、それらを 1 つずつ処理するのではなく、Windows Vista の GUID を使用して、Windows Vista を直接開くことです。
残念ながら、この洗練された方法を使用するには、Windows Vista の GUID を知っている必要があります。一方、上記の野暮な方法を使用する場合は、何も知っている必要はありません (Scripting Guys にとって、これは常に喜ばしいことです)。名前に Vista という言葉が含まれているオペレーティング システムが見つかるまで調べ続ければよいだけです。
注 : Windows Vista のインスタンスがコンピュータに複数インストールされている場合は、どうすればよいでしょうか。その場合は、Vista Ultimate や Vista Enterprise などの文字列を探す必要があります。
Windows Vista が見つかったら、次の 2 行のコードを使用して、Windows ブート マネージャを開き、既定のオペレーティング システムを Windows Vista に設定します。
objStore.OpenObject BootMgrId, objBootMgr
objBootMgr.SetObjectElement _
  DefaultType, objObject.ID
今月はこれで終わりにします。いくら Scripting Guys と言えども、24 時間 365 日、休みなく刺激を受け続けたら、頭がおかしくなりますからね。でも、ご心配なく。来月また、刺激的な Hey, Scripting Guy! コラムを用意して戻ってきます。運が良ければ、皆さんもそれまでにはいつもの状態に戻っているでしょう。
Dr. Scripto のスクリプト パズル
パズルを解く能力だけでなく、スクリプト作成スキルもテストする月に 1 度の課題です。

2008 年 7 月 : VBScript 正方形
そうですね、おそらく正方形ではなく長方形ですが、それは良しとしましょう。このパズルを解くには、右側にある各正方形を左側にある空の正方形にはめ込んで、VBScript 関数の名前を作成します。各正方形は 1 回のみ使用できます。以下に例を示します。
この例では、OU という正方形 (長方形) を 1 つ目の単語に含まれている空の正方形に移動し、MS と OX を 2 つ目の単語に含まれている空の正方形に移動します。これで、VBScript 関数の UBound と MsgBox ができあがります (下図参照)。
それでは、いざ挑戦です。

解答 :
Dr. Scripto のスクリプト パズル
解答 : VBScript 正方形 (2008 年 7 月)

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


デスクトップ ファイル Windows のネットワーク ブートを実行する
Wes Miller

目次
PXE のしくみ
RIS について
WDS の始まり
その他の機能
まとめ
これから数か月にわたり、Windows 展開サービス (WDS) について取り上げます。WDS は、Windows Server 2003 用に別途提供されており、Windows Server 2008 には組み込まれています。WDS は展開インフラストラクチャにおける非常に重要なコンポーネントになる可能性があるので、このシリーズで、WDS の基礎を皆さんに理解していただきたいと思っています。この
第 1 回目のコラムでは、Preboot eXecution Environment (PXE、ピクシーと発音します) のアーキテクチャ、リモート インストール サービス (RIS) の歴史、およびマイクロソフトで使用されているその他の PXE 関連テクノロジについて説明します。
RIS は、2001 年に私が Windows コア OS グループに移ったときに引き継いだテクノロジの 1 つです (RIS は複雑で、BIOS の実装やハードウェアに依存するので、少しびくびくしながらこのテクノロジを引き継ぎました)。ですが、RIS は、私がプログラム マネージャを務めていたときに、Windows® PE と共に最も楽しんだテクノロジの 1 つでもありました。
一連の 3.5 インチのディスクを使用して、Windows 3.0 を初めてインストールしたときのことを思い出します。やがて、起動可能な CD (Windows 98 の一部のバージョンに含まれていました) によって、インストール作業はより簡単になりました。ただし問題もあり、インストールを実行するには、ローカル ハード ディスクだけでなく、必ず特定の種類のローカル メディアが必要でした。
長年の間、Windows のネットワーク ブートを実行する機能 (つまり、ハード ディスクを使用せずに、ネットワーク経由で Windows を完全にブートする機能) を求める意見がユーザーから頻繁に寄せられていました。初期の Windows では、この機能が備わったバージョンも提供されていましたが、Windows NT® ではこの機能が提供されませんでした。Windows Server® 2003 と Windows Server 2008 の最新バージョンは、iSCSI イニシエータを使用して起動できますが、完全にローカルで処理が実行されるわけではない (つまり、常にリモート ドライブをブート ドライブとして使用する) ので、初期の Windows で提供されていたネットワーク ブートとはまったく異なります。
クライアントの事前準備を行う
  • RIS クライアントの事前準備プロセスを評価する
  • 事前準備が完了したクライアントを使用してネットワーク セキュリティを強化するための計画
  • クライアント コンピュータの事前準備を行う
  • オペレーティング システムのリモート インストール
Windows 2000 から、マイクロソフトは、ネットワーク ベースのインストールを可能にする、後に RIS と呼ばれるテクノロジの開発を始めました。RIS の目的は、PXE を使用してオペレーティング システム イメージをインストール先のコンピュータのローカル ディスクに配置するという、比較的わかりやすいものでした。

PXE のしくみ
図 1 は、PXE のブート シーケンスを示しています。PXE は Wired for Management イニシアチブの一部として Intel とその他のベンダによって開発された、比較的単純なプロトコルです。このプロトコルは、BOOTP から派生した動的ホスト構成プロトコル (DHCP) に基づいており、通常はネットワーク インターフェイス カード (NIC) に実装されています。簡単に言うと、次のような動作が行われます。
図 1 PXE のブート シーケンス (画像をクリックすると拡大表示されます)
手順 1 システム BIOS が起動し、起動順序が決定されます。
手順 2 PXE からの起動が、ハード ディスク、フラッシュ ドライブ、および CD-ROM よりも優先されている場合、またはこれらのデバイスがいずれも存在しない場合は、NIC から Universal Network Driver Interface (UNDI) が読み込まれます。NIC の特徴は、非常に小さなネットワーク デバイス ドライバと簡易ファイル転送プロトコル (TFTP) が実装されていることです (BIOS の実装にもよりますが、エンド ユーザーは、PXE ブートを行うために F12 キーを押すことを要求される場合があります。PXE ブートは標準的な動作ではないので、この動作を無効にする機能が提供されていると役立ちます)。
手順 3 システムによって単純なユーザー データグラム プロトコル (UDP) のブロードキャストが行われ、DHCP サーバーの検索が実行されます。実際にはこれが PXE のブート シーケンスの最初の手順であり、"Discover" と呼ばれます。プロトコルが UDP であることに注意してください。つまり、PXE の通信がルーターやスイッチを通過できるように、少し時間を割いて構成を変更する必要が生じる場合があります。
手順 4 DHCP サーバーがブロードキャストを受信した場合、それに応じてこの DHCP サーバーから IP アドレスが返されます。この手順は "Offer" と呼ばれます。ここで覚えておいていただきたいのは、PXE がステートレスであることによって、この時点でクライアントから提供される、システムに関する一意の状態情報の量がかなり限定されることです (MAC アドレスと、場合によっては System Management BIOS GUID (SMBIOS GUID) が提供されます)。
手順 5 クライアントが IP アドレスを含むパケットを受け取った後、追加情報 (つまり、PXE サーバーのアドレス) が必要であることを通知します。ここで、最初に応答した DHCP サーバーからの情報を含む、別のブロードキャストが行われます。このブロードキャストによって、追加情報 (具体的には、ネットワーク ブート プログラム (NBP) の場所) が必要であることが、クライアントから DHCP サーバーに通知されます。この手順は "Request" と呼ばれます。
手順 6 PXE サーバーから、PXE サーバーのアドレスと NBP の場所が返されます。NBP は、非常に小さいブート実行可能ファイルで、32 KB 未満である必要があります。この手順は "Acknowledge" と呼ばれます。楽しみながら手順を追っているうちに、DORA (Discover、Offer、Request、Acknowledge) という頭字語に気付いたと思います。これで、シーケンスの手順を簡単に覚えることができますね。
Microsoft DHCP および WDS をインストールしている場合 (またはその他のベンダによって提供されたテクノロジを使用している場合)、Request の手順は発生しません。実は、DHCP サーバーから最初に提供される Offer パケットには、PXE サーバーと NBP プログラムの場所が既に含まれています (このため、手順が 2 つ省略され、時間を節約できます)。
手順 7 先ほど説明した小さな TFTP プロトコル スタックを保持しているクライアントが、PXE サーバーによって指定されたネットワーク上の場所から NBP をダウンロードします。TFTP は、古くに策定された、非常に小さなステートレスのプロトコルです。TFTP は、セキュリティやパフォーマンスのために選ばれたのではなかったため、多くのルーター管理者は、セキュリティやパフォーマンスを考慮して、このプロトコルを既定で無効にします。しかし、PXE を動作させるには、TFTP を有効にする必要があります。
多くの PXE の実装 (RIS を含む) では、作業を継続するために、この時点でユーザーに F12 キーを押すよう求める機能が提供されますが、通常、PXE サーバーの管理者は、この機能を無効にすることができます。来月 WDS についてさらに詳しく説明するときに、マイクロソフトがパフォーマンスの向上を目的として Windows Server 2008 用 WDS の TFTP デーモン (TFTPD) に実装したいくつかの機能強化について説明します。
手順 8 NBP が初期化されます。RIS の場合は、Windows ブート ローダーが起動し、展開処理が開始されます。この処理では、PXE (少なくとも実際のブート レベルのプロトコル) はもう使用されません。
ここで覚えておく必要があるのは、PXE (RIS、WDS、またはその他のインフラストラクチャ) は、低速リンクや、衛星通信などの待ち時間の長いリンクでは、うまく機能しないことです。低速リンクでは、大量のデータが転送される可能性があり、待ち時間の長いリンクでは、単純に通信速度が遅く、通信を維持することもできない場合があります。
お気付きかもしれませんが、PXE のブート プロセスでは、クライアントが要求を送信するときに、「あなたは私の母親ですか」と具体的にサーバーにたずねることはありません。これは、単純に、ある PXE サーバーを特定できるほど多くの状態情報が提供されないからです。このため、通常は競合状態が発生します。この場合、最初にクライアントの要求に応答したサーバーが優先されます。いくつかの方法を使用すると、この問題の発生率を下げることができます。
  • どれか 1 台の PXE サーバーの応答速度を調整します。サーバーの応答速度に影響を及ぼすのは、ネットワークの待ち時間とサーバーの処理能力です。実際に、以前マイクロソフトでは、Microsoft IT によって使用されていたサーバーの性能が非常に高く、たとえオフィス内に PXE サーバーが配置されていても、社内サーバーの方が先に応答することがありました。この場合は、事前準備が完了したクライアントへの応答でタイムアウトが一切発生しないように、ローカルの PXE サーバーを設定します。
  • クライアントの事前準備を行います。この作業は、PXE サーバーを社内の他の IT サーバーよりも先に応答させる場合、非常に重要です。クライアントの事前準備を完了することによって、Active Directory® は実際に「私はあなたの母親です」と WDS や RIS に返答できるようになります。SMBIOS GUID は、Active Directory に登録されるシステムの一意識別子として非常によく使用されます。ただし、システムに SMBIOS GUID が実装されていない場合 (比較的古いハードウェアは、高い確率でこれに該当します) は、MAC アドレスに基づいた GUID を使用できます (また、そうする必要があります)。詳細については、補足記事「クライアントの事前準備を行う」を参照してください。
  • PXE の通信がスイッチまたはルーターを越えないようにします。つまり、PXE サーバーを各セグメントに配置します。この方法の欠点は、実装と管理の両方に高い費用がかかることです (各サーバーに独自のイメージを配置する必要があります)。
RIS (および現在の WDS) サーバーは、Microsoft DHCP サーバーのように、関連付けられている Active Directory の実装に対して認証を受ける必要があります。この目的は、Active Directory にすべての PXE サーバーを認識させることによって、悪意のある PXE サーバーが原因で発生する問題 (PXE のブロードキャスト ストームなど) の数を減らすことです。
この方法で保護できるのは、Active Directory によって認識されるサーバーのみであることに注意してください。独自のドメインを設定しているか、Microsoft PXE 以外のサーバーを使用している場合、この方法を使用してサーバーを保護することはできません。
マイクロソフトでは、以前、非常に熱心な従業員が、RIS を使用しない "ゼロタッチ" 展開用の PXE サーバーを構成しました。この実装の動作では、ハード ディスクに格納されているデータが完全に消去され、新しいイメージが配置されます。隔離された (ネットワークに接続されていない) 環境で展開作業が行われていれば、問題は発生しなかったと思いますが、残念なことに、この展開作業はネットワークに接続された環境で行われました。このため、ハード ディスクよりも先に PXE が起動するように構成されていた、マイクロソフト幹部のコンピュータのディスクに格納されていたデータが消去されました。
これまで Microsoft IT では、F12 キーを押さなければ PXE ブートを実行できないようにサーバーを構成していたので、このような問題が発生したことはありませんでしたが、この PXE サーバーでは、待ち時間が発生せず、F12 キーを押す必要があることを示すメッセージや、なんらかの通知も提供されませんでした。つまり、この幹部社員のコンピュータと、移動ユーザー プロファイルによって保護されなかったすべてのデータは、事実上失われたことになります。
この話から、"ゼロタッチ" 展開を行う場合に、PXE サーバーを隔離するか、少なくとも F12 キーを押す必要があることを示すメッセージを表示することの重要性がおわかりいただけたと思います。

RIS について
私は、Windows 2000 がリリースされた後に、RIS を引き継ぎました。RIS に関して言えば、時代は Windows 2000 にやさしくはありませんでした。また、Windows Server 2000 の RIS は、テスト、パフォーマンス、およびその他の制約を理由に、Windows 2000 Professional の展開にのみ使用されました。残念なことに、サーバー製品は RIS を使用して展開できませんでした。Windows 2000 は x86 コンピュータでのみ使用できたので、1 つのアーキテクチャ上の 1 つの製品を前提とする RIS の実験台として適していました。RIS は、Active Directory と完全に統合されました (また、その必要がありました)。また、Microsoft DHCP サーバーにも RIS が適切に統合され、このサービスに固有の TFTPD も提供されました。
RIS は、Windows カーネルがセットアップ プロセスを開始できる状態になるまで、NBP を使用して TFTP ダウンロードを続行します (ある時点で、Windows からサーバーへの接続に使用されるプロトコルが TFTPD からサーバー メッセージ ブロック (SMB) に切り替わってからは、フロッピー ディスクを使用して開始される従来の Windows 2000 または Windows XP のインストールと同じリテラル コード パスが使用されます)。ネイティブ モードの Windows が初期化されると、Windows セットアップによって RIS の OSChooser (OSC) ウィザードが起動されます。
OSC の画面は、構成可能な HTML 2.0 のようなページです。これらのページは制約が厳しく、画像などを含めることはできません。また、ANSI 以外の文字を含めることもできません (そのため、一部のロケールでの Windows の展開が複雑になりました)。
最終的に、RIS によって RIS サーバー上に txtsetup.sif ファイルが作成されます。OSChooser ウィザードが完了すると、クライアントは "ソフト リブート" されますが、RIS サーバーと txtsetup.sif ファイルの場所は保持され、ソフト リブートの完了後に再度読み込まれます。この txtsetup.sif ファイルの内容は、基本的に unattend.txt ファイルと同じですが、RIS がセットアップ プロセスを完了するのに役立つ、その他のいくつかのフィールドが含まれています。
RIS では、従来の無人セットアップ (RISetup) と非常によく似たセットアップを実行することもできます。RIS では、Sysprep (RIPrep) と同様の複製ベースのインフラストラクチャが使用され、実際に Sysprep と同じコードが使用されます。ただし、RIPrep イメージを RIS サーバーにアップロードすることもできます。
その後、RIS にはいくつかの基本的な制限があることが明らかになりました。1 つ目は、サーバーを展開するためのサポートが提供されなかったことです。Code Red や Sasser などの特定の攻撃が発生したこと、および 2001 年 9 月 11 日の惨劇からの迅速な回復を目指す主要な顧客が IT に関する複雑な問題を経験したことから、マイクロソフトでは、既存の Windows 2000 RIS サーバーを使用して Windows Server を展開するソリューションの開発に急ピッチで取り組みました。このソリューションは Windows Server 2003 で提供するために開発されましたが、正式にはリリースされませんでした。
PXE に関連するテクノロジの詳細情報
  • PXE クライアント、DHCP、および RIS サーバーの間で行われる、PXE に関する対話
  • PXE を使用したオペレーティング システム展開の計画
  • PXE のアーキテクチャ
  • リモート インストール サービス
  • オペレーティング システムのリモート インストール
  • オペレーティング システムのリモート インストールに関するステップ バイ ステップ ガイド
  • WDS PXE プロバイダ
  • リモート インストール サービスとは
  • Windows Server 2003 Automated Deployment Services
2 つ目は、RIS で OSChooser ウィザードを完全に自動化する機能が提供されなかったことです。この機能は、後に Windows Server 2003 の <META ACTION="AUTOENTER"> 要素によって提供されました。最後は、ANSI 以外の文字が使用された場合に OSChooser が正しく機能しなかったことです。これは、米国外のいくつかの顧客から指摘された重要な欠点です。
このため、たとえば、フランス語のキーボードを使用して RIS インストールを完了することはできませんでした。世界中のコンピュータの BIOS レベルで ANSI 以外の文字を正しく機能させることは非常に難しかったので、簡単にこの問題を解決することはできませんでした。
Windows Server 2003 のリリース時に、Intel Itanium アーキテクチャ、および Windows 2000 のすべてのサーバー製品と Windows Server 2003 のサポートが正式に追加されました。Windows Server 2003 は、x64 アーキテクチャのサポートによってさらなる発展を遂げました。
RIS の TFTPD も、パフォーマンスを向上させるために大幅に書き換えられました。Windows Server 2003 では、最大 75 台までクライアントを同時に起動できるようになりました。この上限に達するのは、SMB の帯域幅が、クライアントへのネットワーク トラフィックによってすべて使用されたときであることを覚えておいてください。

WDS の始まり
"Longhorn" (Windows Server 2008 のコード ネーム) 用の RIS の開発に取り組み始めたとき、私たちは一歩譲歩する必要があることがわかりました。以前のコラムで説明したように、私たちは既に Windows PE からのイメージ ベースの (WIM) セットアップに賭けていました。その譲歩の結果、PXE を使用して起動した Windows PE インスタンスからのイメージ ベースの展開という重要な理念が、WDS の基盤となりました。
また、Windows Vista® を展開するための共通プラットフォームとして Windows Server 2003 を使用できること、および下位の WDS に対応する "帯域外の" ソリューションが必要になることもわかりました。その結果、WDS を Windows Server 2003 SP1 で実行できるようになり、Windows Server 2003 SP2 に WDS が組み込まれました。
WDS は、RIS サーバー (レガシ モード)、ハイブリッド サーバー (混合モード)、または WDS 専用のサーバー (ネイティブ モード) として動作させることができるので、WDS を使用すると、当然の結果として、正式な WDS 形式の展開に移行できます。顧客から、RIS を Windows Server 2003 SP2 システムにインストールする方法はありますか、という問い合わせを受けたことがあります。そうですね、方法はあります。これを行うには、WDS をインストールし、レガシ モードで実行します。図 2 は、サポートされるオペレーティング システムを示しています。
図 2. 展開がサポートされるプラットフォーム
オペレーティング システム | RIS (Windows 2000) | RIS (Windows Server 2003)** | WDS (Windows Server 2003)**** | WDS (Windows Server 2008)
Windows 2000 Pro | X | X | X | X
Windows 2000 Server | * | X | X | X
Windows XP Pro |  | X (x86 および IA64)*** | X | X
Windows Server 2003 |  | X (x86 および IA64)*** | X | X
Windows Vista |  |  | X | X
Windows Server 2008 |  |  | X | X
* Windows 2000 Server の RIS に追加されたサポートの詳細については、support.microsoft.com/kb/308508 と support.microsoft.com/kb/313069 を参照してください。 ** WDS のレガシ モードと混合モードでも、この表の内容に従って、以前のバージョンのインストールがサポートされます。 *** Windows Server 2003 SP1 では x64 ベースのシステムのサポートが追加されました。IA64 システムでは、RISetup ベースのインストールのみがサポートされていました。 **** ネイティブ モードがサポートされます。
Windows Server 2003 SP1 および SP2 の WDS は、WDS への移行を開始することを目的としています。以前に説明したように、Windows Server 2008 の WDS で追加された主な機能は、書き換えられた TFTPD、拡張ファームウェア インターフェイス (EFI) ブートのサポート、そして言うまでもありませんが、マルチキャスト ベースの展開です。

その他の機能
マイクロソフトの別のチームによって、Automated Deployment Services (ADS) が構築されました。このサービスの最も重要な目標は、サーバーのプロビジョニングをすばやく実行することでした。ADS の特徴は、正式なセクタ ベースのイメージ作成、独自のブート エージェント (Windows PE よりも小規模ですが、すべての機能は提供されません)、独自の TFTPD、および非常に高度なマルチキャストです。ADS に組み込まれた機能は、ある程度 System Center Configuration Manager (SCCM) で提供されますが、すべての機能が提供されるわけではありません。
Windows XP Embedded では、独自の TFTPD を経由した RAMDisk への完全な PXE ブートが提供されましたが、この方法ではリモート展開は実行できません。このテクノロジは、PXE を使用して同じディスク イメージからさまざまなシステムを同時に起動できるように設計されました。

まとめ
この記事では、RIS の歴史を簡単に紹介しました。詳細については、補足記事「PXE に関連するテクノロジの詳細情報」を参照してください。来月は、WDS の基本的な知識について説明し、それ以降のコラムでは、WDS の高度な機能 (マルチキャストなど) を紹介します。そして最後は、WDS を使用せずに WDS を使用します (つまり既存の WDS とセットアップのエクスペリエンスを越えて、独自の展開手法を開発します)。

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


セキュリティ ウォッチ パスワードとクレジット カード、第 1 部
Jesper M. Johansson

目次
セキュリティに関する実行不可能なアドバイス
実行不可能かつ間違ったアドバイス
理解不能なアドバイス
画像を用いたサイト認証の落とし穴
先ごろ、ミネソタ大学から連絡があり、学内誌のインタビューを受けてほしいと依頼されました。どうやら実社会で成功を収めている卒業生に関する特集記事を組みたいらしいのですが、だれも見つからなかったので私にお鉢が回ってきたようです。インタビューアが私の仕事の内容についてたずねてきたので、数分間、セキュリティ
インフラストラクチャ ソフトウェアについて説明しました。彼女は驚いたようすで、「本当に複雑なんですね。私は、セキュリティといえば、パスワードとクレジット カードくらいしか思い浮かばないものですから」と答えました。
私はこの彼女の答えについてしばらく考え、なかなかよいポイントを突いていることに気付きました。確かに、セキュリティといえば、パスワードとクレジット カードに違いありません。少なくとも、エンド ユーザーにとってはそうです。我々のような IT 業界の人間はセキュリティというと、暗号化アルゴリズムや WS* の利点、Kerberos は TLS や NTLMv2 よりも優れているかどうか、パスワード ハッシュにはソルトを加えるべきかどうかなど、よく話題になるあらゆる難解なトピックを思い浮かべます。確かに、私たち専門家はエンド ユーザーとはまったく異なる深い洞察を持っていますが、概して、1 つの基本的な事実を忘れがちです。それは、セキュリティは、サービスの提供を受ける側にとっては、パスワードとクレジット カードという形でしか認識されないという事実です。
我々が好んで難解なトピックについて議論したり、新しいテクノロジを考え出したりするのはすべて、エンド ユーザーのデータを保護することが目的であることは確かです。それでも、私たち専門家は本来の目的を見失っているように思えます。IT 業界のセキュリティ専門家たちの存在意義は、利用者の要求、つまりデータを保護するという要求に応えることにあります。それには、もちろん、IT 資産を安全に利用できるようにすることも含まれます。目的はそれだけです。
前回の記事で、ウイルス対策ソフトウェアを実行するためにコンピュータを購入する人はいないと書きました。ユーザーは、オンライン バンキングを行ったり、ゲームをしたり、メールを書いたり、宿題をしたり、その他の主要な機能を利用するためにコンピュータを購入するのです。同じように、企業が IT セキュリティ部門に予算を割いているのは、NTLMv2 を実装させるためではありません。セキュリティ部門に企業の IT 資産を保護させ、企業全体が安全に IT リソースを活用し、ビジネスの目的を達成できるようにするためです。
セキュリティ部門の使命は企業に奉仕することです。
私たちは、企業に奉仕するという意味で本当に良い仕事をしているでしょうか。それとも、実際には企業の役に立っているのではなく、むしろ邪魔をしているのでしょうか。議員や規制策定者は我々が企業の邪魔をするように仕向けているのでしょうか。私には、セキュリティ専門家たちが導入している新しい技術がすべてエンド ユーザーの役に立っているとは思えません。そこで、この記事では、我々 IT プロバイダがエンド ユーザーの役に立つのではなく、むしろ害を及ぼしているような領域について調べてみることにします。
私たちがユーザーに押し付けているセキュリティ上のアドバイスや多くのセキュリティ技術が、実行不可能である、間違っている、または理解不能である、あるいはこの 3 つの点のうち複数が当てはまるようなものであると感じることがときどきあります。この 3 回シリーズの記事では、セキュリティ専門家が、上記の 3 つの点のうち 1 つまたは複数が当てはまるセキュリティ上のアドバイスやテクノロジの展開を行うことによって、ユーザーを混乱させているケースについて見ていきます。

セキュリティに関する実行不可能なアドバイス
ユーザーを最も混乱させるのは、セキュリティに関する実行不可能なアドバイスです。混乱させるだけでなく、間違っているアドバイスさえあります。図 1 に、長年使用され、理論的には正しいものの、実際にはまったく役に立たないよくあるアドバイスの一部を示します。
図 1 セキュリティに関する実行不可能なアドバイス (画像をクリックすると拡大表示されます)
使用しているオンライン アカウントごとに異なるパスワードを使用すること、と書かれている箇所があります。このアドバイスは、30 年前であれば理にかなっていたでしょう。当時は、のちにインターネットとなるネットワークの利用者の数が数百人程度しかいませんでした。彼らは優秀な人たちでしたが、特別良いパスワードを使っていたわけではなかったのです。このアドバイスは不幸にも残されたままとなり、何度も繰り返し言われ続けてきました。しかし、このアドバイスの内容を現在のコンピュータの使用法に合わせて修正する努力は行われませんでした。
皆さんはオンライン アカウントをいくつお持ちでしょうか。私は、厳密には把握していないものの、約 115 のオンライン アカウントを持っています。図 1 のアドバイスによれば、私は 115 の異なるパスワードを作成する必要があるだけでなく、30 ～ 60 日ごとにそれらのパスワードを変更しなければなりません。つまり、毎日 2 ～ 4 個のパスワードを変更しなければならないことになります (計算してみると、年間 690 ～ 1,380 個のパスワードを作成することになります)。
このアドバイスを書いた一部のサイトの技術担当者は毎日 4 つのパスワードを思いつき、115 の現行パスワードを短期記憶に留めておくことができるのかもしれませんが、一般的な大半のインターネット利用者には、そんなことはできないでしょう。
すべてのアカウントで異なるパスワードを使用するというアドバイスは、建前としては正しいし理にかなっています。すべてのパスワードを 30 ～ 60 日ごとに変更するというアドバイスについても同じことが言えます。しかし、このアドバイスは実行不可能なのです。今日のユーザーが使用するパスワードの数の多さを考えると、このアドバイスに従うのは、紙に控えるとかソフトウェアに記憶させるなど、何らかの補助手段を使用しないと無理です。次のような例もあります。

実行不可能かつ間違ったアドバイス
図 2 に示したアドバイスは、世界最大規模の銀行の Web サイトに掲載されているものですが、実行不可能なだけでなく間違っています。"Read our password advice (パスワードに関するアドバイス)" という見出しのこのページには、「すべての場所に異なるパスワードを使用せよ」という言い方が繰り返し出てきます。また、パスワードを決して書き留めたりしないように推奨しています。
図 2 実行不可能かつ間違ったアドバイス (画像をクリックすると拡大表示されます)
私は 115 の異なるパスワードを持っていますが、毎日 4 つのパスワードを作成する必要があり、しかもそれらを書き留めることが許されないというのです。私は最初、パスワードをすべて憶えることができないのは、自分が優秀ではないためだと思っていました。しかし、実際には、だれもが同じようにパスワードを憶えるのに苦労していることを知りました。人間には 115 ものパスワードを憶えることなどできません。人間が憶えて処理できる情報の塊は 7 つまでに制限されます。人間の脳はそのように作られているのです。インターネット上に存在するパスワードに関するほとんどのアドバイスに従うとなると、人間の処理能力ではパスワードを 1 つ作成するのにも足りません (George A. Miller が書いた「The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information (魔法の数 7±2: 我々の情報処理能力のいくつかの限界)」(musanim.com/miller1956) を参照)。
残念ながら、パスワードのアドバイスに関しては、IT 業界は、何度となくユーザーを誤った方向に導いています。われわれセキュリティ専門家がすべての場所で異なるパスワードを使用すべきだとユーザーに忠告するなら、その方法について、つまり、パスワードをどこか安全な場所に記録し格納するという点についても教える必要があります。紙に書き留める方法、セキュリティ保護されたドキュメントを使用する方法、または PasswordSafe (sourceforge.net/projects/passwordsafe) などの特殊なツールを使用する方法があります。パスワードをすべて記憶するか、どこでも同じパスワードを使用するかのどちらかしか選択肢はないのだ、という事実を認識する必要があります。実際、最近行われた調査によると、ユーザーの 88% が認証を必要とするすべてのシステムで同じパスワードを使用しているといいます (msnbc.msn.com/id/24162478 を参照)。
パスワードを書き留めてはならないというアドバイスが、このような結果を招く一因となっていることは間違いありません。セキュリティ専門家たちは、パスワード (およびその他の機密データ) を一切管理してはならないなどと非現実的な忠告をするのではなく、そうした情報の効果的な管理方法をユーザーに教える必要があります。そうすれば、ユーザーがパスワードなどの資格情報を危険にさらすことも少なくなります。

理解不能なアドバイス
前出の 2 つの図では、言い古されたアドバイスを繰り返しています。こうしたアドバイスは、だれもがオンライン接続し、Web ベースのサービスを使用するようになる前の、1960 ～ 1980 年代には有用でした。こうした古いアドバイスについて声高に異を唱える人はまだだれもいません。こうしたアドバイスは一般に広く受け入れられている知恵だからです。
この種のアドバイスはユーザーを混乱させます。どこかにパスワードを保管しなければならないことにユーザーが罪の意識を感じる可能性もあります。セキュリティ専門家たちは、この種のアドバイスをすることによって、ユーザーが必要なことをきちんと行うように仕向けるのではなく、むしろユーザーに害を及ぼしています。結局のところ、セキュリティを管理する方法を考え出すのはユーザーの責任ではないのです。それは、セキュリティ専門家の責任です。我々は、ユーザーが自分のオンライン アカウントを管理するために行ってもよいと思える方法を考え出す必要があります。しかし、ほとんどのセキュリティガイドでは、一昔前のアドバイスが相も変わらず繰り返されているだけなので、ユーザーはやむなく、付箋紙に書き留めたり、スプレッドシートに保存したりして、多数のパスワードを忘れないようにするという手段をとっています。
認証メカニズムとしてのパスワードにはさまざまな可能性があります。しかし、パスワードが抱える一番の問題は、人間はパスワードを記憶するのが苦手であるという点です。この人間の持つ特性にかかわる問題を解決するため、IT 業界ではパスワードに替わるさまざまな新しいしくみを考え出してきました。その中には、置き換えるどころかパスワードを増やしてしまうものもありました。こうしたしくみのせいで、ユーザーはますます混乱しています。
ある金融サービスのサイトに前回アクセスしたときには本当に驚きました。ログイン画面にユーザー名のテキスト ボックスしか表示されていなかったためです (図 3)。
図 3 パスワードの入力場所は?
最初は、偽サイトに接続したのかと思いました。それですぐにサイトを検証してみたところ (そのサイトは証明書を提示していたので検証は簡単でした)、確かに本物のサイトであることがわかりました。問題は、利用者の側が、サイトにログインするとき、ユーザー名とパスワードの 2 つのテキスト フィールドが表示されることに慣れきっている点にあります。何年も同じ手順でログインしてきた結果です。そのため、ユーザー名だけをたずねるサイトに出くわすと、驚いて手を止めてしまうのです。このケースでは、フィッシング攻撃を防ぐため、写真を使ってユーザーがサイトを認証する技術をプロバイダが提供していたことがわかりました。ユーザー名を入力すると、識別可能な写真が画面に表示されます (図 4 を参照)。
図 4 ユーザーによるサイトの認証に画像を使ったサイト (画像をクリックすると拡大表示されます)
この方法のポイントは、どの画像がどのサイトと対になっているかをユーザーが知っているところです。正しい画像が表示されなかったら、そのサイトは偽サイトであるとわかります。それ自体は、理にかなった考え方です。どの画像がどのサイトと対になっているかをユーザーが知っているという前提の下では、この手法はある程度有効です。
勘の鋭い方は、図 4 でアドレス バーが緑色になっていることにお気付きのことと思います。これは、このサイトが SSL と Extended Validation (EV) 証明書を使用していることを意味します。アドレス バーが緑色になっているのはそのためです。これは同時に、サイトの認証に画像を使用するという前提自体が、フィッシング対策として新たな価値をもたらすものではないことを意味します。このような画像は、少なくとも一部のエンド ユーザーにとっては、混乱が増すだけです。このサイトは既にユーザーに対する自身の認証を行っています。会社名、Web サイトのアドレス、信頼できる発行者の名前が明記された証明書を提示しているためです。アドレス バーが緑色であるということから、その会社が EV 証明書を導入するために、わざわざ通常の 3 倍もの高い料金を支払っていることもわかります。
そして、当然ながら、写真が偽物である可能性もあります。ユーザーが自分の写真を送信できるなら、使用されている画像を攻撃者が推測する方法が存在します。ユーザーがすべてのサイトで同じ画像を使用する可能性も大いにあります。その場合、攻撃者はユーザーにとって、(たとえば皆さんも容易に思いつくような) 価値のあるコンテンツを提供するサイトを開設し、そのサイトの認証に使用する画像をユーザーにたずねればよいだけです。ユーザーがすべてのサイトで同じ画像を使用していれば、この偽サイトは、ユーザーが取引銀行で使用している画像を手に入れることができます。
使用する画像を選択できるサイトもあれば、画像ライブラリを使用しているサイトもあります。たとえば、図 4 のサイトでは、318 枚の写真から選択できます。ユーザーが自分の選択した画像をアップロードできないサイトでは、上記の攻撃方法は使えません。しかし、ユーザーが自分で画像を選択できないとなると、あまり頻繁にアクセスしないサイトでどの画像を選択したかユーザー自身が忘れる可能性もあります。正直なところ、私は図 4 に示したサイトで自分が選択した写真を憶えていません (図 4 の画面に表示されている写真ではないことは確かですが)。
こうした画像を用いたアプローチの問題点は、攻撃者がたとえば 318 枚のうち任意の 1 枚を表示したり、Flickr などの写真共有サイトからランダムに選択して提示すれば、多くのユーザーが提示された画像を自分の選択した画像だと思いこむことです。大半の人が画像とサイトの組み合わせを憶えておくことができるなら、フィッシングやセキュリティ関連のさまざまな問題は起こっていないはずです。
サイトが証明書によって既に認証されているのに、ユーザーにサイトが本物であることを証明するためになぜわざわざ写真を使用するのでしょうか。証明書を使用してサイトを検証する方法をユーザーに教えれば済むことなのに、なぜそうしないのでしょうか。サイトが本物であることは証明書によって既にユーザーに証明されているのです。
もちろん証明書を取得するプロセスは、ユーザーのサイト認証用画像を取得するプロセスよりもはるかに安全です。EV 証明書を使用しているサイトに Internet Explorer® 7 または Firefox 3 でアクセスすると、ブラウザのアドレス バーに該当する証明書情報が強調表示されます。ただし、残念ながら、強調表示されるのは料金の高い EV 証明書だけです。

画像を用いたサイト認証の落とし穴
画像による認証技術には多くの問題があります。まず、サイトからユーザー名を簡単に入手できることです。実際、図 4 に示したサイトで、間違ったユーザー名を入力すると、図 5 のようなダイアログが表示されます。ここで秘密の画像を既に選択しているユーザーの正しいユーザー名を入力すると、そのユーザーの秘密の画像を見ることができるのです。秘密の画像は、ユーザーに関する情報を入手しようとしている攻撃者にとってきわめて価値の高い情報です。
図 5 画像による認証を行うサイトでは、ユーザー名を簡単に入手できる
ここで紹介したタイプの実装には、事実上、セキュリティ上の価値はありません。攻撃者は、偽のサイトでログオンの手順を簡単に再現できてしまいます。偽のサイトはユーザー名をたずねた後、本物のサイトに制御を渡すだけです。クライアント上で AJAX を使用してフォームをリアルタイムに更新することで、外観をよく見せることもできます。さらには、本物のサイトがログオン フォームに対するクロスサイト リクエスト偽造攻撃の対策をしていなかったり、ブラウザがクロスサイト XML-HTTP リクエストの安全対策をしていなかったりする場合は、AJAX のコードで本物のサイトに直接リクエストを送信することも可能です。
本物のサイトから結果が返されたら、攻撃者はそのデータを解析し、写真を抜き出して、エンド ユーザーに表示できます。言い換えると、偽のログイン サイトをユーザーに提示できる攻撃者はだれでも、ユーザーの秘密の画像を表示できることになります。要するに、画像によるサイト認証にはまったく意味がないということです。ユーザーがサイトから認証される前に画像が表示されるため、攻撃者は正規ユーザーのユーザー名を取得できた場合は秘密の画像を手に入れることができます。
ユーザーがフォームを送信する前に証明書を確認するように教えられていないとすると (画像によるサイト認証自体がこれと同じ前提に基づいていることを考えると、このように想定しておくのが安全でしょう)、ユーザーからユーザー名を取得するのは簡単です。また、画像を用いたサイト認証方式では、ほとんどの場合、正式なユーザー名を入力したときと無効なユーザー名を入力したときの反応が異なるため、ユーザーから直接入手できなくてもそうしたサイトから正式なユーザー名を容易に入手できます。攻撃者は、実際の攻撃を開始する前に、アウトオブバンド (コンピュータを使わないソーシャル エンジニアリング的な行為) でユーザー名を入手することも可能です。
結局、ユーザーは、自分は安全だと信じるか、ただ混乱させられるだけです。我々は画像を用いたサイト認証の実装に多額の投資をしてきましたが、悪意のあるユーザーがエンド ユーザーを騙して偽のサイトに資格情報を送信させる行為を防ぐことはまったくできていません。
今回のセキュリティ ウォッチはここまでです。次回は、ユーザーを間違った方向に導くセキュリティ上の習慣や質の悪い認証の実装について、さらに具体例を挙げながら解説する予定です。

Jesper M. Johansson は、セキュリティ ソフトウェアの開発に取り組むソフトウェア アーキテクトで、TechNet Magazine の編集にも携わっています。MIS の博士号を持ち、コンピュータ セキュリティの分野で 20 年以上の経験があります。また、エンタープライズ セキュリティの分野で Microsoft MVP を受賞しています。最新の著書には、『Windows Server 2008 Security Resource Kit』があります。


フィールド ノート 正確性の高い投票を実現する
Josh Benaloh

今年は米国大統領選挙が実施されることもあり、選挙に関する技術に世間の注目が集まっています。私たちがどの人物に投票するか悩む一方で、使用する技術についても検討が重ねられています。手作業で票を数える作業は面倒であると同時に数え間違いが起こる可能性があり、レバー機械は知識のある内部関係者しか操作できません。パンチ式投票用紙は、今では有名になりましたが、完全にパンチされず、穴にくずが残る可能性があり、光学スキャン用投票用紙を使用しても、調整精度の低いスキャナによって誤った結果が読み取られる場合があります。タッチ パネル システムは、いい加減な操作や悪質なソフトウェアによって被害を受ける可能性があり、さまざまな手法を組み合わせた技術も、多くの場合、解決できない問題に直面します。
実は、今挙げた例は、これらのシステムの脆弱性のほんの一部にすぎません。さらに、世界中でよく使用されている手法を採用した場合でも、選挙結果の正確性を保証するには、選挙管理者の公正さと高度な技術が必要です。
ただし、上記で紹介したものよりも優れた方法があり、この方法を使用すると、管理者や機器に依存することなく、選挙結果の正確性を保証できます。関係者、各投票者、および選挙に関与している監視者は、実施された選挙の結果が正確であるかどうかを、徹底的に検証できます。
これを理解するために、次のような状況を考えてみましょう。投票者には特定のコードが提供され、投票者はこれを使用して、公開されている Web サイト上で、名前の横に各自の投票データを登録できます。投票者は、各自の投票データが正確に記録されているかどうかをこの Web サイト上で確認できます。また、だれもが第三者として監査を行い、すべての投票者が正当な投票資格を保有しているかどうか、および投票データの数が実際に公表された集計結果と一致しているかどうかを確認できます。
ですが、少し考えてみてください。この "完全に公開された" 選挙にはプライバシーが欠けています。そうです、この問題に対処するには暗号化を使用します。これによって、完全に検証可能で、投票データの機密性も保護される選挙を実施できます。登録された投票データはそのまま格納されるのではなく、公開キーを使用して暗号化され、その暗号化キーは選挙の関係者間で共有されます。このため、複数の関係者が協力しなければ、暗号化は解除できません。選挙が終了したら、選挙の関係者は協力して、選挙の集計結果と、投票者によって登録された暗号化済みの投票データの数と集計結果が正確に一致することを示す暗号化証明書を作成します。
各投票者は、登録した暗号化済みの投票データに各自の意志が反映されているかどうかを確認できます。また、だれもが暗号化証明書を調べて、暗号化された投票データが正確に集計されたかどうかを確認できます。このようにして、集計結果を隅々まで検証できます。
本当にここまで簡単なのかと言えば、そんなことはありません。ここでは事実に即した大まかなしくみを紹介しましたが、このような投票を実現するには、多くの細かい部分に注意深く対処する必要があります。たとえば、選挙に使用する特定の機器によって、投票者のプライバシーが保護されるかどうかを確認するには、今までのような方法を使用する必要があります。また、投票者はどのようにして、暗号化される投票データに各自の意志を反映すればよいでしょうか。投票者は、各自の投票内容を第三者に示すことなく、名前の隣に登録される、暗号化された不可解な値から、その投票が各自の意志によるものであることを保証できる必要があります (強制や票の買収を回避するため)。また、これらは、今までの投票システムよりも複雑な作業を投票者に要求することなく行われなければなりません。
隅々まで検証可能な選挙過程に関する研究が、暗号化の分野で 25 年以上にわたって行われており、現在では、集計結果の正確性を示す暗号化証明書を提供する、確かで実用的な方法が発表されています。研究団体で最近注目を集めているのは、投票者に提供されるフロントエンドであり、この分野でも大きな進歩が見られています。
選挙に関するテクノロジの需要はかなりありますが、膨大というほどではありません。さまざまな分野の事業を展開する巨大な複合企業は、この市場では疑いの目で見られるでしょう。なぜなら、それらの企業は、特定の選挙結果から一部の利益を得ようとするからです。したがって、この需要を満たすのは、企業全体で正確性の高い選挙の実現に取り組む、すき間市場の小規模な企業かもしれません。隅々まで検証可能な選挙方法の詳細と、その関連情報については、research.microsoft.com/crypto/voting を参照してください。

Josh Benaloh は、Microsoft Research の上級暗号技術者です。彼は 8 年間、国際暗号学会の理事を務めました。また、1987 年の博士論文『Verifiable Secret-Ballot Elections』をはじめとして、さまざまな著作物を発表しています。


Windows 秘話 歴史が空き領域を埋める
Raymond Chen

Microsoft Bob のことを覚えていますか。この製品は、Windows® 3.1 で使いやすいユーザー インターフェイスを提供することを目的としていましたが、非常に評判の悪い失敗作となりました (『PC World』で、史上最悪の技術製品の 1 つに選ばれるという不名誉を被りました)。Bob は、生産中止になった後、繰り返しジョークの種にされ、名前が出ただけで笑いが漏れるような製品に成り果てました。
ちなみに、Microsoft® Bob の社内でのコード ネームは "Utopia" (理想郷) でした。確かに大げさですが、少なくとも勢いと活力に満ちた名前ではあります。マーケティング部門のスタッフが製品名を Bob に決めたことを知ったとき、私たちは皆、信じられないといった思いで首を振りました。
ですが、Bob は皆さんが知っている以上の業績を残しています。実際、生産中止になってからの方が役に立ちました。
ソフトウェアを CD-ROM で配布する場合、気にしなければならないことの 1 つは、実際に製品が 1 枚の CD-ROM に収まるようにすることです。さいわい、変換、サポート ツール、および Windows XP の CD-ROM に収録する必要があるその他のデータに必要なディスク領域を考慮に入れても、まだ約 30 MB の空き領域が残っていました。このようなことを気にする人たちは、「CD-ROM の空き領域の分も代金を払っているのだから、その空き領域も使った方がいい」と考えました。
Microsoft Bob の社内でのコード ネームは "Utopia" (理想郷) でした。確かに大げさですが、少なくとも勢いと活力に満ちた名前ではあります (画像をクリックすると拡大表示されます)
その結果、Windows の違法コピーを作成しようとする人たちの動きを鈍らせるためのかすかな試みが行われました。CD-ROM のこの空き領域をダミー データで埋め、Windows セットアップ プログラムで、このダミー データが存在するかどうかを検証するようにしたのです。これにより、CD イメージのコピーをダウンロードする人たちは、約 30 MB の追加データもダウンロードすることになるという理屈です。これは、"ブロードバンド" という言葉がまだ定着しておらず、一般ユーザーはダイヤルアップ接続を使用していたころの話であることを忘れないでください。56 Kb モデム経由で 30 MB の追加データを転送しなければならないことは、ユーザーの動きを鈍らせるちょっとした障害でした。ですが、現在の標準的な通信速度を考えると、もうこの程度ではユーザーの動きをたいして鈍らせることはできないでしょう。
この確認動作を実装するよう依頼された担当者は、ダミー データのソースを用意する必要がありました。彼は単に CryptGenRandom 関数を呼び出して 30 MB の暗号化されたランダムなバイトを生成することもできましたが、それではおもしろみがありません。彼はアーカイブを丹念に調べて Microsoft Bob のコピーを見つけました。そして、すべてのフロッピー ディスク イメージを、サイズの大きな 1 つのファイルにまとめました。Microsoft Bob のフロッピー ディスク イメージのコンテンツは、特にランダムなバイトから構成されていたわけではないので、彼は暗号化によってデータをごちゃ混ぜにすることにしました。暗号化キーを入力するとき、彼はでたらめにキーボードをたたきました。こうして、Microsoft Bob の暗号化されたコピーができあがりました。未使用の領域を埋めるためのデータとして Windows XP の CD-ROM に格納されているのは、このコピーです。
結局、Windows XP は、今までに開発された中で最も効果的な Microsoft Bob の展開ツールとなりました。もしも、皆さんが押し入れのずっと奥の方から Windows XP を探し出してきて、なんらかの方法でしかるべき魂と交信し、ダミー データを格納した担当者とまったく同じ順序でキーボードをたたくことができたら、暗号化プログラムの中から、Microsoft Bob のコピーが姿を現します。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍で、Windows の歴史と Win32 プログラミングについて扱っています。関心があるのは、自分が生きているうちに核融合が可能になるかどうかということです。