Microsoft における Office Live Communications Server 2005 の導入
Microsoft IT は信頼性の高いエンタープライズ規模のリアルタイム プレゼンス/インスタント メッセージング インフラストラクチャをどのように導入および運用しているか
トピック
 | エグゼクティブ サマリ |
| はじめに |
| 状況 |
| Live Communications Server 2005 の概要 |
| ソリューション |
| 結論 |
| 詳細情報 |
| 付録 A – Windows Messenger 5.1 クライアントのブランディング |
エグゼクティブ サマリ
インスタント メッセージング (IM)、オーディオ/ビデオ会議、データ コラボレーション、ホワイトボード共有、リモート アシスタンスなどのリアルタイム プレゼンス/通信手段は、社員間のコミュニケーションを強化し、社員の生産性を向上するうえでの鍵となるサービスとして、ますます注目を集めています。現在、マイクロソフト社内でも社員の機動性が今まで考えられなかったほど向上しています。自らの生産性を上げるために、社員各人が同僚と顔を合わせずにオフィス外 (自宅を含む) で仕事をしたり、面識のない相手とコラボレーション (共同作業) を行う頻度が高くなってきています。Microsoft® Office Live Communications Server 2005 が実現するリアルタイムの通信とプレゼンスは、セキュリティと管理性を損なうことなく、インフォメーション ワーカーの生産性を高めます。
マイクロソフトは以前、基本的なプレゼンス情報とインスタント メッセージングに対する社内ニーズを満たすために、Microsoft Exchange 2000 Server インスタント メッセージング サービスを導入しました。
2003 年春、Microsoft Information Technology (Microsoft IT) は Live Communications Server 2003 を導入し、それまで使用していた Exchange 2000 Server インスタント メッセージング サービスをこれに置き換えました。Live Communications Server 2003 は、Microsoft Office System アプリケーションにプレゼンスをより緊密に統合でき、業界標準の Session Initiation Protocol (SIP) に基づいた設計になっていることから、Exchange 2000 Server のインスタント メッセージング サービスの後継として最適でした。
2004 年夏、マイクロソフトは世界規模のエンタープライズ環境における製品テストのために、Live Communications Server 2005 の初期リリースの導入を開始しました。マイクロソフトでインスタント メッセージングが有効化されているアカウントは 80,000 人分にも及びますが、導入が完了した時点で 5 台のフロントエンド サーバーと 1 台の 2 ノード データベース クラスタが、これらのアカウントをサポートすることになります。
このホワイト ペーパーでは、Live Communications Server 2005 Enterprise Edition に基づくリアルタイム ユーザー間通信ソリューションのプランニング、導入、運用を通じて、Microsoft IT Communications Operations チームが経験してきた事項に焦点を合わせています。
このホワイト ペーパーは特に、リアルタイム プレゼンス/インスタント メッセージング インフラストラクチャのアップグレード (または初期導入) を検討している業務上の意思決定者、技術上の意思決定者、IT 設計者、および開発管理者を対象としています。
はじめに
マイクロソフトが自社の製品と技術を社内で導入するうえでとった方法や培ってきたノウハウを知りたいというお客様からの問合せが Microsoft IT に頻繁に寄せられています。マイクロソフトは 1999 年に、基本的なプレゼンス情報とインスタント メッセージングに対する社内ニーズを満たすために、Microsoft Exchange 2000 Server インスタント メッセージング サービスを導入しました。2003 年春に、Microsoft IT は Live Communications Server 2003 を導入し、マイクロソフト社員が従来よりも効率的に他の社員を見つけて、互いにコミュニケーションできるようになりました。
Microsoft IT は、グローバルな IT サービスを社内で運用している他、顧客へのリリース前の企業向け自社製品について実稼働環境でのテストを行っており、他の大手企業のビジネス ニーズに対応するだけのスケーラビリティを保証しています。Microsoft IT は 2004 年に、この活動の一環として、Live Communications Server 製品開発グループとの連携により、Live Communications Server 2005 を導入しました。Microsoft IT は、リアルタイム通信について以下の 6 つのビジネス ニーズを見据えています。
| • | 導入にあたり高可用性を確保できること。 |
| • | レポート機能を向上すること。 |
| • | Microsoft SQL Server 2000 Data Engine (MSDE) に加え Microsoft SQL Server 2000 をサポートすること。 |
| • | 複数のフォレストを管理できること。 |
| • | 仮想プライベート ネットワーク (VPN) 接続なしでのインターネット アクセスが可能であること。 |
| • | 外部組織とリアルタイム通信サービスのフェデレーションを行うことができること。 |
Microsoft IT と Live Communications Server 製品グループは、マイクロソフトに展開された既存の Live Communications Server 2003 と新しい Live Communications Server 2005 の機能を照らし合わせて、この製品の最終版のリリース前に、新しいリアルタイム ユーザー間通信ソリューションを実稼動環境に導入する戦略を立てました。
2004 年の第 1 四半期に導入のプランニングを開始し、2004 年の春にコンセプト実証テストを完了しました。2004 年の秋に実稼動環境への導入を完了しました。
組織ごとに独自性があるため、各 IT 組織が Live Communication Server 2005 の導入についてプランニングを行う必要がありました。マイクロソフトの導入計画に含まれていたタスクには、他の組織が経験したことがないタスクや、導入中に別々の時点で完了する必要のあるタスクも含まれていました。たとえば、Microsoft IT は、Live Communications Server 2005 の導入と並行して、IPSec (インターネット プロトコル セキュリティ) に基づくネットワーク ドメインの隔離と Windows® XP Professional Service Pack 2 (SP2) の導入も進めていました。そのため、Live Communications Server 2005 への全体的な移行タイミングに影響が出ました。
このホワイト ペーパーは Live Communications Server 2005 の導入手順を示すガイドではありませんが、顧客がこの製品を自社の環境に導入するときの参考になるように、マイクロソフトはこのホワイト ペーパーを提供しています。Live Communications Server 2005 の詳細については、http://www.microsoft.com/japan/office/livecomm/prodinfo/ を参照してください。
メモ セキュリティ上の理由から、フォレストやドメインなどの内部リソースにはマイクロソフト社内で実際に使用している名前とは異なる説明上の名前を使用しています。
状況
マイクロソフトは 2003 年、セキュリティに優れた標準準拠のリアルタイム プレゼンス/インスタント メッセージング ソリューションを社員向けに提供するために、Live Communications Server 2003 を導入しました。図 1 は、Microsoft IT が導入した Live Communications Server 2003 の構成を示しています。
図 1. 以前の Live Communications Server 2003 の物理アーキテクチャ
各フォレスト内のユーザーをホストするには各フォレストに 1 つまたは複数のホーム サーバーが必要となり、そのことを主な理由として、9 台の Live Communications Server 2003 Standard Edition ホーム サーバーが必要となりました。Live Communications Server 2003 Standard Edition は、マイクロソフトのような大規模組織における高可用性要件を満たせるようには設計されていませんでした。また、マイクロソフト社員が VPN 接続を確立しなくてもホーム サーバーにアクセスできるように、外部インターネット アクセスを構成してサポートするのは困難でした。さらに、Live Communications Server 2003 は、選択した組織および顧客とマイクロソフトとの間で、リアルタイム プレゼンス/通信サービスのフェデレーションを実現することはできませんでした。
メモ Live Communications Server 2003 では、リアルタイム通信サービスをホストするサーバーをホーム サーバーと呼んでいました。Live Communications Server 2005 Standard Edition も同様の設計に基づいており、MSDE を使用してユーザー データを各ローカル サーバーに保存します。
Live Communications Server 2005 Enterprise Edition では、サーバー プールの概念に基づいた高スケーラビリティかつ高可用性の導入モデルが採用されています。Live Communications Server 2005 Enterprise Edition はサーバー プールごとに複数のフロントエンド サーバーをサポートしており、クラスタ化したバックエンド SQL Server 2000 データベース サーバーを使用できます。大規模なエンタープライズ環境への導入にあたっては、Standard Edition サーバーと Enterprise Edition サーバー プールを混在させることが可能です。
Microsoft Office Live Communications Server のシステム コンポーネント
セキュリティが強化されたリアルタイム ユーザー間通信ソリューションを導入するには、少なくとも以下の 3 つのコンポーネントが必要です。
| • | リアルタイム通信に対応したクライアント アプリケーション |
| • | リアルタイム通信サーバー |
| • | オペレーティング システムおよびネットワーク インフラストラクチャ |
Windows Messenger
Microsoft IT は 2003 年 3 月に、Windows Messenger 5.0 の導入を開始しました。このリアルタイム通信クライアント アプリケーションは、以下の 3 つのプロトコル スタックと互換性があります。
| • | SIP (Session Initiation Protocol) - Live Communications Server のサポートに使用します。 |
| • | RVP (Rendezvous Protocol) - Microsoft Exchange 2000 Server のインスタント メッセージング サービスとの下位互換性を確保するために使用します。 |
| • | MSNP (Mobile Status Notification Protocol) - .NET Messenger Server のパブリック インスタント メッセージング サービスでサポートされており、MSN Messenger コンシューマ インスタント メッセージング クライアントによって使用されます。 |
トリプル プロトコル スタック ("triple-stack") を採用した Windows Messenger を導入したことにより、マイクロソフト社員は Microsoft Exchange 2000 Server インスタント メッセージング サービスから Live Communications Server への移行をより円滑に進めることが可能になりました。Windows Messenger の最新バージョンは 5.1 です (2004 年 10 月現在)。
Windows Messenger では、ユーザー インターフェイスの主要な要素をログオン先の Live Communications Server 名前空間に基づいてカスタマイズすることができます。Microsoft IT が行ったカスタマイズの詳細については、「付録 A - Windows Messenger 5.1 クライアントのブランディング」の一覧を参照してください。
Microsoft Office Live Communications Server 2003
Live Communications Server では、ユーザー認証、デバイス登録、プレゼンス、招待、暗号化インスタント メッセージングの各サービスをユーザー間で使用できます。認証を完了した Windows Messenger ユーザーは、インスタント メッセージング、ファイル転送、ホワイトボード、音声とビデオを使用して他のユーザーと対話したり、マルチパーティ IM 機能を使って複数のユーザーと対話したりすることができます。
図 1 は、Microsoft IT がオリジナルの Live Communications Server 2003 環境を導入するにあたって使用した物理アーキテクチャを示しています。ワシントン州レッドモンドのデータ センターに 9 台のホーム サーバーを配置していました。そのうちの 6 台はプライマリ フォレスト内の社内ドメイン ユーザーからのニーズの処理に使用し、残り 3 台は 3 つの製品グループの開発/テスト ドメインに使用していました。
レッドモンド データ センターでは、さらに、社内ユーザーを割り当て先のホーム サーバーにルーティングするために、2 つの Live Communications Server 2003 フロントエンド サーバーを導入していました。
この Live Communications Server 2003 構成で、約 80,000 人分のユーザー アカウントをサポートしていました。
Live Communications Server 2005 Enterprise Edition
Live Communications Server 2005 Enterprise Edition は、100,000 人超のユーザーをサポートする大規模な導入に対応できるように設計されています。負荷分散された Windows Server 2003 フロントエンド サーバー プールと、クラスタ化により高可用性を実現できる SQL Server 2000 SP3a バックエンド データベース サーバーがサポートされているので、高可用性と高スケーラビリティを達成できます。
Live Communications Server 2005 は、以下の Windows Server 2003 サービスに依存します。
| • | TLS (Transport Layer Security) - クライアント/サーバー通信の暗号化に使用されます。 |
| • | MTLS (Mutual Transport Layer Security) - サーバー間通信の暗号化に使用されます。 |
| • | Active Directory® ディレクトリ サービス - ユーザー認証 (Kerberos 認証および NTLM 認証を含む) に使用されます。 |
| • | ディレクトリのフォレスト/ドメイン管理 |
| • | Live Communications Server 管理コンソール (および Microsoft 管理コンソール) |
| • | ドメイン ネーム サービス (DNS) による SRV (サービス) レコードのサポート - Windows Messenger 5.1 (または 5.0) と Live Communications Server 2005 との間の接続が自動的に構成されます。 |
ネットワークおよび Active Directory の構造
Microsoft IT がマイクロソフト社内に導入した Active Directory では、Microsoft IT が管理する社内ドメインに含まれているユーザー アカウント、グループ、およびリソースが 1 つのプライマリ フォレストに格納されます。
このプライマリ社内フォレストに属するドメインは、製品開発およびテストに使用されるセカンダリ フォレスト内の子ドメインとの間に、複数の外部信頼関係を結びます。これらの子ドメインとセカンダリ フォレストは、たとえば、実稼働環境内で Active Directory および Exchange Server のアップデート バージョンを開発およびテストする目的などに使用されます。
Microsoft Windows 2000 Active Directory サービスとの下位互換性をテストするためのフォレストを除き、すべてのフォレストが Windows Server 2003 ベースのフォレストです。下位互換性に関するこの要件を満たすために、このフォレスト内のドメインとプライマリ社内フォレスト内のドメインとの間の信頼関係は、ドメイン別に構成する必要があります。プライマリ社内フォレストとその他の Windows Server 2003 セカンダリ フォレストとの間には、Kerberos による推移的な信頼関係が存在します。
複数フォレスト設計により、Microsoft IT は社内フォレスト、開発用フォレスト、およびテスト用フォレスト内のネットワーク ユーザーとリソースを一元管理できるようになりました。ただし各環境は、他のフォレストにおける Active Directory スキーマの変更から隔離されます。
Microsoft IT は、このような混在型フォレスト環境を採用することに加え、中央集中リソース フォレスト内で高可用性構成を使って Live Communications Server 2005 Enterprise Edition を導入することを決定したので、NTLM 認証が使用されるように新しい Live Communications Server 2005 ダイレクタ サービスを構成する必要がありました。
背景
マイクロソフトで Live Communications Server 2005 がどのように導入されたかは、プランニング、設計、および導入の決定を下すに至った背景情報を理解することによって把握しやすくなります。
Microsoft Information Technology
Microsoft IT は、グローバルな運用を推進し、マイクロソフトの組織全体に情報技術サービスを提供しています。また、Microsoft 情報システムをワールドワイドに運用および維持することに関するあらゆる活動を統括しています。活動の対象は技術インフラストラクチャ、社内システム、およびマーケティング情報システムなどです。これらには、実稼動システム、流通システム、およびその他の重要な社内システムが含まれます。さらに、会社としての戦略、プロセス、およびアーキテクチャの設計と統合を統率し、ビジネス業務向上のための世界クラスの利便性と卓越性の達成に取り組んでいます。
Microsoft IT は、サーバー サポート、ユーザー サポート、通信管理、ネットワーク運用、情報セキュリティなどの多様なサービスを提供しています。これらには、世界各国の 300,000 台を超えるコンピュータの接続管理も含まれます。マイクロソフトは世界 400 か所を超える事業所で、およそ 50,000 人の従業員、20,000 人の請負業者、および 20,000 社の請負業者およびベンダを擁しており、Microsoft IT はこれらの人々が常時、企業ネットワークにアクセスできるようにつとめています。
マイクロソフトの本業がソフトウェアの設計であることから、Microsoft IT には他のグローバル プロバイダとは異なるもう 1 つの役割があります。社内の IT 関連業務の他に、Microsoft 技術を初期採用することも Microsoft IT の役割の 1 つになっています。Windows Server 2003、Microsoft Exchange Server 2003、Microsoft SharePoint® 製品とテクノロジなど、Microsoft 製品のテストおよび導入を担当します。このプロセスをマイクロソフトでは "自社のドッグフードを食べる (ドッグ フーディング)" と表現しています。
Live Communications Server 2003 の導入経験
Microsoft IT は Live Communications Server 2005 をどのように導入するかを選定するにあたって、Live Communications Server 2003 の導入および管理で得た経験を大きく活かしました。
Live Communications Server 2003 では、ユーザーが単一のホーム サーバーに静的に割り当てられ、ユーザー プロファイルとプレゼンス情報は各ホーム サーバー上の MSDE データベースに格納されます。ホーム サーバーが使用不能になると、そのサーバーに割り当てられているユーザーは、そのサーバーがオンラインになるまでサービスを使用できませんでした。このことが高可用性サービスの実現を阻んでいました。
また、1 台のサーバーでサポートする最大ユーザー数の推奨値が 10,000 までに制限されていたため、大規模な導入を実現できませんでした。ハードウェア、ソフトウェア、および運用に要する全体的なコストを低減するには、サーバーの数を減らすことが特に重要なポイントとなります。
さらに、Microsoft の企業ファイアウォール内で Microsoft IT が運用しているリアルタイム ユーザー間通信ソリューションへのインターネットからのアクセスを向上してほしいという要望が社員、外部組織、および顧客から寄せられていました。リアルタイム プレゼンスの利用価値を最大限に引き上げるには、社員がインターネットと社内ネットワークのどちらに接続していても、常に簡単に使用できるものにする必要があります。
Live Communications Server 2003 のセットアップ プロセスにも問題があり、Live Communications Server に必要なスキーマ拡張を Active Directory 管理チームが独立して計画および導入するのが困難になっていました。Live Communications Server 2005 セットアップ プログラムでは、この問題を解決するために、Live Communications Server 2005 のスキーマ拡張、インストール、アクティベーションの各タスクをインストーラで制御される個別のステップに分離しています。
マイクロソフトは、複数のフォレストを使用して、製品部門、販売/マーケティング、製品サポートの各チームを個別に管理しています。Live Communications Server 2003 では、複数フォレストのシナリオを実装するために、すべてのフォレストでスキーマを変更すると共に、Microsoft Identity Integration Server 2003 (MIIS) でカスタム ID 同期ソリューションを作成する必要がありました。Microsoft IT による MIIS 導入の詳細については、IT 導入事例ホワイトペーパー『Enabling Cross-Forest Identity Management with Microsoft Identity Integration Server 2003』 (http://www.microsoft.com/technet/itsolutions/msit/deploy/cfimwiis.mspx) (英語) を参照してください。
Live Communications Server 2005 の導入により得られる利点
Microsoft IT では、Live Communications Server 2005 Enterprise Edition を導入することにより、上記の問題に対処できました。スケーラビリティと可用性に優れた新しいリアルタイム通信ソリューションの導入成功に特に寄与したのは、Enterprise Edition に搭載されている以下の機能でした。
高可用性導入シナリオ
Live Communications Server 2003 では、各ユーザーが特定のホーム サーバーに割り当てられていました。このため、いずれかのホーム サーバーが定期メンテナンスやハードウェア/ソフトウェア障害のために使用不能になった場合に、負荷分散やフェールオーバーを行うことはできませんでした。
Live Communications Server 2005 Enterprise Edition には、複数のフロントエンド サーバーを負荷分散とフェールオーバーが可能な単一のサーバー プールに含めるように構成するオプションが追加されています。サーバー プールを使用すると、エンド ユーザー サービスを中断することなく、サーバー別にサーバー ソフトウェアをアップグレードすることもできます。
MSDE に加え SQL Server もサポート
Live Communications Server 2005 Enterprise Edition では、個人の連絡先リストや拒否ユーザー リストを含め、ユーザー プロファイル情報を SQL Server ベースのデータベースで維持します。この製品の 2003 リリースでは、データベース サーバー サポートが MSDE だけに限定されていました。MSDE はスケーラビリティに欠けており、クラスタ化もリモート管理もできず、バックアップと復元が面倒でした。また、MSDE が自動的にインストールされ、SQL Server はデータベース サーバー オプションとしてサポートされていませんでした。
Microsoft IT は、SQL Server と MSDE のどちらを導入するかを選択するオプションが必要だと考えました。Live Communications Server 2005 Enterprise Edition には、このオプションが追加されており、クラスタ化した高可用性データベース サーバーがサポートされるようになりました。
複数フォレストの管理
マイクロソフト社内で実際に経験したように、複数フォレスト環境に Live Communications Server 2003 を導入した場合は、単一の管理者ログオンから複数のフォレストを管理することができず、ユーザーをフォレスト間で移動させるのに困難が伴うなど、さまざまな問題が生じていました。
Live Communications Server の 2005 リリースは大規模導入用に中央集中リソース フォレスト モデルをサポートしているので、前バージョンの Live Communications Server とは異なり、複数のフォレストにまたがった導入と管理を容易に進めることができます。
仮想プライベート ネットワーク (VPN) 接続を使用しないインターネット アクセス
Microsoft IT が Microsoft Exchange Server の導入から学んだ教訓がもう 1 つあります。ユーザーが最初に VPN 接続を確立してログオンしなくても、選択したメッセージング サービスにリモート アクセス可能なようにする必要があることです。
Microsoft Exchange Server 2003 では、この機能を “RPC over HTTP” (HTTP 上のリモート プロシージャ コール) と呼んでいます。Live Communications Server 2005 では、これを “リモート ユーザー” シナリオと呼びます。
VPN サービスの使用頻度が下がれば、ハードウェア、ソフトウェア、および運用に伴うコストが減ります。さらに重要なこととして、VPN を使用せずにリアルタイム プレゼンス情報にアクセスできれば、ユーザーの連絡先リストにある登録者が現在連絡可能かどうかをリアルタイムに確認できるようになります。
プロジェクトの目標
マイクロソフト社員の間では、インスタント メッセージングが積極的に使用されています。Live Communications Server 製品グループは、Live Communications Server のアップデート リリースをワールドワイドな大規模エンタープライズ環境でテストするために、マイクロソフトのこの社内環境をモデルとして使用します。今回の Live Communications Server 導入にあたっては、以下のような観点から目標を設定しました。
| • | 製品の安定性および可用性 - 優先度が最も高い障害が生じずに経過した日数、およびサーバーの実稼働時間と予定稼働時間を尺度とします。 |
| • | 使用率 - 有効なユーザーの数、同時ログオン ユーザーの数、同時アクティブユーザーの数、および導入/アップグレードの完了したサーバーの数を尺度とします。 |
| • | 管理性 - 既製ツールおよび Microsoft Operations Manager (MOM) 2005 サポートによってユーザー情報を移行できるかどうかなどが含まれます。 |
さらに、メトリック追跡用のマトリックスも使用します。このマトリックスには、たとえば、メッセージ数とデータ量でカテゴリ分けしたメッセージの総トラフィック、ヘルプ デスクへの問い合せ件数、製品グループのソフトウェア更新回数などが含まれます。
Microsoft IT が Live Communications Server 2005 をどのように導入したかの詳細については、このホワイト ペーパーの「ソリューション」の節を参照してください。Live Communications Server 2005 の新機能については、次の節「Live Communications Server 2005 の概要」を参照してください。
Live Communications Server 2005 の概要
セキュリティが強化されたリアルタイム通信ソリューションを Microsoft IT がどのように導入したかを理解するには、Live Communications Server 2005 に新たに搭載された導入機能と管理機能について知っておくことが重要です。
既にこれらの機能に関する知識がある場合は、この節を飛ばして、Microsoft IT が Live Communications Server 2005 をどのように導入したかを説明している「ソリューション」の節に進むとよいでしょう。Live Communications Server 2005 の詳細については、Live Communications Server 2005 Web サイト (http://www.microsoft.com/japan/office/livecomm/prodinfo/) を参照してください。
前リリースの Live Communications Server では、以下の 5 つの特性に重点を置いていました。
| • | プレゼンス、IM (インスタント メッセージング)、リアルタイム通信の各機能を使って個人の生産性を向上する。 |
| • | 使い慣れたツールを使ってユーザー、クライアント ソフトウェア、サーバー、およびネットワーク設定を管理する。 |
| • | クライアント側とサーバー側のカスタム ソリューションを開発するための拡張可能なリアルタイム通信プラットフォームを提供する。 |
| • | SIP (Session Initiation Protocol) と SIMPLE (SIP for Instant Messaging および Presence Leveraging Extensions) に基づいた標準ベースの通信プロトコルを搭載する。 |
| • | Microsoft Office System と統合する。 |
上記の特性に重点を置いて設計された Live Communications Server 2005 は、新しい接続機能を提供すると共に、大規模なエンタープライズ導入をサポートする高可用性と高スケーラビリティを実現します。
Live Communications Server 2005 は、ビジネス効率を向上するように設計されており、Microsoft Office System と統合され、セキュリティが強化されたエンタープライズ環境内でインフォメーション ワーカーが同僚のプレゼンスを確認し、同僚とコミュニケーションすることを可能にします。
Live Communications Server 2005 には、Standard Edition と Enterprise Edition の 2 つのエディションがあります。Live Communications Server 2005 Standard Edition は単一サーバー構成用です。MSDE をローカル データベース サーバーとして使用します。一方、Enterprise Edition は複数のフロントエンド サーバーと SQL Server 2000 バックエンド データベース サーバーをサポートしており、高可用性および高スケーラビリティを実現します。さらに、バックエンド データベース サーバーをクラスタ化することにより、データベース サーバーの可用性を高めることも可能です。
可用性とスケーラビリティ
Live Communications Server 2005 Enterprise Edition には、エンタープライズ導入およびスケーラビリティについて以下のオプションが用意されています。
| • | フォールト トレランス用の分散二層アーキテクチャ。 |
| • | クラスタ化または非クラスタ化 SQL Server 2000 バックエンド データベース サーバーに対応。 |
| • | 回復性に優れたクライアント接続 - 最初に接続していたサーバーが定期メンテナンスや予期しない停止などのために使用不能になった場合は、Window Messenger クライアントを別のフロントエンド サーバーに自動的に接続します。 |
| • | サード パーティ製のバックアップ/復元ソフトウェアのサポート。 |
| • | 15,000 人のユーザーをサポートする単一サーバー構成から、100,000 人を超える同時アクティブ ユーザーをサポートするサーバー プールへのスケールアウト |
| • | 帯域幅最適化プロトコルのサポート。 |
| • | ストレージ エリア ネットワーク (SAN) との相互運用性。 |
図 2 は、Live Communications Server 2005 Enterprise Edition による高可用性サーバー プール ソリューションの典型例を示しています。このサーバー プールは、100,000 人超の同時アクティブ ユーザーをサポートできます。Enterprise Edition サーバー プールには、サーバーの主要な役割として、ディレクタ サーバー、フロントエンド サーバー、データベース サーバーの 3 つがあります。さらに、外部インターネット アクセスや組織間でのリアルタイム通信サービスのフェデレーションをサポートする目的で、1 つまたは複数の Live Communications Server 2005 アクセス プロキシ サーバーを境界ネットワーク内に導入することも可能です。
図 2. Live Communications Server 2005 の高可用性サーバー プールの例
ディレクタ サーバー
図 2 に示した高可用性サーバー プールの例では、Windows Messenger イントラネット ユーザーから発生したか、または Windows Messenger リモート ユーザーから Live Communications Server 2005 アクセス プロキシ サーバー経由で発生した SIP メッセージ ストリームを最初にディレクタ サーバーが受信します。ディレクタ サーバーは、イントラネット要求の場合はユーザーをサーバー プールにリダイレクトします。インターネット要求の場合は、インターネット ユーザーがイントラネット内のサーバーに直接接続されていないので、適切なサーバーに SIP メッセージを転送します。Live Communications Server 2005 への移行中には、ディレクタ サーバーを介することにより、ユーザーが各自の Windows Messenger 構成を変更せずに、Live Communications Server 2003 と Live Communications Server 2005 が混在する環境と通信することが可能です。
フロントエンド サーバーとサーバー プール
Live Communications Server 2003 の “ホーム サーバー” に相当するフロントエンド サーバーは、特定のユーザー グループを対象とするすべての通信を処理します。サーバー プールはフロントエンド サーバーのグループであり、単一の仮想 IP アドレス リソースとして扱われます。そのため、ハードウェア ネットワーク ロード バランサが使用されます。ディレクタ サーバーがユーザーをサーバー プールにリダイレクトするときは、ネットワーク ロード バランサの仮想 IP アドレスがリダイレクト先になります。ネットワーク ロード バランサは、ユーザー接続の処理が可能なフロントエンド サーバーを選択します。
Live Communications Server 2005 を段階的に導入したり、組織を拡大したりする場合は、必要に応じてサーバー プールに新しいサーバーを追加することができます。さらに、メンテナンスやハードウェア交換時には、ハードウェア ネットワーク ロード バランサの働きにより、サービス レベルを低下させることなく、選択したフロントエンド サーバーを (通常は 1 台ずつ) 一時的に休止させることができます。定期メンテナンスやサーバー停止時には、サーバー プールに新しいフロントエンド サーバーを追加することにより、フェールオーバーに必要なキャパシティを確保できます。
データベース サーバー
Live Communications Server 2005 Standard Edition では、各ホーム サーバー上で稼動するローカル MSDE データベース サービスをデータベースとして使用します。Live Communications Server 2005 Enterprise Edition の場合、典型的なエンタープライズ構成では、論理的にも物理的にもフロントエンド サーバーから分離された SQL Server 2000 サーバーをデータベース サーバーとして使用します。高可用性シナリオでは、ストレージ エリア ネットワーク (SAN) などの共有ストレージ デバイスに接続された 2 ノードのアクティブ/パッシブ クラスタ SQL Server データベース サーバーをデータベース サーバーとして使用します。図 2 は、後者のシナリオを示しています。
アクセス プロキシ サーバー
Live Communications Server 2005 におけるアクセス プロキシ サーバーの役割は、Live Communications Server 2003 における転送プロキシ サーバーの役割と機能的に似ており、リモート ユーザー用のセキュリティ保護された接続ポイントを提供します。さらに、フェデレーション アクセスが構成されている特定の外部組織からのユーザーも、アクセス プロキシ サーバーに接続します。アクセス プロキシ サーバーを 1 つだけ導入することもできれば、複数のアクセス プロキシ サーバーをネットワーク ロード バランサの後方に配置してスケーラビリティと可用性の高いリモート アクセス ソリューションを実現することもできます。
アクセス プロキシ サーバーでは、着信メッセージのヘッダー (宛先ドメインを含む) が有効かどうかをチェックし、ファイアウォールの外側からのメッセージであることを示すマークを各メッセージに付けます。これらのメッセージは、アクセス プロキシ サーバーからディレクタ サーバーに送信されます。その後、Live Communications Server Standard Edition サーバーまたは Enterprise Edition サーバー プールにメッセージが転送されます。この導入モデルでは、大量のトラフィックをより容易にサポートすることができ、アクセス プロキシ サーバー上で認証が行われます。
アーカイブ エージェント サーバーとアーカイブ データベース サーバー
Microsoft IT は、Live Communications Server 2005 の実稼動環境にアーカイブ エージェント サーバーとアーカイブ データベース サーバーを 1 台ずつ追加しました。アーカイブ データベース サーバーは SAN 環境を使用して、アーカイブ サービスが収集した統計情報を保存します。Microsoft IT はメッセージのコンテンツをアーカイブ対象から除外しました。
Microsoft IT はこのアーカイブ データを使用して Live Communications Server 2005 環境を分析しています。アーカイブ データの長期保存は行われません。アーカイブ インフラストラクチャの導入は、Live Communications Server のテスト活動において重要な位置を占めました。
組織間におけるインターネット アクセスとフェデレーション
多くの企業ユーザーやパブリック インスタント メッセージング サービスのユーザーが同僚、顧客、友人、家族、その他の知り合いとのコミュニケーションに IM を使用しています。Live Communications Server 2005 では、IT 部署が以下の機能を使用して、多岐にわたる IM ニーズを管理できるようになっています。
| • | セキュリティが強化されたリアルタイム プレゼンス/通信のエンタープライズ間におけるフェデレーション |
| • | パブリック インスタント メッセージング サービスへのアクセスの管理 |
| • | リアルタイム通信クリアリング ハウス |
2 つの組織の間でフェデレーションによって確立された信頼関係により、2 つの組織の Live Communications Server 2005 インフラストラクチャ間で、プレゼンスおよびインスタント メッセージを自由に、かつ高いセキュリティで交換することができます。アクセス プロキシ サーバーが境界ネットワーク内で稼動し、着信要求を毎回確認します。Live Communications Server 2005 の導入にサーバー プールを使用しているか、個別のホーム サーバーを使用しているかに応じて、着信要求のリダイレクト先はディレクタ サーバーまたはフロントエンド サーバーになります。
パフォーマンスとキャパシティ プランニング
Microsoft IT によると、Live Communications Server 2003 で MSDE を使用して単一のホーム サーバー上でサポートできるアクティブ ユーザーの最大数は 10,000 人です。Microsoft IT の目標では、Live Communications Server 2005 Enterprise Edition でサポートされている、フロントエンド サーバー プールとクラスタ バックエンド データベースによる導入モデルを使用して、サーバー 1 台あたり 15,000 人のアクティブ ユーザーをサポートする必要がありました。
Live Communications Server 2005 Enterprise Edition を使用した場合、別個の SQL Server バックエンド データベース サーバーと共に単一のサーバーを稼動させることにより、およそ 15,000 〜 20,000 人のアクティブ ユーザーをサポートできると予想されます。さらに、5 台のフロントエンド サーバーと 1 台のクラスタ SQL Server バックエンド データベース サーバーから成るプールを使用すると、100,000 人超の同時アクティブ ユーザーをサポートできます。製品グループが行ったテストでは、Live Communications Server 2005 を使用すると CPU 使用率が大幅に減少する傾向があり、ユーザー ログオンの処理速度が大きく向上することがわかりました。これは、プロトコルの最適化により、サーバーとの間でのラウンド トリップ数が低減されているためです。
さらに、Microsoft Office 2003、Windows SharePoint Services、および SharePoint Portal Server 2003 に組み込まれているリアルタイム通信サービスのサポートも考慮する必要があります。Live Communications Server を導入すると、Microsoft Office System ユーザーが他のエンタープライズ ユーザーのプレゼンス情報を確認したり、Microsoft Outlook や Microsoft Word などの Office アプリケーション内からも、Windows SharePoint Services を通じて作成された Web サイト内からも、インスタント メッセージを送信したりすることができます。これにより、フロントエンド サーバーの負荷が増加します。キャパシティ プランニングにあたっては、この負荷の増加を考慮する必要があります。ただし、このような増加は、Enterprise Edition サーバー 1 台あたりのアクティブ ユーザー数が 15,000 人に上ることが原因です。
ソリューション
セキュリティが強化されたリアルタイム ユーザー間通信ソリューションのプランニングと導入には、6 つの段階がありました。Microsoft IT は、前述したプロジェクト目標に加え、このプロジェクトに以下の 4 つの目標を設定しました。
| • | 中央集中リソース フォレスト導入モデルを使用して Live Communications Server 2005 を導入する。 |
| • | 前バージョンの Live Communications Server と Live Communications Server 2005 Standard Edition サーバーおよび Live Communications Server 2005 Enterprise Edition サーバー プールとの共存および相互運用を保証する。この目標は、マイクロソフトの多くの顧客アップグレード/共存シナリオで重要となるもので、Microsoft IT の Live Communications Server 2003 導入環境をアップグレードするうえで特に必要となる条件です。 |
| • | Live Communications Server を 2003 から 2005 に移行した後もユーザーが各自の連絡先リストと拒否ユーザー リストを維持できるようにする。 |
| • | 既存のサーバー ハードウェアのうち、Live Communications Server 2005 の要件を満たすものは引き続き使用する。 |
Microsoft IT が Live Communications Server 2005 を導入するためにプランニングした 6 つの主要段階を決めるにあたり基準にしたのは、実施する必要のある作業と、各段階の対象となるユーザー グループに対してそれらの作業が与える影響でした。各段階において次の段階に進むための終了基準は、各段階が不備なく完全に実施されるということでした。Microsoft IT がこのプロジェクトの導入フェーズにおいて使用した 6 つの段階を以下に示します。
1. | 準備 - 新しい Live Communications Server 2005 環境の基本コンポーネントを準備しました。具体的には、Live Communications Server 2005 サーバー プールをホストするための中央集中リソース フォレストの導入、2005 用の Active Directory スキーマ拡張の導入、SQL Server データベース サーバー クラスタ (専用 SAN を含む) のインストールと構成、単一の Live Communications Server 2005 Enterprise Edition フロントエンド サーバーのインストールを行いました。2003 と 2005 の相互運用シナリオをテストできるように、Microsoft IT から選択したユーザーに対して、この環境へのアクセスを許可しました。 |
2. | サーバー プールの導入 - Live Communications Server 2003 インフラストラクチャからのユーザー移行を進めながら、サーバーの導入を拡張してサーバー プールに Live Communications Server 2005 Enterprise Edition サーバーを追加しました。この段階で、3 つの小規模な Active Directory フォレストに所属していたユーザーを Live Communications Server 2005 の中央集中リソース フォレストに移行しました。 |
3. | ユーザーの大規模移行 - Live Communications Server 2003 と 2005 の相互運用性をテストおよび確認した後、その他の大規模なフォレストの移行に着手しました。 |
4. | Live Communications Server 2003 のクリーンアップ - 具体的には、残っていた Live Communications Server 2003 環境の削除、パフォーマンス ログ データの監視および収集プロセスの更新、さらに Live Communications Server 2005 環境用のマニュアル (インストール、障害復旧、トラブルシューティング、操作の各ガイド) の更新を行いました。 |
5. | テスト サーバーの導入 - 製品の更新プログラムの継続的導入を実稼働環境でテストするための準備として、Live Communications Server 2005 Standard Edition サーバーを導入しました。Microsoft IT および Live Communications Server 製品グループから選択したユーザーを Enterprise Edition サーバー プールから新しい Standard Edition 実稼動テスト サーバーに移行しました。 |
6. | 外部インターネット アクセス - 社員、特定の外部顧客、および連絡先に対し、VPN を使用せずにリモート アクセスする機能を提供するために、アクセス プロキシ サーバー専用の外部ディレクタ サーバーを導入しました。 |
全体的な戦略としては、Live Communications Server 2005 をインストールおよび構成して前リリースと併用しながら、ユーザー グループを順次新しいプラットフォームに移行するという同時進行方式をとりました。
プランニング
Microsoft IT は、Live Communications Server 2005 の導入中にもインスタント メッセージング サービスを継続的に提供しながら、新しい 2 層式のサーバー プール導入モデルを実装するために、Live Communications Server 2005 の導入後に 2003 ユーザーを移行する必要がありました。2003 サーバーは、不要になった時点で消去し、再構築した後、マイクロソフトのデータ センターの 1 つに再導入することにしました。
Active Directory のプランニング
Live Communications Server では、サーバーとクライアントのセキュリティと管理性を万全なものとするために Active Directory が必要となります。Live Communications Server では、Windows 2000 Service Pack 3 (SP3) または Windows Server 2003 の Active Directory をサポートします。ただし、複数のフォレストがある場合は、フォレスト間の Kerberos 認証を行うために、すべてのフォレストが純粋な Windows Server 2003 フォレストであることが必要となります。
フォレスト内に Windows Server 2003 以外のドメイン コントローラがある場合、Windows Messenger 5.0 クライアントが認証に失敗する可能性があります。この問題を解決するには、Live Communications Server でディレクタ サーバーの認証方式を NTLM に設定します。この場合、クライアントが NTLM によってエンド ユーザーとして認証されると、フロントエンド サーバーがそのクライアントを適切なサーバー プール サーバーに接続します。
Live Communications Server のデータベースでは、ドメイン コントローラへの影響が最小化されています。Live Communications Server がドメイン コントローラと通信するのは、以下の場合だけです。
| • | サーバーの初回起動中に完全な Active Directory 同期化が行われるとき。 |
| • | Active Directory 更新に伴う増分同期化が行われるとき。サーバーの初回起動後、Active Directory は、およそ 5 分に 1 回チェックされます。ドメイン コントローラに対する影響はほとんどありません。 |
| • | リアルタイム通信サービスをユーザーに提供するとき。 |
| • | Live Communications Server サービスへの初回ログオンでクライアントが認証されるとき。 |
Microsoft IT は、Live Communications Server 2005 Enterprise Edition を使用することにより、社内用のリアルタイム通信サービスを社内の中央集中フォレストに高可用性ソリューションとして導入することができました。これは、Microsoft IT が Live Communications Server 2005 の Active Directory スキーマ拡張を社内の中央集中フォレストだけに導入すればよく、製品の開発およびテスト用のセカンダリ フォレストには導入する必要がなかったことを意味します。
ドメイン ネーム サービスのプランニング
Microsoft IT は、Windows Messenger クライアントを手動ではなく自動で構成する方法をとりました。Windows Messenger のインストール時に自動構成をセットアップした後、Live Communications Server の名前空間に対して自動構成がサポートされるようにドメイン ネーム システム (DNS) サービスを構成しました。
組織でクライアントの自動構成を使用するときには、クライアントが DNS のサービス ロケーション (SRV) レコードから Live Communications Server サービスを検索します。DNS SRV レコードでは、Live Communications Server サービスの名前空間が特定のサーバー名および TCP/IP ポート番号にマップされます。
Windows Messenger 5.1 クライアントは起動時に、ユーザーの SIP 通信サーバー アカウントに含まれている名前空間に基づいて、DNS SRV レコード検索を行います。たとえば、contoso.com 名前空間にログインしているユーザーについて、Windows Messenger は以下の方法で Live Communications Server DNS SRV レコードの名前を検索します。
_sip._tls.contoso.com
DNS SRV レコード検索により、Windows Messenger ユーザーが接続するサーバー、サーバー プール、またはディレクタ サーバーの DNS 名と、使用する TCP/IP ポート (一般に、暗号化 TLS 接続の場合はポート 5061、非暗号化 TCP/IP 接続の場合はポート 5060) が返されます。
DNS SRV レコードを使用できない場合、クライアントは従来どおりの DNS 検索を行い、"sip." の後ろにユーザー アカウントの名前空間が続いているサーバー名を探します。上の例では、DNS の "A" レコードは次のような名前になります。
sip.contoso.com
DNS 名とポートの解決が完了すると、Windows Messenger が Live Communications Server 2005 サービスに接続可能になります。
自動構成により、ユーザーと環境のニーズに応じてサーバーを非常に柔軟に管理できると同時に、クライアントの管理と運用に伴うコストを低減できます。
リモート ユーザーおよびフェデレーション アクセスをサポートするように DNS を構成する
Live Communications Server 2005 のアクセス プロキシを経由したフェデレーション アクセスをサポートするには、アクセス プロキシ サーバーの従来どおりの DNS "A" レコードを組織の外部 DNS サーバー内で構成する必要があります。一般に、この DNS レコードの名前は内部名 (sip.contoso.com など) と同じになります。暗号化 TLS (および MTLS) 接続の確立には、既定ポート 5061 が使用されます。
Microsoft IT は、若干異なるアプローチを使って、マイクロソフトの中央集中リソース フォレスト サーバー プールへのリモート ユーザー接続をサポートしました。マイクロソフト社員は、顧客のオフィスやホーム オフィスからモバイル ユーザーとしてアクセスすることが頻繁にあります。このような環境では、Secure HTTP (HTTPS) アクセス用の既定ポートは開放されているものの、ポート 5061 がローカル ファイアウォールによってブロックされていることがよくあります。Microsoft IT は、この問題に対処するために、既定ポート 5061 ではなくポート 443 を使用するように Live Communications Server 2005 アクセス プロキシ サーバーを構成しました。これらのリモート ユーザー接続の暗号化には TLS が使用されます。
証明書サービス
Live Communications Server 2005 で TLS をトランスポート プロトコルとして使用可能にするには、組織で公開キー基盤 (PKI) を有効にする必要があります。サーバーとクライアントの間の TLS 接続を開始するには、証明書を使用します。マイクロソフトは既に、Windows Server 2003 証明書サービスに基づく社内 PKI を導入しているので、Microsoft IT は Microsoft Windows の自動登録機能を使用して、Live Communications Server が稼動しているサーバーの証明書を取得しました。自動登録では、各サーバーがドメインに参加した直後にサーバー自体の証明書をエンタープライズ証明機関 (CA) に要求し、その証明書を自動的に取得することができます。
マイクロソフトのサーバーとクライアントはいずれも Microsoft IT の管理下にあるドメインに参加したときに自動的に登録され、証明書を受け取ります。このため、証明書に関するその他の作業が不要になります。つまり、Live Communications Server では、特殊な証明書を明示的に作成する必要がありません。Live Communications Server で証明書が使用されるのは、以下の条件を満たしている場合です。
| • | クライアントとサーバーの認証が可能な証明書であること。 |
| • | サーバーの完全修飾ドメイン名 (FQDN) が証明書に含まれていること。 |
Live Communications Server のアーキテクチャでは、基盤になっているオペレーティング システムが証明書情報をクライアントおよびサーバー用にキャッシュします。
ネットワーク キャパシティのプランニング
Live Communications Server では、8 時間で各ユーザーにつき 1 秒あたり平均して 1.6 キロビット/秒 (Kbps) のネットワーク帯域幅がプレゼンスおよびインスタント メッセージングのトラフィックに使用されます。Microsoft IT は、以前に行った Live Communications Server 製品グループのテスト結果に基づいて、この値を割り出しました。レドモンド データ センターと世界各国の地方データ センターを結ぶ接続の帯域幅は十分大きいので、ワイド エリア ネットワーク (WAN) リンク間で負荷を処理することができます。そのため、上記の値でも Live Communications Server を搭載したサーバーの導入を一元的に実施できると判断しました。ネットワーク データの圧縮も、リアルタイム通信サービスで使用する帯域幅の節減に有効でした。
Microsoft IT は、中央集中モデルによりユーザーがサーバーにログオンするときの総ログオン時間が増加することも認識していましたが、ログオン時間の増加は 1 秒に満たないものであり、ユーザーが処理速度の低下を感じるようなことはありませんでした。中央集中モデルには、管理の簡略化によるコスト削減という目に見える利点がありました。
セキュリティのプランニング
Microsoft IT は、Live Communications Server サービスのセキュリティを強化するために、高セキュリティ モードに設定した Windows Messenger 5.1 を導入し、TLS 以外のトランスポート モードをすべて無効化しました。
クライアントに上記の設定と高セキュリティ モードを適用した結果、マイクロソフト環境内での動作は以下のようになりました。
| • | サーバーとクライアントとの間で TCP/IP ポートから送信される情報は TLS によって暗号化されます。Live Communications Server での既定の通信プロトコルは非暗号化 TCP です。 メモ サーバー側では、サーバー間で転送される情報を相互 TLS (MTLS) で暗号化する構成をとりました。 |
| • | Live Communications Server は Kerberos 認証または NTLM 認証を必要とします。Kerberos は Live Communications Server の既定の認証方式です。マイクロソフトのテスト チームおよび製品サポート チームが使用していた Windows 2000 コンピュータとの下位互換性を確保するために、Microsoft IT はフロントエンド サーバーの認証方式として NTLM を採用しました。フロントエンド サーバーで Kerberos 認証のみを使用した場合、セキュリティは向上しますが、Windows 2000 フォレスト内のユーザーは認証されません。 |
| • | ネットワーク変換テーブルの UPnP (Universal Plug and Play) は、認証なしの HTTP プロトコルに依存しているため、クライアント上では無効化されています。 |
| • | すべての IM セッションについてピア ツー ピア接続が無効化されています。これにより、オーディオ/ビデオやデータ コラボレーション セッションの招待状を含むすべての通信が強制的に Live Communications Server 経由でルーティングされます。インスタント メッセージをクライアント間で直接転送できるようにする場合、セキュリティ上のリスクが生じます。これは、インスタント メッセージをアーカイブできないので、不正使用の有無を確認できないためです。 |
| • | オーディオ/ビデオ会議およびデータ コラボレーション セッション自体には、最初の招待が受け入れられた後、従来どおりにピア ツー ピア接続が使用されます。 |
高セキュリティ モードには、.NET Messenger Service および Exchange IM への接続無効化などの任意に選択できる機能がありますが、マイクロソフト社員がパブリック インスタント メッセージング ネットワーク上で家族と連絡を取るための代替手段が必要なことも考慮し、クライアント上では .NET Messenger Service を無効化していません。
上記のセキュリティに関する考慮事項に加え、組織でグループ ポリシーを使用すると、オーディオとビデオの暗号化が必須で行われるように構成できます。オーディオとビデオを暗号化すると会議のセットアップに要する時間が長くなるため、Microsoft IT はこの構成を使用しませんでした。この場合、接続のセキュリティよりもユーザーによる使用感を重視すべきと考えました。データは社内ネットワークだけを通過するので、オーディオ/ビデオ通信用の個々のネットワーク パケットをだれかが改ざんする恐れは、ほとんどないと判断しました。
Microsoft IT はネットワーク ドメインの隔離をサポートするために IPSec を導入しており、それに追加する形で上記の構成を採用しました。マイクロソフトのエンタープライズ規模の IPSec 導入の詳細については、Microsoft IT 導入事例ホワイトペーパー「Improving Security with Domain Isolation: Microsoft IT Implements IP Security (IPSec)」 (http://www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx) (英語) を参照してください。
通信プラン
継続中のソフトウェア導入に関するマイクロソフト社員への情報伝達については、すべて Microsoft IT 内の専任クライアント サービス チームが情報発信と取りまとめを行っています。これにより、他の Microsoft IT プロジェクトとの時間調整と連携が図られています。マイクロソフト社員に計画とニーズを伝達しなければならないプロジェクトが他にある場合は、そのプロジェクトと正しく連動するように、一定品質の電子メール メッセージが Microsoft IT から社員に送信されます｡
Live Communications Server 2005 への移行にあたり、社員各自がいつ移行の影響を受けるか、エンド ユーザー サポート ヘルプ ページがどこにあるか、質問や問題がある場合にヘルプデスクに問い合わせるにはどうすればよいかなどの情報を電子メールで社員に通知しました。
Microsoft IT は、サポート対象の製品ごとにエンド ユーザー サポート Web ページを設けています。このページには、Windows Messenger や、Live Communications Server 2005 の導入に伴って適用されるサービスも含まれています。エンド ユーザー サポート Web ページには、よく寄せられる質問 (FAQs) の一覧、自己解決用のトラブルシューティング情報を始め、マイクロソフト社員が Windows Messenger の最新バージョンをダウンロードしてインストールするための社内向けソフトウェア配布サーバーへのリンクが掲載されています。
アーキテクチャ
Live Communication Server 2005 では、中央集中リソース フォレスト導入モデルにより、高可用性サーバー プールを導入することが可能となっています。Microsoft IT は、2005 リリースの鍵となるエンタープライズ向けのこの機能を活用しました。
中央集中リソース フォレスト導入モデル
Active Directory 側から見ると、Live Communications Server 2005 サーバー プールは中央集中リソース フォレスト (マイクロソフト社内フォレスト) 内に導入されていることになります。このフォレスト内に最も多数のユーザー オブジェクトが作成されています。Microsoft IT は、電子メールが有効化されているすべてのユーザー オブジェクトについて Live Communications Server の機能を有効化しました。電子メールが有効化されているユーザー オブジェクトが既に中央集中リソース フォレストに含まれていた場合は、そのユーザー オブジェクトについてリアルタイム通信サービスを有効化しました。
Live Communications Server 2005 では、電子メールが有効化されているユーザー オブジェクトがいずれかのセカンダリ フォレストに含まれていれば、中央集中リソース フォレスト内の Active Directory 連絡先オブジェクトをユーザー プリンシパルとして使用することができます。Microsoft IT は、Microsoft Identity Integration Server 2003 (MIIS) を使用して、中央集中リソース フォレスト内の連絡先オブジェクトとセカンダリ フォレスト内のユーザー オブジェクトの作成と同期化を自動化しました。
Microsoft Metadirectory Services (MMS) の後継サービスである MIIS は、中央集中サービスであり、組織の ID 情報を複数のディレクトリに保存および統合します。MIIS の目的は、ユーザー、アプリケーション、およびネットワーク リソースを識別する既知の情報を統一されたビューで提供することにあります。MIIS は、生産性の向上、セキュリティ リスクの軽減、およびエンタープライズ規模の ID 情報の管理と統合に伴う総所有コストの低減に有効です。
図 3 は、セカンダリ フォレスト/子ドメイン内のユーザー オブジェクトをエクスポートして、対応する連絡先オブジェクトを中央集中リソース フォレスト内に作成するプロセスの流れを示しています。MIIS は、セカンダリ フォレストからユーザー オブジェクト情報を選択し、中央集中リソース フォレスト内に連絡先オブジェクトを作成します。中央集中リソース フォレストから各セカンダリ フォレストへの一方向の信頼関係がまだ存在しない場合は、この信頼関係を作成する必要があります。
図 3. Microsoft IT による Live Communications Server 2005 フォレスト間トポロジ
サーバー プールのアーキテクチャ
図 4 は、Microsoft IT が導入した Live Communications Server 2005 サーバー プールのアーキテクチャを示しています。Live Communications Server 2005 を使用し、中央集中リソース フォレスト内ですべての Microsoft 社員および請負業者をローカル ユーザー オブジェクトまたはインポートした連絡先オブジェクトとして構成するだけで、セキュリティが強化されたリアルタイムのプレゼンス/通信サービスが、ユーザーのホーム ドメインに関係なくすべてのユーザーに提供されます。このように中央集中化された高スケーラビリティ設計により、Live Communications Server サーバーを各セカンダリ フォレストや子ドメインに個別に導入する必要がなくなりました。
図 4. Microsoft IT による Live Communications Server 2005 サーバー プールのアーキテクチャ
図 4 内の Live Communications Server 2005 アプリケーション サーバーがホストするサーバー側コードがホストにより、アプリケーションは、Windows Messenger クライアントではなくアプリケーション エージェント宛ての IM メッセージを傍受して再ルーティングできます。Microsoft IT の開発者は、新しいアプリケーションのテストとサポートに Standard Edition アプリケーション サーバーを使用しています。
組織間におけるリモート ユーザー アクセスとフェデレーション
マイクロソフトのファイアウォールの内側にいる社員がファイアウォールの外側にいる社員や請負業者とコミュニケーションできるようにするために、図 5 に示すような、Live Communications Server 2005 によるリモート ユーザーおよびフェデレーション アクセス アーキテクチャを導入することにしました。
図 5. リモート ユーザーおよびフェデレーション アクセス用の物理アーキテクチャ
この環境では、次の 3 種類の外部通信がサポートされています。
| • | 外部インターネット アクセス。顧客オフィス、その他の事業所、およびホーム オフィスで仕事をしているマイクロソフト社員が従来型のパソコンを使用して行います。 |
| • | 直接フェデレーション。マイクロソフトの特定の顧客および外部組織に導入された Live Communications Server 2005 と、Microsoft IT の Live Communications Server 2005 アクセス プロキシ サーバーとの間で、プレゼンス情報とインスタント メッセージを直接交換できます。Microsoft IT は、この直接フェデレーションをビジネス ニーズに応じて特定の組織との間で構成しています。 |
| • | クリアリング ハウス フェデレーション。インターネット上の Live Communications Server 2005 クリアリング ハウスの導入を通じて実現されます。マイクロソフトは、プレリリース バージョンを使用している組織のためにクリアリング ハウスをパイロット運用しました。最終的には、このクリアリング ハウス フェデレーション モデルに基づいて、サード パーティ プロバイダがインスタント メッセージ/プレゼンス サービスを提供することができます。 |
リモート ユーザー アクセス
マイクロソフト社員によるリモート アクセスは、図 5 に示す Live Communications Server 2005 アクセス プロキシ サーバーへの直接 TLS アクセスによって実現されています。アクセス プロキシ サーバーは、Windows Messenger によって生成されたプレゼンス情報およびインスタント メッセージを外部ディレクタ サーバーに転送します。外部ディレクタ サーバーは、受け取ったメッセージを中央集中リソース フォレスト サーバー プール (図 4) 内の 2 つの内部ディレクタ サーバーに転送します。
直接フェデレーション
直接フェデレーションでは、2 つの異なる組織の Live Communications Server 2005 アクセス プロキシ サーバーが、信頼済み MTLS 接続を通じて、内部に導入された Live Communications Server 2005 に接続するように構成されます。
マイクロソフトは、Live Communications Server 2005 アクセス プロキシ サーバーを各組織で容易に構成できるように、パブリック証明機関 (CA) 発行の証明書を使用して MTLS 接続を構成しました。さらに、Microsoft IT は、アクセス プロキシ サーバーおよび外部ディレクタ サーバーを以下のように構成しました。
| • | Windows Server 2003 サーバーをドメインには追加せずに、"ワークグループ" サーバーとしてインストールすることにより、自動登録から生じる問題を回避しました。 |
| • | セキュリティ上の理由により、アクセス プロキシ サーバーのネットワーク インターフェイス カード上では、ポート 5061 (Live Communications Server が SIP メッセージの交換に使用) とポート 443 だけを TCP/IP ポートとして有効にしました。 |
クリアリング ハウス フェデレーション
複数の組織がそれぞれの Live Communications Server 2005 環境のフェデレーションを行う場合、各組織内のアクセス プロキシ サーバー間の MTLS 接続をペアにして構成すると、セットアップと管理が煩雑になることがあります。複数の組織がリアルタイム プレゼンス情報およびインスタント メッセージを交換する場合は、クリアリング ハウス フェデレーションを Live Communications Server 2005 を導入するうえでの代替戦略として使用すると、構成タスクとメンテナンス タスクが簡単になります。
Live Communications Server 2005 クリアリング ハウスは、外部に導入され、インターネットに直接接続されている Live Communications Server 2005 です。Microsoft でホストしているクリアリング ハウスは、1 つの Live Communications Server 2005 Standard Edition サーバー、1 つのアクセス プロキシ サーバー、および 1 つの Microsoft Internet Security and Acceleration 2004 サーバーから構成されています。
Microsoft IT は、クリアリング ハウス インフラストラクチャを導入した後、クリアリング ハウスから開始した着信接続を Live Communications Server 2005 アクセス プロキシ サーバーが信頼するように構成しました。同様に、クリアリング ハウス側でも、Microsoft IT アクセス プロキシから開始した接続を信頼するように構成しました。その後、特定の外部連絡先と顧客を招待し、相手側のプロキシ サーバーをクリアリング ハウスに接続するように構成しました。マイクロソフトは、クリアリング ハウス アクセス用のプロキシ サーバーを構成するにあたって、各組織から渡されたサーバー証明書を使用して組織ごとの信頼済み接続を作成しました。Microsoft IT が直接フェデレーションを実際に実装した結果、各組織にとって最も簡単なアプローチとなったのは、それぞれ組織のサーバー証明書を同じパブリック CA から取得することでした。これにより、すべての適切なルート証明書が各組織のアクセス プロキシ サーバーに確実にインストールされるようにするための余分な手順を省くことができました。
フェデレーション アクセスの制御
特定の組織またはクリアリング ハウスに対して、Microsoft IT Live Communications Server 2005 アクセス プロキシ サーバーへのアクセスを許可するかどうかの制御は、Microsoft IT がフェデレーション接続を作成するときに設定します。Microsoft IT Live Communications Server 2005 アクセス プロキシ サーバーの直接フェデレーションを有効にするように外部組織を構成すると、その組織の名前空間に含まれている各ユーザーが自分の連絡先リストに Microsoft 社員を追加して、プレゼンス情報とインスタント メッセージをやり取りすることが可能になります。外部連絡先がマイクロソフト社員に連絡するときは、その社員の SIP アドレスを知っている必要があります。マイクロソフト社員の社内ディレクトリを外部連絡先が検索することはできません。
Microsoft IT の Live Communications Server 2005 アクセス プロキシ サーバーのフェデレーション用にクリアリング ハウスを構成する場合も、直接フェデレーションのシナリオの場合と同様に、クリアリング ハウスを使ってフェデレーションを行う組織のフェデレーション可能なユーザーはすべて、マイクロソフト社のフェデレーション可能な社員とやり取りを行うことができます。ただし、Microsoft IT (またはクリアリング ハウスを使ってフェデレーションを行う任意の組織) の Live Communications Server 2005 アクセス プロキシ サーバーは、特定の名前空間 (インターネット ドメイン) からの接続をブロックするように構成することもできます。この構成は、クリアリング ハウスの参加者のうち、特定の参加者からのアクセスをブロックする必要がある場合に特に役立ちます。
導入
ここでは、図 4 に示した Live Communications Server 2005 サーバー プール アーキテクチャを Microsoft IT が導入しつつ、既存の Live Communications Server 2003 を Live Communications Server 2005 に移行するにあたって経験した事項について説明します。
Live Communications Server 2005 導入プロセスに Microsoft IT が含めた主要なステップは、以下のように要約できます。
| • | 中央集中リソース フォレストとして使用するフォレストを選択し、Live Communications Server 2005 セットアップ ウィザードで Active Directory スキーマを拡張する。 |
| • | Live Communications Server 2005 フロントエンド サーバー プールを最初は 1 台のフロントエンド サーバーだけでセットアップし、クラスタ SQL Server バックエンド データベース サーバーおよび SAN をセットアップする。 |
| • | MIIS Live Communications Server の同期化を構成する。 |
| • | ユーザーの Live Communications Server 2003 データをセカンダリ フォレストからエクスポートする。 |
| • | ユーザーのデータを中央集中リソース フォレスト内の連絡先オブジェクトにインポートする。 |
| • | 連絡先のホームを中央集中リソース フォレストに再設定する。 |
| • | セカンダリ フォレスト内の Live Communications Server 2003 ユーザー オブジェクトを無効化する。 |
| • | 既存の Live Communications Server 2003 サーバーを廃止後に再利用する。 |
| • | Active Directory の連絡先オブジェクトおよび Live Communications Server 2003 属性をセカンダリ フォレスト内のユーザー オブジェクトからクリーンアップする。 |
サーバー ハードウェア
Microsoft IT は、Live Communications Server 2005 の必要条件に最もよく一致する、Microsoft IT の標準構成に基づいたサーバー ハードウェア構成を使用しました。
表 1. Microsoft IT が導入したサーバー ハードウェア
| サーバー ロール | 構成 |
アクセス プロキシ サーバー | デュアル Intel Xeon 3.06 GHz、1 MB キャッシュ、533 MHz FSB 2 GB DDR 266 MHz RAM 2 x 18 GB HDD (15,000 RPM SCSI)、2 GB ネットワーク インターフェイス カード (NIC) Windows Server 2003 Service Pack 1* Live Communications Server 2005 (アクセス プロキシ サーバー セットアップ オプション) |
ディレクタ サーバー | デュアル Intel Xeon 3.06 GHz、1 MB キャッシュ、533 MHz FSB 2 GB DDR 266 MHz RAM 6 x 18 GB HDD (15,000 RPM SCSI) 100 MB ネットワーク インターフェイス カード (NIC) Windows Server 2003 Service Pack 1* Live Communications Server 2005 Standard Edition |
プール内のフロントエンド サーバー | デュアル Intel Xeon 3.06 GHz 1 MB キャッシュ、533 MHz FSB 2 GB DDR 266 MHz RAM 4 x 18 GB HDD (15,000 RPM SCSI)、100 MB NIC Windows Server 2003 Service Pack 1* Live Communications Server 2005 Enterprise Edition |
バックエンド データベース サーバー ノード | クワッド Intel Xeon 2.3 GHz 1 MB キャッシュ、533 MHz FSB 5 GB DDR 266 MHz RAM 2 x 34 GB HDD (15,000 RPM SCSI)、1 GB NIC Windows Server 2003 Server Pack 1* SQL Server 2000 Server Pack Service Pack 3a |
アーカイブ データベース サーバー | クワッド Intel Xeon 2.3 GHz 1 MB キャッシュ、533 MHz FSB 5 GB DDR 266 MHz RAM 2 x 34 GB HDD (15,000 RPM SCSI)、1 GB NIC Windows Server 2003 Service Pack 1* SQL Server 2000 Service Pack Service Pack 3a (ストレージ用として SAN に接続) |
アーカイブ エージェント サーバー | デュアル Intel Xeon 3.06 GHz 1 MB キャッシュ、533 MHz FSB 2 GB DDR 266 MHz RAM 2 x 18 GB HDD (15,000 RPM SCSI)、2 GB NIC Windows Server 2003 Service Pack 1* MSMQ (Microsoft Message Queuing) サービス |
*Microsoft IT は、Live Communications Server 2005 の導入中に Windows Server 2003 の Service Pack 1 のベータ テストを実施していました。顧客側で Live Communications Server 2005 を導入する場合には、Windows Server 2003 Service Pack 1 は必須となりません。
中央集中リソース フォレストの Active Directory 同期化
次の表は、Live Communications Server 2005 のディレクトリ属性のうち、セカンダリ フォレストと中央集中リソース フォレストとの間で同期する必要がある属性を示しています。
表 2. Live Communications Server 2005 の Active Directory 属性
| Active Directory 属性 | 説明 |
msRTCSIP-UserEnabled | ユーザーに対し、ライブ通信サービスを有効化します。 |
msRTCSIP-FederationEnabled | ユーザーに対し、Live Communications Server のフェデレーションによる信頼関係を確立している他の組織のユーザーとのコミュニケーションを有効化します。 |
msRTCSIP-InternetAccessEnabled | ユーザーに対し、インターネット アクセス (VPN 接続なし) を有効化します。 |
msRTCSIP-PrimaryHomeServer | このユーザーのサーバーおよびサービスのドメイン名 (Standard Edition の場合は単一のサーバー、Enterprise Edition の場合はサーバー プール)。 |
msRTCSIP-PrimaryUserAddress | SIP URI (SIP ユニバーサル リソース識別子)。 |
msRTCSIP-OriginatorSid | NTLM の権限付きオブジェクト セキュリティ識別子 SID。中央集中リソース フォレスト内の連絡先または無効化されたユーザーを権限付きユーザー プリンシパル アカウントにマップします。 |
proxyaddresses | プロキシ アドレス。 |
Microsoft IT は、MIIS を使用してセカンダリ フォレスト内のユーザー オブジェクトを MIIS データベースと同期化し、その後、MIIS データベースから中央集中リソース フォレスト内の Active Directory 連絡先オブジェクトへの同期化を行いました。
運用
Communications Operations グループは Live Communications Server のメンテナンスを目的とした日常業務を行っています。これには、サーバーの主要な機能を監視するカウンタのデータを毎日収集し、各サーバーの負荷を確認する作業などが含まれます。その他にも、サーバーのバックアップや、使用可能なディスク領域、メモリ使用量、プロセッサ パフォーマンスのチェックなどのメンテナンス業務があります。つまり、Microsoft で導入されている他の IT サービスの運用業務と同じような作業を行っています。
サポート構造
Microsoft では、Live Communications Server を実行するサーバーにおいて問題が発見された場合、次のような順序で問題がエスカレーションされます。
| • | 第 1 層 : ヘルプデスク。ほとんどの問題は MOM インフラストラクチャによって検出されます。ただし、サーバーの所有者やユーザーが問題に気付き、ヘルプデスクに連絡する場合もあります。 |
| • | 第 2 層 : サポート サービスおよびクライアント サービス。サポート サービスは、MOM からの通知によってサーバーを常時監視しているため、ヘルプデスクより先に問題を発見する場合もあります。ただし、サーバーの所有者やユーザーがサーバーまたはクライアントの問題に気付き、ヘルプデスクに連絡した場合は、クライアント サービスがヘルプデスクから通知を受け、問題に対処します。これにより、サービス要求を開始し、それを基に問題を解決することができます。 |
| • | 第 3 層 : Communications Operations チーム。Communications Operations チームは、第 2 層で使用しているサポート資料でカバーされていないサーバー/クライアント関連の問題を引き受けます。さらに、第 2 層でカバーされているが解決できない問題についても、このチームが解決に当たり、サービス要求を処理します。 |
| • | 第 4 層 : Infrastructure Engineering チーム。問題を解決するために、IT アーキテクチャ、ハードウェア規格、またはソフトウェア規格の変更が必要となった場合、Communications Operations チームは Infrastructure Engineering チームに連絡します。Infrastructure Engineering チームは、必要に応じて製品開発グループに連絡し、製品の改善策について協議します。 |
マイクロソフトは、サービスに関する問題を解決するにあたって、サービス レベル契約 (SLA) の応答時間を 4 つ設定しています。次の表は、サポート層に適用されるこれらの応答時間を示しています。
表 3. マイクロソフトにおけるサービス問題の解決に適用される SLA 応答時間
| 優先度 | 定義 | 解決までの時間 |
緊急 | 次の条件の 1 つまたは両方に該当する問題 : 1 つのサイト、IT サービス、または重要な非冗長 IT デバイスの 50% 以上に影響を及ぼす予期しない停止 50 以上のクライアントまたはユーザーに影響を及ぼす予期しない停止 | 4 時間 |
高 | 次の条件の 1 つ以上に該当する問題 : 1 つのサイト、IT サービス、または重要な非冗長 IT デバイスの 50% 未満に影響を及ぼし、かつ単一ユーザーの問題ではない予期しない停止 IT サービスまたはサーバー/デバイスの冗長性を 50% 以上低下させる予期しない停止 50 未満のクライアントまたはユーザーに影響を及ぼし、かつ単一ユーザーの問題ではない予期しない停止 | 12 時間 |
中 | 次の条件の 1 つまたは両方に該当する問題 : IT サービスまたはサーバー/デバイスの冗長性を 50% 未満低下させる予期しない停止 単一のクライアントまたはユーザーに影響を及ぼす予期しない停止 | 72 時間 |
低 | ユーザーに影響を及ぼすことはないと考えられるため、時間の制約がない作業や予防的なメンテナンス。たとえば、情報の要求、予定されていた作業、ユーザーに影響を及ぼさない予防的なメンテナンスなどです。 | 無制限 |
クライアント サポート担当者のトレーニング
Live Communications Server を初めてマイクロソフトに導入したときには、クライアント サポート担当者向けのトレーニング資料がリリースされていなかったため、Communications Operations チームがクライアント サービス チームを対象として、エスカレーション階層の第 2 層に該当する問題の解決に関するトレーニング セッションを実施しました。基本的に、クライアント サービス チームは Live Communications Server などのサービスが使用できなくなるアカウント上の問題 (Active Directory に関する問題など) を扱います。
ヘルプデスクの担当者が Windows Messenger 5.1 のユーザーからの問い合わせに対応できるようにするために、Communications Operations グループはヘルプデスクの特定の問題に関する専門家 (SME) を対象とするトレーニング セッションも開催しました。さらに、各 SME がそれぞれのスタッフに対して Windows Messenger 5.1 のサポートに関するトレーニングを行いました。
Communications Operations チームは、クライアント側の問題を解決するためのマニュアルとして、第 1 層および第 2 層のヘルプデスク担当者向けのトラブルシューティング ガイドを作成しました。
運用サポート
導入を完了後の Live Communications Server 中央集中リソース フォレストは、7 台のサーバーで構成され、マイクロソフト社内の有効アカウント約 80,000 個をサポートしました。このソリューションは、Microsoft IT Communications Operations チームの上級運用アナリストによって監視および維持されています。上級運用アナリストは、Microsoft IT データ センター インフラストラクチャを使用して、サーバー バックアップ サービス、第 1 レベルおよび第 2 レベルのヘルプデスク サービス、および基本的なサーバー監視に当たっています。
上級運用アナリストは、Live Communications Server 2005 の Microsoft Operations Manager 2005 (MOM) 管理パックを使用して、主要な運用メトリックスの監視と追跡を行っています。第 3 レベルのサポート問題と解決策は、第 1 層および第 2 層のヘルプデスク スタッフがアクセスできる社内の Microsoft IT サイトでドキュメント化されています。
サーバーの監視
マイクロソフトは、Microsoft Operations Manager (MOM) を使用して、Active Directory、DNS、DHCP などのコア サービスを含む、コンピュータ インフラストラクチャのサーバー層を管理しています。MOM は、膨大な数のサーバー上のイベント ログから定義済みのイベントを収集し、SQL Server ベースの中央データベースに保存します。多数のサーバーに対して稼働状況を監視するスクリプトの実行も行います。また、特に重要なイベントについて通知を作成し、中央コンソールに送信します。さらに、管理の対象となるすべてのサーバーからパフォーマンス データを収集し、パフォーマンスしきい値の例外を知らせる通知を生成します。
Live Communications Server 2005 には Microsoft Operations Manager 2005 (MOM) 管理パックが用意されており、MOM アプリケーションを使用してサービスを中央で監視することができます。MOM によって運用管理に役立つ情報が得られます。たとえば、サーバーがオフラインになったときには MOM から通知が送信され、Live Communications Server サービスに同時にログオンしていたユーザーの人数を確認することができます。
メモ Live Communications Server の MOM 管理パックを入手するには、MOM と Live Communications Server の両方のライセンスが必要です。ライセンスを購入すると、MOM の Web サイト http://www.microsoft.com/japan/mom/downloads/2005/default.mspx から管理パックをダウンロードできます。
ほとんどの場合、MOM は潜在的な問題を検出し、Server Support チームに通知を送信します。通知を受け取った Server Support チームは、第 1 層および第 2 層のサポート ドキュメントに特定の問題の解決策が記載されていなければ、Communications Operations チームに問題をエスカレーションします。
パブリック ビューには、Live Communications Server サービスの動作に影響するホーム サーバーの稼働状況がグラフィカルに表示されます。Live Communications Server の MOM 管理パックには、次の 3 つのパブリック ビューがあります。
| • | ログオンしているエンドポイント - Live Communications Server サービスにログオンしているユーザーの数を示すカウンタが表示されます。 |
| • | コンピュータの状態 - このビューには、プロセッサ データを示すカウンタとページング データを示すカウンタが表示されます。プロセッサ データではプロセッサに対する負荷の大きさを確認することができ、サーバーに新たなユーザーを追加できるかどうかを判断するときに役立ちます。ページング データでは、サーバーの RAM が不足していないかどうかを確認できます。 |
| • | 接続の状態 - このビューには、[フロー制御接続]、[キューの深さ]、[受信メッセージの平均保留時間] の 3 つのカウンタが表示されます。[フロー制御接続] カウンタは、メッセージを制限しているサーバーに対するクライアント接続数のことであり、(ゼロを超えると) そのサーバーへ割り当てるユーザー数を減らす必要があることを示します。[キューの深さ] カウンタは、サーバーが要求をキューに入れているかどうかを示します。要求がキューに入っている場合はサービスの応答速度が遅くなることがあります。一定の時間 (目安としては 30 秒以上) にわたり値が 0 を超えた場合は、対策が必要となります。[受信メッセージの平均保留時間] カウンタは、受信メッセージが処理されるまでに要した時間の平均秒数を示します。この値が大きくなると、クライアント側で応答の遅延が発生することがあり、場合によってはサーバーに割り当てられたユーザーの数を減らす必要があります。 |
Communications Operations チームは、マイクロソフト社内のインフラストラクチャ要素のうち、通常は Live Communications Server と直接関係しないが状況によって影響を及ぼすことがある要素について、そのサポートおよび管理を担当するチームと連携を取っています。たとえば、ネットワーク グループは 2 つのデータ センターを結ぶネットワークが機能停止に陥ったという通知を MOM から受け取った場合、Live Communications Server サービスにも影響が及ぶ可能性があるため、Communications Operations チームにも通知の内容を知らせます。
同様に、インフラストラクチャ サポート チームは、Active Directory の情報のレプリケーションに要する時間が SLA に規定されている時間を超えているという通知を受け取った場合、その通知を Communications Operations チームにも送信します。Active Directory に関連する問題は必ずしも Live Communications Server サービスに直接的な影響を及ぼすわけではありませんが、このようなチーム間の連携によって Communications Operations チームは、近い将来ユーザーがログオンできなくなり、サービス要求が提出されたときのための準備を整えておくことができます。組織全体に事前対応の連絡体制が確立されていると、従業員が日常的に使用するサービスのメンテナンスに役立ちます。
Live Communications Server の MOM 管理パックには統計情報を作成する機能がないため、テキスト メッセージ、音声メッセージ、ビデオ メッセージ、短距離通信、および長距離通信の特定の時点における件数などを調べることはできません。Microsoft IT は Microsoft 製品のテストおよびトラブルシューティングを担当しているため、Windows や Live Communications Server アーカイブ ログなどの別の方法を使用して、テスト対象のサービスからパフォーマンスや動作状況に関するデータを収集し、分析しています。Live Communications Server を始めとする各製品の開発グループは、このようなデータを製品の機能向上に役立てています。
バックアップ、復元、障害復旧
バックアップを定期的に行うことは、Live Communications Server の運用に必要な日常業務の重要な要素の 1 つであり、障害復旧計画における最初の準備作業でもあります。また、バックアップの復元と回復についても手順を決めておく必要があります。ここでは、マイクロソフトの Live Communications Server 2005 アーキテクチャ コンポーネントを対象とするバックアップ、復元、および障害復旧の手順について説明します。
Live Communications Server 2005 アクセス プロキシ サーバー
アクセス プロキシ サーバーは、アプリケーションの状態やユーザー データを一切維持しません。バックアップ手順は、コンピュータのシステム状態のバックアップだけに制限されます。外部のインターネットから内部の IM 環境へのアクセスは、基幹的なサービスと見なされていません。最悪のシナリオにおいてアクセス プロキシ サーバーを復旧するには、Microsoft IT が交換用 Windows Server 2003 サーバーの再イメージ化を行い、アクセス プロキシ サーバー サーバーで Live Communications Server 2005 を再インストールした後、コンピュータのシステム状態を復元することになります。このアプローチでは、交換用サーバーのサーバー コンピュータ名が以前のサーバーと同じになっていることが前提となります。
Live Communications Server 2005 ディレクタ サーバー
ディレクタ サーバーは、新しいユーザー セッションのユーザー認証を行うことができるようにするために、ユーザー情報のデータベースを維持します。このサーバーには、その他のアプリケーションまたはセッション データは維持されません。復旧シナリオでは、ディレクタ サーバーをインストールして既存の環境に構成したときに、このデータベースが自動的に再構築されます。Microsoft IT は、ディレクタ サーバー上のコンピュータ システム状態だけをバックアップしています。
Live Communications Server 2005 Enterprise Edition のサーバー プールおよびデータベース サーバー
Live Communications Server 2005 のアプリケーション状態情報とユーザー情報はすべてクラスタ SQL Server データベース サーバーによって維持されます。SQL Server データベース ファイルは、サーバー プール SAN 上の専用パーティションに置かれます。
Microsoft IT は、SQL Server 2000 を使用して、個々の Live Communications Server 2005 データベースのスナップショット バックアップを毎日 1 回作成しています。バックアップ ファイルは、サーバー上の別のパーティションに書き込まれた後、Microsoft IT 標準のバックアップ サービスによってディスクからテープにバックアップされます。
中央集中リソース フォレスト プール内の Live Communications Server 2005 Enterprise Edition フロントエンド サーバーを復旧するには、新しくインストールしたフロントエンド サーバーと交換し、ハードウェア ロード バランサおよび中央集中リソース フォレスト サーバー プール内でそのサーバーを構成するだけです。前述したように、Microsoft IT はキャパシティ プランニングの観点から中央集中リソース フォレスト サーバー プール内に別のフロントエンド サーバーを追加しました。これにより、定期メンテナンスや予期しない停止に備えた追加のキャパシティを確保しています (個々のフロントエンド サーバーのローリング アップグレードを含む)。
さらに、Live Communications Server 2005 の DBImpExp ユーティリティで各ユーザーの連絡先リストを XML ファイルにバックアップするカスタム スクリプトを毎朝および毎晩 1 回ずつ実行しています。これにより、テープからデータベースを完全に復元する必要はなく、単一のユーザーの連絡先リストをすばやく復元できるようになっています。
Live Communications Server 2005 のアーカイブ エージェントとデータベース サーバー
アーカイブ エージェントとデータベース サーバーの役割は、主にメトリック収集を対象としており、Microsoft IT Communications Operations チームでは基幹的なものと見なしていません。アーカイブ サーバー上でバックアップされるデータは、コンピュータ システムの状態だけです。
結論
Microsoft IT は、Live Communications Server 2005、Windows Server 2003、Active Directory、および Microsoft Identity Integration Server を基盤として、セキュリティが強化されたリアルタイムのユーザー間通信ソリューションを導入しました。これにより、マイクロソフト社員、Microsoft IT、および Live Communications Server 2005 製品グループが次の項で示すような利点を得ることが可能になりました。
利点
マイクロソフトにおける Live Communications Server 2005 Enterprise Edition の導入は、以下の利点をもたらしました。
可用性、スケーラビリティ、パフォーマンスのいずれにも優れたリアルタイム通信ソリューションの導入により、サービス レベルが向上
Live Communications Server 2003 から Live Communications Server 2005 へのアップグレードによる最も大きな変更点は、高可用性の大規模導入が Enterprise Edition によってサポートされたことです。このことは、フロントエンド サーバーの負荷分散プールとクラスタ SQL Server バックエンド データベース サーバーによる二層アーキテクチャによります。ハードウェアとインストールのコストが若干増加したものの、管理と運用のコストを同程度か、または従来以下に抑えながら、従来より高いサービス可用性をマイクロソフト社員に提供することができました。
Microsoft IT が現在運用しているリアルタイム プレゼンス/インスタント メッセージング ソリューションはスケールアップが容易なため、更新プログラム、サービス パック、製品アップグレードなどの適用が必要になったときには、単一のサーバー コンピュータを停止すれだけ済みます。これにより、サービスの中断を最小限に抑えることができます。しかも、Live Communications Server 2005 のユーザーとサーバーをすべて一元管理することが可能になっています。さらに、中央集中化されたクラスタ データベース サーバー ソリューションにより、毎晩 1 回のバックアップが必要となるストレージ ボリュームは 1 つだけです。以前では、レッドモンド データ センターの各 Live Communications Server 2003 ホーム サーバー上で Microsoft SQL Server 2000 Data Engine (MSDE) が個別に維持されており、それぞれのバックアップが必要となっていました。
内部アクセスとリモート アクセスのセキュリティ向上、セットアップ、管理、追跡の簡易化
インターネットからのリモート ユーザー アクセスに VPN 接続が不要
マイクロソフト社員の多くは、建物間を移動して会議に出席したり、出先やホーム オフィスで働いたりするモバイル ユーザーです。VPN 接続を使用せずにリアルタイム プレゼンス情報にアクセスできるので、ユーザーがインターネットに接続しているときも、マイクソフト社内のネットワークに接続しているときも、有線であるか無線であるかに関係なく、シームレスにサービスを使用できるようになりました。
通信の暗号化
エンタープライズ内のコンテンツを暗号化することは、セキュリティ確保の上で重要なポイントです。Exchange 2000 Server のインスタント メッセージング サービスとパブリック インスタント メッセージング ネットワークを使用している場合は、すべての通信がクリア テキストで転送されます。クリア テキスト通信がファイアウォールを通過すると、ウイルスやその他の攻撃にさらされたり、だれかがメッセージ会話を盗み見たりするリスクが生じます。
Live Communications Server 2005 には、TLS (Transport Layer Security) プロトコルによるエンド ツー エンドの暗号化や Active Directory による完全な認証など、高レベルのセキュリティ機能が組み込まれています。クライアントとサーバー間のトラフィックの暗号化および復号化が可能であるため、情報が転送中に傍受され、読まれる恐れはありません。
クライアント上では高セキュリティ モードが適用され、サーバー上では TLS プロトコルおよび MTLS プロトコルが構成されています。これにより、Live Communications Server 2005 と Windows Messenger 5.1 との間のすべての通信、およびサーバー間のすべての通信が暗号化されます。このことは大きな利点をもたらします。マイクロソフト社員はインターネットからもサービスにアクセスできます。
複数フォレスト ネットワーク環境における導入および管理の簡易化とコスト削減
Active Directory スキーマ拡張を単一フォレストだけに限定
中央集中リソース フォレスト導入モデルを使用しているため、エンタープライズ インスタント メッセージングへの参加が必要なフォレストごとに、Live Communications Server 2005 用の Active Directory スキーマ拡張を個別に適用する必要はありません。Active Directory スキーマ拡張を適用する必要があるのは、中央集中リソース フォレストとして選択したフォレストだけです。これにより、スキーマ変更の社内導入、複製、およびメンテナンスが簡単になりました。
ユーザー アカウントのライフサイクル管理
社員の入社時または退社時には、連絡先オブジェクトの作成または削除が MIIS によって自動的に管理されます。これにより、IT リソースをより有効に利用でき、継続的なメンテナンスにかかるコストが減少します。
複数のフォレストにわたる単一の名前空間
Live Communications Server 2005 では、ライブ通信サービスを必要とするユーザーが含まれているフォレストのそれぞれにライブ通信サービスを導入する必要があります。
ディレクトリがフォレスト間で同期されている限り、Live Communications Server ではすべてのフォレストで共通の名前空間が使用されるため、フォレスト間通信のセキュリティが強化されます。たとえば、マイクロソフトでは、エイリアスに "microsoft.com" 名前空間を追加したものが SIP アドレスとしてフォレスト内のユーザーに割り当てられます。Windows Messenger では、名、姓、またはアカウント名によるユーザー検索が可能なため、セカンダリ フォレスト内のユーザーを簡単に探し出すことができます。
さらに、2 つの子ドメイン内のユーザーをサポートするときに、親ドメインにすべてのユーザーを所属させる必要はありません。すべての Live Communications Server ユーザーをいずれかの子ドメイン内でホストすることができます。これにより、マイクロソフト管理者は、いずれかの子ドメインで設定されているインフラストラクチャを通じて他の子ドメイン内のユーザーをサポートできるので、管理対象となるサーバーの数が減ります。マイクロソフトの環境は複数のフォレストとドメインで構成されていますが、Microsoft IT が各フォレストとドメインに個別にサーバーを配置する必要はありませんでした。
得られた教訓とベスト プラクティス
Live Communications Server 2005 のプランニングと導入を進める過程で、Microsoft IT はいくつかの未経験の状況に遭遇し、それらに対処しました。この経験から、以下の教訓とベスト プラクティスが得られました。
高セキュリティ モードを使用する
高セキュリティ モードでのクライアント接続が可能なレジストリ設定を使用すること。高セキュリティ設定を適用するには、TLS および MTLS を有効化してサーバーとクライアントとの間の情報を暗号化する、Kerberos 認証および NTLM 認証を必須にする、Universal Plug and Play (UPnP) を無効化する、すべてのインスタント メッセージと Windows Messenger の他の機能への招待についてピア ツー ピア接続を無効化する、などの変更を行う必要があります。高セキュリティ モードでは、単一の設定を通じてサービスの主要部分のセキュリティ レベルが向上します。
特に大きな利点は、ログオン資格情報、インスタント メッセージのテキスト、およびプレゼンス情報を含め、すべてのクライアント/サーバー通信およびサーバー間通信がエンド ツー エンドで暗号化されることにあります。オーディオ/ビデオ会議やファイル転送など、Windows Messenger のその他の機能については、ユーザー間で直接ネットワーク接続が確立されます。ユーザー間でオーディオ/ビデオ会議またはファイル転送セッションが確立されると、これらの機能にはピア ツー ピアのプロトコルが使用されます。
無関係なように見えるインフラストラクチャの変更にも注意を払う
Microsoft IT は、Live Communications Server 2005 の導入と並行して、Live Communications Server の導入に影響を及ぼす可能性があるプロジェクトをいくつか完了または開始したところでした。これらのプロジェクトには、Windows XP Service Pack 2 の導入、IPSec に基づくネットワーク ドメインの隔離、無線ネットワーク インフラストラクチャのアップグレード、新しいサーバー オペレーティング システム サービス パックのテスト、代替のネットワーク負荷分散ソリューションの導入などがありました。
Microsoft IT の Communications Operations チームでは、Live Communications Server 2005 の導入中、上記のプロジェクトのそれぞれに関連する小さな問題の解決に迫られました。問題の解決には、Microsoft IT サービス組織間に広く開放している電子コミュニケーションが役立ちました。
導入計画
組織で Live Communications Server の導入を計画するときは、導入フェーズおよび Live Communications Server を稼動するサーバーの数と構成が、以下の要因に依存することに注意する必要があります。
| • | 組織の規模 - フォレストの数、データ センターの位置、予想されるユーザー数、セッションごとの 1 ユーザーあたりの予想メッセージ数などが含まれます。 |
| • | ユーザーの利用傾向 - セッションの頻度、連絡先の数、オーディオ、ビデオ、およびコラボレーションのトラフィックに対するテキスト メッセージ トラフィックの比率などが含まれます。 |
| • | 既存のソリューション (Live Communications Server 2003 や Exchange 2000 Server インスタント メッセージング サービスなど) からの移行が導入に伴うかどうか、Live Communications Server 2005 が組織で初めて導入するリアルタイム通信ソリューションなのかどうか。 |
Live Communications Server 2005 の導入計画の詳細については、http://www.microsoft.com/japan/office/livecomm/prodinfo/ を参照してください。
ユーザーを教育する
高度な質問については、電子メールで返答すると共に、よく寄せられる質問 (FAQ) の一覧や他の情報源へのリンクを示す社内 Web サイトを公開します。
マイクロソフト社内における Live Communications Server のパイロット導入中に Microsoft IT に寄せられた質問のほとんどは、クライアントに関するものでした。たとえば、自分の連絡先リストで一部の連絡先が重複しているのはなぜかという質問や、Live Communications Server に登録していない連絡先との間で Windows Messenger 5.1 クライアントを通じてチャットすることは可能かという質問がありました。
Live Communications Server アーキテクチャを中央集中化する
複数のフォレストがある組織で Live Communications Server 2005 用のサーバーを一元管理用の場所にインストールする場合は、1 つの DNS エントリを作成し、そのエントリをすべての社内フォレストの間で複製することができます。中央集中モデルには、サービスに必要な DNS レコードの管理が容易になるという利点があります。ただし、データ センターが地理的に広く分散している場合 (たとえば複数の大陸に分散している場合) は、中央集中モデルをサポートするのに十分な帯域幅がデータ センター間に存在するかどうかを確認しなければなりません。少なくとも 8 時間で各ユーザーにつき 1 秒あたり平均して 1.6 キロビットの帯域幅が必要になります。
中央集中モデルでは、ユーザーがサービスにログオンするのに要する時間が長くなる可能性があります。現在のネットワーク遅延を測定すると、このモデルによる影響の度合いを判断できます。ネットワーク遅延を測定する方法の基本的な例として、サーバーと目的地のコンピュータとの間で PING プロトコルにより 1 KB のパケットを 100 個送信する方法があります。マイクロソフトの場合、遅延時間は 107 ミリ秒でした。Microsoft IT は、この程度の小さな遅延であれば、分散サーバー導入戦略を検討する必要はないと判断しました。実際のネットワーク環境で遅延が著しい場合は、1 つまたは複数のホーム サーバーを分散させることが選択肢の 1 つとなります。
まとめ
Microsoft IT が Live Communications Server 2005 Enterprise Edition を導入した結果、80,000 超のアカウントを要する大規模なエンタープライズ環境で製品をテストするという目的と、プレゼンスとインスタント メッセージングなどのリアルタイム通信機能をマイクロソフト社員に提供するという目的を同時に達成できました。
Live Communications Server 2005 Enterprise Edition は、以下の利点をもたらす完全なエンタープライズ ソリューションです。
| • | TLS 暗号化、Windows 認証、およびメッセージ アーカイブにより、セキュリティが向上します。 |
| • | リアルタイム プレゼンスおよびセキュリティが強化されたインスタント メッセージングにより、エンド ユーザーの生産性が向上すると共に、意思決定に要する時間が短くなります。 |
| • | 優れた管理性により、組織の施設内にある既存のエンタープライズ インフラストラクチャを利用でき、安全性および信頼性に欠ける公共サービスに依存せずに済むので、導入および管理が容易になります。 |
| • | 高い拡張性により、API を使用して斬新なアプリケーションやカスタマイズされたソリューションを作成できます。 |
Live Communications Server 2005 を導入すると、インスタント メッセージング サービスを管理しやすくなると同時に、ユーザー コミュニケーションの効率とセキュリティが向上し、社員の生産性が高まり、その結果、組織のコスト低減につながります。Live Communications Server 2005 は、SIP を使用して従来のインスタント メッセージングに優るコミュニケーションを実現するアプリケーションおよびソリューション (カスタム リアルタイム通信、Voice over IP (VoIP) テレフォニー アプリケーション、Microsoft Office System など) のプラットフォームとしても、長期にわたって価値をもたらします。
詳細情報
Microsoft Office Live Communications Server
| • | Microsoft Office Live Communications Server Web サイト (http://www.microsoft.com/japan/office/livecomm/) |
| • | Microsoft Office Live Communications Server Development Center (http://msdn2.microsoft.com/en-us/office/default.aspx) (英語) |
関連する Microsoft IT 導入事例ホワイトペーパー
| • | 「Improving Security with Domain Isolation: Microsoft IT Implements IP Security (IPSec) (http://www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx) (英語) |
| • | 「Enabling Cross-Forest Identity Management with Microsoft Identity Integration Server 2003」(http://www.microsoft.com/technet/itsolutions/msit/deploy/cfimwiis.mspx) (英語) |
その他の情報
| • | Microsoft Operations Manager Web サイト (http://www.microsoft.com/japan/mom/) |
| • | Microsoft Identity Integration Server Web サイト (http://www.microsoft.com/japan/windowsserversystem/miis2003/) |
Microsoft Sales Information Center
インターネットでは、次の Web サイトで当社の情報をご覧いただけます。
http://www.microsoft.com/japan/
http://www.microsoft.com/japan/showcase/
付録 A – Windows Messenger 5.1 クライアントのブランディング
Microsoft IT は、Windows Messenger 5.1 クライアントをすべてのユーザーに配布するのに先がけ、パイロット ユーザーの助けになるようにクライアントのブランディング機能を使用しました。たとえば、ユーザーによる使用感を評価する目的で、アンケートを作成し、Windows Messenger 5.1 に表示されるバナー画像をクリックするとアンケートに回答できるようにしました。
Microsoft IT クライアント サービス チームは、Windows Messenger 5.1 のブランディング機能 (会話ウィンドウの一番下に表示されるバナー画像など) を社員への情報伝達に使用しています。社員が Windows Messenger 5.1 をインストールすると、以下に示しているブランディング用レジストリ設定が適用されます。Microsoft IT は、このブランディング用レジストリ設定から参照されているコンテンツを変更することにより、すべてのクライアントに対し次回のログオン時に新しいコンテンツを表示させることができます。
Microsoft IT は、ブランディングに 5 つの主要な要素を使用しています。これらはいずれも、クライアントのインストール時にクライアントのレジストリに書き込まれます。次の表は、それらのレジストリ エントリの名前を示しています。
表 4. Windows Messenger 5.1 クライアントのブランディング用レジストリ設定
| レジストリ設定 | 説明 |
BannerURL | 会話ウィンドウの下部に表示される画像の URL を指定します。この部分をクリックすると、BannerLinkURL に定義された場所に移動します。Microsoft IT サービス チームでは BannerURL 画像と BannerLinkURL リンクを使用して、Windows Messenger 5.1 ユーザーに IT 関連のメッセージやその他のメッセージを伝達しました。 |
BannerLinkURL | Windows Messenger 5.1 からユーザーをリダイレクトする場合に、リダイレクト先のページの URL を指定します。たとえば、クライアントの更新プログラムがある Web ページやサービスの機能に関する情報が掲載された Web ページにリダイレクトすることもできます。導入プロジェクトのパイロット フェーズ中は、ユーザーがアンケートにリダイレクトされるように BannerLinkURL を設定しました。Web サーバー上でリダイレクトを使用するので、クライアント側のレジストリ設定を変更することなく、ユーザーがバナー画像をクリックしたときに表示するページを制御できます。 |
HelpURL | [ヘルプ] メニューからユーザーが参照できる URL を指定します。Microsoft IT は、このエントリを Windows Messenger 5.1 に関する Microsoft IT Web ページに設定しました。このページには、よく寄せられる質問 (FAQ) やサーバーの稼働状況などの情報があります。 |
Providername | [ヘルプ] メニューに表示するメニュー項目のテキストを指定します。このメニュー項目をクリックすると、HelpURL に関連付けられている Web ページが表示されます。 |
TabURL | Windows Messenger 5.1 アプリケーションの左側に表示するカスタム タブの構成情報が格納されている XML マニフェスト ファイルの URL を指定します。 |