MAPI over HTTP による Outlook の接続


(この記事は 2014 年 5 月 9 日に The Exchange Team Blog に投稿された記事 Outlook Connectivity with MAPI over HTTP の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

Exchange 2013 SP1 では多数の新機能が導入されましたが、その中の 1 つに、MAPI over HTTP (略称: MAPI/HTTP) と呼ばれる Outlook との接続メソッドがあります。この新しい接続メソッドには、ユーザーの皆様から多くの関心が寄せられています。今回の記事では、この機能の詳細な内容、この機能で何ができるのか、また将来の展望について説明します。さらに、お客様のユーザーの皆様にこの機能をお使いいただくために、導入方法や導入環境についてのヒントをご紹介します。

MAPI over HTTP の概要

MAPI over HTTP とは、Outlook と Exchange の接続に使用される新しい転送方式です。この MAPI/HTTP は、Exchange 2013 SP1 および Outlook 2013 SP1 で最初に導入され、Office 365 でも 5 月から段階的に導入が進められています。これは RPC over HTTP 接続 (Outlook Anywhere として知られている接続) を長期的に置き換えるもので、MAPI/HTTP の導入により、Outlook Anywhere が古い RPC テクノロジに依存しているために発生する複雑さが排除されます。その構造を比較してみましょう。

image

image

MAPI/HTTP により、接続が、本来の HTTP の要求/応答パターンに移行され、Outlook と Exchange の間のセッションごとに、持続期間の長い TCP 接続を 2 つ開く必要がなくなります。これまでは、各 RPC/HTTP セッションで RPC_DATA_IN と RPC_DATA_OUT の 2 つの接続が必要でしたが、MAPI/HTTP では不要となり、クライアントとサーバーの間で同時に確立される TCP 接続の数が少なくなります。MAPI/HTTP では、持続期間の長い接続 1 つと、オンデマンドで持続期間の短い接続を 1 つ、同時に最大で 2 つの接続を確立します。

Outlook Anywhere では、Exchange との接続をすべて 2 重にラッピングする必要があり、いっそう複雑になっていました。MAPI/HTTP では、ネットワークの任意の場所に送信される HTTP パケットの中で RPC をカプセル化する必要がありません。そのため、MAPI/HTTP はしくみが理解しやすくなり、HTTP のペイロードも予測可能になりました。

他に、ネットワーク レベルの変更点として、MAPI/HTTP ではクライアント/サーバー セッションが、基盤となるネットワーク接続から切り離されているということが挙げられます。Outlook Anywhere 接続では、クライアントとサーバー間のネットワーク接続が切断されるとセッションは無効となり、すべて再接続する必要があったため、時間と費用の無駄となっていました。MAPI/HTTP では、ネットワーク接続が切断されてもセッション自体は 15 分間リセットされないので、クライアントは再接続するだけで、ネットワーク レベルの障害が発生した直前の状態から継続することができます。これは、低品質のネットワークから接続している場合に非常に便利です。さらに従来は、サーバー側の予想外の一時的なネットワーク異常が発生すると、すべてのクライアント セッションが無効になり、その後メールボックス サーバーへの再接続要求が急増していました。再接続を要求する Outlook クライアントの数によっては、RPC/HTTP 接続の再確立のためにメールボックス サーバーのリソースに大きな負荷がかかる場合があり、1 か所で発生したサーバー側のネットワーク異常による障害が他の場所 (複数のサーバーに接続している Outlook クライアント) にも波及したり、障害の復旧が遅れたりすることがありました。

MAPI over HTTP のメリット

既によく知られていて広く使用されている従来のしくみがまったく新しいものに変更された理由について、疑問をお持ちの方もいらっしゃるかも知れません。それについてご説明します。

元々、Outlook Anywhere アーキテクチャは、幅広い種類のネットワークからクライアント接続が確立されるという現在の状況を想定して設計したものではありませんでした。Outlook Anywhere の設計時点では、携帯電話ネットワークやホーム ネットワーク、飛行機の無線ネットワークなどの、低速で信頼性の低いネットワークからの接続は、考慮されていなかったのです。接続に対する現在のニーズに対応し、また Exchange の進化を促進するための最良の方法として、チームは、簡潔なアーキテクチャを新たに構築することから始めました。

MAPI/HTTP の主要な目標は、Exchange への接続を迅速化して、あらゆる種類の接続でユーザー エクスペリエンスを向上させることです。これにより、ユーザーへのメールの配信も早くなります。さらに、MAPI/HTTP では、転送中にネットワークでパケットの損失が発生した場合の接続の回復性が向上します。お客様のユーザーに提供される今回の改良点のうち、いくつかを数値で表してみましょう。これらの数値は、マイクロソフトが社内で実施したユーザー テストで得られた結果です。

Outlook の起動時に、“Connecting to Outlook” というメッセージが Outlook のステータス バーで表示されます。MAPI/HTTP では、ユーザーがこの接続を待機する時間が短縮されています。モニタリング対象のクライアントで、Outlook の初回起動時に同期を開始するまで、Outlook Anywhere では 90 秒を要していましたが、これが 70% 短縮され、30 秒になりました。

クライアントが休止状態から再開される場合、または新しいネットワークに再接続される場合についても、機能が強化されています。テストでは、休止状態からの再開時に、MAPI/HTTP を使用しているクライアントのうち 80% が 30 秒以内に同期処理を開始しました。一方、Outlook Anywhere のクライアントでは 40 秒以上を要しました。このような改善が見られたのは、MAPI/HTTP が一時停止/再開機能を実装していることにより、クライアントが毎回新しく接続をネゴシエートせずに、既存の接続を使用して再開できるからです。現行では MAPI/HTTP のセッションは 15 分間有効ですが、マイクロソフトでは、さらに微調整を行って時間を延長し、この機能をさらに強化する予定です。

実施された機能強化は、エンド ユーザー向けのものだけではありません。IT 管理者にとっては、プロトコルの可視性が向上し、問題の識別や修正をより早く、確実に行えるようになりました。MAPI/HTTP がより一般的な HTTP プロトコルのペイロードに移行したため、HTTP のデバッグで一般的に使われているお馴染みのツールを使用することが可能です。また、IIS と HttpProxy のログに、HTTP をベースとする他のプロトコル (Outlook Web App など) と同様の情報が含まれるようになったほか、ヘッダーで情報を渡すことができるようになりました。これまでは、RPC/HTTP 特有のデバッグ手順は、マイクロソフトの自社製内部ツールでのみ使用可能でしたが、今回の移行により、すべてのお客様に、同じ水準でデバッグ用ツールを使用していただけます。

また、MAPI/HTTP が Outlook を自動検出する機能からの応答が大幅に簡素化されました。この応答に含まれる設定は、プロトコルのバージョンと、お客様の企業ネットワークの内外から Exchange のメールボックスとディレクトリに接続する際に使用する Outlook のエンドポイントの URL のみとなっています。Outlook はこの返された URL をあいまいな URL としてそのまま扱い、その後エンドポイントが変更された場合に接続が切断される可能性を最小化しています。MAPI/HTTP では、他の Web プロトコルと同様に匿名の HTTP 要求を Exchange に送信して認証設定を取得するので、自動検出を行ってこの認証設定を提供する必要がありません。これにより、Outlook の認証設定の変更を展開することが容易になっています。

将来の展望

MAPI/HTTP により、Exchange 製品の革新がますます加速していきます。ユーザーの要求に応えられるほどの進化が見込めない RPC テクノロジへの依存を排除することにより、アーキテクチャが簡素化され、さらに接続機能の拡張にもつながります。Outlook のロードマップでは、Office 365 での多要素認証の実現が予定されています。この機能は MAPI/HTTP の使用によって実現され、今年中の導入を目標としています。これらの機能についての詳細は、最近投稿された Office 365 の多要素認証に関するブログ記事をご覧ください。これは Office 365 MFA だけにとどまらず、サード パーティの ID プロバイダーへも拡張される予定です。

MAPI/HTTP のしくみ

MAPI/HTTP が有効になっている状態で Outlook 2013 SP1 のクライアントが Exchange Server 2013 SP1 に接続する場合を例に挙げて説明します。

  1. Outlook クライアントが自動検出機能の POST 要求で処理を開始します。この要求には、Outlook によって、当該クライアントで MAPI/HTTP が有効であることを示す、X-MapiHTTPCapability = 1 という新しい属性が含まれています。
  2. Exchange サーバーは、MAPI/HTTP が有効なクライアントから要求が届いたことを察知し、その MAPI/HTTP 情報を使用して応答します。これには、MAPI/HTTP を使用してメールボックスに接続する方法を指定する設定などが含まれます。このとき、当該サーバーでは、MAPI/HTTP の構成および使用準備が完了しているものとします。
  3. Outlook クライアントは新しい接続経路を検出し、Outlook を再起動して新しい接続を使用するように促します。再起動されるまでは、Outlook は引き続き Outlook Anywhere を使用します。マイクロソフトは、お客様が最新版の Office クライアントの更新を展開して、最良のユーザー エクスペリエンスをご利用になることをお勧めします。それにより、メッセージは表示されなくなり、次回以降、メッセージの表示なしに、Outlook が再起動され、接続が移行されます。
  4. 再起動後は、Outlook と Exchange の通信に MAPI/HTTP が使用されます。

要件

ここまでで、お客様がユーザーに提供可能なメリットについて明確にご理解いただけたかと思います。ここからは、MAPI/HTTP を使用するための要件について説明します。

サーバーの要件: MAPI/HTTP を使用する場合、Exchange 2013 のクライアント アクセス サーバーをすべて Exchange Server 2013 SP1 (またはそれ以降) に更新する必要があります。この機能は SP1 では既定で無効になっているため、サーバーを更新しても各ユーザーは変更を意識することはありません。Office 365 Exchange Online ユーザーの場合は、サービス側の展開について心配する必要はありません。

クライアントの要件: MAPI/HTTP を使用するには、Outlook クライアントを更新する必要があります。Office 2013 SP1 または Office 365 ProPlus の 2 月の更新 (ProPlus では SP1 と同等) が MAPI/HTTP を使用するための要件となっています。ユーザーが MAPI/HTTP を使用できるようになった場合に再起動を求めるメッセージが表示されないように、Office 2013 の 5 月のパブリック版の更新、または Office 365 ProPlus の 4 月の更新を展開することを推奨します。

Outlook 2010 は 2015 年 1 月の更新以降 MAPI/HTTP をサポートしています。また、2015 年 4 月の更新にて追加の修正がリリースされておりますので、こちらのインストールを推奨いたします。

使用準備

準備作業として、最初に、前項で説明したようにサーバーとクライアントに必要な更新を適用します。その次に、MAPI/HTTP がお客様のオンプレミスのサーバーにどのような影響を及ぼす可能性があるかを評価します。繰り返しになりますが、Office 365 ユーザーの場合は、この心配は不要です。

MAPI/HTTP を企業で実装した場合、Exchange サーバーのリソースに影響を及ぼします。先の手順に進む前に、お客様のサーバー リソースに対する影響を確認する必要があります。Exchange 2013 Server Role Requirements Calculator (英語) が、MAPI/HTTP を使用した場合の要素に対応するように更新されています。次の手順に進む前に、このツールの最新バージョン (v6.3 またはそれ以降) を使用して確認してください。MAPI/HTTP では、Exchange のクライアント アクセス サーバーの CPU 負荷が増大します。増大幅は Exchange 2013 RTM と比較して 50% 程度ですが、Exchange 2010 の要件よりは低く抑えられています。計画策定時には、マルチロール構成で展開すると、お客様のサイズへの影響を最小限に抑えられることに留意してください。繰り返しますが、上記のツールを使用して、お客様の環境に対してどのような影響が出る可能性があるかを確認してください。この CPU 負荷の増大の理由は、いくつかの持続期間の短い接続で要求レートが高くなり、その各要求で認証とプロキシ転送を処理する必要があるためです。

MAPI/HTTP のパフォーマンスを最高の状態で発揮させるには、Exchange 2013 サーバーに .NET 4.5.1 をインストールする必要があります。.NET 4.5.1 をインストールすると、要求がキューで待機するのを回避するために通知チャネルを非同期のまま確保するよう修正されているため、ユーザーが長時間待機させられる事態を回避できます。

Exchange と Outlook の間での通信方式の変更による転送量への実際の影響は、大きくありません。転送量の増加の原因は、MAPI/HTTP のヘッダーのコンテンツによるものです。通常のメッセージの通信では、Outlook Anywhere で平均 50 KB のパケットの場合、パケット サイズが平均で 1.2% 増加していることが確認されました。また、10 MB を超えるデータ転送では、実際の転送量は 5 ~ 10% 増加します。ただし、この増加量は接続の切断や再開がない理想的なネットワークを想定した場合であり、実際には、MAPI/HTTP でデータを転送した場合に、Outlook Anywhere よりも転送量が少なくなる場合もあります。Outlook Anywhere には接続を再開する機能がありません。そのため、アイテムの再同期を実行すると、その際の転送量は MAPI/HTTP のヘッダー情報の増加分をすぐに上回る可能性があります。

MAPI/HTTP の展開

ここまでで、サーバーに SP1 を適用し、クライアントを更新し、予期されるサイズへの影響の確認も終了し、MAPI/HTTP を実装する準備が完了しました。MAPI/HTTP は SP1 の既定では無効になっているので、明示的に構成して有効にする必要があります。この手順の詳細は、TechNet の記事「MAPI over HTTP」を参照してください。

展開に際して、次の項目が重要となります。

  • 名前空間: MAPI/HTTP は CAS の新しいエンドポイントであり、内部の名前空間と外部の名前空間の両方を使用できます。名前空間の設計を適切に行うための詳細情報は、「Exchange 2013 での名前空間の計画」および「Exchange 2013 での負荷分散」を参照してください。
  • 証明書: Exchange で使用される証明書では、内部と外部の両方の MAPI/HTTP 仮想ディレクトリを保持していないと、ユーザーに対して証明書を求めるメッセージが表示されます。このため、証明書に名前が存在しているかどうかを考慮します。計画の詳細については、証明書の計画に関するブログ記事をご覧ください。
  • MAPI/HTTP の構成: MAPI/HTTP を有効にするには、Exchange の構成を企業レベルで行う必要があります。サーバーのサブセット レベルでは、この構成は実施できません。クライアントの動作をより詳細に制御するには、レジストリ キーを使用する必要があります。
注: より詳細な制御が必要な場合、各クライアント マシンのレジストリ キーを使用して、クライアントの動作を制御することができます。この操作はオプションであり、使用は推奨しませんが、このレベルの制御が必要な場合は使用可能です。このレジストリのエントリでは、自動検出要求において Outlook が MAPI/HTTP 対応のフラグを Exchange に送信することを禁止します。クライアントでこのレジストリ キーを変更しても、次回クライアントが自動検出クエリを Exchange に対して実行するまでは、何も起こりません。

MAPI/HTTP を禁止すると、強制的に RPC/HTTP が使用されます。

HKEY_CURRENT_USER\Software\Microsoft\Exchange]
”MapiHttpDisabled” =dword:00000001

MAPI/HTTP を許可する場合、MapiHttpDisabled DWORD をただ削除するか、この値を次のように 0 に設定します。

HKEY_CURRENT_USER\Software\Microsoft\Exchange]
”MapiHttpDisabled” =dword:00000000
  • 接続性: 重要な考慮事項として、最後に、負荷分散、リバース プロキシ、ファイアウォールのそれぞれが MAPI/HTTP の仮想ディレクトリにアクセスできるように構成されているかどうかを検証することが挙げられます。現時点では、ForeFront Unified Access Gateway (UAG) 2010 SP4 は MAPI/HTTP との互換性はありません。UAG チームは、今後の更新で MAPI/HTTP をサポートするための取り組みを進めています。

動作の確認方法

構成が意図したとおりに動作しているかどうかを手早く確認する方法が、いくつかあります。

1. Test-OutlookConnectivity コマンドレットでテストする

下記のコマンドレットで MAPI/HTTP 接続のテストを行います。

Test-OutlookConnectivity -RunFromServerId Contoso -ProbeIdentity OutlookMapiHttpSelfTestProbe

このテストの詳細については、TechNet の記事「MAPI over HTTP」を参照してください。

2. MAPI/HTTP のサーバー ログを調査する

管理者は、次の MAPI/HTTP のログ ファイルを調べると、構成が動作する様子を確認できます。

場所

パス

CAS

%ExchangeInstallPath%Logging\HttpProxy\Mapi\HTTP

メールボックス

%ExchangeInstallPath%Logging\MAPI Client Access\

メールボックス

%ExchangeInstallPath%Logging\MAPI Address Book Service\

3. Outlook の接続状態をクライアントで確認する

クライアントが接続に MAPI/HTTP を使用しているかどうかを簡単に確認する方法は、他にもあります。通知エリアで Ctrl キーを押しながら Outlook アイコンを右クリックして [接続状態…] を選択し、[Outlook の接続状態] ダイアログを起動します。接続で MAPI/HTTP が使用されているかどうかをすばやく確認するには、次の主要なフィールドを確認します。

フィールド

Protocol

HTTP (Outlook Anywhere の場合は RPC/HTTP となります)

Proxy Server

Server name

実際のサーバー名 (Outlook Anywhere 接続では GUID となります)

image

まとめ

MAPI/HTTP では、転送処理が簡素化され、その結果 Outlook と Exchange の間のアーキテクチャも簡素化されています。また、ユーザー エクスペリエンスが改善され、メールへのアクセスが高速化されると共に Outlook 接続の回復性が向上しました。この取り組みは、Outlook への多要素認証機能の導入など、今後の機能の基礎となります。また、IT 担当者が標準的な HTTP プロトコルのツールを使用してクライアント接続に関する問題のサポートやトラブルシューティングを行ううえでも役に立ちます。

すべてが新しくなるため、実装に際しては適切に計画を策定する必要があります。展開を開始する前に、TechNet の展開ガイドの記事を参照し、最新の計算ツールでサイズの推奨事項を確認してください。これらを適切に利用すると、MAPI/HTTP の展開をスムーズに実施できます。

このブログ記事の執筆に際し、Brian Day と Abdel Bahgat の協力に感謝の意を表します。

Brian Shiers | テクニカル プロダクト マネージャー

 

 

MAPI/HTTP に関するよく寄せられる質問

マイクロソフトは、MAPI/HTTP の開発、内部テスト、およびお客様の TAP テスト (英語) の際に頻繁に寄せられた質問を、多数収集しました。これらの回答が、皆様の MAPI/HTTP に関する疑問の解決のお役に立ちますと幸いです。

MAPI/HTTP は、サーバー単位で有効/無効を設定できますか。

いいえ。この Exchange の設定は企業全体で一括して行います。あるサーバーが MAPI/HTTP に対応していない場合にデータベースのフェールオーバーの際に表示されるユーザー エクスペリエンスは、MAPI/HTTP の有効/無効を切り替えるソリューションとしては使用できません。

MAPI/HTTP は、メールボックス単位で有効/無効を設定できますか。

いいえ。現時点では、単一のメールボックスに対して、Set-CasMailbox パラメーターで MAPI/HTTP の有効/無効を設定することはできません。

レジストリ キーを更新してクライアントで MAPI/HTTP を無効にしたのですが、接続が変更されません。

このレジストリのエントリは、自動検出機能の要求の際に Outlook が Exchange に送る MAPI/HTTP の機能の制御のみを行います。Outlook が使用している接続方法が直接変更されることはなく、また Outlook を再起動するだけで変更されることもありません。自動検出機能の応答では、Outlook は MAPI/HTTP または RPC/HTTP の設定の取得のみを行い、両者の切り替えを直接行うことはできません。変更を適用する前に、レジストリのエントリを設定した後に Outlook が次回の自動検出要求を実行し、Exchange から応答を得るようにする必要があります。この手順を迅速に行うには、次の 2 つのオプションが利用できます。

  1. 必要に応じてレジストリのエントリを設定し、Outlook を終了して、Outlook のプロファイルを削除し、それから Outlook を再起動してプロファイル ウィザードを実行します。この場合、即座に切り替えが行われますが、Outlook のプロファイルに保存されていた設定はすべて失われます。
  2. 必要に応じてレジストリのエントリを設定し、Outlook を終了して、%LOCALAPPDATA%\Microsoft\Outlook フォルダーに隠しファイルとして格納されている、自動検出機能の応答の XML ファイルを削除して、Outlook を再起動します。
  3. さらにもう一度 Outlook を再起動すると、切り替えが完了します。

ユーザーのメールボックス データベースが MAPI/HTTP 対応のサーバーにマウントされていて、MAPI/HTTP 非対応のサーバーにデータベース フェールオーバーが発生した場合はどうなりますか。

たとえば、DAG 内に MAPI/HTTP 非対応のメールボックス サーバーもあり、企業内で MAPI/HTTP が既に有効化されていて、さらにメールボックスが SP1 (またはそれ以降) のサーバーから SP1 よりも前のバージョンのサーバーにフェールオーバーされた場合、または MAPI/HTTP 対応のメールボックス サーバーから MAPI/HTTP 非対応のサーバーにメールボックスを移動した場合などに、そのような状況が発生します。

上記の例では、メールボックスが SP1 よりも前のバージョンのサーバーにマウントされているので、MAPI/HTTP が有効な接続方法ではなくなります。このため、Outlook は接続に失敗し、次回の自動検出の実行時にユーザーに対して Outlook の再起動を要求するメッセージが表示されます。クライアントの再起動後、クライアントのプロファイルは RPC/HTTP を使用するように戻されます。

: MAPI/HTTP 対応/非対応の Exchange メールボックス サーバーが同一 DAG 内に混在する環境でも MAPI/HTTP を有効にできますが、上記のような事態が発生する可能性があるため、このような利用は推奨されません。企業で MAPI/HTTP を有効にする際には、その前に社内全体で SP1 またはそれ以降へのアップグレードを完了させることをお勧めします。

追加のメールボックスでまだ MAPI/HTTP が有効化されておらず、このメールボックスにユーザーがアクセスした場合はどうなりますか。

Outlook のプロファイルは、ユーザーがプライマリのメールボックスで MAPI/HTTP を使用していても、MAPI/HTTP 以外の接続方法で引き続き追加のリソースにアクセスできます。たとえば、ユーザーは MAPI/HTTP を使用していない他の Exchange サーバーにある従来のパブリック フォルダーや共有メールボックスに引き続きアクセスできます。自動検出処理の際に、Exchange はアクセス先の各リソースで必要となる適切な接続方法を決定し、Outlook に渡します。

MAPI/HTTP 接続が使用不能になった場合、クライアントは RPC/HTTP へのフォールバックを行いますか。

いいえ。元の自動検出機能の応答には、使用する接続方法は 1 種類しか記述されていないため、MAPI/HTTP 接続が使用不能になっても、ユーザーのプロファイルにより RPC/HTTP の使用が試行されることはありません。MAPI/HTTP から RPC/HTTP へ、またはその逆のフォールバックが実行されることはありません。通常の高可用性設計では、サーバーまたはサービスで障害が発生した場合でも MAPI/HTTP のエンドポイントへのアクセスが確保されるように考慮します。

MAPI/HTTP Exchange Web Services (EWS) に替わるものなのですか。

いいえ。MAPI/HTTP は EWS の代替ではありません。現行の EWS クライアントを MAPI/HTTP に移行する予定はありません。

RPC/HTTP は接続方法として使用できなくなるのですか。

将来的には、MAPI/HTTP 非対応のバージョンの Outlook が製品サポート ライフサイクルから除外され、使用できなくなる可能性があります。しかし、すぐに RPC/HTTP を有効な接続方法から除外する予定はありません。

MAPI/HTTP ではどのような認証メソッドがサポートされていますか。

MAPI/HTTP への移行による大きな構造的改良として、MAPI/HTTP が認証処理から隔離されている点が挙げられます。つまり、認証は HTTP 層で実行されるため、HTTP で実行可能なものはすべて MAPI/HTTP で使用できます。

MAPI/HTTP への移行が Lync クライアントに悪影響を及ぼす可能性はありますか。

いいえ。Lync クライアントは Outlook で構成されたものと同一のプロファイルを使用し、Outlook で使用される接続方法を使用して接続を確立します。

サード パーティのアプリケーションで MAPI/HTTP を使用するための SDK API はないのですか。

MAPI/HTTP プロトコルは公式にドキュメント化されていて (PDF (英語) をダウンロード)、RPC/HTTP と同レベルのドキュメントがサポートされています。MAPI/HTTP 用 MAPI CDO ライブラリを更新する予定はありません。また、サード パーティ企業は、Exchange と通信を行う際の長期的なプロトコルとして Exchange Web サービスを引き続き使用しています。詳細については、記事「Exchange 2013 のクライアント アクセス サーバーのロール (英語)」をご覧ください。

MAPI/HTTP のクライアントの要件を教えてください。

MAPI/HTTP を使用する際には、Office 2013 Service Pack 1 を適用済みの Outlook 2013 クライアントか、2 月の更新を適用済みの Office 365 ProPlus クライアントを使用する必要があります。Outlook 2010 につきましては、2015 年 1 月の更新以降 MAPI/HTTP をサポートしています。また、2015 年 4 月の更新にて追加の修正がリリースされておりますので、こちらのインストールを推奨いたします。

今回の変更は、Exchange 2013 ARRWAPTMGUAGB2MABCBBD などで発行する場合にどのような影響がありますか。

MAPI/HTTP を使用して Exchange 2013 を発行する場合も、それほど大きくは変わりません。CAS へのユーザー アクセスを処理する Exchange の前のデバイスが、Default Web Site/mapi/ という仮想ディレクトリへのアクセスを許可するように設定する必要があります。

image

現時点では、すべてのフィルタリング オプションを無効にしても、UAG SP3 と MAPI/HTTP との互換性はありません。今後の更新で UAG に MAPI/HTTP のサポートが追加される予定です。

詳細情報

さらに詳細な情報をお求めの方は、この話題に関する Microsoft Exchange Conference 2014 の下記のセッションをご覧ください。

Outlook の接続: 現在と今後 (英語)

Outlook 2013 の新機能と今後 (英語)

Outlook 2013 の認証に関する新機能 (英語)

Skip to main content