После долгих исследований и тестирования я реализовал правила перенаправления, чтобы проверка автообнаружения выполнялась не на моем веб-сервере. В этом посте я пытаюсь выяснить, что может быть не так (может быть, что все не так, я просто хочу проверить), почему перенаправления, которые у меня есть, не работают на моем виртуальном хосте на моем веб-сервере Apache. Я включил три своих перенаправления, которые я сохранил на виртуальном хосте 443:
Redirect permanent /autodiscover/autodiscover.xml https://outlook.office365.com/owa/plymouthinc.com/Autodiscover/Autodiscover.xml
Redirect permanent /AutoDiscover/AutoDiscover.xml https://outlook.office365.com/owa/plymouthinc.com/Autodiscover/Autodiscover.xml
Redirect permanent /Autodiscover/Autodiscover.xml https://outlook.office365.com/owa/plymouthinc.com/Autodiscover/Autodiscover.xml
После перезапуска Apache я запустил https://testconnectivity.microsoft.com/ инструмент, чтобы убедиться, что перенаправления работают, и я все еще вижу следующее в моих журналах ошибок.
192.168.9.16 - - [15/Aug/2018:16:05:12 -0700] "POST /Autodiscover/Autodiscover.xml HTTP/1.1" 404 38531 "-" "Microsoft Office/15.0 (Windows NT 6.2; Microsoft Outlook 15.0.4615; Pro; MS Connectivity Analyzer)"
192.168.9.16 - - [15/Aug/2018:16:05:13 -0700] "POST /Autodiscover/Autodiscover.xml HTTP/1.1" 404 38556 "-" "Microsoft Office/15.0 (Windows NT 6.2; Microsoft Outlook 15.0.4615; Pro; MS Connectivity Analyzer)"
Теперь это чисто косметический характер, чтобы решить эту проблему - все мои пользователи могут отправлять и получать электронные письма без проблем, это просто то, что мы в ИТ-команде хотели бы исправить. Мои журналы ошибок не заполнены ошибками 404, перечисленные выше ошибки появляются только при запуске инструмента - а не в том случае, если / когда пользователь настраивает свои почтовые клиенты (настольный компьютер или телефон); Я протестировал это и просмотрел журналы, чтобы увидеть, появилось ли что-нибудь в журналах, что могло бы иметь отношение к результатам результатов анализатора подключения ... ничего.
Я связался с самими Microsoft, предоставил им результаты работы инструмента анализатора подключения, и они ответили: "Ваша учетная запись настроена правильно, дальнейшее тестирование не требуется, это ожидаемый результат.. "Я не затаил дыхание, чтобы получить от них реальный ответ, но я подумал, что хотя бы попробую. Как я уже сказал, это то, что мы в ИТ-отделе хотели бы решить, но это не влияет на моих пользователей. в любом случае.
Кто-нибудь еще, у кого есть внутренний веб-сервер компании, использующий Office365, сталкивался с этой проблемой в прошлом? Если да, то что вы сделали, чтобы исправить это - если вы что-то сделали? Любые гуру Linux / Apache видят то, чего я не улавливаю?
Я более чем готов предоставить любую дополнительную информацию, которая может вам понадобиться для оказания помощи; как всегда, если это не соответствует рекомендациям по форматированию или требуется дополнительная информация, сообщите мне, и я внесу изменения или предоставлю дополнительную информацию. Большое спасибо!
Ваша учетная запись настроена правильно, нет необходимости в дальнейшем тестировании, и это ожидаемый результат.
Это реальный ответ: нет проблем с перенаправлением /Autodiscover/Autodiscover.xml. Несмотря на использование протокола HTTPS, Outlook не является веб-браузером, и его не следует рассматривать как таковой. Outlook не заботится о ваших перенаправлениях. Вместо этого, учитывая 404 (или любой другой, кроме 200) ответ переходит к следующему кандидату, как объяснено в обоих Обзор процесса автообнаружения и Служба автообнаружения.
Итак, эффективно ваш autodiscover.plymouthinc.com. IN CNAME autodiscover.outlook.com. делает свое дело. Как указано в вашем вопросе, клиенты даже не используют plymouthinc.com для автоматического обнаружения, и если они это сделали, это не считается ошибкой. Поэтому это действительно ожидаемый результат. Перестань беспокоиться.
Еще одно заблуждение, не связанное с Autodiscovery: если вам когда-нибудь понадобится перенаправить POST просьбы, помните, что Redirect permanent возвращает код состояния 301 переехал навсегда, в результате чего URL из Location: заголовок, полученный с помощью GET метод. Если вам нужно сохранить данные POST, используйте код состояния 307 Временное перенаправлениевместо этого. (См. RFC 7231 6.4.2. & 6.4.7.)