Outlook 2016 изпълнението на автоматично откриване

Обобщена информация

Автоматично откриване е функция, която Outlook използва, за да получите информация за конфигуриране на сървъри, на които се свързва. В Outlook 2016 с Exchange сървъри, автоматично откриване се счита за Единична точка на истината за информация за конфигуриране и трябва да бъде конфигурирана и работи правилно за Outlook да бъде напълно функционална. Тази статия описва изпълнението на Autodiscover в текущия канал Click-to-Run версия на Outlook 2016. За повече информация за изданията на канал на клиент на Office 365 вижте следните уеб сайтове на Microsoft:

Версия и компилация брой актуализация канал съобщения за клиенти на Office 365

Office 365 клиент актуализация канал издания

Допълнителна информация

Времето за автоматично откриване

Автоматично откриване работи на следните дати:

При създаване на акаунт.
На определени интервали за събиране на промени на URL адреси, които предоставят уеб услуги на Exchange функции (OOF, услугата за наличност и т.н.). Ако този процес е успешно, опитайте друг става един час по-късно. Ако опитът е неуспешно, опитайте следващия се прави 5 минути по-късно. Всеки опит да се разпределят потенциално с 25 % поради задача инфраструктура използвани от всички приложения на Microsoft Office.
В отговор на някои повреди връзка. При различни сценарии при опит за свързване е Неуспешно стартиране на Outlook Autodiscover задача да извлече нови настройки на всеки опит за коригиране на проблеми.
Когато друго приложение извиква го с помощта на MAPI. За повече информация относно MAPI, вижте следната статия от MSDN: Outlook MAPI препратка.

Автоматично откриване ефективност

Използвайте Потребителски основно име (UPN) за да ускорите процеса на автоматично откриване.

На компютър, присъединени към домейн Outlook трябва да знаете UPN на потребителя, за да започне процесът на автоматично откриване. UPN може да се използва за влизане в Windows, при което Outlook има пряк достъп до UPN от идентификационни данни за влизане. Но ако потребител използва домейн\потребителско име за влизане в Windows, Outlook само има същите идентификационни данни на потребителя. За да получите UPN, Outlook трябва да първо Потърсете потребител в директорията. Outlook ще поиска, че тази дума следва преследване препратки. В сложни среди това може да предизвика голям брой домейнови контролери за контакт, преди да се намери резултат. След Outlook открие UPN за потребителя, стойността е кеширана в профила и търсене не се случи отново за този потребител.

За да избегнете тази ситуация, потребителят може да влезете като използвате UPN вместо домейн\потребителско име.

ИТАР съображения

Microsoft Office 365 предоставя функции, които могат да поддържат клиенти ИТАРзадължения. В контекста на функцията за автоматично откриване в Outlook това включва настройките на правилата и поведението, което осигурява сервизни крайни точки за автоматично откриване съответстват на изискванията за държавни облак. По-конкретно в Office 365 стъпките, изброени в процеса на автоматично откриване (стъпка 4 и стъпка 11), правилата за контрол има да се гарантира, че съответните сервизни крайни точки в процеса на автоматично откриване.

Процесът на автоматично откриване

Всеки път, че Outlook трябва Autodiscover информация, тя използва набор от стъпки, подредени да се опитате да извлечете XML полезни данни, който съдържа настройките. Много от тези стъпки може да се контролира чрез обекти на групови правила (GPO) и стойността на GPO е включена в описанието на стъпка.

Стъпка 1: Потърсете сценарии за рестартиране

В някои случаи, например когато добавяте акаунт, докато Outlook работи Autodiscover товар е кеширана в локален файл да се използва при рестартиране на клиента на Outlook. Първата стъпка е да проверите в системния регистър за специални "boot" информация, която казва на Outlook, които са в средата на една от тези Autodiscover рестартирате сценарии и да чете Autodiscover полезните данни от специални локален файл. Това е редки случаи и обикновено не са причина общи въпроси за автоматично откриване. За тази стъпка ако Outlook реши в този сценарий специално зареждане и да извлече Autodiscover XML данни е неуспешен, цялата Autodiscover е неуспешен. Няма допълнителни стъпки са опит.

Няма конкретни правила за контрол на тази стъпка.

Стъпка 2: Потърсете локалното предпочитания

Outlook предлага GPO да позволите на администраторите конкретен Autodiscover XML файл за конфигуриране на разполагане. Ако администратор е инсталирал тази стойност в системния регистър и схемата на autodiscover.xml файл, Outlook се чете Autodiscover полезните данни от този файл. Това отново става рядко и обикновено не са причина за общи Autodiscover проблеми. Ако тази стъпка не извлече полезни данни, Outlook премества в стъпка 3. За повече информация относно Autodiscover XML, вижте следната статия на TechNet: план за автоматично конфигуриране на потребителски акаунти в Outlook 2010Забележкатази статия е създадена за Outlook 2010. Обаче е все още съществува за по-нови версии на Outlook. Правилата за управление стойност за тази стъпка е както следва: PreferLocalXML.

Стъпка 3: Потърсете последната известна добра (LKG) данни

Когато Autodiscover извлича полезните данни XML успешно през всяка стъпка, полезните данни може да се кешира локално като "последната известна добра" конфигурация. Първата често успешно начин да получите Autodiscover товар е последната известна добра файла. Пътят на последната известна добра XML файлът идва от профила на Outlook. LKG стъпка се използва само за откриване на конфигурацията на първичната пощенска кутия. Ако Autodiscover търсенето е за не основен кутия (алтернативен, делегат, публична папка, група пощенска кутия и т. н), тогава LKG стъпка автоматично се пропуска. Ако тази стъпка не извлече полезни данни, Outlook премества в стъпка 4. Правилата за управление стойност за тази стъпка е както следва: ExcludeLastKnownGoodURL.

Стъпка 4: Проверка за O365 приоритет

Outlook използва набор от евристики за определяне дали предоставените потребителски акаунт идва от Office 365. Ако Outlook определи уверено, че сте потребител на O365, се прави опит да извлече Autodiscover полезните данни от известни O365 крайни точки (обикновено https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml или https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). Ако тази стъпка не се извлече полезни данни, Outlook премества в стъпка 5. Правилата за управление стойност за тази стъпка е както следва:

ExcludeExplicitO365Endpoint.

ИТАР внимание

По подразбиране Outlook заявки известни крайна точка за извличане на полезните данни автоматично откриване. Съществуващата политика да заобиколи тази стъпка е валидна и може да се използва за да преминете към стъпка 5, без да се опитва крайна точка. Освен това има нови правила, които насочва Outlook заявка Централна Office 365 Config услуга за извличане на съответните URL адреси от който да изтеглите Autodiscover полезните данни. Концептуален процесът работи по следния начин:

Можете да зададете нови правила.
По време на стъпка 4 от процеса на автоматично откриване Outlook заявки за услугата на Office 365 Config.
Услугата определя кои (ако има такива) специални ИТАР нужди са в сила за определен потребител и връща съответните URL за този потребител с помощта на информацията за домейна на UPN.
Outlook се опитва да извлече Autodiscover полезните данни от URL адреси, предоставяни от услугата.

Правилата за контрол стойност за нова функция за използване на Office 365 Config услугата е EnableOffice365ConfigService.

Забележка

След компилация 16.0.9327.1000EnableOffice365ConfigService е вече не се използва.

Стъпка 5: Потърсете SCP данни

Ако компютърът е домейна, Outlook изпълнява LDAP заявка за извличане на данни точка на свързване на услугата, която връща пътя на Autodiscover XML. След това се прави опит за всеки URL адрес, който се връща от SCP търсенето да се опита да извлече Autodiscover полезните данни. Ако тази стъпка не извлече полезни данни, Outlook премества в стъпка 6. За повече информация относно SCP, вижте следната статия от MSDN: публикуване с точки на свързване на услугата. Правилата за управление стойност за тази стъпка е както следва: ExcludeScpLookup.

Стъпка 6: Проверете главен домейн

За тази стъпка Outlook изгражда URL адрес от името на домейна на първоначалния адрес във формата на https://<domain>/autodiscover/autodiscover.xml и да извлече полезните данни от резултат URL. Тъй като много главни области не са конфигурирани за автоматично откриване, Outlook целенасочено silences сертификат грешки, които възникват при извличане на опит. Ако тази стъпка не извлече полезни данни, Outlook премества към стъпка 7. Правилата за управление стойност за тази стъпка е както следва: ExcludeHttpsRootDomain.

Стъпка 7: Проверка Autodiscover домейн

За тази стъпка Outlook изгражда URL адрес от името на домейна на първоначалния адрес във формата на https://autodiscover.<domain>/autodiscover/autodiscover.xml и да извлече полезните данни от резултат URL. Тъй като това е основният URL обикновено за автоматично откриване на данни, Outlook не тишина сертификат грешки, които възникват при извличане на опит. Ако тази стъпка не извлече полезни данни, Outlook премества в стъпка 8. Правилата за управление стойност за тази стъпка е както следва: ExcludeHttpsAutoDiscoverDomain.

Стъпка 8: Проверка за локални данни

В стъпка 2 Outlook проверява дали администратор е инсталирал правила за конкретно проверка за автоматично откриване на полезните данни като предпочитание. Ако няма никакви правила на място, но предишните стъпки не извличане на полезни данни, Outlook сега се опитва да извлече полезни данни от локален файл без PreferLocalXML декларация. Ако тази стъпка не извлече полезни данни, Outlook премества в стъпка 9. Няма правила за контрол на тази стъпка.

Стъпка 9: Проверка за HTTP пренасочвания

За тази стъпка, Outlook изпраща заявка за автоматично откриване домейн URL (http://autodiscover. < домейн > / autodiscover/autodiscover.xml) и тест за пренасочване отговор. Ако се връща действителната Autodiscover XML полезни данни и не пренасочване, Outlook игнорира действителната Autodiscover XML отговор, защото той е възстановен без защита (http). Ако отговорът е валиден пренасочване URL Outlook следва пренасочване и да извлече XML полезни данни от новия URL адрес. Outlook ще изпълнява сертификат проверки, за да предотвратите пренасочване към злонамерени URL адреси в тази стъпка. Ако тази стъпка не извлече полезни данни, Outlook премества в стъпка 10. Правилата за управление стойност за тази стъпка е както следва: ExcludeHttpRedirect.

Стъпка 10: Проверка за SRV данни

За тази стъпка Outlook прави заявка DNS за "_autodiscover._tcp. < домейн >" и линии чрез резултати от търсене за първия запис, което се използва https протокола. Outlook се опитва да извлече полезните данни от този адрес. Ако тази стъпка не извлече полезни данни, Outlook премества стъпка 11.Правилата за управление стойност за тази стъпка е както следва: ExcludeSrvRecord.

Стъпка 11: Проверете за O365 като failsafe

Ако всички предишни стъпки не връща полезни данни, Outlook използва по-малко ограничителен набор от евристики да реши потенциално полезни последен опит да O365 крайни точки. Ако outlook реши, че опитът е полезно, тя се опитва известните O365 Autodiscover крайни точки акаунт е O365 акаунт. Този опит използва същите целеви URL адреси, като стъпка 4 и се различава само в това, че е опитал като последно средство и не по-рано в процеса на автоматично откриване. Правилата за управление стойност за тази стъпка е както следва: ExcludeExplicitO365Endpoint.

ИТАР съображения

Ако Outlook получава тази стъпка и не е успешно извлечен Autodiscover полезни данни, два теста се извършват за да видите дали трябва да се опита известни крайни точки на Office 365. Първо Ако пощенската кутия на потребителски акаунт (например outlook.com), известни крайни е опит. Второ Ако пощенската кутия се определя принадлежи към домейн, който няма ИТАР изисквания, известни крайни е опит. Ако пощенската кутия се определя търговски и принадлежи към домейн, който е ИТАР изисквания, няма опит за известни крайни точки на Office 365. В бъдеще издания стъпка 11 може да преместите същата логика като стъпка 4 и повикване Config услугата на Office 365. При тази промяна, тази статия ще се актуализира за отразяване на новия стъпката.

Пренасочване на обработка

Стъпка 9 в секцията автоматично откриване на процеса е изрично стъпка, за да се справят незащитен пренасочване данни. В някой от другите защитени стъпки, за всякакви опити за извличане на Autodiscover XML полезните данни един възможен отговор от крайната точка е пренасочване отговор. Този отговор казва на Outlook да се пренасочи към нов, различен URL да се опита да извлече полезните данни. Освен това пренасочване на данни може да съдържа нов, различен имейл адрес да се използва като целеви адрес за автоматично откриване на опит. Outlook смята три отделни отговора да е "пренасочване на отговор":

HTTP код на състоянието (301, 302) с нов адрес
Код на състояние на HTTP 200, но с полезни данни XML, което казва на Outlook за пренасочване към друг URL адрес
HTTP код на състоянието на 200, но с полезни данни XML, което казва на Outlook да използва различен smtp адрес като адрес на целта.

В случай 1 и 2 Outlook се опитва да извлече autodiscover XML от новия URL адрес, при условие че протокола https. Незащитен (http) URL адреси не са опит. Освен това дори ако протокола в новия URL адрес е https, Outlook ще проверява сертификат информация, за да предостави допълнителна мярка за сигурност. Случай 3 Outlook стартира целия autodiscover процеса отначало. Ако всички стъпки (1-11) се опитват без успех с помощта на новия имейл адрес, след това Outlook се връща към първия имейл адрес, премества в стъпка 5 и продължава Опитът за извличане на XML товар с оригиналните адрес.

Изключения

Стъпките в процеса на автоматично откриване са общите правила за как Outlook се опитва да получи autodiscover полезните данни. Има различни оптимизации и изключение опити, които могат да променят процеса малко. Например когато създаването на нов акаунт, Outlook вътрешно пропуска стъпка 3 (проверка за последната известна добра (LKG) данни), тъй като все още не са последната известна добра запис. По същия начин, ако Опитът е предизвикана поради грешка с помощта на текущата конфигурация информация, след това Outlook целенасочено иска да autodiscover отново и не използвайте LKG информация защото вероятно последната известна добра информация води до грешка.

Правила за управление

Правила за стойностите, които са дефинирани от процеса на автоматично откриване раздел може да бъде стойности в системния регистър, основано на правила или non основано на правила стойности. Когато те са разположени 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

Ключ: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover Стойност: EnableOffice365ConfigService По подразбиране: 0 Данни: Задайте DWORD данните на 1, за да накарате Outlook да се обадите на услугата за конфигуриране на Office 365 да извлече съответния Autodiscover URL адреси.

Настройки на изчакване на HTTP

Ключ: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover Стойност: изчакване По подразбиране: 25 секунди Минимум: 10 секунди Максимум: 120 секунди

Информация за: Определени периоди на изчакване се използват като WinHttpSetTimeouts настройки. Подробности се подава на всички от четирите параметъра на WinHttpSetTimeouts API. Това потенциално позволява HTTP искането, не може да се стигне за по-бързо, което ще подобри цялостната производителност. Настройките може да позволи на HTTP заявка, отнема повече време от по подразбиране преди да успее чрез увеличаване на настройката на времето за изчакване на нещо по-големи от преди. MAPI/Http протокол за контрол

Ключ: HKEY_CURRENT_USER\Software\Microsoft\Exchange Стойност: MapiHttpDisabled По подразбиране: 0 Данни: 1 = протокол е забранено; 0 = протоколът е активиран

Информация: Тази стойност не се намира под ключа за автоматично откриване. Това е общ определя, дали Outlook може да опита да се свърже с Exchange с помощта на Mapi/Http протокол стека. По подразбиране в Outlook 2016 не са забранени протокола. Това позволява да добавите специални заглавка процеса на автоматично откриване (X-MapiHttpCapability:1) на откриването процес, така че настройките на Mapi/Http протокол могат да бъдат оценени и обработва. Наследено удостоверяване предаване на контрола

Ключ: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC Стойност: AllowNegoCapabilityHeader По подразбиране: 0 Данни: 1 = заглавките се добавят; 0 = не се добавят заглавки

Информация: Бележка тази стойност не е под ключа за автоматично откриване. Тази настройка определя дали заглавка за предаване на удостоверяване се добавя към http заявки. Съдържанието на заглавката зависят удостоверяването възможностите на клиентския компютър. Заглавка на пример може да бъде: "X-преговорите-способност: договори, pku2u, Kerberos, NTLM, MSOIDSSP". Тази стойност в системния регистър и заглавка, която добавя са рядко използван във всяка модерна удостоверяване стека и много вероятно да повлияе на процеса на tAodiscover отрицателен или положителен начин. Отстраняване на грешки на сертификат

Ключ: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover Стойност: ShowCertErrors По подразбиране: 0 Данни: 1 = Покажи сертификата предупреждения/грешки; 0 = не се показват предупреждения за сертификат

Информация: Тази стойност определя как Outlook манипулатори сертификат за грешки и предупреждения, които са получили при изпълнява http задачи. Outlook може да промените тази настройка в някои случаи (стъпка 6 в секцията автоматично откриване на процеса), но за общия случай, ако тази настройка е активирана, Outlook ще подкана с диалоговия прозорец за защита, която показва сертификат грешка или предупреждение и позволяват OK или Отмяна на 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: 9 август 2016

Автоматично откриване на други протоколи

Автоматично откриване като функция се използва от Outlook да откриете и конфигуриране на акаунти за Exchange ActiveSync (EAS). EAS Autodiscover процес и вземане на решение е отделен от стъпките, описани в тази статия. Например EAS изпълнението не изпълнява O365 крайни логика и не е стъпка, която ще проверява за SCP места. Тази статия е с обхват описва подробно стъпките, които Outlook използва за автоматично откриване опити за получаване на MAPI протоколи от Exchange.

Препратки

Наследена информация за автоматично откриване може да се намери в следната статия в базата знания на Microsoft:

2212902 неочаквано Autodiscover поведение, когато имате настройките на системния регистър под \Autodiscover ключ

За повече информация за автоматично откриване вижте следните статии на Microsoft:

Автоматично откриване на Exchange

Услугата