Outlook 2019 の話

メールの件名から取得した文字列をバーコードとして本文の右側に追記し、印刷するマクロ

outlooklab Outlook 2013 の話、Outlook 2016 の話、Outlook 2019 の話

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

OutlookVBA初心者です。
1クリックで以下の作業を行いたいと考えております。
(環境：Win10/Outlook2013)

・本文の一部だけを抜粋してヘッダーまたはフッターに表示
　もしくは件名の後ろから7文字
・抜粋した文字列をバーコード表示(バーコードフォントは入っております)
・クイック印刷

抜粋する条件は指定文字列の後ろの7文字です。
(バーコードフォントはBC39のため前後に*を結合する必要があります)

また、実現出来たら他の(遠隔地の営業所)PCにも同様の設定を行いたいのですが、
直接使用しているPCにコードをコピペする以外に方法はありませんでしょうか？

お力添えいただけますと幸いです。
何卒宜しくお願い致します。

バーコードの表示が可能なフォントがインストールされている場合、HTML のタグでフォントを指定することにより文字列をバーコードとして表示することが可能です。
以下のマクロはバーコードのフォントの名前が “Bar-Code 39” である場合に本文の右上にバーコードを表示するものです。
なお、コメントでも返信しましたが、マクロをコピーペースト以外で配布することはできず、配布が必要な場合はアドインとして実装する必要があります。

' ここをトリプルクリックでマクロ全体を選択できます。
Public Sub PrintWithBarcode()
     Const BARCODE_FONT = "Bar-Code 39"  ' バーコードのフォントの名前
     Const BARCODE_SIZE = "20.0pt"       ' バーコードのサイズ
     Const BARCODE_LENGTH = 7            ' バーコード文字列の長さ
     Dim objItem As MailItem
     Dim strBarcode As String
     Dim strHtml As String
     Dim iBodyStart As Integer
     Dim objPrint As MailItem
     ' 現在表示中のメールを取得
     If TypeName(ActiveWindow) = "Inspector" Then
         Set objItem = ActiveInspector.CurrentItem
     Else
         Set objItem = ActiveExplorer.Selection(1)
     End If
     ' メールの件名の末尾の文字を取得
     strBarcode = Right(objItem.Subject, BARCODE_LENGTH)
     ' バーコード表示用の HTML 文字列生成
     strBarcode = "<p align='right' style='font-family:" & BARCODE_FONT _
         & ";font-size:" & BARCODE_SIZE & "'>*" & strBarcode & "*</p>"
     ' 本文を HTML で取得
     strHtml = objItem.HTMLBody
     ' BODY タグの開始位置を取得
     iBodyStart = InStr(LCase(strHtml), "<body")
     If iBodyStart > 0 Then
         ' BODY タグの終了位置を取得
         While iBodyStart <= Len(strHtml) And Mid(strHtml, iBodyStart, 1) <> ">"
             iBodyStart = iBodyStart + 1
         Wend
     End If
     iBodyStart = iBodyStart + 1
     ' 印刷用にメールをコピー
     Set objPrint = objItem.Copy
     ' 本文にバーコードのタグを追加
     objPrint.HTMLBody = Left(strHtml, iBodyStart - 1) & strBarcode & Mid(strHtml, iBodyStart)
     ' メールを印刷
     objPrint.PrintOut
     ' 印刷用のメールを閉じて削除
     objPrint.Close olDiscard
     objPrint.Delete
End Sub

マクロの登録方法やメニューへの追加について

シナリオごとの Autodiscover の動作

outlooklab Outlook 2016 の話、Outlook 2019 の話、Outlook の基礎

先週予告した通り、今回は一般的なシナリオごとにどのような手順で 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 の詳細動作

outlooklab Outlook 2016 の話、Outlook 2019 の話、Outlook の基礎

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 の手順です。(Office 2016 の Outlook では行われません。)

技術情報では「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″&gt;
<Response xmlns=”http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a”&gt;
<Account>
<AccountType>email</AccountType>
<Action>redirectUrl</Action>
<RedirectUrl>https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml</RedirectUrl&gt;
</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 の手順により構成されるかの解説をします。

Outlook 2019 の新機能

outlooklab Outlook 2019 の話

9/25 に Office 2019 が一般向けにリリースされ、10/5ました。

Office 2019 に含まれる Outlook 2019 の主な新機能としては以下のようなものがあります。

  • 優先受信トレイ
  • スケーラブル ベクター グラフィックス
  • ハンズフリー入力
  • 3 つ目のタイムゾーンの追加
  • メールの読み上げ
  • クラウド添付ファイルの自動ダウンロード

ただ、現在 Outlook 2016 を使われている方の中には、既に上記の機能を使っている、という人もいるかもしれません。
というのも、Office 2019 はこれまでの Office のバージョン アップとはちょっと異なるからです。

Office 2013 までは、Office のメジャー バージョン アップが 3-4 年に1度の割合で行われ、UI の変更や大掛かりな新機能の追加はメジャー バージョン アップで行われていました。

しかし、Office 2016 では、従来のインストール方式である MSI 版はこれまでと同じ方式 (機能追加なし) である一方、新しい C2R (Click-To-Run) 版では随時新機能が追加されるようになりました。
これは、日々新機能が追加されるクラウドやモバイルのスピード感に対応するための提供方法と思われます。
こうなってくると、メジャー バージョン アップはもはや不要と思われるのですが、問題は MSI 版を使用しているユーザーです。

MSI 版は C2R 版のように新機能が追加されないので、Office の進化に取り残されて行ってしまいます。
そこで、こうした MSI 版を使用しているユーザー向けに最新の Office 2016 の C2R 版を「Office 2019」として提供するというのが、今回のバージョン アップになります。
そのため、Office 2019 という名前ではありますが、ファイルのバージョン番号は 2016 と同じ 16.0 となっています。

Office 2016 の C2R 版の最新を切り出した形でリリースされているため、Office 2019 は C2R 版しか存在しないことになりますが、だからと言って今後 Office の C2R 版の一本化がされるというわけでもなさそうです。
というのも、もともと MSI 版を使用しているユーザーは新機能より安定性を求めており、UI の変更なども極力望んでいないと想定されるからです。
したがって、Office 2019 はリリース後は新機能の追加が凍結され、セキュリティ修正や重要な修正だけが行われるようなものになるでしょう。