摘要
Autodiscover 是 Outlook 用來取得連接伺服器設定資訊的功能。 在 Outlook 2016 與 Exchange 伺服器中，Autodiscover 被視為設定資訊的唯一真實點，必須正確配置並運作，Outlook 才能完整運作。 本文說明 Outlook 2016 目前 Click-to-Run 版本中自動發現功能的實作。 欲了解更多關於 Office 365 用戶端通道釋出的資訊，請參閱以下 Microsoft 網站：
其他資訊
自動發現定時
自動發現會在以下時間執行：
- 在帳號建立時。
- 在固定間隔內收集提供 Exchange Web Service 功能 (OOF、可用性服務等 URL 變更) 。 若此過程成功，一小時後再嘗試一次。 若未成功，下一次嘗試則在5分鐘後進行。 由於所有 Microsoft Office 應用程式使用的背景任務基礎架構，每次嘗試的延遲可能被錯開多達 25%。
- 針對某些連線故障。 在各種情況下，當連線嘗試失敗時，Outlook 會啟動自動發現任務，以取得新的設定以修正連線問題。
- 當另一個應用程式使用 MAPI 呼叫時， 欲了解更多關於 MAPI 的資訊，請參閱以下 MSDN 文章： Outlook MAPI 參考資料。
自動發現效率
請使用 使用者主體名稱 (UPN) 來加速自動發現流程。
在網域加入的電腦上，Outlook 需要知道使用者的 UPN 才能啟動自動發現程序。 UPN 可能被用來登入 Windows，這時 Outlook 就能直接從登入憑證存取 UPN。 但如果使用者使用 domain\username 在 Windows 登入，Outlook 只會給使用者相同的帳號憑證。 為了取得 UPN，Outlook 必須先在目錄中查詢使用者。 Outlook 會要求此查詢追蹤推薦。 在複雜環境中，這可能導致在找到結果前需要接觸大量 DC。 Outlook 在發現該使用者的 UPN 後，該值會被快取到設定檔中，且該使用者不應再進行查詢。
為避免這種情況，使用者可使用UPN登入，而非網域/使用者名稱。
ITAR 考量
Microsoft Office 365 提供可支援客戶履行 ITAR 義務的功能。 在 Outlook 的 Autodiscover 功能中，此功能集包含政策設定與行為，確保用於 Autodiscover 的服務端點符合主權雲端需求。 具體來說，在自動發現流程中列出的第 4 步與第 11 步) 中列出的Office 365具體步驟中， ( 可進行政策控制，以確保在自動發現過程中使用適當的服務端點。
自動發現流程 每次 Outlook 需要自動發現資訊時，都會依序嘗試取得包含設定的 XML 有效載荷。 許多步驟可透過 GPO) (群組原則 物件來控制，且 GPO 值包含在步驟描述中。
步驟 1：檢查重啟情境
在某些情況下，例如在 Outlook 執行時新增第二個帳號，Autodiscover 的負載會被快取到本地檔案，以便在重新啟動 Outlook 用戶端時使用。 Autodiscover 的第一步是檢查登錄檔，尋找某些特殊的「開機」資訊，告訴 Outlook 你正處於這些重啟情境中，並從特殊的本地檔案讀取 Autodiscover 的有效載荷。 這種情況很少見，通常不是一般 Autodiscover 問題的原因。 在此步驟中，如果 Outlook 判定你處於這種特殊的開機情境，且嘗試取回 Autodiscover XML 資料失敗，整個 Autodiscover 嘗試也會失敗。 不會嘗試其他步驟。
這個步驟沒有特定的政策控制。
步驟 2：檢查本地資料偏好
Outlook 提供一個 GPO，讓管理員可以部署特定的 Autodiscover XML 檔案以進行設定。 若管理員部署了此登錄檔值並做種 autodiscover.xml 檔案，Outlook 會從該檔案讀取 Autodiscover 有效載荷。 這同樣是罕見的情況，通常不會造成一般 Autodiscover 問題。 若此步驟無法取得有效載荷，Outlook 將進入第三步。
欲了解更多 Autodiscover XML 的資訊，請參閱以下 TechNet 文章： 計畫在 Outlook 2010 中自動配置使用者帳號
註 本文為 Outlook 2010 撰寫。 不過，它對後續版本的 Outlook 仍然適用。
此步驟的政策控制值如下： PreferLocalXML。
步驟三：檢查最後已知貨物 (LKG) 資料
當 Autodiscover 成功透過任何步驟檢索 XML 有效載荷時，該有效載荷可能會以「最後已知良好」配置的身份在本地快取。 第一個常見成功取得 Autodiscover payload 的方法就是從這個已知良好檔案中取得。 最後已知正常的 XML 檔案路徑來自 Outlook 設定檔。 LKG 步驟僅用於發現主要信箱配置。 如果 AutoDiscover 查詢是針對非主要信箱， (備用、代理、公共資料夾、群組信箱等) ，那麼 LKG 步驟會自動跳過。 如果此步驟無法取得有效載荷，Outlook 將進入第四步。
此步驟的政策控制值如下： ExcludeLastKnownGoodURL。
步驟四：檢查 O365 是否為優先
Outlook 會用一套啟發式方法來判斷所提供的使用者帳號是否來自 Office 365。 如果 Outlook 確定您是 O365 使用者，會嘗試從已知的 O365 端點取回 Autodiscover 有效載荷， (通常是 https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml 或 https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml) 。 若此步驟無法取得有效載荷，Outlook 將進入第 5 步。
此步驟的政策控制值如下：
ExcludeExplicitO365Endpoint.
ITAR 考量
預設情況下，Outlook 會查詢已知端點以取得 Autodiscover 有效載荷。 現有的繞過此步驟的政策仍然有效，且可直接進入第 5 步，無需嘗試端點。 另外，有一項新政策會指示 Outlook 查詢中央的 Office 365 設定服務，以取得適當的 URL，進而取得 Autodiscover 的載荷。 概念上，這個過程如下：
- 你制定新政策。
- 在自動發現程序的第 4 步，Outlook 會查詢 Office 365 設定服務。
- 服務 (判斷指定使用者是否有) 特別的 ITAR 需求，並利用 UPN 的網域資訊回傳該使用者的適當網址。
- Outlook 嘗試從服務提供的 URL 中擷取 Autodiscover 有效載荷。
使用 Office 365 設定服務的新功能所設定的政策控制值為 EnableOffice365ConfigService。
注意
自建檔 16.0.9327.1000 起， EnableOffice365ConfigService 政策已不再使用。
步驟五：檢查SCP資料
若電腦已加入網域，Outlook 會執行 LDAP 查詢以取得服務連接點資料，回傳 Autodiscover XML 的路徑。 接著會嘗試對每個 SCP 查詢回傳的 URL，嘗試取得 Autodiscover 有效載荷。 若此步驟無法取得有效載荷，Outlook 將進入第 6 步。
欲了解更多關於 SCP 的資訊，請參閱以下 MSDN 文章： 使用服務連接點發佈。
此步驟的政策控制值如下： ExcludeScpLookup。
步驟 6：檢查根網域
在此步驟中，Outlook 會從初始地址的網域名稱建立一個 URL，格式為 https://< domain>/autodiscover/autodiscover.xml，並嘗試從所得 URL 中取得有效載荷。 由於許多根網域未設定自動發現，Outlook 會刻意靜音在嘗試檢索時發生的憑證錯誤。 如果此步驟無法取得有效載荷，Outlook 將進入第 7 步。
此步驟的政策控制值如下： ExcludeHttpsRootDomain。
步驟七：檢查 Autodiscover 網域
在此步驟中，Outlook 會從初始地址的網域名稱建立一個 https://autodiscover 格式的 URL。<>domain/autodiscover/autodiscover.xml 並嘗試從產生的 URL 中取得有效載荷。 由於這是 Autodiscover 資料的主要 URL，Outlook 不會靜音在嘗試擷取時發生的任何憑證錯誤。 若此步驟無法取得有效載荷，Outlook 將進入第 8 步。
此步驟的政策控制值如下： ExcludeHttpsAutoDiscoverDomain。
步驟八：檢查本地資料
在步驟 2 中，Outlook 檢查管理員是否部署了政策，專門以 Autodiscover payload 作為偏好。 如果沒有相關政策，但之前的步驟沒有取得有效載荷，Outlook 現在即使沒有啟用 PreferLocalXML 設定，也會嘗試從本地檔案取得有效載荷。 若此步驟無法取得有效載荷，Outlook 將進入第 9 步。
此步驟沒有政策控制。
步驟 9：檢查 HTTP 重定向
此步驟中，Outlook 會向自動發現網域的 URL (http://autodiscover 發送請求。<>網域/自動發現/autodiscover.xml) 並測試重定向回應。 如果回傳的是實際的 Autodiscover XML 有效載荷而非重定向，Outlook 會忽略實際的 Autodiscover XML 回應，因為該回應是未 (http) 安全性下取得的。 若回應是有效的重定向 URL，Outlook 會依照該重定向 URL 嘗試從新網址取得有效載荷 XML。 Outlook 也會在此步驟執行憑證檢查，以防止被導向可能有害的 URL。 若此步驟無法取得有效載荷，Outlook 將進入第 10 步。
此步驟的政策控制值如下： ExcludeHttpRedirect。
步驟 10：檢查 SRV 資料
在此階段，Outlook 會查詢「_autodiscover._tcp.<網域名稱>」，並循環搜尋第一個使用 HTTPS 作為協定的紀錄。 Outlook 接著嘗試從該 URL 取得有效載荷。 若此步驟無法取得有效載荷，Outlook 將進入第 11 步。
此步驟的政策控制值如下： 排除SrvRecord。
步驟 11：檢查 O365 是否為保險
如果之前所有步驟都沒有回傳有效載荷，Outlook 會使用較寬鬆的啟發式方法來判斷最後嘗試對 O365 端點是否有潛在幫助。 如果 Outlook 認為值得嘗試，會嘗試已知的 O365 自動發現端點，前提是該帳號是 O365 帳號。 此嘗試使用與第四步相同的目標網址，唯一不同的是它是作為最後手段嘗試，而非在自動發現流程的早期階段。
此步驟的政策控制值如下： ExcludeExplicitO365Endpoint。
ITAR 考量
如果 Outlook 進入此階段仍未成功取得 Autodiscover 的有效載荷，將進行兩次測試以判斷是否應該嘗試這些知名的 Office 365 端點。 首先，若信箱是消費者帳戶 (例如 outlook.com) ，則嘗試使用知名端點。 其次，若信箱被認定屬於不符合 ITAR 要求的網域，則嘗試使用已知端點。 若該信箱被認定為商業且屬於有 ITAR 要求的網域，則不會嘗試傳送知名的 Office 365 端點。 未來版本中，步驟 11 可能會移至與步驟 4 相同的邏輯，並呼叫 Office 365 設定服務。 當該變更完成後，本文將更新以反映新的流程步驟。
自動發現流程中第 9 步的重定向處理是明確處理非安全重定向資料的步驟。 在其他安全步驟中，對於任何嘗試取得 Autodiscover XML 有效載荷的嘗試，端點可能的回應是重定向回應。 這個回應會告訴 Outlook 重新導向到一個新的、不同的 URL，以便嘗試取得有效載荷。 此外，重定向資料中可能包含一個新的、不同的電子郵件地址，作為自動發現嘗試的目標地址。 Outlook 將三個獨立的回應視為「重定向回應」：
- HTTP 狀態碼 (301、302) 並換上新網址
- HTTP 狀態碼為 200，但 payload XML 會告訴 Outlook 將重定向到不同的 URL
- HTTP 狀態碼為 200，但 payload XML 告訴 Outlook 使用不同的 smtp 位址作為目標位址。
在情況 1 和 2 中，Outlook 嘗試從新網址中取得自動發現的 XML，前提是協定是 https。 不安全的 (http) URL 不會嘗試。 此外，即使新網址的協定是 https，Outlook 仍會檢查憑證資訊以提供額外的安全措施。
第三種情況是 Outlook 從頭開始整個自動發現流程。 如果嘗試 (1至11) 所有步驟都未成功使用新電子郵件地址，Outlook 會返回原始電子郵件地址，進入步驟5，繼續嘗試取得帶有原始地址的 XML 有效載荷。
例外：自動發現流程中的步驟是 Outlook 嘗試取得自動發現有效載荷的一般規則。 有各種優化和特殊嘗試可能會稍微改變流程。 例如，在新建帳戶時，Outlook 內部會跳過第 3 步 (檢查最後一次可行貨物 (LKG) 資料) ，因為目前還無法有最後一次已知良好紀錄。 同樣地，如果嘗試是因為使用目前設定資訊而錯誤觸發，Outlook 會故意再次自動發現，而不會使用 LKG 資訊，因為最後已知的良好資訊可能導致失敗。
政策控制 Autodiscover Process 區段定義的政策值可以是基於政策的登錄值或非基於政策的值。 當這些設定是透過 GPO，或手動設定政策鍵時，設定會優先於非政策鍵。
非政策說明：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
政策重點：HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover
每個值的類型為 DWORD。
PreferLocalXML 與其他控制值不同，因為設定為 1 時，Outlook 會開啟該步驟。 對於剩餘的數值，設定為 1 時，Outlook 會要求關閉或跳過相關步驟。 例如，將 ExcludeHttpsRootDomain 設為 1，Outlook 就不會執行第 6 步。
額外登錄控制
Outlook 提供數個額外的基於登錄檔的設定選項，可能會影響自動發現流程：
使用 Office 365 設定服務
說明：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Value： EnableOffice365ConfigService
預設值：0
資料：將此 DWORD 資料設為 1，強制 Outlook 呼叫 Office 365 設定服務以取得適當的 Autodiscover URL。
HTTP 逾時設定
說明：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
價值：暫停
預設時間：25秒
最少：10秒
最長：120秒
資訊：指定的逾時時間會被用作 WinHttpSetTimeout 的設定。 指定的資料會傳遞到 WinHttpSetTimeouts API 的四個參數。 這有可能讓無法被存取的 HTTP 請求更快逾時，進而提升整體效能。 設定也可以讓 HTTP 請求即使超過 25 秒預設時間也能成功，方法是將逾時設定提高到 25 秒。
Mapi/Http 協定控制
說明：HKEY_CURRENT_USER\Software\Microsoft\Exchange
值：MapiHttpDisabled
預設值：0
資料：1 = 協定已停用;0 = 協定已啟用
資訊：這個數值不在 Autodiscover 鍵下。 這是一個通用設定，用來控制 Outlook 是否能透過 Mapi/Http 協定堆疊嘗試連接 Exchange。 Outlook 2016 的預設設定是不停用這個協定。 這讓 Autodiscover 程序能在發現程序中加入特殊標頭 (X-MapiHttpCapability：1) ，以便評估與處理 Mapi/Http 協定設定。
舊有認證協商控制
說明：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC
值：AllowNegoCapabilityHeader
預設值：0
資料：1 = 標頭被加入;0 = 未加入標頭
資訊：請注意，這個數值不在 Autodiscover 鍵下。 此設定控制是否會在 HTTP 請求中加入認證協商標頭。 標頭的內容取決於用戶端電腦的認證能力。 範例標頭可能是：「X-Nego-Capability： Negotiate， pku2u， Kerberos， NTLM， MSOIDSSP」。 這個登錄檔值及其新增標頭在任何現代認證堆疊中很少使用，且極不可能對 tAodiscover 流程產生正面或負面的影響。
憑證錯誤處理
說明：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
值：ShowCertErrors
預設值：0
資料：1 = 顯示憑證警告/錯誤;0 = 不顯示證書警告
資訊：此值控制 Outlook 執行 http 任務時接收的憑證錯誤與警告。 Outlook 在某些情況下可能會在自動發現流程第 6 步 () 覆蓋此設定，但一般情況下，若啟用此設定，Outlook 會跳出安全對話框，顯示憑證錯誤或警告，並允許使用者確認或取消 Http 請求。 有三個特定的憑證錯誤，使用者可以選擇忽略，並讓 Outlook 重新嘗試 http 請求：
WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID – 憑證屬性中的日期有問題
WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID – 憑證屬性中的通用名稱有問題
WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA – 憑證屬性中的憑證授權機構有問題
關於這三種憑證錯誤狀態的更多資訊，請參閱 WINHTTP_STATUS_CALLBACK回調函式
代理驗證處理
說明：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
值：AllowOutlookHttpProxyAuthentication
預設值：0
資料：1 = 允許 Outlook 處理來自代理伺服器的認證挑戰;0 = 代理伺服器的認證挑戰無聲失敗
資訊：此登錄檔值允許放寬安全設定，詳見 Microsoft 知識庫的以下文章：
3115474 MS16-099：Outlook 2010 安全更新說明：2016 年 8 月 9 日
其他協議的自動發現
AutoDiscover 作為一項功能，Outlook 也用來發現並設定Exchange ActiveSync (EAS) 帳號。 EAS 自動發現的流程與決策與本文所述步驟是分開的。 例如，EAS 實作未實作 O365 端點邏輯，也沒有檢查 SCP 位置的步驟。 本文旨在說明 Outlook 在 Autodiscover 嘗試從 Exchange 取得基於 MAPI 協定的詳細步驟。
參考資料
關於 autodiscover 的舊有資訊可在 Microsoft 知識庫的以下文章中找到：
2212902 在 \Autodiscover 鍵下設定登錄檔時，意外自動發現行為
欲了解更多 Autodiscover 資訊，請參閱以下 Microsoft 文章：