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 なら使用可能であり、サーバーのメンテナンスからも解放されるという大きなメリットがあります。
いずれにせよ、クラウドとオンプレで全く同じ運用や使い方はできないと認識し、クラウドの特性を生かした使い方をすることで、より安定して快適な運用ができるようになるでしょう。

Outlook の「既定のフォルダー」の名前を変更する

コメントにて以下のご要望をいただきました。


Windows8.1 Outlook2013にて、ぷららへIMAP接続でメールを使用しています。
Outlook2010までは下記ページのSTEP 12図のように「送信済みアイテム」と「Sent」フォルダが重複して作成されても、STEP 16図のようにインターネット電子メール設定で指定すれば問題なかったのですが、Outlook2013のにはインターネット電子メール設定に、この「送信済みアイテム」と「削除済みアイテム」タブがありません。また「送信済みアイテム – Sent」と「削除済みアイテム – Trash」ペアの他に、「迷惑メール – Junk」も重複してフォルダが作成されてしまいます。これら重複して作成されてしまうIMAPフォルダをマクロで一致させることは出来ないでしょうか?可能でしたら、ぜひともお願い致します。

Outlook 2010 新規設定方法(IMAP)
http://support.eonet.jp/setup/mail/imap/win/ol2010_setup_imap.html



残念ながら、Outlook では既定で作成される「受信トレイ」や「送信済みアイテム」、「削除済みアイテム」のようなフォルダーは「既定のフォルダー」という特別なフォルダーとして扱われており、このフォルダーをマクロで別のフォルダーに変更したり、フォルダーの名前を変えたりというようなことはできません。
また、「既定のフォルダー」については、Outlook がこれらのフォルダーを作成した際に、そのフォルダーのエントリ ID を PST やメールボックスのプロパティとして保存しており、この情報を変更することもマクロではできません。

しかし、MFCMAPI というツールを使うと、既定のフォルダーであっても名前を変更することが可能です。
今回のように IMAP サーバーと重複するフォルダーに名前を変更する場合の手順は以下の通りになります。

  1. http://mfcmapi.codeplex.com にアクセスし、画面右の [download] ボタンをクリックして zip ファイルをダウンロードします。
  2. ダウンロードした zip ファイルを展開し、MFCMAPI.EXE を取り出します。
  3. MFCMAPI.EXE を実行します。
  4. 起動画面で [OK] をクリックします。
  5. [Session] メニューの [Logon…] をクリックします。
  6. [プロファイルの選択] ウィンドウで IMAP 接続のプロファイルを選択し、[OK] をクリックします。
  7. [Display Name] が電子メール アドレスとなっているエントリをダブルクリックします。
  8. [ルート – メールボックス]-[IPM_SUBTREE] と展開します。
  9. [IPM_SUBTREE] の下の [Sent] をクリックし、2 秒ほど待ってから再度クリックします。
    すると、Sent が反転し、文字入力状態となります。
  10. ”Sent.bak” と入力し、Enter キーを押します。
  11. [IPM_SUBTREE] の下の [送信済みアイテム] をクリックし、2 秒ほど待ってから再度クリックします。
  12. ”Sent” と入力し、Enter キーを押します。

これにより、Outlook の既定の「送信済みアイテム」フォルダーの名前が、IMAP サーバーと同じ「Sent」に変更されます。
IMAP 接続ではフォルダーは名前でのみ識別されるので、このように設定した後で Outlook を起動すると、サーバー上の「Sent」フォルダーのメールが Outlook で既定の送信済みアイテム フォルダーとして認識されている「Sent」フォルダーにダウンロードされるようになります。

「削除済みアイテム – Trash」や「迷惑メール – Junk」についても上記と同様に名前を変更することで、重複を解消することができるでしょう。
なお、.bak を付けた元のフォルダーについては、同期が正しくできていることを確認した後で削除しても構いません。

Exchange 環境における電子メール アドレス = LegacyExchangeDN

一般に、電子メールアドレスというと、"xxxx@example.com" のような SMTP アドレスを意味します。
しかし、Exchange 環境の Outlook においては、以下のようなフォーマットの文字列がメールアドレスとなります。

  /o=組織名/ou=管理グループ/cn=Recipients/cn=名前またはエイリアス

これは Active Directory では LegacyExchangeDN という属性で保持されているもので、X.500 という形式のアドレス文字列となります。
なぜ SMTP アドレスではなく、このような文字列がアドレス文字列として使用されているかについては、Exchange の歴史的な背景に理由があります。

Exchange Server の最初のバージョンは 4.0 であり、このバージョンで Exchange サーバーでのメールの送受信は X.400 という規約に基づいて行われていました。
X.400 とは、ITU-T (International Telecommunication Union Telecommunication Standardization Sector) という標準化団体で策定された電子メールについての標準であり、Exchange サーバーはその時点でのオープンな標準に適合するよう X.400 をベースとしたものとなっていました。
また、アドレス帳などをつかさどるディレクトリ サービスについても同様に標準規格である X.500 をベースとしたものとなっており、この規約の文字列が Outlook においては Exchange サーバーの受信者の電子メールアドレスとして使用されていました。
さらに、このバージョンではインターネットのメールはオプション扱いであり、SMTP アドレスを持たない Exchange 受信者が存在する状態でもありました。

やがて、インターネットの普及とともに SMTP が世界的な電子メールの標準になると、Exchange Server も 2003 から SMTP をベースとしてメールの送受信を行うようになりましたが、互換性のため X.500 形式のアドレスは現在でも Outlook での Exchange 受信者のアドレスとして使用されています。名前こそ LegacyExchangeDN ですが、現役で使用されているアドレスなのです。

したがって、Exchange 環境下では LegacyExchangeDN をむやみに変更したり、再利用をしてはいけません。
たとえば、UserA と UserB が同じ LegacyExchangeDN を持っていた場合、Outlook から見るとこの 2 人のユーザーは同一アドレスとなります。そのため、UserA に送るつもりが UserB に送られるというような現象が発生する可能性があり、誤送信の原因になります。

[mailto リンクで UTF-8 を使う] と Outlook

Internet Explorer 7.0 以降には [mailto リンクで UTF-8 を使う] というオプションがあります。
この設定とメールクライアント、および mailto リンクの指定方法の組み合わせによっては、件名や本文で文字化けが発生します。
以下では IE7 の挙動がどのように変わるかと、その結果 Outlook をはじめとするマイクロソフトのメール クライアントでどのような動作が行われるかについてまとめました。

Internet Explorer 6.0 以前について

HTML 中に mailto が出現する場合、FORM で指定する場合と HREF で指定する場合があり、HREF で指定する場合はさらに全角文字を事前にエンコードする場合とそうでない場合があります。それぞれについての動作は以下の通りです。

1. フォームの ACTION を mailto: とし、Subject および Body をフォームのパラメータとして送信した場合

Subject や Body の DBCS は、HTML で指定されている文字コードで % エンコードされ、ShellExecuteA によりメールソフトに渡されます。
例えば、Shift-JIS で記述されたページのフォームで Subject を「日本語件名」、Body を「日本語本文」とすると、下記の文字列がメールソフトに渡されます。

  mailto:test@example.com?subject=%93%FA%96%7B%8C%EA%8C%8F%96%BC&body=%93%FA%96%7B%8C%EA%96%7B%95%B6

一方 UTF-8 で記述されたページのフォームで同様のパラメータを指定すると、下記の文字列がメールソフトに渡されます。

  mailto:test@example.com?subject=%E6%97%A5%E6%9C%AC%E8%AA%9E%E4%BB%B6%E5%90%8D&body=%E6%97%A5%E6%9C%AC%E8%AA%9E%E6%9C%AC%E6%96%87

2. HTML 中の HREF タグで mailto のリンクの Subject および Body の全角文字があらかじめ % エンコードされている場合

HTML で指定されている文字コードに関わらず、指定された文字列がそのままメールソフトに渡されます。
例えば、下記の文字列は全角文字を Shift-JIS のコードにより % エンコードしたものですが、UTF-8 が指定されている HTML にこのようなリンクがあっても、この文字列のままメールソフトに渡されます。

  mailto:test@example.com?subject=%93%FA%96%7B%8C%EA%8C%8F%96%BC&body=%93%FA%96%7B%8C%EA%96%7B%95%B6

3. HTML 中の HREF タグで mailto のリンクの Subject および Body に全角文字を指定した場合

HTML で指定されている文字コードのまま、ShellExecutteA によりメールソフトに渡されます。
例えば、Shift-JIS で記述されたページの mailto リンクで Subject を「日本語件名」、Body を「日本語本文」とすると、下記の文字列が Shift-JIS の文字列としてメール ソフトに渡されます。

  mailto:test@example.com?subject=日本語件名&body=日本語本文

一方、UTF-8 で記述されたページの mailto リンクで同様の文字列を指定した場合、上記の文字列がエンコードされず、UTF-8 のバイト文字列としてメールソフトに渡されます。

Internet Explorer 7.0 以降について

Internet Explorer 7.0 以降では [mailto リンクで UTF-8 を使う] の設定がありますが、これをオフにした場合は Internet Explorer 6.0 以前と同様の動作となります。
また、オンにした場合でも、上記の 1. および 2. の動作は変わりません。
そして、3. の HREF タグの mailto の Subject および Body に全角文字を指定した場合に、以下のような動作をします。

  1. 文字列を HTML で指定された文字コード (または自動認識されたページの文字コード) により Unicode に変換します。
  2. Unicode 文字列を UTF-8 とし、% エンコードを行います。

そのため、 Subject を「日本語件名」、Body を「日本語本文」とすると、HTML の文字コード指定に関わらず、下記の文字列がメールソフトに渡されます。

  mailto:test@example.com?subject=%E6%97%A5%E6%9C%AC%E8%AA%9E%E4%BB%B6%E5%90%8D&body=%E6%97%A5%E6%9C%AC%E8%AA%9E%E6%9C%AC%E6%96%87

Outlook 2010/2007 について

Outlook 2010/2007 は Internet Explorer の [mailto リンクで UTF-8 を使う] の設定により動作が変わります。Outlook 2010/2007 にも [ツール]-[オプション]-[メール形式]-[文字設定オプション] に [mailto: プロトコルで UTF-8 をサポートする] がありますが、どちらのオプションも設定されるレジストリは同じ HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Protocols\Mailto\UTF8Encoding になります。そのため、このオプションをオンにすると自動的に Internet Explorer の [mailto リンクで UTF-8 を使う] がオンになります。
[mailto リンクで UTF-8 を使う] がオンである場合、mailto のリンクは Internet Explorer で UTF-8 による % エンコードが行われていると仮定します。
そのため、指定された mailto の文字列については、% エンコードをデコードし、UTF-8 の文字列として取得します。
その結果、ShellExecute やショートカットを使い、Internet Explorer を経由せずに Subject や Body に Shift-JIS の全角文字を指定した場合、文字化けが発生します。
一方、[mailto リンクで UTF-8 を使う] がオフである場合、mailto のリンクは Windows の既定のコードページによりエンコードされていると仮定します。
そのため、指定された mailto の文字列については、% エンコードをデコードし、日本語環境では Shift-JIS の文字列として取得します。

Windows メールについて

Windows メールでは Internet Explorer の [mailto リンクで UTF-8 を使う] の設定によって動作が変わることはありません。
mailto リンクで指定された文字列をデコードした後、パラメータごとに処理します。
そして、件名については UTF-8 が使用されている場合でも正しく識別できますが、本文については文字化けが発生します。

Outlook 2003 以前、および Outlook Express について

Outlook 2003 以前、および Outlook Express が開発された際には、[mailto リンクで UTF-8 を使う] というオプションは存在していません。したがって、mailto に指定された文字列については、常に Shift-JIS として解釈されます。
その結果、以下の状況では文字化けが発生します。
1. UTF-8 で指定されたページにおいて、フォームにより全角文字が送信される場合
2. [mailto リンクで UTF-8 を使う] がオンにされた状態で、HTML の HREF で mailto に全角文字が指定された場合

まとめ

上記の動作をすべてまとめると以下のようになります。

Internet Explorer 6 以前、または [mailto リンクで UTF-8 を使う] がオフである場合

・フォームによる送信

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
NG
NG (件名は OK)
NG
Shift-JIS
OK
OK
OK

・全角文字の mailto

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
NG
NG (件名は OK)
NG
Shift-JIS
OK
OK
OK

※ UTF-8 の文字がエンコードされずに指定された場合、UTF-8 の 3 バイト目の文字が DBCS の 1 バイト目と解釈され、パラメータの連結を意味する & が正しく識別できなくなることがあります。そのような場合には、順序によって本文または件名が空白となります。

・ShellExecute 直接指定

すべてのクライアントで OK
※ ファイル名を指定して実行やショートカットなどで mailto リンクに全角文字を指定した場合も ShellExecute 直接指定と同様です。

[mailto リンクで UTF-8 を使う] がオンである場合

・フォームによる送信

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
OK
NG (件名は OK)
NG
Shift-JIS
NG
OK
OK

・全角文字の mailto

コードページ
Oultook 2010/2007
Windows メール
Outlook 2003 以前および
Outlook Express
UTF-8
OK
NG (件名は OK)
NG
Shift-JIS
OK
NG
NG

・ShellExecute 直接指定

Outlook 2010/2007 は NG、他は OK

IMAP のストアが既定のデータ ストアに設定できない理由

Outlook で IMAP サーバーを使用すると、フォルダのツリー表示には [個人用フォルダ] のほかに IMAP アカウントのメールアドレスをルートとするフォルダ階層が作成されます。どちらにも受信トレイがあるため、一本化したいと思っても、個人用フォルダは既定のデータ ストアとなっていて削除できず、IMAP アカウントのツリーを既定のデータ ストアにすることができません。

このようなことが起こるのは、IMAP アカウントのツリーとして表示される IMAP ストアに制限があるためです。

IMAP というプロトコルは、基本的にはサーバー上にメールを保持し、クライアントが必要に応じてサーバー上のメールを参照するという動作になります。
そして、Outlook で表示される IMAP アカウントのフォルダは、IMAP サーバー上のメールデータのキャッシュになり、メール以外のデータを置くことができません。
一方、Outlook としては既定のデータ ファイルにメールだけでなく予定や連絡先など様々なデータを保存する必要があります。
IMAP サーバーは予定や連絡先を保存することができないため、既定のデータ ファイルとして設定できないのです。

パブリック フォルダに保存したファイルで競合が発生する現象について

ネットワーク ドライブなどの共有フォルダに Word や Excel のファイルを保存し、それを複数のユーザーで開いた場合、後で開いたユーザーについては編集ロックがかかり、先に開いたユーザーが編集を終えるまで書き込みができません。

しかし、Exchange サーバーのパブリック フォルダに直接ファイルを投稿し、それを Outlook 経由で開いたような場合、そのファイルはロックがされず複数のユーザーが同時に編集することができてしまいます。そして、別々に変更を加えて保存すると、"競合メッセージ" が発生し、どちらか一方または両方を保存するというオプションの選択になります。
このような動作となるのは、Exchange サーバーのパブリック フォルダにはロックという機構がないためです。

Exchange サーバーにはパブリック フォルダの複製機能があり、例えば東京とニューヨークのサーバーで同じフォルダを別々のサーバーによって保持するということが可能です。このような環境でロックをかけようとすると、東京とニューヨークの両方のサーバーでロックが必要となり、ロック中にネットワークの切断が発生したような場合に解除ができない、というような現象が発生する可能性があります。
このようなことが発生しないように、Exchange サーバーではパブリック フォルダ上のアイテムやファイルをロックすることはせず、複数で同時に変更が発生した場合には競合メッセージを生成するという仕様になっています。

複数のユーザーでファイルを編集しつつ、ロックなどの機能も必要ということであれば、Windows SharePoint Service などを使ってください。

[リソースの設定] で [出席依頼と会議キャンセルを自動処理する] をオンにした場合の Outlook の動作について

Outlook の [ツール]-[オプション]-[初期設定]-[予定表オプション]-[リソースの設定] には [出席依頼と会議キャンセルを自動処理する] というチェックボックスがあります。これをオンにすると、あたかも Outlook が受信した会議出席依頼を処理するかのように見えますが、Exchange サーバー環境ではそのような動作にはなりません。

では、どうなるのでしょうか?

この設定を行うと、そのメールボックスの公開された空き時間情報には「メールボックスがリソースである」ということを示すフラグが付与されます。そして、会議の出席者やリソースとしてそのメールボックスを追加した場合、会議出席依頼の送信の際に Outlook はそのメールボックスに対して会議出席依頼を送信しません。その代わりに、Outlook はそのメールボックスの予定表フォルダを開き、予定アイテムを直接書き込んでしまいます。

たとえば、UserA と UserB というメールボックスがあり、UserB で [出席依頼と会議キャンセルを自動処理する] をオンにしていたとします。UserC が会議出席依頼のあて先として UserA と UserB を指定して送信した場合、Outlook は以下のような動作をします。

  1. UserB の予定表に会議出席依頼に対応する予定アイテムを直接保存します。
  2. UserA に会議出席依頼を送信します。
  3. UserC の予定表に会議の予定を保存します。

つまり、[出席依頼と会議キャンセルを自動処理する] という設定をオンにした場合に、自動処理を行うのは受信側の Outlook ではなく送信側の Outlook であり、設定を行ったメールボックスには会議出席依頼は送信されてこなくなります。

なお、[予定済みの時間帯への出席依頼は自動的に辞退する] もオンになっており、会議に重なる時間に予定が入っている場合には、1. でエラーが表示され、ほかの出席者にも会議出席依頼が送信されません。

本来、この設定は会議室やプロジェクターのように会議で使用するリソースを会議出席依頼で確保する際に、リソースのメールボックスに Outlook が常時ログオンしている必要がないようにするためのものです。Exchange Server 2003 以降ではサーバー側でリソースの会議出席依頼を処理する方法があるため、[リソースの設定] はレガシーな機能といえます。また、この設定を行うためには予定表の書き込み権限をほかのユーザーに与えなければならず、誤って直接リソースの予定表に予定を書き込むことでダブル ブッキングを招くようなこともあります。そのため、サーバーが Exchange Server 2003 以降であれば、サーバーの機能を使ったほうがよいでしょう。

ちなみに、Exchange Server 2007 の Outlook Web Access のオプションにもリソースの設定がありますが、こちらはサーバー側での会議出席依頼の処理方法を設定するものであり、Outlook のリソースの設定とは異なります。