Exchange Online でやってはいけない 10 のこと

以前、Outlook でやってはいけない 10 のことという記事で Outlook を使用するうえで問題が発生しうる使用方法について説明しましたが、Exchange Online 環境ではクラウド サービスという性質上、オンプレでは問題なかったものの、クラウドでは注意が必要な使い方というものがあります。
今回はそのような使い方などについて説明します。

1. オンライン モードで使用する

クライアント端末の紛失や盗難に備え、クライアント上に情報を保持させないようキャッシュ モードではなくオンライン モードで Outlook を使用するというのはよくある使い方です。
しかし、Exchange Online ではキャッシュ モードが強く推奨されています。
これは、インターネットの通信遅延によるものです。
Exchange Online への接続にはインターネットが使用されるため、クライアントからサーバーへのアクセスは複数のルーターやネットワークを経由する場合があります。
そして、経由するルーターやネットワークが多くなればなるほど、少しずつパケットの遅延が累積していき、クライアントからのリクエストに対するサーバーの応答が遅くなることになります。
オンライン モードで使用している場合、アイテムの一覧表示やアイテムの表示、変更など、Outlook のほとんどすべての操作でサーバーとの通信が発生するため、それらがすべて遅くなる可能性があり、ネットワークによっては使用に耐えられない状況となる場合があります。
残念ながら、インターネットの通信遅延については改善する方法はほとんどないため、オンライン モードでパフォーマンスを改善する方法はないといってよいでしょう。
どうしてもクライアントにデータを置くことができないのであれば、Outlook をオンライン モードで使用するより Outlook on the Web (OotW) を使ったほうが良いかもしれません。

2. 最新でないバージョンで使用する

延長サポートに入っているものも含めて、現在サポートされている Office のバージョンは 2007、2010、2013、2016 とあります。
そして、現時点では Exchange Online には、現在サポートされているすべての Outlook のバージョンで接続できることが可能です。
しかし、この状況はいつまでも続くものではありません。
Outlook 2007 のサポートが終了を迎える 2017 年 10 月に、Exchange Online で RPC/HTTP での接続が終了します。
RPC/HTTP とは Exchange Online に接続するための方法のひとつで、現在は RPC/HTTP という方法と MAPI/HTTP という方法の 2 つがサポートされているのですが、2017 年 10 月 31 日に RPC/HTTP が廃止され、MAPI/HTTP に一本化されるのです。

ここで問題となるのは Outlook 2007 です。
Outlook 2010 以降では修正プログラムの適用などで MAPI/HTTP が使用可能となっていますが、Outlook 2007 には MAPI/HTTP を使用する方法が用意されていません。
そのため、10 月 31 日以降は Outlook 2007 で Exchange Online に接続することができなくなるということになります (メールの送受信だけで使うなら POP や IMAP で接続することは可能です)。

これまでは、サポートが終了するといっても自己責任で使用し続けるということはできましたが、RPC/HTTP の廃止は実質的にバージョンアップが強制されるものであり、相当のインパクトがあると考えられます。
今後も、古いバージョンで発生する問題が修正されなかったり、新しい機能が使用できないなどの不都合は出てくると考えられます。
Office 365 に限らず、クラウド環境は常に進化し続けることがメリットの一つであるため、そのメリットを享受する意味でも、最新のバージョンを使用したほうが良いでしょう。
もし、社内の都合などで特定のバージョンを使用し続けなければならないという制約があるなら、クラウドへの移行は見送ったほうが良いかもしれません。

3. Outlook の最新バージョンと他の Office 製品の古いバージョンを混在させる

上記にも関連することですが、Exchange Online への接続要件を満たすために、Office 全体のバージョン アップはせず、Outlook だけのバージョン アップを検討される方もいるようです。
しかし、Outlook と他の Office のバージョンが異なる場合、製品の連携などに制限が出ます。
例えば、Outlook と同じバージョンの Word がインストールされていない場合、Outlook のメール編集の際に Word を使用する一部の機能が使用できません。
また、Office ファイルの添付ファイル プレビューなども使用できません。
バージョン アップできない理由は様々あると思いますが、いずれはバージョン アップが必要になるのは確実であり、先送りすればそれだけ問題が増えていくと考えたほうが良いでしょう。

4. 参照権限以上で予定表を共有する

他のユーザーの予定を把握するため、予定表をグループなどで共有するというのはよくある使い方です。
しかし、参照権限以上で予定表を共有すると Exchange Online 特有の壁にぶつかる場合があります。
Outlook でほかのユーザーの予定表を開く場合、その予定表にアクセスするための個別の TCP セッションが必要となります。
問題はキャッシュ モードで [共有フォルダーをダウンロード] がオンになっている場合です。
この設定をしていると、Outlook は一度開いたほかのユーザーの予定表についても OST にキャッシュするのですが、このキャッシュ情報を常に最新にするために、Outlook の起動直後から TCP セッションを確立する動作となります。
そのため、例えば 30 個の予定表フォルダーを開いた場合、その後は常に 30 (RPC/HTTP の場合は 60) の TCP セッションを確立し、Outlook が終了するまでセッションを張り続けます。
これによりプロキシや NAT の TCP セッションが不足するという問題が生じる可能性があるのです。
これを回避するには [共有フォルダーをダウンロード] をオフにするというものが考えられますが、この設定にするとほかのユーザーの予定表表示が遅くなったり、多数のユーザーの予定表を表示する際に Outlook がハングアップする場合があります。
そのため、基本的には予定表の共有は [空き時間情報、件名、場所] という権限で行ったほうが良いでしょう。
この権限の場合、予定表フォルダーへのアクセスには個別の TCP セッションが不要となり、サーバーから一括で複数ユーザーの最新の情報を取得することが可能です。

5. オンプレと Exchange Online で同じ SMTP アドレスのメールボックスを並行運用する

オンプレから Exchange Online への移行にあたって、問題発生時の切り戻しを考えて、オンプレと Exchange Online の両方にメールボックスを用意して段階的に移行しようと考える方がいるようです。
結論から言うと、大体はうまくいきません。
まず、オンプレから Exchange Online への切り替えで、AutoDiscover の振り先だけ変えればクライアントの移行が完了する、と期待していると大幅に裏切られます。
Outlook の OST にはメールボックスの GUID というものが保持されており、この GUID は同じ SMTP アドレスを使っても全く違ったものが設定されます。
そして、Outlook は接続したメールボックスの GUID が OST に保存されている GUID と異なる場合、「一時メールボックスに接続した」と判断します。
その結果、以下のようなダイアログが表示されます。

「メールボックスは、一時的に Microsoft Exchange サーバーで移動されています。一時メールボックスは存在しますが、以前のデータの一部が含まれていない可能性があります。

一時メールボックスに接続するか、以前のデータをすべて使用してオフラインで作業することができます。以前のデータを使用する場合は、電子メール メッセージの送受信はできません。」

このメッセージの通り、この状態になるとオフラインで移行前のメールボックスのメールを参照するか、オンライン モードで Exchange Online のメールボックスにアクセスするかの二択になり、移行前のメールを自動的に Exchange Online に移動する、というようなこともできません。
さらに問題なのは、プロファイルがこの状態になると起動時に必ず上記のメッセージが表示されるようになり、AutoDiscover の振り先をオンプレに戻しても解消できないという点です。
これを解消するにはプロファイルの再作成しか方法はありません。

また、プロファイルの作り直しをするつもりでも、うまく AutoDiscover を制御できなければ想定外の情報を取得して上記の一時メールボックスの状態になる可能性があるので、「Exchange Online 移行のパフォーマンスとベスト プラクティス」にあるような方法での移行をお勧めします。

6. インターネット接続の帯域幅を増やさずに移行する

オンプレミスで Exchange サーバーを運用していたものを Exchange Online に移行する場合、インターネットへのトラフィックは増えることが予想されます。
ただ、どの程度増えるのかという予測は非常に難しいものです。
単純なメールの送受信量だけでなく、予定表などの共有状況などにより、トラフィックが大幅に増える可能性もあります。
そのため、現在のインターネット接続の帯域幅の使用量がすでに飽和状態に近いのであれば、帯域幅を増やす必要があるでしょう。
帯域幅の増やさずに、Exchange Online へのトラフィックを制限しようとしても、効果的な方法は実際のところありません。
なぜなら、そもそも無駄なトラフィックを発生させるような設計にはなっていないためです。
現時点で帯域幅に多少の余裕があっても、使用状況によってはすぐにひっ迫する可能性もあるので、インターネット接続の増速がどのくらいの期間と費用でできるのかを、移行前にあらかじめ見積もっておくと安心です。
もし、増速が難しいような状況なのであれば、Exchange Online への移行は見送ったほうが良いかもしれません。

7. 自社で IT インフラの要員を確保しない

クラウド サービスへの接続で問題が発生する場合、原因としては大きく分けて以下のようなものが考えられます。

    1) クラウド サービスのサイト内のサーバーやネットワークの問題
    2) クラウド サービスと自社ネットワークの間のインターネットの問題
    3) 自社ネットワーク内のルーターやプロキシなどネットワークの問題
    4) クライアントの問題

このうち、クラウド サービスのサポートに問い合わせて対応してもらえるのは、1) と 4) です (サービスによっては 1)  だけの場合もあります)。
しかし、2) や 3) についてはクラウド サービスが用意するものではないため、サポートの対応には限界があります。
クラウドにしてしまえば自社の IT 要員が不要、と勘違いしていると、いざ 2) や 3) で問題が生じたときに、誰も対応できないという事態に陥ります。
そのため、クラウド サービスを使う場合でも、自社の IT インフラをサポートできる要員を確保するべきです。

8. Outlook から IMAP で接続する

Outlook には IMAP でサーバーに接続する機能があります。
また、Exchange Online には IMAP でクライアントからの接続を受ける機能があります。
したがって、Outlook から Exchange Online に IMAP で接続することは技術的には可能であり、サポート対象外ということもありません。
そのため、以下のような理由で Exchange Online に IMAP で Outlook から接続することを検討される方もいるようです。

• 古いバージョンの Outlook で接続したい
• オンプレや別サービスと同じ SMTP アドレスを使いたい

ただ、本来は Outlook や Exchange Online の IMAP 機能はサードパーティ製のメール サーバー/クライアントと接続するためのものであるため、IMAP を使用した場合には Exchange や Outlook 固有の機能が使えず、メリットがほとんどありません。
また、このような使い方はレアなケースであるため、想定外の不具合に遭遇する可能性が高いと考えられます。
したがって、IMAP で接続するくらいなら、OotW を使ったほうがより Exchange Online のメリットを享受できるといえます。

9. 原因追及を要求する

クラウド サービスではオンプレとは比べ物にならない台数のサーバーが常時稼働しています。
そして、一定の割合でハードディスクやネットワーク機器の物理的な故障などが発生することが想定されます。
そのため、語弊を恐れず言えば、クラウド サービスでは常に何らかのトラブルが生じていると考えられます。
もちろん、そのようなハードウェアの障害が発生しても、ユーザーに影響を与えないような構成となっているわけですが、それでも予期せぬトラブルというものは発生するものです。
オンプレ環境の場合、サーバーのダウンや障害などが発生した際には、原因追及や再発防止などの対策をとると思いますが、クラウドで同じレベルの原因追及や再発防止策の要求は極めて困難です。
というのも、車に例えるなら、オンプレは自家用車のようなものであり、クラウドというのは乗り合いバスのようなものだからです。

オンプレ環境は、ハードウェアは自前で持つことにより、トラブル発生時の対応や調査も自分で行う必要があります (SIer にすべて任せるという手もありますが)。
その代わり、いつまでも古いバージョンを使い続けたり、特殊な使い方をすることもできます。

一方、クラウド環境は多数のユーザーとハードウェアやソフトウェアを共有するものであり、基本的には自動的に最新のバージョンに更新され、使用方法の自由度はオンプレと比べて制限があります。
その代わり、メンテナンスはクラウド サービスに任せることができます。

したがって、クラウド サービスを使うに当たっては、サービス提供者を信頼し、トラブルが生じても原因追及や再発防止も含めて一任することにしてしまうのが良いと思います。
トラブルのたびに原因追及や再発防止策が提示されなければ不安ということは、いわば信頼できないクラウド サービスを使用しているということなので、そのようなサービスに自社のデータを預けるべきではないでしょう。

10. エンド ユーザーの要求をすべて実現しようとする

前述の通り、クラウド サービスではオンプレに比べて設定や拡張性に制限があり、エンド ユーザーの要求をすべて実現しようとすると、様々な障害に遭遇する可能性があります。
例えばメールの送受信数制限のようなサービス全体に影響を与えうるものについては、クラウドとオンプレでは設定できる範囲が異なり、たとえ一時的であっても、その制限を超えるような方法は用意されていません。
そのような状況で要求を実現しようとしても、特別対応される可能性はほとんどないでしょう。
また、クラウド サービスではある日突然 (実際には事前にアナウンスされていることがほとんどなのですが) 新機能がリリースされ、メニューが追加されたり、反対に機能が削除されたりする場合があります。
それについて機能を増やしたくないとか、削除されると困るというようなことを言っても、対応される可能性は低いといえます。
したがって、クラウド サービスを使うに当たっては、エンド ユーザーの様々な要求 (ローカルにデータを置きたくない、バージョンアップしたくない、全員の予定表の詳細を見たいなど) をすべて実現しようとせず、基本的にあるがままを受け入れるというスタンスで使うほうが良いでしょう。
もし、エンドユーザーを説得する自信がないのであれば、クラウドへの移行は見送ったほうが良いかもしれません。

まとめ

Exchange Online について、様々な制限を書いてしまったため、クラウドよりオンプレのほうが良いと思われる方もいるかもしれません。
しかし、オンプレでは使用できない最新の機能が Exchange Online なら使用可能であり、サーバーのメンテナンスからも解放されるという大きなメリットがあります。
いずれにせよ、クラウドとオンプレで全く同じ運用や使い方はできないと認識し、クラウドの特性を生かした使い方をすることで、より安定して快適な運用ができるようになるでしょう。