Outlook 2016自動探索的實現

摘要

自動探索功能是Outlook用來取得所連接之伺服器的組組資訊。在Outlook 2016伺服器Exchange中，自動探索被視為組組資訊的單一事實點，而且必須正確Outlook功能。本文將說明目前頻道的自動探索的Outlook 2016。有關用戶端通道發行Office 365，請參閱下列 Microsoft 網站：

用戶端的更新通道版本和Office 365編號

Office 365用戶端更新通道發行

其他相關資訊

自動探索計時

自動探索會于下列時間執行：

建立帳戶期間。
在設定間隔收集提供 OOF Exchange可用性服務等 (Web 服務功能的 URL 變更) 。如果此程式成功，則一小時後再嘗試一次。如果嘗試失敗，請在 5 分鐘後進行下一次嘗試。由於所有應用程式都使用背景工作基礎結構，因此每次嘗試可能會錯開 2 Microsoft Office 5%。
回應特定連接失敗。在各種情況下，當連接嘗試失敗時，Outlook啟動自動探索工作，以在任何嘗試修正連接問題時，來取回新設定。
當另一個應用程式使用 MAPI 來調用它時。有關 MAPI 的資訊，請參閱下列 MSDN 文章：Outlook MAPI 參考。

自動探索效率

使用使用者主體名稱 (UPN) 加速自動探索程式。

在加入網域的電腦上，Outlook使用者必須知道 UPN，才能啟動自動探索程式。 UPN 可能用來登入 Windows，在這種情況下，Outlook可以直接從登入認證存取 UPN。但如果使用者使用網域\使用者名稱登入Windows，Outlook使用者只有相同的認證。若要取得 UPN，Outlook必須先在目錄中查看使用者。 Outlook會要求此查詢應追蹤推薦。在複雜的環境中，這可能會導致在找到結果之前先與大量的 DC 進行聯繫。在Outlook使用者發現 UPN 之後，值會緩存在設定檔中，因此此使用者不應再次進行查詢。

若要避免此情況，使用者可以使用 UPN 登入，而不是使用網域\使用者名稱。

ITAR 考慮

Microsoft Office 365提供的功能可支援具有ITAR義務的客戶。在 Outlook 中的自動探索功能中，這項功能集包含原則設定和行為，可確保用於自動探索的服務端點符合主權雲端需求。具體來說，在 Office 365 自動探索程式 ( 步驟 4 和步驟 11) 中列出的特定步驟中，可以使用策略控制項，以確保在自動探索程式期間使用適當的服務端點。

自動探索程式每次Outlook自動探索資訊時，都會使用一組已排序的步驟來嘗試取回包含設定設定之 XML 負載。許多這些步驟都可以使用群組原則物件 (GPO) ，且 GPO 值會包含在步驟描述中。

步驟 1：檢查重新開機案例

在某些情況下，例如當您在 Outlook 執行時新增第二個帳戶時，自動探索負載會快到本地檔案，在重新開機用戶端Outlook使用。第一個自動探索步驟是檢查註冊表，以尋找一些特殊的「開機」資訊，告知 Outlook 您正參與這些重新開機案例的其中一個案例，並讀取特殊本地檔案的自動探索負載。這種情況很少發生，通常不會造成一般自動探索問題。針對此步驟，Outlook決定您在這個特殊的啟動案例，而嘗試取回自動探索 XML 資料失敗時，整個自動探索嘗試會失敗。不會嘗試其他步驟。

此步驟沒有特定的策略控制項。

步驟 2：檢查本地資料喜好設定

Outlook GPO，讓系統管理員部署特定的自動探索 XML 檔案，以用於組組。如果系統管理員已部署此登錄值，並設定autodiscover.xml，Outlook讀取此檔案的自動探索負載。再次發生此情況並不常見，通常不會造成一般自動探索問題。如果此步驟無法取回有效負載，Outlook移至步驟 3。若要進一步瞭解自動探索 XML，請參閱下列 TechNet 文章：計畫在Outlook 2010中自動設定使用者帳戶注意本文是于 2010 Outlook建立。不過，它仍然適用于較新版本的 Outlook。此步驟的策略控制項值如下 ：PreferLocalXML。

步驟 3：檢查 LKG (上一) 良好狀態

當自動探索透過任何步驟成功取回 XML 負載時，負載可能會以「最後已知良好」組組的方式在本地進行緩存。取得自動探索有效負載的第一個常見成功方法是從最後一個已知良好檔案取得。最後一個已知良好 XML 檔案的路徑來自Outlook設定檔。 LKG 步驟僅適用于探索主信箱組組。如果自動探索尋找適用于非主要信箱 (替代、代理人、公用資料夾、群組信箱等) ，則會自動略過 LKG 步驟。如果此步驟無法取回有效負載，Outlook移至步驟 4。此步驟的策略控制項值如下 ：ExcludeLastKnownGoodURL。

步驟 4：檢查 O365 為優先順序

Outlook使用一組啟發式來判斷所提供的使用者帳戶是否來自 Office 365。如果 Outlook確定您為 O365 使用者，會嘗試從已知 O365 端點取得自動探索負載 (通常是 HTTPs://autodiscover-s.outlook.com/autodiscover/autodiscover.xml 或 HTTPs://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml) 。如果此步驟無法取回有效負載，Outlook移至步驟 5。此步驟的策略控制項值如下所示：

ExcludeExplicitO365Endpoint。

ITAR 考慮

根據預設，Outlook查詢已知端點以取回自動探索負載。忽略此步驟的現有策略仍然有效，可用來前往步驟 5，而不嘗試端點。或者，有一個新Outlook會引導使用者查詢中央 Office 365 Config Service，以從它取回自動探索負載的適當 URL。從概念上來說，程式運作方式如下：

您設定了新政策。
在自動探索程式的步驟 4 中，Outlook Config 服務Office 365查詢。
服務會決定 (特定使用者) ITAR 需求是否生效，服務會使用 UPN 的網域資訊，為該使用者返回適當的 URL。
Outlook嘗試從服務提供的 URL 中取回自動探索負載。

使用 Config Service 的新功能之Office 365值為EnableOffice365ConfigService。

附註: 自建立16.0.9327.1000起，將不再使用 EnableOffice365ConfigService 政策。

步驟 5：檢查 SCP 資料

如果電腦已加入網域，Outlook執行 LDAP 查詢，以傳回自動探索 XML 的路徑的服務連接點資料。接著會嘗試對 SCP 查詢傳回的每個 URL 嘗試取回自動探索負載。如果此步驟無法取回有效負載，Outlook移至步驟 6。有關 SCP 的資訊，請參閱下列 MSDN 文章：使用服務連接點發佈。此步驟的策略控制項值如下 ：ExcludeScpLookup。

步驟 6：檢查根網域

針對此步驟，Outlook以 HTTPs：//<網域>/autodiscover/autodiscover.xml 的格式，從初始位址的功能變數名稱建立 URL，並嘗試從產生的 URL 中取回負載。由於許多根網域未針對自動探索進行Outlook，因此系統會故意將嘗試取回期間發生的任何憑證錯誤靜音。如果此步驟無法取回有效負載，Outlook移至步驟 7。此步驟的策略控制項值如下 ：ExcludeHttpsRootDomain。

步驟 7：檢查自動探索網域

針對此步驟，Outlook以 HTTPs：//autodiscover.<網域>/autodiscover/autodiscover.xml 的格式，從初始位址的功能變數名稱建立 URL，並嘗試從產生的 URL 中取回負載。因為這是自動探索資料的主要 URL，Outlook不會將嘗試取回期間發生的任何憑證錯誤靜音。如果此步驟無法取回有效負載，Outlook移至步驟 8。此步驟的策略控制項值如下 ：ExcludeHTTPsAutoDiscoverDomain。

步驟 8：檢查本地資料

在步驟 2 中，Outlook管理員是否已部署策略，以特別檢查自動探索負載為喜好設定。如果沒有設定任何策略，但上述步驟並未取回有效負載，Outlook現在會嘗試從本地檔案中取回有效負載，即使未設定了 PreferLocalXML 設定。如果此步驟無法取回有效負載，Outlook移至步驟 9。此步驟沒有策略控制項。

步驟 9：檢查 HTTP 重新導向

針對此步驟，Outlook傳送要求至自動探索網域 URL (HTTP：//autodiscover.<網域>/autodiscover/autodiscover.xml) 並測試重新導向回應。如果傳回實際的自動探索 XML 負載，而不是重新導向，Outlook會忽略實際的自動探索 XML 回應，因為它是在沒有安全性的情況下 (HTTP) 。如果回應是有效的重新導向 URL，請Outlook重新導向，並嘗試從新 URL 中取回有效負載 XML。 Outlook也會執行憑證檢查，以防止重新導向到此步驟中可能有害的 URL。如果此步驟無法取回有效負載，Outlook移至步驟 10。此步驟的策略控制項值如下 ：ExcludeHttpRedirect。

步驟 10：檢查 SRV 資料

針對此步驟，Outlook會針對 "_autodiscover._tcp.<功能變數名稱>"進行 DNS 查詢，並迴圈流覽尋找使用 HTTPs 做為通訊協定的第一個記錄的結果。 Outlook，然後嘗試從該 URL 中取回負載。如果此步驟無法取回有效負載，Outlook移至步驟 11。此步驟的策略控制項值如下：ExcludeSrvRecord。

步驟 11：檢查 O365 是否失敗

如果上述所有步驟都未返回有效負載，Outlook會使用一組較不嚴格的啟發式來判斷 O365 端點的最終嘗試是否可能有所説明。如果 outlook 認為值得嘗試，它會嘗試已知的 O365 自動探索端點，以防帳戶是 O365 帳戶。此嘗試會使用與步驟 4 相同的目標 URL，而且只會因為嘗試做為最後一個方法，而不是在自動探索程式稍早時，而有所差異。此步驟的策略控制項值如下 ：ExcludeExplicitO365Endpoint。

ITAR 考慮

如果Outlook執行此步驟，但尚未成功取回自動探索負載，會執行兩個測試，以查看是否應該嘗試Office 365已知端點。首先，如果信箱是消費者帳戶， (例如 outlook.com) ，會嘗試已知端點。第二，如果信箱被判定為屬於沒有 ITAR 要求的網域，會嘗試已知的端點。如果信箱被判定為商業且屬於具有 ITAR 需求的網域，則不會嘗試使用已知的Office 365端點。在未來版本中，步驟 11 可能會移至與步驟 4 相同的邏輯，並Office 365 Config Service。進行變更時，本文將會更新以反映新的程式步驟。

自動探索程式區段的重新導向處理步驟 9 是處理非安全重新導向資料的明確步驟。在任何其他安全步驟中，針對任何嘗試取回自動探索 XML 負載，端點的一個可能回應是重新導向回應。此回應會Outlook重新導向至新的不同 URL，以嘗試取回負載。此外，重新導向資料可能包含新的不同電子郵件地址，以做為自動探索嘗試的目標位址。 Outlook三個不同的回復為「重新導向回應」：

包含新 URL (301、302) HTTP 狀態碼
HTTP 狀態碼為 200，但包含有效負載 XML，Outlook重新導向至其他 URL
HTTP 狀態碼為 200，但包含有效負載 XML，Outlook使用不同的 smtp 位址做為目標位址。

在案例 1 和 2 中，Outlook嘗試從新 URL 中取回自動探索 XML，但通訊協定為 HTTPs。未嘗試 (HTTP) URL。此外，即使新 URL 中的通訊協定是 HTTPs，Outlook檢查憑證資訊，以提供額外的安全性。針對 case 3，Outlook從一開始即會啟動整個自動探索程式。如果使用新電子郵件地址 (1-11) 的所有步驟都未成功，Outlook 會回到原始電子郵件地址，移至步驟 5，並繼續嘗試以原始位址來取回 XML 負載。

例外：自動探索程式區段的步驟是自動探索Outlook自動探索負載的一般規則。有各種優化和特殊嘗試可能會稍微變更程式。例如，當您建立新帳戶時，Outlook在內部略過步驟 3 (檢查最後已知良好 (LKG) 資料) ，因為它尚未有最後一個已知良好專案。同樣地，如果因使用目前組組資訊而發生錯誤而觸發嘗試，Outlook 則 Outlook 故意想要再次自動探索，而不想使用 LKG 資訊，因為假設最後一個已知良好資訊會導致失敗。

策略控制項：定義自動探索程式區段的策略值可以是策略型的註冊表值或非策略型值。透過 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 Config Service

金鑰：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover 值：EnableOffice365ConfigService 預設值：0 資料：將此 DWORD 資料設為 1，強制Outlook Config Service Office 365以取回適當的自動探索 URL。

HTTP 的省時設定

金鑰：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover 值：超時預設值：25 秒最小值：10 秒最大值：120 秒

資訊：指定的時出時間會做為 WinHttpSetTimeouts 設定。指定的資料會傳遞到 WinHttpSetTimeouts API 的所有四個參數。這可能會導致無法取得 HTTP 要求以更快速地退出，這會改善整體績效。設定也可能允許 HTTP 要求超過預設 25 秒的時間，將省時設定增加為大於 25 秒。Mapi/Http 通訊協定控制項

金鑰：HKEY_CURRENT_USER\Software\Microsoft\Exchange 值：MapiHttpDisabled 預設值：0 資料：1 = 通訊協定已停用;0 = 已啟用通訊協定

資訊：此值不在自動探索金鑰下。這是一般設定，可控制使用者Outlook使用 Mapi/Http 通訊協定堆疊Exchange以嘗試連接到其他網站。預設Outlook 2016不會停用此通訊協定。這可讓自動探索程式在探索程式新增特殊頁首 (X-MapiHttpCapability：1) ，以便評估及處理 Mapi/Http 通訊協定設定。舊版驗證協商控制

金鑰：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC 值：AllowNegoCapabilityHeader 預設值：0 資料：1 = 已新增頁標題;0 = 未新增頁標題

資訊：請注意，此值不在自動探索金鑰下。此設定會控制是否將驗證協商標頭新加到 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函數

Proxy 驗證處理

金鑰：HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\ 值：AllowOutlookHttpProxyAuthentication 預設值：0 資料：1 = 允許Outlook Proxy 伺服器的驗證挑戰;0 = Proxy 伺服器的無提示失敗驗證挑戰

資訊：此註冊表值可讓您放鬆安全性配置，並詳述 Microsoft 知識庫中的下列文章：3115474 MS16-099：Outlook 2010 安全性更新的描述：2016 年 8 月 9 日

其他通訊協定的自動探索

系統也會使用自動探索功能Outlook EAS Exchange ActiveSync (帳戶) 設定。 EAS 自動探索程式與決策與本文所述的步驟是分開的。例如，EAS 實現並未實現 O365 端點邏輯，而且沒有檢查 SCP 位置的步驟。本文旨在說明自動探索Outlook嘗試從系統取得 MAPI 型通訊協定的詳細Exchange。

參考

有關自動探索的舊版資訊，請參閱 Microsoft 知識庫中的下列文章：

2212902 當您在 \Autodiscover 金鑰下有註冊表設定時，發生意外的自動探索行為

有關自動探索的資訊，請參閱下列 Microsoft 文章：

自動探索Exchange

自動探索服務

摘要