シナリオごとの Autodiscover の動作

先週予告した通り、今回は一般的なシナリオごとにどのような手順で Autodiscover が実行されるかを解説します。

今回想定したシナリオは以下の通りです。

以下それぞれのシナリオについて説明します。

シナリオ 1: Exchange オンプレミス環境 – 単一フォレスト、社内のみ

このシナリオは Exchange がインストールされたフォレストと同じフォレストにクライアントがあり、社内からしかアクセスが行われないというものです。
この場合、通常は SCP で Autodiscover が実行されます。

SCP で Autodiscover が成功するためには DNS 設定が適切に設定されており、クライアントから LDAP で GC に接続できる必要がありますが、普通にインストールすれば問題は発生しないはずです。

ただし、複数のサイトがある環境で Exchange サーバーがサイトごとに存在する場合、クライアントが存在するサイトと異なるサイトの Exchange サーバーに対して Autodiscover が実行されてしまう可能性があります。
このようなことを防ぐには Set-ClientAccessServer の –AutoDiscoverSiteScope により、サーバーの AD サイトを正しく設定する必要があります。

また、既定では SCP の前に O365 へのアクセスが発生しますので、こちらを抑止したい場合は ExcludeExplicitO365Endpoint レジストリを設定します。

シナリオ 2: Exchange オンプレミス環境 – 単一フォレスト、社外アクセス

このシナリオは、シナリオ 1 に社外アクセスが加わったものです。
社外アクセスといっても VPN 接続で社内の GC などにアクセスできる場合は、シナリオ 1 と同等となります。
VPN ではなくリバース プロキシーを立てて社外からのアクセスを受け付けるような場合や、VPN を使っていても GC への接続を制限しているような場合がこのシナリオに相当します。

社外アクセスで GC に接続ができない場合、SCP が使えないため、通常は https://autodiscover.メールドメイン により Autodiscover が実行できるようにします。
具体的には社内の Exchange サーバーに接続できるリバース プロキシーのサーバーの IP アドレスが autodiscover.メールドメインによって解決されるように DNS の A レコードまたは CNAME レコードで設定し、その名前を含む証明書がリバース プロキシーのサーバー証明書として構成されている必要があります。

ノート PC を社内でも社外でも使うというような場合、LKG により社外でも社内のサーバーの URL で Autodiscover が実行されることがありますので、そのようなアクセスで問題が生じる可能性があるなら、社内も社外も https://autodiscover.メールドメイン で統一するという方法もあります。

なお、社外からドメイン名でアクセスすると http://www.ドメイン名 というサーバーにリダイレクトされるというような構成をしている場合がありますが、そのような環境では https://autodiscover.メールドメイン の前に https://メールドメイン にリクエストが行われ、想定外の警告が表示される可能性があります。
そのため、ExcludeHttpsRootDomain を設定しておくとよいでしょう。

シナリオ 3: Exchange オンプレミス環境 – 複数フォレスト、信頼関係あり

このシナリオは、Exchange サーバーがインストールされたフォレストとクライアントのフォレストが異なるものの、フォレスト間で信頼関係が結ばれており、クライアントのログオンで使用したアカウントの認証情報で別フォレストにある Exchange サーバーに接続できるというものです。

この場合、既定では SCP が使用できませんが、前回の手順 5 で説明した通り Export-AutoDiscoverConfig で SCP の情報をクライアント側のフォレストにエクスポートすることで、SCP による Autodiscover が成功する動作となります。
注意点としてはクライアントと Exchange フォレストにある GC の間にファイアウォールがあり、LDAP などをブロックしてしまうと、SCP による Autodiscover が失敗するというものがあります。

なお、何らかの理由で Export-AutoDiscoverConfig が実行できないような場合は、次のシナリオ 4 と同じ状態になります。

シナリオ 4: Exchange オンプレミス環境 – 複数フォレスト、信頼関係なし

このシナリオは、Exchange サーバーがインストールされたフォレストとクライアントのフォレストが異なり、フォレスト間の信頼関係もないというものです。

一般的には、https://autodiscover.メールドメイン で Autodiscover が成功するように構成します。
しかし、多数の異なるフォレストからアクセスが行われ、それぞれが独自のメールドメインを持つというような場合、サーバー証明書の管理が難しくなる可能性があります。
そのような場合は、シナリオ 9 の Exchange ホスティング環境と同様になると考えられます。

なお、クライアント環境の SCP は使用できないので、ExcludeScpLookup を設定してしまってよいでしょう。
また、ExcludeExplicitO365Endpoint や ExcludeHttpsRootDomain も設定したほうが良いかもしれません。

シナリオ 5: Exchange オンプレミス環境 – ワークグループ

通常、企業内で使用するクライアント PC はドメインに参加していると思うのですが、何らかの理由でワークグループの端末から Exchange に接続するというシナリオです。

この場合、SCP は使用できませんので、シナリオ 2 と同様になります。

シナリオ 6: Exchange Online 環境 – オンプレミスなし

このシナリオは、既存のオンプレミス環境にもともと Exchange サーバーは存在せず、新規に Exchange Online を使用するというものです。

この場合は前回の記事の手順 4 (O365 を優先的に確認) が使用されるので、特に設定をしなくても接続はできるはずです。

ただ、この手順は Office 365 ProPlus でしか実行されないため、Outlook 2013 以前や Outlook 2016 の MSI 版を使用している場合には以下のいずれかの DNS 設定が必要になります。

  • autodiscover.メールドメイン で autodiscover.outlook.com に接続するよう CNAME レコードを設定
  • メールドメインの _autodiscover の SRV レコードで autodiscover-s.outlook.com を設定

CNAME と SRV では設定するサーバー名が異なることに注意してください。
また、ExcludeScpLookup や ExcludeHttpsRootDomain を設定しておくとよいと思います。

シナリオ 7: Exchange Online とオンプレミスのハイブリッド環境

このシナリオは、オンプレミスで Exchange サーバーを使用していた組織が Exchange Online に移行する場合に最もよくあるパターンと考えられます。
この環境で Exchange Online に移行済みのメールボックスにアクセスする場合の Autodiscover の手順は以下のようになります。

  1. SCP (もしくは https://autodiscover.メールドメイン など) によりオンプレミスの Exchange サーバーから XML ファイルを取得します。
  2. 取得した XML ファイルには、構成情報ではなく O365 上のメールアドレス (テナントごとに固有の onmicrosoft.com のアドレス) へのリダイレクトが指定されているため、このアドレスで改めて最初から Autodiscover のプロセスを開始します。
  3. http#x3a;//autodiscover.テナント.onmicrosoft.com で https://autodiscover-s.outlook.com にリダイレクトされ、このサーバーから実際の設定情報を含む XML ファイルを取得します。

このように SCP と HTTP リダイレクトの両方が使用される動作となります。
よくある問題としては http://autodiscover.テナント.onmicrosoft.com の接続がプロキシ設定の問題 (O365 には直接接続が想定されているのに、プロキシの例外として設定されていなかったなど) で失敗するというものがあります。

また、SCP で取得される O365 上のメールアドレスは、AD 上ではユーザーの RemoteRoutingAddress という属性に格納されていますので、何らかの理由でこちらの情報が削除されると Autodiscover が失敗します。

なお、このシナリオではいろいろな Autodiscover が実行される可能性があるのですが、おそらくルートドメインによる Autodiscover が行われることはないので、ExcludeHttpsRootDomain は設定してもよいと思います。

シナリオ 8: Exchange Online とオンプレミスの混在

このシナリオは何らかの理由で Exchange Online とオンプレミスのハイブリッド構成ができず、一時的に Exchange Online とオンプレミスの両方に同じ SMTP アドレスを持つメールボックスが存在してしまうというものです。
このような構成はお勧めできないのですが、どうしてもこの構成をとるのであれば、Autodiscover の構成を慎重に行う必要があります。

まず、Exchange Online 上に作成したテナントでオンプレミスと同じ SMTP アドレスが使用されるようになると、O365 の優先確認により Exchange Online での Autodiscover が実行されるようになります。
この時点でユーザーが Exchange Online にアクセスするための認証情報を持っていなければ Exchange Online に接続はされませんが、不必要な認証ダイアログが起動時などに表示されるという現象が発生します。

また、キャッシュ モードを使用している場合には、オンプレミスで使用していたプロファイルで Autodiscover により Exchange Online の情報が取得されると Exchange Online に接続され、OST に保存されている情報と Exchange Online のメールボックスの情報に不整合が検出されます。
その結果、「メールボックスは、一時的に Microsoft Exchange サーバーで移動されています。」という警告メッセージが表示され、オンライン モードで接続するか、オフラインで OST を参照するかのいずれかしか選択できなくなります。
そのため、プロファイルの再作成は必須なのですが、Exchange Online への移行後に誤ってオンプレミスの Autodiscover に接続されると、再び一時メールボックスの状態になってしまいます。

これらのことを回避するには移行前と移行後でレジストリ設定によりどの Autodiscover を停止するかを厳密にコントロールし、誤って別の Autodiscover で成功しないようにする必要があります。
移行前と移行後で設定すべきレジストリは以下の通りとなります。

移行前 (オンプレミスで Autodiscover)

  • ExcludeExplicitO365EndPoint
  • ExcludeHttpRedirect
  • ExcludeSrvRecord (DNS の SRV レコードに Exchange Online の設定をしている場合のみ)

移行後 (Exchange Online で Autodiscover)

  • ExcludeScpLookup
  • ExcludeHttpsAutodiscoverDomain
  • ExcludeSrvRecord (DNS の SRV レコードにオンプレミスの設定をしている場合のみ)

シナリオ 9: Exchange ホスティング環境

このシナリオは Exchange サーバーを利用して他の会社や個人にメール サービスを提供する環境を想定しています。

この場合、サービスを提供する会社の Active Directory と信頼関係を結ぶどころか、Active Directory が存在しない可能性もあるため、SCP は使用できません。
また、提供するメールアドレスとして顧客ごとに固有のドメインを使うことが想定されるため、https://autodiscover.メールドメイン での Autodiscover をするには以下のいずれかの対処が必要となります。

  • メールドメインごとにサーバーを用意する
  • 一つのサーバーで複数の autodiscover.メールドメイン の名前を登録した証明書を使用する

しかし、いずれも現実的ではありません。

そこで、http://autodiscover.メールドメイン によるリダイレクトか、DNS の SRV レコードでの Autodiscover を使用することになりますが、リダイレクトの際には警告が表示されてしまいます。
これを回避するには前回の手順 9 に記載した RedirectServers のレジストリ設定をあらかじめクライアントに設定しておく必要があるのですが、レジストリの展開はホスティング サービスでは困難かもしれません。
そのため、マニュアルなどであらかじめ警告が出ることを明記しておくことになるでしょう。

シナリオ 10: POP/IMAP 環境

最後のシナリオは Exchange を使用しない POP/IMAP 環境での Autodiscover です。
前回の手順 8 でも説明しましたが、以下の URL のサンプルを参考にしてXML ファイルを作成することで社内 (あるいは ISP) の POP/IMAP サーバーの構成を自動化することができます。

https://docs.microsoft.com/ja-jp/previous-versions/office/office-2010/cc511507(v=office.14)?redirectedfrom=MSDN

これについては https://メールドメイン か https://autodiscover.メールドメイン のいずれかのサーバーを用意するというのが妥当と思われます。
注意点としてはこのサーバーに対するリクエストは POST メソッドが使用されるということです。
Autodiscover には POST によりユーザー情報を含んだ XML を提供し、それに合致する構成情報を取得するという前提があるので、Autodiscover で接続されるサーバーが /autodiscover/autodiscover.xml というファイルに対する POST メソッドを拒否するような場合は Autodiscover が失敗します。
したがって、Autodiscover の XML を提供するサーバーについては、実際にサーバーから取得される XML ファイルがユーザー情報を持たない汎用的なものであっても 、必ず POST メソッドで XML ファイルを返すよう構成する必要があります。

Autodiscover の詳細動作

Outlook には Autodiscover という機能があります。
この機能により、メールアドレスとパスワードだけでメール アカウントの構成に必要なサーバーやポート番号などの情報を取得して設定することができます。
Autodiscover では、最終的にサーバーなどの構成情報を含むデータを XML ファイルとして取得するのですが、Outlook はインターネットで一般的に使われる POP や IMAP といったサーバーだけでなく、Microsoft 独自のプロトコルで接続する Exchange サーバーにも対応するため、XML の取得をいくつかの方法で試みる動作になっています。
そのため、環境によっては情報の取得に時間がかかったり、想定外の警告が表示されるということがあります。
 
Microsoft サポート技術情報の「Outlook 2016 の Autodiscover の実装」によると、以下の順序で Autodiscover が実行されます。

  1. 再起動のシナリオを確認する
  2. ローカル データの環境設定を確認する
  3. 前回の既知の有効 (LKG) データを確認する
  4. O365 を優先的に確認する
  5. SCP データを確認する
  6. ルート ドメインを確認する
  7. Autodiscover ドメイン
  8. ローカル データを確認する
  9. HTTP リダイレクトを確認する
  10. SRV データを確認する
  11. O365 のフェールセーフを確認する

前述のサポート技術情報では上記の概要が説明されていますが、具体的にどのような処理が行われるかや、どのようなシナリオで必要なのかなど、トラブルシュートに必要な詳細情報がありません。
そこで、今回の記事では、Autodiscover の詳細について上記の順で説明したいと思います。

手順 0: ローカルにキャッシュされた XML ファイルを確認する

いきなり上記の手順にない処理からスタートしましたが、この手順はすでにプロファイルが作成済みの場合の起動時のみ実行されます。
この手順以外で Autodiscover が成功すると、その際にサーバーから取得した XML ファイルが以下の通り保存されます。
 
フォルダー: C:\Users\ユーザー名\AppData\Local\Microsoft\Outlook\16
ファイル名: AutoD.メールアドレス.xml
 
そして、2 回目以降の起動ではこのファイルを読み込んでサーバーに接続するため、素早く起動できるというメリットがあります。
言い換えると、このファイルが何らかの理由で削除されると、Outlook 起動時に上記の手順で Autodiscover が実行される動作となるので、環境によっては起動に時間がかかるということになります。
 
特に RDS や VDI 環境で移動ユーザー プロファイルを使用している場合、通常は上記のファイルは移動対象ではなく、ログオフ時に削除されるため、このような環境でログオン直後の初回の Outlook の起動にだけ時間がかかるという現象の原因は上記のファイルが削除されることにあると考えられます。
 
また、サーバーの移動や、オンプレミスの Exchange サーバーから Exchange Online に移動した後のサーバー切り替えに失敗するという場合、上記のファイルに移動前の古い情報が残っており、その情報での接続で失敗までに時間がかかりすぎている可能性があります。
そのような場合は、切り替え後に一度上記のファイルを削除することで回避するかもしれません。

手順 1: 再起動のシナリオを確認する

この手順は技術情報にもある通り、Outlook の起動中に Exchange アカウントを追加し、再起動した際に実行されるシナリオです。
具体的には、Outlook の起動中に Exchange アカウントを追加すると、Autodiscover が実行されますが、取得された XML ファイルの内容が以下の通り保存されます。
 
フォルダー: C:\Users\ユーザー名\AppData\Local\Microsoft\Outlook
ファイル名: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.txt
※ X はランダムな 16 進数
 
また、以下のレジストリも設定されます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\プロファイル名\AutoDisc
名前: 追加したアカウントのメールアドレス
種類: REG_BINARY
値: UNICODE で上記のファイルのフルパスを含むバイナリデータ
 
そして、次回起動時に Outlook がプロファイルのレジストリに上記のデータが含まれていることを確認すると、データに格納されているパスのファイルから Autodiscover の設定を読み込み、サーバーの構成を行います。
通常起こることではありませんが、もしアカウントを追加してから Outlook を終了し、次に起動するまでに上記のファイルが削除されたような場合、次回起動時のアカウント追加処理が失敗し、アカウントの追加は行われません。 

手順 2: ローカル データの環境設定を確認する

この手順は以下のレジストリ設定がなければ実行されません。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: PreferLocalXML
種類: REG_DWORD
値: 1
 
この設定は手順 8 の「ローカル データを確認する」の処理を他よりも前に実行させることを目的としています。
何らかの理由で手順 3 から手順 7 をレジストリ設定でスキップさせずに手順 8 を実行させたい場合にこの設定を行います。
例えば、特定のドメインだけローカル XML で構成し、ほかのドメインは通常の Autodiscover で構成するというような場合などが考えられます。
 
ローカル データの確認の詳細については、手順 8 で説明します。 

手順 3: 前回の既知の有効 (LKG) データを確認する

この手順はプロファイルが作成されている状況でのみ実行され、アカウント作成時には実行されません。
正常にプロファイルが作成されてアカウントが追加されると、以下のレジストリに Autodiscover の XML ファイルを取得した URL が Unicode のバイナリで格納されます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\プロファイル名\アカウントごとのランダムな 16 進数
名前: 001f664a
種類: REG_BINARY
 
そして、次回以降の Autodiscover は試行錯誤せずに前回の既知の有効な (Last Known Good) URL にアクセスすることで、時間が短縮できるというものです。
サーバーの移行などにより LKG URL が無効となってしまった状況で、この URL へのアクセスが問題になるようであれば以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeLastKnownGoodURL
種類: REG_DWORD
値: 1
 
ただし、この設定を行うと、後述の SCP による Autodiscover のために GC へのアクセスが発生して GC の負荷が増大したり、Autodiscover に時間がかかるようになる可能性があります。 

手順 4: O365 を優先的に確認する

こちらは、Outlook for Office 365 ProPlus において、特に設定を行っていない状況で最初に行われる Autodiscover の手順です。

技術情報では「Outlook は一連のヒューリスティックを使用して、指定されたユーザー アカウントが Office 365 から提供されたかどうかを判断します」とあるのですが、実際に判断しているのは実は Outlook ではありません。
まず、Outlook は以下の URL で GET リクエストを行います。
 
https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/メールアドレス?Protocol=Autodiscoverv1
 
そうすると、これを受け取った O365 のサーバーがメールアドレスに応じて正しいと思われる Autodiscover URL へのリダイレクトを行います。
つまり、判定を行っているのは O365 のサーバーになります。
ただし、厳密にメールアドレスのチェックを行っているわけではなく、O365 に登録されているドメインであれば O365 の Exchange サーバーの URL に、そうでなければ https://autodiscover.メールドメイン/autodiscover/autodiscover.xml にリダイレクトされるという動作のようです。
そして、O365 のアカウントであれば最終的に https://outlook.office365.com/autodiscover/autodiscover.xml で構成情報の取得が成功します。
 
O365 にメールボックスがなく、outlook.office365.com というサーバーにアクセスができない環境で失敗までに時間がかかるような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeExplicitO365Endpoint
種類: REG_DWORD
値: 1 

手順 5: SCP データを確認する

この手順は、ドメインに参加しているクライアントでのみ実行される手順です。
Exchange サーバーがインストールされると、Active Directory の構成名前付きコンテキストに Autodiscover の URL が書き込まれます。
具体的には以下の DN のオブジェクトの serviceConnectionPoint プロパティに格納されます。
 
CN=サーバー名,CN=Autodiscover,CN=Protocols,CN=サーバー名,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=組織名,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=組織固有の DC
 
Outlook は PC が Active Directory ドメインに参加していることを認識すると、LDAP によりドメインの GC に対して上記のオブジェクトを Keyword の値で検索し、見つかったオブジェクトの serviceConnectionPoint プロパティに格納されている URL に対して HTTP のリクエストを行って自動構成の XML を取得します。
 
既定では、Exchange サーバーが異なるフォレストにインストールされている場合には上記の情報がクライアントの AD 上に存在しないため SCP による構成は失敗します。
しかし、Exchange サーバーの Export-AutoDiscoverConfig コマンドレットでクライアントのフォレストに SCP の情報をエクスポートすると、そのフォレストで SCP による Autodiscover ができるようになります。
この場合、クライアントの AD では以下の DN のオブジェクトが生成されます。
 
CN=Exchange のドメイン名,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=組織固有の DC
 
そして、このオブジェクトの serviceConnectionPoint プロパティの serviceConnectionPoint プロパティの値を取得するのですが、ここに格納されているのは Autodiscover の URL 自体ではなく、LDAP://<ドメイン名> という LDAP の URL となります。
そこで、Outlook は指定された LDAP URL に対して改めて SCP 取得のための検索を行い、見つかったオブジェクトの serviceConnectionPoint プロパティから Autodiscover の URL を取得するという処理を行います。
そのため、別フォレストの Exchange への Autodiscover を SCP で成功させるには以下のような要件が必要になります。

  • DNS により Exchange のドメインの LDAP の SRV レコードが取得できる
  • Exchange のドメインの GC の LDAP (TCP ポート 389) に接続ができる
  • Exchange のドメインの GC に対して Windows にログオンしたユーザーの資格情報で認証が通る

クライアントが所属するフォレストに Exchange サーバーが存在せず、GC への不要な LDAP アクセスを抑止したいような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeScpLookup
種類: REG_DWORD
値: 1

手順 6: ルート ドメインを確認する

この手順では、以下のような URL での Autodiscover を実行します。
 
https://<メールドメイン>/Autodiscover/Autodiscover.xml
 
例えば、user@example.com というメールアドレスの Autodiscover の場合、https://example.com/Autodiscover/Autodiscover.xml という URL で構成情報の取得を行います。
これが成功するにはドメイン名で解決される IP アドレスでサーバーが稼働しており、そのサーバーのサーバー証明書の名前にドメイン名が設定されている必要があります。
インターネット プロバイダーなどで POP/IMAP アカウントを Autodiscover で構成する場合などに使用することが想定されていると思われます。
 
なお、Active Directory 環境では、ドメイン名で名前解決するとドメイン コントローラーの IP が返され、https://ドメイン名/ でドメイン コントローラーへのアクセスが発生する場合があります。
また、DNS の管理を外部に委託している場合に、ドメイン名でのアクセスが委託先のサーバーへのリクエストになり、想定外の認証要求や証明書エラー、接続遅延などの原因になることもあります。
例えば、Outlook の起動時に認証ダイアログが表示され、何を入力しても通らないものの、キャンセルしても特に問題ないというような場合、ルート ドメインの Autodiscover が原因の可能性があります。
そのため、Exchange アカウントを作る前提の場合は、以下のレジストリ設定でこの動作を無効にすることをお勧めします。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeHttpsRootDomain
種類: REG_DWORD
値: 1 

手順 7: Autodiscover ドメイン

この手順では、以下のような URL での Autodiscover を実行します。
 
https://autodiscover.メールドメイン/Autodiscover/Autodiscover.xml
 
例えば、user@example.com というメールアドレスの Autodiscover の場合、https://autodiscover.example.com/Autodiscover/Autodiscover.xml という URL で構成情報の取得を行います。
オンプレミス環境で社外から接続するというような場合や、ワークグループもしくは Exchange サーバーとは別のフォレスト環境から接続する場合には、SCP での取得ができないため、この手順で Autodiscover を実行するのが一般的です。
この手順が実施されるときのポイントとしては、autodiscover.メールドメイン という名前で解決されるサーバーのサーバー証明書の名前に autodiscover.メールドメイン が含まれていなければならないという点があります。
通常、Exchange サーバーを構築する際にはサーバー自体に autodiscover という名前を付けることはほとんどないと思われるので、サーバー証明書にも実サーバーの名前を設定し、DNS の CNAME で autodiscover として実サーバーに接続するよう構成することになります。
しかし、サーバー証明書に autodiscover が別名で登録されていない場合には、Outlook が https://autodiscover.メールドメイン としてアクセスした際に、想定したサーバー名と異なる証明書であるため、警告が表示される結果となります。
これを回避するには、Exchange に登録するサーバー証明書に以下のいずれかの対応を行う必要があります。

  • 別名として autodiscover.メールドメイン を登録する
  • ワイルドカード証明書を使用する (名前を *.メールドメイン とする)

なお、O365 環境では autodiscover.メールドメイン というサーバーは CNAME で autodiscover.outlook.com に接続されるように構成されることがあります、このサーバーでは TCP ポート 443 での接続は遮断されるので、この手順は失敗するのが想定される動作です。
 
autodiscover という名前で CNAME の登録をしていないような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeHttpsAutodiscoverDomain
種類: REG_DWORD
値: 1 

手順 8: ローカル データを確認する

この手順はあらかじめ Autodiscover の XML ファイルを作成してクライアントに配布しておき、それをもとに自動構成を行うというものです。
この手順を行うには、ローカル ファイルに XML ファイルを配置し、以下のレジストリに保存した XML ファイルのパスを記述する必要があります。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: メールドメイン
種類: REG_SZ
値: XML ファイルのフル パス名
 
Outlook 2010 までは既定でいくつかのプロバイダの XML ファイルがインストールされていたのですが、Outlook 2013 以降はインストールされなくなったようです。
ローカルの XML ファイルだとプロバイダ側での構成変更に対応できなかったからかもしれません。
 
保存する XML ファイルには以下の 2 つのパターンがあります。 

  • XML に構成情報を記載する
  • XML にリダイレクト URL を記載する

前者は、ユーザーごとに固有の情報がメールアドレスやログオン情報のみの場合に有効な方法です。
Outlook 2013 まではこの方法で Exchange アカウントの構成もできていたのですが、Outlook 2016 以降ではこの方法での Exchange アカウントの構成はできなくなりました。
POP/IMAP などの環境であれば Outlook 2016 以降でも構成は可能であり、以下の URL のサンプルを参考にしてXML ファイルを作成することで社内の POP/IMAP サーバーの構成を自動化することもできます。
https://docs.microsoft.com/ja-jp/previous-versions/office/office-2010/cc511507(v=office.14)?redirectedfrom=MSDN
 
後者は、XML ファイル自体には構成情報が含まれておらず、実際に構成情報を取得するための URL が記載されているというものです。
例えば、O365 に接続するための Autodiscover の URL を XML ファイルに記述する場合は以下のようなものとなります。
 
<?xml version=”1.0″ encoding=”utf-8″ ?>
<Autodiscover xmlns=”http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006″>
<Response xmlns=”http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a”>
<Account>
<AccountType>email</AccountType>
<Action>redirectUrl</Action>
<RedirectUrl>https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml</RedirectUrl>
</Account>
</Response>
</Autodiscover>
 
この方法は、O365 に接続したいものの、DNS の構成に手が出せず、後述の CNAME レコードも SRV レコードも設定できないというような場合に使われるようです。
 
なお、メールドメインのレジストリ設定がなければ実行されないものであるため、この手順を無効にするレジストリ設定はありません。 

手順 9: HTTP リダイレクトを確認する

この手順では、まず以下のような URL にアクセスします。
 
http://autodiscover.メールドメイン/Autodiscover/Autodiscover.xml
 
例えば、user@example.com というメールアドレスの Autodiscover の場合、http://autodiscover.example.com/Autodiscover/Autodiscover.xml という URL にアクセスするのですが、この URL で構成情報の取得は行われません。
その代わり、サーバーから HTTP の 302 という応答とともにリダイレクト先の URL が返され、その URL から構成情報を取得するという動作になります。
このような手順が必要となる理由としては、サーバー証明書のサーバー名が特定できない環境があるためです。
具体的にはパブリック クラウド環境や多数のメールドメインを持つような大企業などでは、たとえワイルドカード証明書を使ったとしてもサーバー証明書に追加しなければならない名前が多すぎたり、証明書の書き換えが頻繁に発生する状況となります。
こうした環境で https://autodiscover.ルートドメイン で証明書の警告を出さないようにすることは難しいため、証明書のチェックが不要な http://autodiscover.ルートドメイン にアクセスを行い、そこから単一の URL にリクエストを転送することで、サーバー証明書の問題が回避させるというのがこの手順の目的です。
 
ただし、http によるリクエストの場合、そのサーバーの信頼性が確認できず、何らかの方法で不正なサーバーにリダイレクトされる可能性もあります。
そのため、リダイレクトの際に「この Web サイトで メールアドレス のサーバー設定を構成できるようにしますか?」というような警告メッセージが表示されます。
このダイアログを最初から表示させたくない場合には、以下のレジストリ設定を行う必要があります。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover\RedirectServers
名前: リダイレクト先サーバーの FQDN
種類: REG_SZ
値: 空の文字列
 
DNS に autodiscover という名前で CNAME の登録をしていないような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeHttpRedirect
種類: REG_DWORD
値: 1 

手順 10: SRV データを確認する

この手順は DNS の “メールドメイン” の SRV レコードに以下のような値を設定しておくことで、指定されたサーバーから構成情報を取得するというものです。
 
サービス: _autodiscover
プロトコル: _tcp
ポート番号: 443
ホスト: Autodiscover の取得先となるサーバーの FQDN
 
こちらも、手順 9 と同様に多数のメールドメインを扱う環境で使用され、サーバーにアクセスする際にリダイレクトの警告が表示されます。
警告を表示しないようにする設定も手順 9 と同じです。
 
DNS に Autodiscover の SRV レコードの登録をしていないような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeSrvRecord
種類: REG_DWORD
値: 1 

手順 11: O365 のフェールセーフを確認する

最後の手順は、アカウント作成時には行われません。
既存のアカウントが O365 のものであることがわかっている状況で、何故か Autodiscover に失敗してしまったという場合に、 O365 の既知の Autodiscover URL から構成情報を取得するというものです。
この動作は手順 4  のレジストリ設定で O365 の優先構成を無効にすると、自動的に無効化されます。

まとめ

上記のように Outlook は様々な方法で Autodiscover を実行しますが、基本的にはどれか 1 つ成功すればよいものであるため、不要な手順は ExcludeXXX レジストリにより無効化しておくと時間短縮や想定外の動作の抑制になるでしょう。
無効化するためのレジストリのキーとしては HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover と記載しましたが、グループ ポリシーで展開する場合には HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Autodiscover というキーで展開することになります。
 
「説明が長すぎて結局どの手順で成功するのかわからない」という方もいると思うので、来週は一般的な環境でどの Autodiscover の手順により構成されるかの解説をします。

PropertyAccessor とウイルス感染

コメントにて以下のようなご質問をいただきました。


こんにちは。メールを開くことによるウイルス感染を防止するため、メールを開かずにヘッダ情報より、送信者のアドレスを表示する方法を検討しています。

■環境
・windows10
・Outlook2010(サポート終了後はOutlook2016)

■知りたいこと
別の方法があればご教示いただけますと幸いですが、現在は、PropertyAccessor を使用し、ヘッダ情報より「From:」を検索し、送信者アドレスをmsgboxで表示できるようにvbaを作成しております。

ここで疑問なのですが、PropertyAccessor を使用し取得したヘッダ情報は、メールを開いて取得したものではないのか?ということです。

やりたいことが、ウイルス感染防止。そのために、メールを開かずに送信者アドレスを知りたいなので、PropertyAccessorで、実はメールを開いていたでは、全く意味がありません。
上記の情報または、別にアドイン等導入することなくメールを開かずに、送信者アドレスを取得する方法がありましたら、ご教示いただければと思っております。
よろしくお願いします。


結論から言えば、PropertyAccessor を使用したタイミングでウイルスに感染するというようなことはありません。
それを説明するには、まず「メールを開く」とはどういうことなのかを定義する必要があるでしょう。

一般的な概念では「メールを開く」というのは Outlook のユーザー インターフェイスで本文を表示することを指すと考えられます。
この状態でウイルスに感染する可能性があるのは、本文を表示するコンポーネントにセキュリティ ホールが存在した場合になります。

Outlook 2003 までの Outlook は Internet Explorer により HTML メールの本文を表示しており、Internet Explorer には比較的容易な方法 (HTML に JavaScript を埋め込むなど) でセキュリティ ホールを悪用することができていたため、実際に本文を表示した際にウイルスに感染するという問題が発生することがありました。
しかし、Outlook 2007 以降の Outlook では本文の表示には Word のコンポーネントを使用しており、Internet Explorer のセキュリティ ホールの影響を受けることはありません。
もちろん、Word にセキュリティ ホールがあればそれを悪用した攻撃は可能となるのですが、Outlook の本文の表示の際に悪用するより、細工した Word ファイルを添付して送信したほうが Outlook 以外のメーラーも攻撃できるので、現在の Outlook で本文を表示するだけで感染するウイルスが登場する可能性は極めて低いと思われます。
また、Word のセキュリティ ホールを狙うようなウイルスの対策としては [ファイル]-[オプション]-[セキュリティ センター] の [セキュリティ センターの設定] (または [トラスト センター] の [トラスト センターの設定]) をクリックし、[電子メールのセキュリティ] で [すべての標準メールをテキスト形式で表示する] をオンにするというものがあります。
これにより、Word のコンポーネントを使用せずに抽出したテキスト本文のみが表示されるようになります。

いずれにせよ、「メールを開く」が本文を表示するという意味なら、PropertyAccessor を使用する際に Word のコンポーネントは使用されないので、メールを開いて取得したものではないといえます。

一方、「メールを開く」というのが「メールのデータを参照する」ということになると、話が変わってきます。
一般的に、SMTP で送信されるメールは MIME というフォーマットで送信されます。
このフォーマットは単一のテキスト データの中にメールのヘッダーや本文、添付ファイルなどをエンコードして格納するようなものであるため、受信したメール サーバーやメール クライアントはこの MIME データから件名や差出人などの情報を解析して取り出す必要があります。
そして、この解析処理に何らかのセキュリティ ホールがあり、それを悪用するようなウイルスが存在した場合、メール ソフトがメールを受信した瞬間に感染するという可能性もあるということになるのです。

そのような意味では、PropertyAccessor を使用して取得したヘッダー情報は「メールを開いて」取得したものと言えます。
ただ、Outlook ではヘッダー情報は受信したタイミングで MIME データから MAPI プロパティに変換されているため、PropertyAccessor を使用するタイミングでウイルスに感染するということはありません。
なお、この問題について対処するとなると、Outlook のセキュリティ修正を適用する以外に方法はないでしょう。

ちなみに、ウイルス感染防止のために送信者アドレスをチェックしたいとのことですが、SMTP では送信者のなりすましが簡単にできます。
実際、最近ではすでにやり取りした相手のメール アドレスやメールの内容などを使用してウイルスが含まれる添付ファイルを送って感染させるというような手口も確認されています。
そのため、送信者のアドレスだけで安全かどうかを判断するのはかえって危険なのではないかと思います。

参考リンク:
「Emotet」と呼ばれるウイルスへの感染を狙うメールについて

Outlook のメール スレッドの管理方法

スレッドを保ったまま任意の文字列を件名のプレフィックスにつけて返信するマクロのコメントにて以下のご要望をいただきました。


こんにちは。
便利に使用させていただいております。
大変ありがとうございます。

さらに便利に使用するため、
下記を解決する方法はありませんでしょうか?

■現状
送信者 件名
Aさん :   テスト送信
私(マクロ使用):  【ABC】: テスト送信
Aさん 受信 : 【ABC】: テスト送信
Aさん 返信 : テスト送信
※Aさんが受信時は付加したテキスト【ABC】が表示されており、
スレッドも維持されているが、されにそのメールに返信しようとすると
私が付加したテキスト【ABC】は存在しない
⇒私がさらに返信する際、同じテキストをまた付加しないといけない

■理想
送信者 件名
Aさん :   テスト送信
私(マクロ使用):  【ABC】: テスト送信
Aさん 受信 : 【ABC】: テスト送信
Aさん 返信(マクロ不使用) :【ABC】: テスト送信
※一度付加されたテキスト【ABC】は、マクロを使用しなくても以降ずっと保持される

※私はOutlook 2016 MSO 16.0.8201.2193 32ビット です。

お手数ですがよろしくお願いいたします。


残念ながら、ご要望の動作はできません。
これは、Outlook のスレッド管理方法に起因しています。

Outlook では、メールのスレッドを管理するために PR_NORMALIZED_SUBJECT というプロパティが使われます。
このプロパティは、件名に含まれる “RE:” や “FW:” を取り除いた文字列を保持するもので、Outlook でスレッドが生成される場合は、PR_NORMALIZED_SUBJECT が同じメールをまとめるという動作になります。
(厳密にはこれ以外のプロパティも使用されます。)

一方、件名に含まれるものの PR_NORMALIZED_SUBJECT に含まれない “RE:” や “FW:” については、PR_SUBJECT_PREFIX という別のプロパティに格納され、スレッドを保ったまま任意の文字列を件名のプレフィックスにつけて返信するマクロではこちらのプロパティに任意の文字列を追加することで、スレッドの保持を実現しています。

マクロを使用せずに返信などを行ったときに文字列を維持する場合には、PR_NORMALIZED_SUBJECT の方に文字列を追加する必要がありますが、PR_NORMALIZED_SUBJECT を変更するとスレッドが維持できなくなり、当初の目的が果たせなくなります。
したがって、スレッドを維持する必要があるなら、マクロを使い続ける必要があるということになります。

マクロやアドインで送信トレイにあるメールの送信がキャンセルされる

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


はじめて投稿させていただきます。
どうぞ、よろしくお願いいたします。

ThinkPad X230
  Intel Core i7-3520M CPU 2.90 GHz
  RAM 4.00 GB
  Windows 7 SP1 (32 bit)

Outlook 2013

といった環境です。

メールの返信、全員への返信、転送、のときに、
  本文を Plain Text で編集送信できるよう、
  見様見真似で下のようなコードを書きました。

概ねうまく動いているのですが、
1. メール編集
2. 送信ボタン
3. 送信トレイで内容確認
4. 送信ボタン

と、やったときに、送信トレイ内のメール一覧のところで

日付: なし

となり、「送受信」の操作を行っても
  メールが送信されなくなってしまいます。

((各々のメールで送信ボタンを押しても、
すぐにはメールが送信されない設定にして
  あります))

どうも、下のコードの

Private Sub oExpl_SelectionChange()

に、問題があるらしく、

Set oItem = oExpl.Selection.Item(1)
にブレークポイントを入れて、止めておいた状態で

「送受信」の操作

を行うと、メールが送信されます。

ここに、何か条件分岐のコードを入れれば良いように思うのですが、
  見様見真似でありますため、どうすれば良いのか、
さっぱりわかりません。

どうか、ご教示のほど、よろしくお願いいたします。

<<コード省略>>


Private Sub oExpl_SelectionChange() ‘☆どうもここが問題らしいです☆

On Error Resume Next

If oExpl.CurrentFolder.Name = “送信トレイ” Then ‘挿入
Exit Sub ‘挿入
End If ‘挿入

Set oItem = oExpl.Selection.Item(1)

End Sub

で、とりあえず使っております。

上手くいっているようですが、これで、いいんでしょうか。


はい。この対応で問題ありません。

ご質問の動作は、Outlook オブジェクト モデルにより送信トレイにあるアイテムを参照すると、送信処理がキャンセルされるという仕様により発生します。
特定のプロパティにアクセスしたらというようなことではなく、Outlook オブジェクト モデルを使用してアイテムのオブジェクトを取得するという処理をしただけで、送信がキャンセルされます。(ただし、送信トレイのアイテムが送信処理の最中であれば、キャンセルされるのではなくアイテムの取得に失敗します。)

そのため、送信トレイのアイテムは不用意にアクセスしないようにする必要があります。
例えば、アイテムのプレビューなどでも送信がキャンセルされることになるので、送信トレイでは閲覧ウィンドウがオンにできないようになっています。

すでに実装されている「フォルダー名が “送信トレイ” の場合にはアイテムへのアクセスを行わない」という条件分岐でも対応可能ですが、例えば PST にある “送信トレイ” フォルダーではアイテムにアクセスさせたいというような要件があるなら、以下の条件分岐の方が確実でしょう。

If oExpl.CurrentFolder.EntryID = Session.GetDefaultFolder(olFolderOutbox).EntryId Then

Exchange 環境でほかのユーザーの予定表を参照する際の動作

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


コメント失礼します。

outlook2016‐exchange2016です。

〈ご質問したいこと〉

素朴な疑問で恐縮なのですが、outlookで組織内(同じ上司の配下です)ユーザーの予定表を参照する際、EWSって影響するのでしょうか。

〈補足〉

下の予定表問題に対してメールボックスの EWS を有効化したら直ったと言われてますがしっくり来てません。

 ー問題

ユーザXからユーザAの予定表は見えていて、ユーザBの予定表を表示しようとするとエラーになり、アイテムが1つも表示されません。

ユーザYからはA、Bの予定表は参照可能で、

X、Yの権限はA、Bに対して共にデフォルトの参照権限です。

かつ、OWAからはユーザXからユーザBの予定表を参照可能です。

OLKのプロファイル再作成は試して改善しませんでした。

エラーはうろ覚えで申し訳ありませんが、403エラー系、権限が不足している旨の表示だったと思います。

初めてお世話になりますが、どうぞよろしくお願いします。


結論から言えば、Outlook で他のユーザーの予定表を参照する際には EWS の影響を受けます。

Outlook で他のユーザーの予定表を参照する際の詳細な動作は以下の通りです。

  1. 空き時間情報の表示
    1.1. 空き時間情報の取得を行うための EWS の URL を自分のメールアドレスによる AutoDiscover で取得
    1.2. EWS により他のユーザーの空き時間情報を取得
  2. 他のユーザーのメールボックスの予定表から取得した予定アイテムをもとにした詳細表示
    2.1. 他のユーザーのメールボックスにログオンするための接続情報をそのユーザーのメールアドレスによる AutoDiscover で取得
    2.2. 取得した接続情報をもとにメールボックスにログオン
    2.3. 予定表のアクセス権がある場合、予定表フォルダーからアイテムを取得して表示

上記の 1.2. で EWS を使用して空き時間を採取するのですが、ここで失敗してしまうと 2. 以降には進みません。
そのため、EWS を有効化しない場合に表示ができないという現象が発生します。

なお、EWS が無効でも別のユーザーからは予定表が参照できていたようですが、その場合は共有フォルダーのダウンロードがオンになっていて OST にダウンロードされている予定表の表示ができていたということではないかと思います。

EWS は空き時間情報の取得だけでなく、不在時の応答の設定や、代理人設定などでも使用されるものですので、EWS は常に有効化しておくべきでしょう。

msg ファイルとして保存しようとするとメモリ不足でエラーになる原因

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


はじめまして。これほど情報量満載のサイトがある
のを知り感動いたしました。
早速質問させて戴きたく。

Outlook2013上で所定フォルダ上のメールメッセージを
SaveAsメソッドによりディスクにmsg形式で保存する
VBAを作成していますが、メールメッセージがmsg形式
の添付ファイルを持つ場合に保存が失敗し、そこで
メモリエラーでプログラムが途中終了してしまいます。
保存の際、ディスク上に16kBのmsgファイルが出来る
のですがサイズがそこから増えることなく、エラー
「処理を実行するためのメモリが不足しています」が
出て、途中終了するとともに、上記ファイルが自動
削除されます。

【試行実験】
・msg形式での保存では、Unicodeの如何を問わず保存不能
・マニュアルで「ファイル~名前をつけて保存(msg形式)」
でも保存不能
・保存不能のケースで、TXT形式での保存は可能
・添付のmsgファイルが壊れていることはおそらくなく、
ダブルクリックで開いてみることが可能。但しそれを
保存することも同じエラーで不能。
・メールメッセージをexplorer上のD&Dしてmsg形式で
保存することは可能

【相談事項】
所定フォルダ上の複数のメールメッセージを1つずつ
msg形式でプログラムで保存したいので、
・最終的には、対象とするメールメッセージを全て保存したい
・不能なメッセージがあってもそこで途中終了せず、次の対象
の保存に取りかかれるようにせめてしたい

【参考】
添付ファイルのmsgが大きなサイズの場合に失敗するようですが、
以下には必ずしもそうでは無く沢山の相手先が設定されていると
失敗するとの話もあるそうです。もはや私には理解が及びません。
https://www.experts-exchange.com/questions/28536821/Outlook-vba-cannot-save-a-large-Msg-file-to-disk-error-2147024882-There-is-not-enough-free-memory.html
https://social.msdn.microsoft.com/Forums/office/en-US/2836370d-33dd-44fe-b480-26edcf1f6859/does-the-saveas-method-in-microsoftofficeoutlookinterop-have-a-maximum-file-size?forum=outlookdev
何卒よろしくお願いいたします。


msg ファイルがメモリ不足で保存できないという現象が発生する場合、ほとんどは msg ファイルで使用されている OLE 複合ファイルという形式の制限に起因して発生しています。

OLE 複合ファイルとは Windows で一つのファイルに様々な情報をオブジェクトという形で保存する形式のファイルです。
多くのファイル フォーマットは、特定のデータを保存するための形式であり、例えばテキスト形式なら文字列データ、JPG 形式なら画像データなどを保存します。
しかし、OLE 複合ファイルについてはどのようなデータでも保存可能とするため、データをオブジェクトという形で複数保存できるようになっています。
実際、Office 2003 までは Word も Excel も PowerPoint も OLE 複合ファイルの形式でファイルを保存しており、Word ファイルの中に Excel データの一部を埋め込んだり、拡張子を削除してもダブルクリックすると適切なアプリケーションで自動的に開いたりできていました。

Outlook も他の Office 製品と同様に OLE 複合ファイル形式で msg ファイルや oft ファイルを保存しており、メールに含まれる受信者や添付ファイルはそれぞれ個別のオブジェクトとしてファイルに格納されています。
また、メールに別のメールを添付しているという場合、添付されたメールも単一のデータではなく、そのメール自体の受信者や添付ファイルが個別のオブジェクトとして保存されます。
そのため、多数の受信者や添付ファイルを含むメールを保存する場合、一つの OLE 複合ファイル内に大量のオブジェクトが生成されるということになります。
しかし、OLE 複合ファイルでは一つのファイル内で同時に開くことができるオブジェクトの数が制限されており、この制限を超えるような書き込みが行われた場合に「メモリ不足」という意味のエラーが発生するのです。

SaveAs で保存できないアイテムを Explorer にドラッグアンドドロップすると保存ができるようですが、この場合はファイルへの書き込みを行うのは Explorer であり、Explorer が何らかの方法で制限を回避しているものと思われます。
(あるいは単にエラーを無視しているだけかもしれません。)

いずれにせよ、残念ながら、マクロで SaveAs により msg ファイルとして保存する場合にマクロの記述方法やレジストリ設定などでこの制限を回避する方法はありません。
このエラーが発生した場合に処理を中断させたくないということであれば、SaveAs の前に On Error Resume Next を実行し、エラーで中断せずに継続させるようにしてください。

参考リンク:

No MSG For You! – SGriffin’s MAPI Internals

[INFO] MSG 複合ファイルへのメッセージの保存

VBA の実行時エラーを処理する