Пользователь связанного почтового ящика иногда подключается к неправильной организации Exchange
Конфигурация следующая:
- В домене hosting.contoso.com размещается локальная организация Exchange 2013, в которой размещено несколько доменов второго уровня, включая домен contoso.com. Домен находится в отдельном лесу, и имеет доверие леса с доменом office.contoso.com, который также является корневым доменом отдельного леса.
- Установлено VPN-соединение между office.contoso.com и hosting.contoso.com, а также всеми серверами Exchange. доступны для обеих сторон через внутренние диапазоны IP.
- Пользователи в домене office.contoso.com имеют суффикс UPN contoso.com и подключаются к организации Exchange через MAPI через HTTPS, разрешенный для внешних диапазонов IP-адресов серверов Exchange в домене hosting.contoso.com.
- Сервер имен contoso.com представляет собой автономный DNS-сервер, доступный как NS1.contoso.com для Интернета, и на котором размещаются все необходимые записи MX, A, TXT и SRV для организации contoso.com Exchange, необходимые для его обнаружения извне. OWA также опубликован и работает.
- The office.contoso. com недавно был интегрирован с AD FS в организацию клиента Microsoft Office 365, у которой есть собственная организация Exchange, однако ни одна из записей DNS contoso.com не указывает на microsoft.com, office.com, outlook. com или где-либо еще от Microsoft. Вся конфигурация завершена, ни одна из сторон не сообщает о проблемах с интеграцией AD.
Пользователь из office.contoso.com отправил сообщение с Outlook 2016 из внутренней сети домена office.contoso.com третьей стороне с помощью CC адрес одного из почтовых ящиков общедоступных папок в локальной организации Exchange и не получил сообщение в эту общедоступную папку. Расследование в конечном итоге обнаружило, что электронное письмо было отправлено через организацию Office 365 Exchange, у которой не зарегистрирован адрес электронной почты общей папки. поэтому отчет о недоставке был создан и помещен в облачный почтовый ящик Exchange, связанный с этим пользователем. Третья сторона получила сообщение правильно, несмотря на запись SPF домена contoso.com, которая должна была помешать серверам Microsoft успешно отправлять это электронное письмо, поскольку их внешние IP-адреса не разрешаются обратно ни в одно из DNS-имен contoso.com. (Конфигурация стороннего почтового сервера выходит за рамки этого вопроса)
Вопрос:
- КАК Outlook может обнаружить, что существует другая организация Exchange, настроенная как для подключения, так и для отправки электронной почты для домена office.contoso. com?
- ПОЧЕМУ он на самом деле решил подключиться в другом месте, но основная учетная запись Exchange уже настроена на использование адреса из @ contoso.com?
- ПОЧЕМУ Outlook НЕ отображал содержимое неправильного почтового ящика после такого переключения, и ПОЧЕМУ Outlook отправил сообщение «Отправлено» в правильный почтовый ящик, а отправил его через неправильный почтовый ящик?
- КАК COME Office 365 Outlook, установленный на ПК во внешней сети, подключается к организации Office 365, несмотря на действительный адрес автообнаружения, существующий в contoso .com домен? Если используется автономная установка той же версии Office, которая не использует Office 365 для активации, процесс автообнаружения завершается мгновенно, при этом он подключается с помощью RPC / MAPI через HTTPS к локальному серверу Exchange CAS.
- Что должно быть системный администратор домена office.contoso.com должен ОБАИМ разрешить существование организации Exchange в Office 365 и полностью исключить любую возможность для пользователей Перспективы подключения к нему, если не указано иное?
Мне удалось найти ответ на этот вопрос. Ссылка на полностью объясненный ответ находится здесь: Как Outlook (2016) выполняет автоматическое обнаружение . Выдержка выглядит следующим образом:
Шаг 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.
Как объясняется в этом руководстве, Outlook 2016 использует «эвристику» для определения следует ли проверять подготавливаемую организацию Office 365 для Exchange. Более того, этот шаг 4 выполняется задолго до любого другого шага, настраиваемого в Active Directory или на сайтах автообнаружения. Поэтому ответ прост: добавьте либо настройку реестра, либо подходящую политику с установленными шаблонами ADM Office 2016. Раздел реестра - HKEY_CURRENT_USER \ Software \ Policies \ Microsoft \ Office \ 16.0 \ Outlook \ AutoDiscover \ ExcludeExplicitO365Endpoint , введите REG_DWORD , значение 1 . Черт возьми, когда дело доходит до того, чтобы Outlook 2016 не пытался переходить в облако.
Остается вопрос № 3: «Почему Outlook не отображает правильное содержимое подключенного почтового ящика», но на него отвечает Outlook, обычно работающий в режиме кэширования. , поэтому он отображает локальный кеш и случайные изменения, загруженные с помощью запросов на вытягивание из Exchange. В этом случае содержимое локального почтового ящика Exchange было загружено локально до того, как Outlook выполнил свой танец вероятности и подключился к облаку, поэтому он просто отображал их вместе с сообщением, только что отправленным через облако, обеспечивая описанный эффект.
И, наконец, автономной версией оказался Outlook 2013, который еще не использует такую эвристику по дизайну, поэтому работал, как ожидалось.