• [アーティクル]

通信

Exchange Server 2007 を使用してユニファイド メッセージングを展開する

Jeff Goodwin

 

概要:

  • テレフォニーの基礎
  • ユニファイド メッセージングを設計する際の考慮事項
  • ユーザーの移行

Exchange Server 2007 ユニファイド メッセージングを環境に展開することに決めたとします。ユニファイド メッセージング サーバーの役割をインストールし、これを既存の PBX と統合して、現在ではあなたと他の 10 名の従業員のボイスメール、電子メール、および FAX メッセージが Exchange に格納されています。一瞬、

これで非常に大きな仕事をやり遂げたと思ったかもしれません。しかし、同じ機能を、複数のサイトに分散している数千人のサブスクライバに、業務に支障のない形で展開するにはどうしたらよいでしょうか。

そのような場合に、この記事がお役に立てればと思います。この記事は、ユニファイド メッセージングを環境に展開する方法と、このような展開に関係するテレフォニーの概念について、理解を深めていただくことを目的としています。Exchange Server 2007 ユニファイド メッセージングのインストール、構成、または機能については、この記事の最後にある「ユニファイド メッセージングの関連情報」を参照してください。また、マイクロソフトは、Exchange Server 2007 ユニファイド メッセージングに関するコンサルティング、設計、および展開のサポートを提供できる企業をユニファイド メッセージング スペシャリストとして認定しています。インストール、構成、または展開に関するサポートが必要な場合は、いずれかのスペシャリストに問い合わせてください。これらのスペシャリストについても、「ユニファイド メッセージングの関連情報」を参照してください。

はじめに

ユニファイド メッセージング テクノロジは Exchange にとって目新しいものではありません。さまざまな組織が、Exchange と統合できるユニファイド メッセージング製品を提供しています。ただし、Exchange でユニファイド メッセージングがネイティブにサポートされるのは、このバージョンが初めてです。Exchange Server 2007 ユニファイド メッセージングの登場以来、多くの顧客がこの機能を組織内の小規模のグループに展開しています。しかし、さまざまな理由から、すべてのユーザーにユニファイド メッセージングが展開されない場合があります。問題の 1 つは、多くの Exchange 管理者にとってテレフォニーの概念やユニファイド メッセージング サービスの実装に必要なテクノロジは未知のもので、これらのソリューションを設計し、自社に展開する作業にかなり苦労していることです。

どのような展開プロジェクトにも当てはまることですが、段階的なアプローチが通常は最良の結果を生みます。アーキテクチャの計画、ソリューションのテスト、ユーザー コミュニティでのパイロット運用、トレーニング、および新システムへのユーザーの移行という 5 段階が、ユニファイド メッセージング プロジェクトで考慮する必要があるすべての側面と言えます。このプロジェクトを計画する際は、組織の IT 部門と通信部門の両方が参加することが非常に重要です。

従来のボイスメール プラットフォームで当然のように利用されている機能の多くは、新システムでも実現するか、実現できない場合は、新システムの実装時にユーザー コミュニティへの影響を抑えられるような代替ソリューションを設計する必要があります。これは、通信チームの助けを必要とする主要な領域です。同時に、通信チームは、展開が行われてから、新しいボイスメール プラットフォームの管理、トラブルシューティング、およびサポートをどのように進めるかについて、IT チームから学ぶ必要があります。

テレフォニーの基礎

基本のアーキテクチャ、通話フロー、およびユニファイド メッセージング関連の用語を理解していると、かなり計画が楽になります。図 1 は、企業の既存のテレフォニー システムに統合されたユニファイド メッセージング ソリューションの一例を示しています。このような展開を行う際に利用する、いくつかの最も一般的な概念とテクノロジについて、詳しく見ていきましょう。

図 1 PBX とユニファイド メッセージングが統合されたソリューション

図 1** PBX とユニファイド メッセージングが統合されたソリューション **(画像を拡大するには、ここをクリックします)

構内交換機 (PBX) は、企業内で使用される専用電話網です。このようなシステムでは、通常、各ユーザーには PBX に接続された机上電話が支給され、この電話機を使用して内線番号 (通常 4 桁または 5 桁の番号) をダイヤルすることで社内の他のユーザーに電話をかけたり、社外の番号に電話をかけたりすることができます。

さまざまな場所に PBX が配置されている場合は、PBX ベンダ固有のネットワーク テクノロジを利用してこれらのシステムが接続される場合があります。これによって、ネットワーク経由で接続された PBX を使用するすべてのユーザーが、内線番号をダイヤルするだけで電話をかけ合えるようになります。

ユニファイド メッセージングでは、2 つの異種システムを統合する必要があります。これらは、Exchange メッセージングと物理的なテレフォニー システムです。ユニファイド メッセージング サーバーとテレフォニー アーキテクチャとの間の通信は、セッション開始プロトコル (SIP) を使用して確立されます。PBX テクノロジの中には、SIP を介して直接ユニファイド メッセージング サーバーと通信できるものも、SIP ゲートウェイを必要とするものもあります。図 1 では、PBX は T1 回線を経由して SIP ゲートウェイに接続されています。通話がユニファイド メッセージングに転送されると、PBX は情報 (発信側の電話番号、受信側の電話番号、なんらかの理由コードなど) を SIP ゲートウェイに送信して、ユニファイド メッセージング サーバーがどのユーザー宛ての通話であるかを認識できるようにします。

PBX の中には、IP ネットワークを経由して接続できるものもあります。テレフォニー ネットワークを構築すると、一元管理を行うボイスメール ソリューションに IP ネットワーク経由で通話をリダイレクトできます。たとえば、図 2 では、チューリッヒとロンドンがネットワークで接続されています。

図 2 より複雑なユニファイド メッセージングの展開

図 2** より複雑なユニファイド メッセージングの展開 **(画像を拡大するには、ここをクリックします)

通話フロー

ユニファイド メッセージングの関連情報

社外からユニファイド メッセージングのサブスクライバ宛てに電話がかかってきたとします。ここでは、このユニファイド メッセージングのサブスクライバが外出していて、電話に出られないとします。図 1 で、このメッセージの経路をたどることができます。

PBX が通話を SIP ゲートウェイに送信し、SIP ゲートウェイは、SIP over TCP を経由してユニファイド メッセージング サーバーとこの通話に関するネゴシエーションを行います。サーバーは、どのユーザー宛ての電話であるかを示す統合データを SIP ゲートウェイから受信します。ユニファイド メッセージング サーバーは、サブスクライバの不在応答メッセージを再生し、社外の発信者がメッセージを録音できるようにします。この発信者のメッセージは、ユニファイド メッセージングのサブスクライバの Exchange メールボックスに配信されます。

この通話フローは、実際の処理をかなり簡略化したものです。理解する必要があるのは、メッセージが録音されると、ユニファイド メッセージング サーバーがそのメッセージを SMTP 経由でハブ トランスポート サーバーに転送して、メールボックス サーバーに配信されるようにするということです。

ユーザーは、ユニファイド メッセージングのサブスクライバとして、電話 (Outlook® Voice Access を使用) またはコンピュータ (Outlook 2007 または Outlook Web Access を使用) から各自の Exchange メールボックスにアクセスできます。ただし、サブスクライバは電話での再生と呼ばれる新機能を使用すると、電話から Outlook 2007 や Outlook Web Access を使用してメッセージにアクセスできます。この機能は、サブスクライバがコンピュータからメッセージにアクセスするのではなく、指定された電話番号に電話をかけることで、選択したメッセージをユニファイド メッセージングによって再生できる機能です。この方法を使用した場合、ユニファイド メッセージング サーバーはクライアント アクセス サーバーとメールボックス サーバーの両方と通信します。これを理解しておくことは重要です。クライアント アクセス サーバーがローカルに配置されていないリモート オフィスにユニファイド メッセージング サーバーを配置する場合、このユニファイド メッセージング サーバーは、WAN を経由してクライアント アクセス サーバーにアクセスする必要があるため、パフォーマンスが低下する可能性があります。

システムの設計

Exchange のアーキテクチャの設計は、大きく 2 つに分類できます。これらは、集中型と分散型です。一般に、ユニファイド メッセージングのアーキテクチャは、Exchange のアーキテクチャに従っています。つまり、メールボックス サーバーが展開される場所には、ユニファイド メッセージング サーバーも展開されます。もちろん、どんな規則にも例外はあります。

ユニファイド メッセージングのアーキテクチャを設計する際は、5 つの基本的な領域について考慮する必要があります。

  • サーバーの配置場所
  • ユニファイド メッセージング サーバーの数
  • SIP ゲートウェイ
  • メールボックスのストレージ
  • ユニファイド メッセージング サイトの構成

また、ビジネスの継続性についても注意してください。一般に、Exchange に関連する障害回復計画を使用して、ユニファイド メッセージングに関連する要素を特定できます。

サンプルの展開シナリオを使用すると、ユニファイド メッセージング サーバーの役割を理解しやすくなるでしょう。図 2 は、ユニファイド メッセージングを実装した Exchange Server 2007 を大規模な企業に展開した場合の状態をわかりやすく表しています。

より複雑なこの設計では、シアトルとロンドンにプライマリ データセンターがあります。この 2 つの拠点には、メールボックス サーバーとハブ トランスポート サーバーがローカルに配置されているため、ユニファイド メッセージング サーバーがそれぞれのユーザー コミュニティにサービスを提供しています。どちらのサイトにも、通話応答を提供する目的で、ローカルのユニファイド メッセージング サーバーにコール カバレッジを提供する IP PBX が配置されています。

中規模のサイトは、ニューヨークとグラスゴーにあります。この 2 つの拠点には、メールボックス サーバーとハブ トランスポート サーバーがローカルに配置されているため、ユニファイド メッセージング サーバーがそれぞれのユーザー コミュニティにサービスを提供しています。プライマリ データセンターと同様に、どちらのサイトにも、通話応答を提供する目的で、ローカルのユニファイド メッセージング サーバーにコール カバレッジを提供する IP PBX が配置されています。

小規模なサイトには、メールボックス サーバーもハブ トランスポート サーバーもローカルに配置されていませんが、プライマリ データセンターのユニファイド メッセージング機能を利用できるようにしています。オースティンには、アナログ接続を使用してローカルの SIP ゲートウェイに接続する NEC PBX が配置されています。ローカルのエンド ユーザーへの通話はこの SIP ゲートウェイに転送され、SIP ゲートウェイがシアトルのユニファイド メッセージング サーバーとネゴシエートし、ユニファイド メッセージングの通話応答を提供します。

チューリッヒでは Avaya Communication Manager が使用されており、IP ネットワークを経由してロンドンの Avaya Communication Manager に接続されています。ローカルのエンド ユーザーへの通話はこの Avaya Communication Manager ネットワークを経由して転送され、Avaya Communication Manager がロンドンのユニファイド メッセージング サーバーとネゴシエートし、ユニファイド メッセージングの通話応答を提供します。

この例のシアトル サイトでは、物理的に同じ場所に、Exchange メールボックス サーバーとユニファイド メッセージング サーバーが配置されています。シングル サイト アーキテクチャを実装する場合は、すべてのサーバー (メールボックス、ユニファイド メッセージング、クライアント アクセスなど) と PBX 機器を同じサイト内に配置します。複数のサイトを所有している企業では、設計がより複雑になります。この複雑さは手に負えないもののように思えるかもしれませんが、ユニファイド メッセージングの基本原理を適切に理解しておけば対応できます。

図 2 に示されているように、サイトにメールボックス サーバーが配置されている場合は、ユニファイド メッセージング サーバーもこのサイトに配置することをお勧めします。シアトル、ロンドン、ニューヨーク、グラスゴーは、どれもこの設計が適しています。オースティンやチューリッヒにはメールボックス サーバーがローカルに配置されていませんが、IP ネットワークを使用することで、ユニファイド メッセージング サービスを提供できます。オースティンにはアナログ PBX がローカルに配置されています。この場合、SIP ゲートウェイを使用して、シアトルのユニファイド メッセージング サーバーへの IP ネットワーク接続を提供する必要があります。チューリッヒには IP PBX がローカルに配置されており、ネットワーク経由でロンドンの PBX に接続されています。したがって、チューリッヒのユーザーへの通話は、テレフォニー ネットワークを経由して、ロンドンの PBX とユニファイド メッセージング サーバーに転送されます。

チューリッヒのサブスクライバ宛ての通話は、ネットワーク経由で転送され、ロンドンにある集中管理用のユニファイド メッセージング システムによって処理されます。ネットワーク障害が発生した場合は、ネットワークが修復されるまでチューリッヒのすべてのサブスクライバへの通話に応答することができません。ネットワーク障害が発生した場合にもローカルでサービスを提供し続ける必要がある場合は、ユニファイド メッセージング サーバーをチューリッヒに配置します。ネットワーク障害が発生した場合、ユニファイド メッセージング サーバーが引き続き通話に応答し、ネットワークが修復された時点で通話を配信します。

各環境に適したアーキテクチャを設計する際に、考慮すべき最も重要な要素は、おそらくサーバーの配置でしょう。図 3 のフローチャートは、適切なサーバーの配置を決定する際に役立ちます。

図 3 サーバーの配置を決定する

図 3** サーバーの配置を決定する **(画像を拡大するには、ここをクリックします)

サーバーの要件を見積もる

次に考慮すべき領域は、ユーザー コミュニティをサポートするために必要なユニファイド メッセージング サーバーの数です。この数は、サイト固有のいくつかの要因によって決まります。

ユニファイド メッセージングのスケーラビリティは、サーバーがサポートできる同時通話 (テレフォニーの世界では "通話ポート") の数によって決まります。システムへの各通話は、ネットワーク、CPU、メモリ、およびディスク リソースを提供する専用のユニファイド メッセージング サーバーを必要とします。これらのリソースを追加することで、ユニファイド メッセージング サーバーが、より多くの同時通話をサポートできるようになります。これらのリソースは常に限られているため、ユニファイド メッセージング サーバーが一度に処理できる同時通話の数は、リソースが過負荷にならない範囲に制限されます。

ここでは詳しく説明しませんが、Erlang トラフィック分析計算を使用すると、サブスクライバの人数をサポートするために必要なポート数を特定できます。より簡単な方法は、既存のボイスメール システムで使用されているボイスメール ポートの数をテレフォニー管理者に尋ねることです。現場での経験から言うと、従来のボイスメール システムのポート要件とユニファイド ボイスメール システムのポート要件は、非常に似ています。

私は、基本的に 1 台のサーバーに 60 個を超えるポートは実装しないことを推奨しています。これは、ソフトウェアやハードウェアの制限とは関係ありません。この根拠は、ポートが 60 個あるサーバーでは、約 5,000 人のユーザーをサポートできるという事実です。このサーバーで障害が発生した場合、たった 1 台のサーバーの障害によって、(非常に大規模な) サブスクライバ ベース全体に影響を与えることになります。

ユニファイド メッセージング サーバーを実装するときは、N+1 の冗長性が確保されるようにアーキテクチャを設計するとよいでしょう。図 4 は、完全に冗長なサーバーと SIP ゲートウェイの設計を示しています。この設計を使用すると、ユニファイド メッセージング サーバー 1 で障害が発生した場合、SIP ゲートウェイ 1 からの通話は、自動的にユニファイド メッセージング サーバー 2 と通話をネゴシエートします。また、SIP ゲートウェイ間で均等に通話の負荷が分散されるように、PBX のプログラムを作成することもできます。たとえば、最初にシステムに着信した通話は、SIP ゲートウェイ 1 にルーティングされ、次にシステムに着信した通話は SIP ゲートウェイ 2 にルーティングされるようにすることができます。通話を複数のゲートウェイに交互にルーティングすることで、ユニファイド メッセージング サーバー間で通話が均等に分散され、負荷が共有されます。

図 4 サーバー間で通話を分散し、冗長性を確保する

図 4** サーバー間で通話を分散し、冗長性を確保する **(画像を拡大するには、ここをクリックします)

Exchange Server 2007 ユニファイド メッセージング ソリューションでサポートされている SIP ゲートウェイ プロバイダは、現在 2 社あります。これらは、AudioCodes と Dialogic です。設計に SIP ゲートウェイを組み込む必要がある場合は、その設計に必要なセッション (ポート) の数がサポートされているものを購入してください。たとえば、設計で 32 個のポートが必要とされている場合は、少なくとも 32 セッションがサポートされているゲートウェイが必要です。

使用している PBX をユニファイド メッセージングに使用できるかどうかや、どのゲートウェイを使用すべきかについては、「ユニファイド メッセージングの関連情報」を参照してください。このセクションには、マイクロソフトから提供されている特定のガイダンスや、各組織の特定の要件を評価する際に役立つユニファイド メッセージング スペシャリストの一覧へのリンクが記載されています。私個人の経験から言えば、SIP ゲートウェイおよび Exchange ユニファイド メッセージングと連携させることができない PBX はそれほど多くありません。また、一部の PBX は SIP over TCP を使用してネイティブにユニファイド メッセージング サーバーと通信できます。

Exchange ユニファイド メッセージングでは、ボイスメール メッセージの保存用に 3 種類のオーディオ コーデックがサポートされています。これらは、G.711 PCM Linear、GSM 06.10、および Windows Media® Audio (WMA) です。PCM Linear WAV ファイルのサイズは、オーディオ 1 秒間あたり約 16 KB です。WMA は、ユニファイド メッセージングの既定のオーディオ コーデックです。WMA では、オーディオが 1 秒間あたり 1.1 キロビット (kb) に圧縮され、7 KB のヘッダーが付けられます。GSM 06.10 では、オーディオが 1 秒間あたり1.6 kb に圧縮されますが、ヘッダーのサイズは WMA エンコードよりも小さくなります。

WMA も GSM 06.10 エンコードも、ボイス メッセージングの品質としては合格です。WMA または GSM コーデックを使用した現場での経験から言うと、組織でどの程度ボイスメールが使用されているかによりますが、メールボックス ストアのサイズが 10 ～ 20% 増加することが予想されます。

環境で使用するオーディオ コーデックを決める際は、エンド ユーザーのモバイル デバイスやその他のオペレーティング システムを考慮してください。このトピックに関するほとんどの問題は、ユーザーが所有している Windows Mobile® デバイスでボイスメールを使用できるかどうかに関係しています。その他のオペレーティング システムも考慮する必要があります。おそらく、WMA ファイルを再生できない可能性がある Linux コンピュータが多数展開されていると思います。状況はさまざまだと思いますが、これらの要因が存在する場合、該当するユーザーのトレーニングに必要なヘルプ デスクのリソースは増加します。

構成とテスト

ユニファイド メッセージング アーキテクチャが集中型であるか分散型であるかにかかわらず、ユニファイド メッセージングを組織に展開する前に考慮する必要があるボイスメールの要件は多数あります。プロジェクト チームで話し合う必要があるトピックの詳細な一覧については、「ユニファイド メッセージングのチェックリスト」を参照してください。ユニファイド メッセージングの実装を考えているサイトごとに、すべてのトピックの情報を収集してください。これらのトピックについて話し合う際は、IT チームと通信チームの両方が協力する必要があることを忘れないでください。

システムを設計し、構成を完了したら、テスト システムを運用して設計を検証します。複数のサイトを使用する設計の場合、少なくとも 2 つのサイトをテストして、概念を実証し、設計が正しく機能するかどうかを検証します。

構成要件を基に機能テストの計画を作成した後、テストを実施します。機能テストの計画には、サブスクライバのアクセス方法 (電話、Outlook 2007、および Outlook Web Access)、管理方法、およびハードウェア障害とネットワーク障害を含める必要があります。

テストが完了し、ユニファイド メッセージングが従来のボイスメール システムの機能を再現していること、または再現できない構成や機能をサポートする代替ソリューションが設計されていることを全員が認めた段階で、ユーザーのパイロット グループを選抜して、システムをテストします。パイロット グループを用意することで、従来のボイスメール システムからユニファイド メッセージングにサブスクライバを移行 (テレフォニー用語では "カットオーバー") するために、各環境で必要になる手順を実際に確認できます。一般に、サブスクライバのカットオーバーに必要な手順は次のとおりです。

  1. 既存のボイスメール システムのサブスクライバを無効にします。
  2. Exchange 管理コンソールを使用して、Active Directory でこのサブスクライバのユニファイド メッセージングを有効にします。
  3. 電話のカバレッジ パスをユニファイド メッセージングのパイロット番号に変更します。

既存のボイスメール システムのサブスクライバを無効にして、古いメールボックスにメッセージが送信されないようにすることが重要です。

パイロット フェーズ中に、システムの機能に関する疑問点をサブスクライバから収集します。これらの詳細を記録することで、トレーニング フェーズ中によく発生する問題に対処できます。

カットオーバーを成功させるためには、トレーニングが非常に重要です。ユーザーは、電話から特定のユーザー インターフェイスを使用してボイスメールにアクセスすることに慣れています。たとえば、あるボイスメール システムでは、5 を押すとメッセージを聞くことができます。Exchange ユニファイド メッセージングでは、1 を押すか "ボイスメール" と言う (または Outlook 2007 か Outlook Web Access を使用して音声メッセージを再生する) 必要があります。ユニファイド メッセージングのサブスクライバ向けのトレーニングでは、テレフォニー ユーザー インターフェイス、Outlook Voice Access、および Outlook または Outlook Web Access の操作をすべて説明するようにします。

Exchange 2007 ユニファイド メッセージングでは、口頭で操作を指示できる機能が Outlook Voice Access に組み込まれます。ユーザーの中にはシステムの新機能をとても気に入り、そのことが別のユーザー インターフェイスへの移行を後押しすることがあります。

Exchange ユニファイド メッセージングでは、あるユーザーを有効にしたときに、そのユーザーにカスタムのテキスト電子メール メッセージを送信する機能が提供されます。このカスタム メッセージを使用して、よく寄せられる質問 (FAQ)、サブスクライバ向けのドキュメント、ヘルプ デスクの電話番号など、役立つ Web リンクを提供することができます。また、ボイスメール システムへのアクセス方法や、サブスクライバ固有のパスワードといった情報を提供することもできます。これは、エンド ユーザーを有効にする際に利用できる、最も強力な機能の 1 つです。

ユーザーを移行する

ユニファイド メッセージングのチェックリスト

ここでは、ユニファイド メッセージング システムのいくつかの基本要素と、Exchange Server 2007 ユニファイド メッセージングの展開と構成に備えて決定する必要がある項目を示します。展開計画を作成する際のチェックリストとして使用してください。

ダイヤル プラン ユニファイド メッセージングのダイヤル プランは、PBX および関連付けられている内線番号に論理的に対応しています。ダイヤル プランについて、あらかじめ検討する必要がある項目を次に示します。

  • 内線番号は何桁にするか。
  • ユニファイド メッセージング システムのパイロット番号は何番にするか。
  • ユーザーが外線にダイヤルするには、何が必要か。
  • メッセージにどのオーディオ コーデックを使用するか。
  • 社内のオペレータの内線番号は何番にするか。

ハント グループとパイロット番号 ハント グループは、特定の順序で通話を受信するように構成された一連の内線番号です。パイロット番号は、ハント グループにアクセスするためにダイヤルする主内線番号です。ハント グループのメンバの内線番号と、設計内のボイスメール ポートの番号には、同じものを使用する必要があります。

メールボックス ポリシー ボイスメール メールボックスのポリシーと Exchange メールボックスのポリシーとの間には、あまり違いはありません。考慮する必要があるいくつかのポリシーを次に示します。

  • ボイスメールを削除せずに保持しておく日数。
  • ボイスメールのパスワードの再設定を要求する頻度。
  • ボイスメールのバックアップ ポリシー。
  • パスワードの最低文字数。
  • メールボックスをロックするログオンの失敗回数。

自動応答 (AA) 自動応答は、特定のサブスクライバ宛てではない着信通話に応答します。自動応答は、情報を提供し、組織内の場所に発信者を案内します。Exchange ユニファイド メッセージングの AA 案内では、DTMF 機能と音声認識機能が提供されます。考慮事項を次に示します。

  • 日中、夜間、および休日に異なる AA メッセージを使用するか (メッセージは文書化し記録する必要があります)。
  • どのユーザーに AA メニューからのダイヤルを許可するか。
  • AA を使用した場合に音声案内機能を使用できるか。
  • AA を使用するために複数の言語が必要になるか。

汎用または夜間メールボックス 一部の組織では、汎用または夜間メールボックスを用意して、発信者が一般的な配信メッセージを残すことができるようにしています。企業でこのようなメールボックスを導入している場合は、Exchange メールボックスを作成し、ユニファイド メッセージングを有効にする必要があります。

Message Waiting Indication (MWI) Message Waiting Indication は、メールボックス内にまだ再生されていないボイス メッセージがあることを知らせる電話機上のライトです。電話機の Message Waiting Indication が展開の要件に含まれるかどうかを検討します。

複数の内線番号のサポート 多くの組織には、複数の電話を使用している従業員がいます。このようなユーザーをユニファイド メッセージングのサブスクライバとして有効にする場合は、その時点のユーザーの内線番号をすべて関連付ける必要があります。作業を開始する前に、複数の内線番号を使用している従業員の一覧を作成してください。

音声自動応答装置 (IVR) のサポート 従来のボイスメール システムの中には、ユニファイド メッセージングでは再現できない IVR アプリケーションがサポートされているものもあります。置き換えられるシステムに、このようなアプリケーションが関連付けられていないかどうかを確認してください。このようなアプリケーションは、既存のシステムに残すことができる場合もあれば、代わりの IVR アプリケーションで置き換えなければならない場合もあります。

ボイスメール ネットワーク ボイスメール ネットワークでは、異種システム間でメッセージを送信するための手段が提供されます。たとえば、大規模な企業では、CEO が組織全体にボイス メッセージを送信したり、消防訓練についての案内など、一般的な情報を通知する場合があります。ボイスメール ネットワークがあれば、CEO がボイス メッセージを一度録音したら、どのボイスメール システムに所属しているかに関係なく、全従業員にそのボイス メッセージを送信できます。現時点では、Exchange ユニファイド メッセージングと他の従来のボイスメール システムを接続するネットワークを構築することはできません。

FAX のサポート 従来のボイスメール プラットフォームの中には、FAX の受信をサポートし、ボイスメールと受信 FAX に同じ電話番号を使用できるものもあります。Exchange Server 2007 ユニファイド メッセージングでは FAX の受信がサポートされているため、この機能を置き換えることができます。これは一方向の機能であり、FAX の送信機能はサポートされていません。この機能が必要な場合は、この機能がサポートされているサードパーティ製品の使用を検討してください。

システムを完全な運用に移行する方法に関しては、さまざまな見方があります。主な 2 つの方法論は、段階的な移行とフラッシュ カットです。どちらを使用するにしても、パイロット グループから収集して記録した一般的な質問に対処できるように、ヘルプ デスク スタッフを教育します。また、ユーザーを有効にする方法、ユーザーが有効になっていることを確認する方法、およびパスワードを変更する方法についても指導します。

古いボイスメール システムからユニファイド メッセージングにユーザーを移行する作業は非常に簡単ですが、1 つ注意が必要なことがあります。それは、ボイスメール ネットワークです。電子メール システムで他の電子メール ユーザーやシステムに電子メールを送信、転送、および返信できるように、ボイスメール システムでも他のボイスメール ユーザーやシステムにボイスメールを送信、転送、および返信できます。

たとえば、古いボイスメール システム上で Alice と Brian というユーザーが管理されているシナリオについて考えてみましょう。Brian はユニファイド メッセージングに移行され、古いボイスメール システム上の Alice にメッセージを送信したいとします。この 2 人のユーザーは別のシステムに所属しているため、ボイスメール メッセージを送信、転送、または返信し合うことができなくなり、残念なことですがボイスメールの孤島が生まれます。

従来のボイスメール システムでこの問題を解決する方法は、異種システムどうしをネットワーク経由で接続できるネットワーク プロトコル コンバータを使用することでした。ただし、現時点では、Exchange Server 2007 ユニファイド メッセージングと異種システムをネットワーク経由で接続できるネットワーク プロトコル コンバータはありません。これは皆さんの組織にとって重要でない場合もありますが、ユーザーを少しずつ移行する場合は注意が必要な問題です。

個人的には、サイト規模ですべてのユーザーを移行するフラッシュ カットがお気に入りです。フラッシュ カットは、あるシステムから別のシステムに一斉に移行する方法です。通常、この作業は週末に行われ、金曜日にユーザーが帰宅してから、月曜日に出社するまでの間に、新しいボイスメール システムに移行します。管理者の中には、フラッシュ カットは、小規模な企業ユーザーやリモート サイトのみに使用すべきだとする方もいます。私はそうは思いません。1 か所で 7,000 人のユーザーという大規模なフラッシュ カットに関わったことがありますが、サポートを必要としてヘルプ デスクに問い合わせた従業員は 1％ 未満でした。プロジェクトの他のすべてのフェーズが問題なく計画および実行されているのであれば、完全な運用システムへのカットオーバーはスムーズに進むでしょう。

ただし、複数のサイトを完全な運用システムにカットオーバーする場合は、小規模なリモート サイトから大規模なサイトへと 1 つずつカットオーバーすることを検討してください。小規模なサイトでの作業で学んだことを見直して、必要な変更をプロジェクトの計画に組み込むようにします。

通常、システムをカットオーバーして運用を開始する前に、すべてのユーザーのトレーニングを完了し、すべてのユーザーのユニファイド メッセージングを有効にする必要があります。ボイスメール システムのフラッシュ カットを準備するための手順を次に示します。

まず、ユニファイド メッセージング システムのインストール、構成、およびテストが完了していることを確認します。

少人数のグループでトレーニングを実施します。参加しているユーザーに、システムの運用を開始する前にメールボックスが有効になることを説明します。また、メールボックスにログインし、パスワードの変更と応答メッセージの録音を行ってメールボックスを初期化することを推奨します。トレーニングが完了したら、直ちにユーザーを有効にして、ユーザーが各自のメールボックスをカットオーバー前に初期化できるようにします。

最後に、すべてのトレーニングが完了したら、週末に古いボイスメール システムのすべてのユーザーを無効にし、ユーザーの電話を Exchange ユニファイド メッセージングに転送します。これで、月曜日の朝には組織内のすべてのユーザーが新システムを使用できるようになります。

カットオーバーを実施する

1 つのサイトをサポートする場合でも、大規模な複数のサイトを所有する組織をサポートする場合でも、この記事の情報は役立つと思います。複数のサイトを所有する組織では、設計がより複雑になる可能性はありますが、ユーザーの数が 50 人であっても 5,000 人であっても、基本的な要件は変わりません。

ユニファイド メッセージング ソリューションの展開時には、IT チームと通信チームが協力し合うことが非常に重要です。私の経験では、ユニファイド メッセージング プロジェクトを脱線させかねないことの中でも、IT チームと通信チームとの間の不和や、ソリューションに関する意見の不一致が発生した場合、展開が失敗する可能性があります。テクノロジの集中化はそれほど難しくありませんが、IT と通信の両方を理解し、両チームをまとめたり、プロジェクトの展開を成功に導く計画の作成をサポートしたりできる社外の協力者が必要になる場合もあります。

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

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