укажите какую учетную запись вы хотите использовать чтобы открыть документ autodiscover xml
Укажите какую учетную запись вы хотите использовать чтобы открыть документ autodiscover xml
Вопрос
Клиенты с Outlook 2016
Сервер Exchange 2010
И клиенты и сервер находятся в одной, внутренней сети(и в одной подсети).
Возможности полноценно организовать службу Autodiscover нет.
Как показать Outlook где на локальном диске лежит файл Autodiscover.xml я понимаю.
Что должен содержать файл Autodiscover.xml? В моем случае этого:
Что нужно вписать в файл Autodiscover.xml?
Ответы
В Office 365 это немного по другому работает. Вы не можете использовать Domain\User, вы используете user@domain.com запись для авторизации.
Office 365 проверяется autodiscover при каждой сессии, а настройки реестра перетираются с каждым обновлением, а иногда в режиме реального времени.
PS. Я бы настроил hybrid и не парился.
5f886935-fb5f-4873-bb67-eb4feb0bfbb1
Это Guid другого ящика (откуда вы взяли XML), и это точка подключение к почтовому ящику клиента.
Неожиданное поведение автообнаружения, когда есть настройки в разделе \Autodiscover
Симптомы
Когда Microsoft Outlook пытается извлечь данные автообнаружения с сервера, на котором работает Microsoft Exchange Server, могут возникнуть непредвиденные результаты, если вы используете одно или несколько доступных значений реестра, которые можно использовать для управления автообнаружением.
Причина
Когда Outlook пытается связаться со службой автообнаружения на сервере Exchange с ролью сервера клиентского доступа (CAS), он может использовать несколько различных методов для доступа к службе в зависимости от топологии клиент-сервер. В настоящее время реализованы следующие методы, используемые в Outlook:
По умолчанию, Outlook использует один или несколько из этих методов, если он не может получить доступ к службе автообнаружения. Например, в сценарии с компьютером, не присоединенным к домену, Outlook попытается подключиться к предварительно определенным URL-адресам (например, https://autodiscover.contoso.com/autodiscover/autodiscover.xml ) с помощью DNS-сервера. В случае неудачи Outlook попробует использовать метод перенаправления HTTP. Если это тоже не удается, Outlook попытается использовать метод поиска записей SRV. В случае неудачного использования всех методов поиска Outlook не сможет получить настройку мобильного Outlook и параметры URL-адреса.
Дополнительные сведения о различных методах подключения к службе автообнаружения, используемых в Outlook, см. в следующих документах о службе автообнаружения Exchange:
Однако в некоторых сценариях для получения доступа к службе автообнаружения может потребоваться использование значений реестра/политики, связанные с автообнаружением, для управления методами, используемыми в Outlook. Однако, если неправильно настроить значения реестра/политики автообнаружения, вы можете помешать Outlook получать информацию автообнаружения.
Решение
Чтобы решить эту проблему, просмотрите данные реестра, связанные с автообнаружением, которые могут храниться в вашем клиенте Outlook, чтобы убедиться, что эти данные настроены правильно. Кроме того, если вы не уверены в том, нужны ли данные реестра, рассмотрите возможность изменения данных для любого из этих значений реестра на ноль (0), а затем протестируйте Outlook, чтобы увидеть, есть ли разница в автообнаружении.
В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о резервном копировании и восстановлении реестра см. в следующей статье базы знаний Майкрософт: 322756 Создание резервной копии и восстановление реестра Windows
Откройте редактор реестра.
Найдите и выделите следующий подраздел реестра:
x.0 в этом маршруте реестра соответствует версии Outlook (16.0 = Outlook 2016, 15.0 = Outlook 2013, 14.0 = Outlook 2010, 12.0 = Outlook 2007).
Просмотрите следующие возможные значения DWORD, которые могут быть расположены под ключом \Autodiscover.
Это значение позволяет администраторам Exchange указать, будут ли пользователи проходить проверку подлинности с использованием электронной почты настроенной учетной записи или имени-субъекта пользователя (UPN) во время сценариев автообнаружения. Для получения дополнительной информации см. Обновление для Outlook 2016 от 5 ноября 2019 г. (KB4484139).
ExcludeLastKnownGoodURL (применяется только к версии Outlook 2010 14.0.7140.5001 и более поздним версиям)
ExcludeExplicitO365Endpoint (применяется только к версии Outlook 2016 16.0.6741.2017 и более поздним версиям)
В некоторых документах указывается, что в этом сценарии Outlook использует ExcludeSrvLookupvalue. К сожалению, эта документация неверна, так как значение ExcludeSrvLookup не существует в коде Outlook. Только значение ExcludeSrvRecordregistry используется Outlook для управления поиском записей SRV для автообнаружения. Поэтому, если вы обнаружите значение ExcludeSrvLookup под подразделом \Autodiscover, вы можете изменить его значение до 0.
Повторите шаг 3, используя следующий подраздел реестра:
x.0 в этом маршруте реестра соответствует версии Outlook (16.0 = Outlook 2016, 15.0 = Outlook 2013, 14.0 = Outlook 2010, 12.0 = Outlook 2007).
Дополнительная информация
Вы можете использовать следующие шаги в Outlook, чтобы определить метод, с помощью которого Outlook пытается извлечь данные автообнаружения из Exchange:
Следующий рисунок показывает вкладку журнала, когда значения ExcludeScpLookup и ExcludeHttpsAutoDiscoverDomain были установлены на 1.
Сравните эту информацию, когда только значение ExcludeScpLookup установлено до 1.
Игнорируйте ошибки на этих рисунках, потому что эта информация предназначена только для того, чтобы показать различные попытки поиска, предпринимаемые Outlook.
Кроме того, если вы включите ведение журнала в Outlook (2007 или 2010), различные попытки поиска автообнаружения можно найти в файле %temp%\Olkdisc.log Этот файл журнала также содержит все параметры реестра, которые вы настроили для исключения любых методов поиска автообнаружения. На следующем рисунке четко видно, что значения ExcludeScpLookup и ExcludeHttpsAutoDiscoverDomain равны 1.
Для получения дополнительной информации об управлении и администрировании автообнаружения на стороне клиента перейдите к следующей статье базы знаний:
Укажите какую учетную запись вы хотите использовать чтобы открыть документ autodiscover xml
Вопрос
Клиенты с Outlook 2016
Сервер Exchange 2010
И клиенты и сервер находятся в одной, внутренней сети(и в одной подсети).
Возможности полноценно организовать службу Autodiscover нет.
Как показать Outlook где на локальном диске лежит файл Autodiscover.xml я понимаю.
Что должен содержать файл Autodiscover.xml? В моем случае этого:
Что нужно вписать в файл Autodiscover.xml?
Ответы
В Office 365 это немного по другому работает. Вы не можете использовать Domain\User, вы используете user@domain.com запись для авторизации.
Office 365 проверяется autodiscover при каждой сессии, а настройки реестра перетираются с каждым обновлением, а иногда в режиме реального времени.
PS. Я бы настроил hybrid и не парился.
5f886935-fb5f-4873-bb67-eb4feb0bfbb1
Это Guid другого ящика (откуда вы взяли XML), и это точка подключение к почтовому ящику клиента.
Ручная настройка подключения к Exchange в Outlook 2016
В Outlook 2016 разработчики полностью убрали возможность ручной настройки почтового профиля пользователя для подключения к серверу Exchange. Предполагается, что Outlook 2016 должен автоматически получить всю необходимую информацию с помощью процедуры Autodiscover (все возможные варианты, позволяющие клиенту выполнить автообнаружение описаны в статье Медленная работа автообнаружения Exchange Autodiscover в Outlook 2016).
Однако в некоторых случаях автообнаружение не может быть выполнено (не правильно настроен Autodiscover, проблемы с доступом к файлу Autodiscover.xml и т.п.) и пользователю нужно настроить подключение к Exchange серверу вручную. Разберемся, как это сделать.
Метод 1. Локальный XML редирект
Метод 2. Локальный XML файл с настройками подключения к Exchange
В том случае, если URL с файлом autodiscover.xml недоступен, придется создать локальный XML файл с полными настройками пользователя для подключения к Exchange. Пример параметров, которые нужно указывать в этом файле можно получить с уже настроенного клиента Outlook. Для этого, перейдите в папку C:\Users\%username%\AppData\Local\Microsoft\Outlook, где вы найдете файл с именем [длинныйGUID]-Autodiscover.xml.
Скопируйте этот файл, измените, если нужно параметры учетной записи и поместите его в папку C:\Autodiscover\autodiscover.xml. Затем выполните 3 и 4 шаг из первого метода.
Если получить такой файл не удаётся, можно попробовать создать его вручную. Формат файла должен быть таким.
При использовании Outlook Anywhere (RPC/HTTP)
При подключении без Outlook Anywhere:
В данных XML файлах нужно изменить данные в квадратных скобках на информацию, соответствующую вашему домену (ее может выдать администратор Exchange или AD).
Отлично! Только таким образом через локальный XML файл получилось настроить Outlook 2016 для работы с Exchange 2010 с компьютера, который не в домене
Автору благодарность! Outlook 2016 + Exchange 2010 полет нормальный!
Люди, имейте в виду, такая проблема может возникнуть с Office 365 аккаунтом и 13-16 Outlook клиентом. Что именно у меня и произошло. Сами понимаете, настройками autodiscover и настройками web-сервера в случае полного облачного размещения вы не обладаете совсем. А для аккаунта не вытягивается autodiscover. И хоть ты убейся. Поддержка МС естественно помочь особо не может )
Обычно настройка Office 365 аккаунтов это операция в три клика, а тут я попал надолго. Но статья помогла.
Чёй-то не было у меня такого раздела AutoDiscover вот здесь
Компьютер\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\
А когда я его создал сам и всё что надо туда вписал, не работает всё-равно.
Такие дела.
Ничего не срабатывает с outlook 365 🙁
Опишите проблему подробнее. Какая версия Outlook, Exchange, архитектура подключения, у вас все on-prem, полностью облачные пользователи или гибрид?
Outlook из Office 365
Почтовый сервер Exchange точно не могу сказать, но старый, веб-интерфейс почты жёлтенький, похоже ещё 2013 г.
Попробовал и первый, и второй способы — результат нулевой (xml-файл на сервере доступен)
Outlook 2016 внедрения автоdiscover
Аннотация
Функция автоdiscover используется Outlook для получения сведений о конфигурации серверов, к которым оно подключается. В Outlook 2016 с серверами Exchange автораспоиск считается единственным пунктом для сведений о конфигурации и должен быть настроен и правильно работать, чтобы Outlook работать. В этой статье описано внедрение автооткрытия в выпуске «нажми и нажми и Outlook 2016». Дополнительные сведения о выпусках Office 365- и клиентских каналов см. на следующих веб-сайтах Майкрософт:
Дополнительная информация
Время автооткрытия
Автооткрытие выполняется в следующее время:
Во время создания учетной записи.
Заданные интервалы для сбора изменений URL-адресов, которые предоставляют Exchange функций веб-службы (OOF, служба доступности и так далее). Если этот процесс выполнен успешно, еще одна попытка будет выполнена через час. Если попытка не удалась, следующая попытка будет выполнена через 5 минут. Каждая попытка может быть ошеломляема до 25 процентов из-за инфраструктуры фоновых задач, используемой всеми Microsoft Office приложениями.
В ответ на некоторые сбои подключения. В разных случаях при неудачной попытке подключения Outlook запускает задачу автоdiscover для извлечения новых параметров в любой попытке устранить проблему с подключением.
Когда другое приложение вызывает его с помощью MAPI. Дополнительные сведения о MAPI см. в следующей статье MSDN: справочник Outlook MAPI.
Используйте имя пользователя (UPN), чтобы ускорить процесс автоdiscover.
На компьютере, который является Outlook доменом, необходимо знать имя пользователя-пользователя, чтобы начать процесс автооружия. Возможно, для входа в Windows использовался upN, Outlook имеет прямой доступ к нему из учетных данных для входа. Но если пользователь использует домен\имя пользователя для входа в Windows, Outlook у него будут только те же учетные данные. Чтобы получить имя имя-пользователя, Outlook сначала нужно найти пользователя в каталоге. Outlook запросит эту искомую ссылку. В сложных средах это может привести к тому, что перед найденным результатом будет связываться большое количество компьютеров. Когда Outlook имя-имя пользователя, значение кэшется в профиле, и для этого пользователя больше не должно повториться подсмотр.
Чтобы избежать этого, пользователь может войти в систему с помощью имени имени пользователя, а не домена\имя пользователя.
Microsoft Office 365 функции, которые могут поддерживать клиентов по обязательствам ITAR. В контексте функции автообнаружия в Outlook этот набор включает параметры политики и поведение, гарантирующее соблюдение конечных точек службы, используемых для автообнаружия, требований к облачной среде. В частности, в Office 365 действиях, перечисленных в процессе автоdiscover (шаг 4 и шаг 11), можно использовать управление политикой, чтобы обеспечить, чтобы во время процесса автоdiscover использовались соответствующие конечные точки службы.
Процесс авторасстановки. Каждый раз Outlook когда требуется информация автоdiscover, он использует набор упорядоченных действий для получения XML-данных, которые содержат параметры конфигурации. Многие из этих действий можно контролировать с помощью объектов групповой политики (GPO), и значение объекта групповой политики включается в описание шага.
Шаг 1. Проверка сценариев перезапуска
В некоторых случаях, например при добавлении второй учетной записи во время Outlook, автообнаружить кэшется в локальном файле, который будет использоваться при перезапуске Outlook клиента. Первое, что нужно сделать, — проверить реестр на случай, если в реестре есть специальные сведения о загрузке Outlook что вы находитесь в середине одного из этих сценариев перезапуска, и прочитать сведения об автообнаружещении из специального локального файла. Это редкий случай, который обычно не является причиной проблем с авторасчетом. Если на этом шаге Outlook, что вы находитесь в этом специальном сценарии загрузки, а попытка восстановить XML-данные автооткрытия не удалився, будет сбой всей попытки автоdiscover. Дополнительные действия не предпринята.
Для этого шага не существует определенного контроля политики.
Шаг 2. Проверка настройки локальных данных
Outlook позволяет администраторам развертывать определенный XML-файл автообнаружения, который будет использоваться для настройки. Если администратор развернул это значение реестра и засеил файл autodiscover.xml, Outlook прочитает из этого файла автообнаружние. Это снова редкий случай, и обычно это не является причиной проблем с авторасчетом. Если это не погрузка, Outlook к шагу 3.
Дополнительные сведения об автоматическом обнаружении XML см. в следующей статье TechNet: Планирование автоматической настройки учетных записей пользователей в Outlook 2010Примечание. Эта статья создана для Outlook
2010. Однако он по-прежнему актуален для более поздних версий Outlook.
Для этого шага можно использовать следующий стиль управления политикой: PreferLocalXML.
Шаг 3. Проверка последних известных хороших данных (LKG)
Когда автооткрытие успешно извлекает XML-загрузку на любом этапе, она может быть кэшна локально в качестве конфигурации «последней известной полезной». Первый часто успешный способ получения полезной информации автообнаружия — это последний известный хороший файл. Путь к последнему известному XML-файлу следует из Outlook профиля. Шаг LKG используется только для обнаружения конфигурации основного почтового ящика. Если подзапрос автообнаружния для не основного почтового ящика (запасной, делегат, общедоступный папка, почтовый ящик группы и так далее), то шаг LKG автоматически пропускается. Если это не погрузка, Outlook к шагу 4.
Значение контроля политики для этого шага: ExcludeLastKnownGoodURL.
Шаг 4. Проверка приоритета O365
Outlook использует набор heuristics, чтобы определить, является ли предоставленная учетная запись пользователя Office 365. Если Outlook вы уверены в том, что вы пользователь O365, будет предпринята попытка получить загрузку автооткрытия из известных конечных точек O365 (как правило, это https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml или https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). Если это не погрузка, Outlook к шагу 5.
Для этого шага можно в качестве значения управления политикой:
По умолчанию Outlook запросы известной конечной точки для получения полезной нагрузки автоdiscover. Существующая политика обхода этого шага по-прежнему действительна, и ее можно использовать для перейти к шагу 5, не применяя конечную точку. Кроме того, существует новая политика, которая направляет запрос Outlook центральной службе config service Office 365 для получения нужных URL-адресов, из которых извлекать данные авторасчета. По концептуальной концепции процесс работает следующим образом:
Вы настроим новую политику.
На этапе 4 процесса автооткрытия Outlook запросы в службу Office 365 config.
Служба определяет, какие особые потребности ITAR (если таковые имеются) для указанного пользователя, и возвращает соответствующие URL-адреса для этого пользователя, используя сведения о домене имени пользователя-пользователя.
Outlook пытается получить payload autodiscover из URL-адресов службы.
Для новой функции, которая будет использовать службу Office 365 Config Service, используется значение EnableOffice365ConfigService.
Примечание: В сборке 16.0.9327.1000политика EnableOffice365ConfigService больше не используется.
Шаг 5. Проверка данных SCP
Если компьютер подключен к домену, Outlook выполняет запрос LDAP для получения данных точки соединения службы, возвращающий путь XML автоdiscover. Затем в каждый URL-адрес, возвращаемый подстановки SCP, будет выполнена попытка получения полезной информации autodiscover. Если это не погрузка, Outlook к шагу 6.
Дополнительные сведения о SCP см. в следующей статье MSDN: Публикация с точками соединения служб.
Для этого шага имеется такое значение управления политикой: ExcludeScpLookup.
Шаг 6. Проверка корневого домена
На этом этапе Outlook создает URL-адрес из доменного имени исходного адреса в формате https:// /autodiscover/autodiscover.xml и пытается получить результат из полученных URL-адресов. Так как многие корневые домены не настроены для автоdiscover, Outlook намеренно заглушет все ошибки сертификата, которые возникают при попытке истребирования. Если это не пошаговая загрузка, Outlook к шагу 7.
Для этого шага имеется такое значение управления политикой: ExcludeHttpsRootDomain.
Шаг 7. Проверка домена autodiscover
В этом шаге Outlook создает URL-адрес из доменного имени исходного адреса в формате https://autodiscover. /autodiscover/autodiscover.xml и пытается получить результат из полученных URL-адресов. Так как обычно это основной URL-адрес для данных автоdiscover, Outlook не заглушет ошибки сертификата, которые возникают при попытке и получить. Если это не погрузка, Outlook к шагу 8.
Для этого шага имеется такое значение управления политикой: ExcludeHttpsAutoDiscoverDomain.
Шаг 8. Проверка локальных данных
На шаге 2 Outlook, не развернул ли администратор политику для проверки полезной нагрузки автоdiscover в качестве параметра. Если политика не была на месте, но предыдущие действия не были извлечены, Outlook теперь пытается извлечь полезное из локального файла даже без параметра PreferLocalXML. Если это не погрузка, Outlook к шагу 9.
Для этого шага не существует контроля политики.
Шаг 9. Проверка перенаправления HTTP
На этом шаге Outlook запрос на URL-адрес домена автоdiscover (http://autodiscover. /autodiscover/autodiscover.xml) и протестировать на перенаправление ответов. Если возвращается фактическая XML-загрузка autodiscover, а не перенаправление, Outlook игнорирует фактический XML-ответ autodiscover, так как он был извлечен без защиты (http). Если ответ является допустимым URL-адресом перенаправления, Outlook следует за перенаправлением и пытается получить XML-адрес полезной информации из нового URL-адреса. Outlook выполняет проверку сертификата, чтобы предотвратить перенаправление на потенциально опасные URL-адреса на этом этапе. Если это не погрузка, Outlook к шагу 10.
Для этого шага имеется следующий контроль политики: ExcludeHttpRedirect.
Шаг 10. Проверка данных SRV
На этом этапе Outlook создает запрос DNS для _autodiscover._tcp. » и зациклит результаты поиска первой записи, в протоколе которого используется протокол https. Outlook затем пытается получить полезное по ЭТОМУ URL-адресу. Если это не погрузка, Outlook к шагу 11.
Для этого шага имеется такое значение управления политикой: ExcludeSrvRecord.
Шаг 11. Проверка O365 как failsafe
Если все предыдущие шаги не возвращают полезные данные, Outlook использует менее строгий набор авристических мер, чтобы решить, может ли оказаться полезной окончательная попытка в конечных точках O365. Если Outlook решает, что попытка имеет смысл, она пытается использовать известные конечные точки автоdiscover O365, если учетная запись — это учетная запись O365. В этой попытке используются те же целевые URL-адреса, что и в шаге 4, и она отличается только тем, что она была использована как последняя мера, а не ранее в процессе автооткрытия.
Для этого шага имеется такое значение управления политикой: ExcludeExplicitO365Endpoint.
Если Outlook дойдет до этого шага и не удалось получить загрузку автоdiscover, выполняются два теста, чтобы определить, следует ли Office 365 конечные точки. Во-первых, если почтовый ящик является учетной записью потребителей (например, outlook.com), то будет предпринята попытка известной конечной точки. Во-вторых, если почтовый ящик относится к домену, который не имеет требований ITAR, будет предпринята попытка известной конечной точки. Если почтовый ящик является коммерческим и относится к домену с требованиями ITAR, никаких попыток к известным конечным точкам Office 365 не будет. В последующих выпусках шаг 11 может перейти к той же логике, что и шаг 4, и вызвать Office 365 config Service. После внося этого изменения эта статья будет обновлена с учетом нового шага процесса.
Обработка перенаправления. Шаг 9 в разделе Процесс автообнаружния является явным шагом для обработки данных, не влияющих на перенаправление. В любом из других безопасных действий для любой попытки получить XML-загрузку autodiscover одним из возможных ответов с конечной точки является ответ на перенаправление. Этот ответ Outlook перенаправить на новый, другой URL-адрес для получения полезной информации. Кроме того, данные перенаправления могут содержать новый, другой адрес электронной почты, который будет использовать в качестве целевого адреса для попытки автоdiscover. Outlook три отдельных ответа считаются «перенаправлением ответов»:
Код состояния HTTP (301, 302) с новым URL-адресом
Код состояния HTTP 200, но с XML-кодом полезной нагрузки, который Outlook перенаправить на другой URL-адрес
Код состояния HTTP 200, но с XML-кодом полезной нагрузки, который Outlook использовать другой smtp-адрес в качестве целевого адреса.
В случаях 1 и 2 Outlook пытается получить XML-адрес автоdiscover из нового URL-адреса при условии, что протокол https. Url-адреса nonsecure (http) не попытаются. Кроме того, даже если в новом URL-адресе указан протокол https, Outlook проверяет сведения сертификата, чтобы обеспечить дополнительную безопасность.
В случае с Outlook 3 начинается весь процесс автоdiscover. Если все действия (1–11) без успеха с использованием нового адреса электронной почты, Outlook возвращается на исходный адрес электронной почты, переходит к шагу 5 и продолжается попытка получить XML-загрузку с исходным адресом.
Исключения. Действия в разделе Процесс автооткрытия являются общими правилами получения полезной информации Outlook автоdiscover. Процесс может несколько измениться с помощью различных оптимизаций и попыток оптимизации. Например, при создании новой учетной записи Outlook пропускает шаг 3 (проверка на last Known Good (LKG), так как в нем пока не может быть последней известной допустимой записи. Аналогично, если попытка была предпринята из-за ошибки с использованием текущих сведений конфигурации, 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 предлагает несколько дополнительных параметров конфигурации на основе реестра, которые могут повлиять на процесс автоdiscover:
Использование службы Office 365 config Service
Ключ: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Значение: EnableOffice365ConfigService
По умолчанию: 0
Данные. Установите для этого DWORD 1, чтобы Outlook вызвать службу Office 365 для получения соответствующих URL-адресов автоdiscover.
Параметры времени и времени от времени http
Ключ: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Значение: время и время
По умолчанию: 25 секунд
Минимальное время: 10 секунд
Максимальное значение: 120 секунд
Информационные параметры. Указанные параметров времени от времени работы используются в качестве параметров WinHttpSetTimeouts. Указанные данные передаются всем четырем параметрам API WinHttpSetTimeouts. Это может обеспечить быстрое время выполнения HTTP-запроса, что повысит общую производительность. Эти параметры также позволяют успешно использовать HTTP-запрос, который занимает больше 25 секунд по умолчанию, увеличив значение времени, которое превышает 25 секунд.
Управление протоколом Mapi/Http
Ключ: HKEY_CURRENT_USER\Software\Microsoft\Exchange
Значение: MapiHttpDisabled
По умолчанию: 0
Данные: 1 = Протокол отключен; 0 = Протокол включен
Информационные данные. Это значение не находится под ключом автоdiscover. Это общий параметр, который управляет возможностью Outlook подключения к Exchange с помощью стопки протоколов Mapi/Http. По умолчанию этот протокол Outlook 2016 отключен. Это позволяет процессу автообнаружения добавить в процесс обнаружения специальный заглавный заглавный (X-MapihttpCapability:1), чтобы можно было оценить и обрабатывать параметры протокола Mapi/Http.
Управление согласованием устаревшей проверки подлинности
Ключ: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC
Значение: AllowNegoCapabilityHeader
По умолчанию: 0
Данные: добавляется 1 = Headers; 0 = Не добавляются headers
Информационные сведения. Обратите внимание, что это значение не находится в ключе автоdiscover. Этот параметр управляет тем, добавляется ли заглавная заявка на согласование проверки подлинности к 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 = беззвучно сбой проверки подлинности с прокси-серверов
Информационные сведения. Это значение реестра допускает обновление конфигурации безопасности и подробно описано в следующей статье базы знаний Майкрософт: 3115474 MS16-099: описание обновления для системы безопасности для
Outlook 2010 г.: 9 августа 2016 г.
Автооткрытие для других протоколов
Функция автоdiscover также используется Outlook для обнаружения и настройки Exchange ActiveSync учетных записей EAS. Процесс автоdiscover EAS и принятие решений отделены от действий, описанных в этой статье. Например, реализация EAS не реализует логику конечной точки O365 и не выполняет этап проверки на наличие местоположений SCP. В этой статье описываются подробные действия, которые Outlook для получения протоколов на основе MAPI из Exchange.
Ссылки
Устаревшие сведения об автооткрытии можно найти в следующей статье базы знаний Майкрософт:
2212902 Непредвиденное поведение автооткрытия при настройке реестра под ключом \Autodiscover
Дополнительные сведения об автооткрытии см. в следующих статьях Майкрософт: