Я установил среду сосуществования с Exchange 2010 и Exchange 2016.
На данный момент почтовый поток работает без проблем, и я перевел двух тестовых пользователей с 2010 на 2016.
SMTP-трафик и HTTPS проксируются из новой установки Exchange 2016 и отлично работают для пользователей 2010 года.
Моя проблема в том, что при миграции пользователей в Outlook 2016 возникают проблемы с подключением к новому серверу.
Когда я открываю Outlook, он по-прежнему использует RPC / HTTP по отношению к старому серверу.
Если я удалю старый профиль и заново создаю его с помощью автообнаружения, он будет работать нормально.
Затем я вижу трафик MAPI, и он, как и ожидалось, попадает на новый сервер.
Это вызовет проблемы, если мне придется вручную заново создавать профили для всех пользователей в нашей компании.
У кого-нибудь есть указатели?
Отредактировано с дополнительной информацией:
Я перенес своего собственного пользователя, и у меня был открыт прогноз. Я получил сообщение, что мой ящик был перенесен и мне нужно перезапустить Outlook; так и сделал! Мой мобильный телефон и OWA работают так, как задумано, и это просто мои клиенты из Outlook. Это произошло на двух моих компьютерах, подключенных к одному и тому же почтовому ящику и одному пользователю (домашний и офисный компьютер).
При открытии клиента Outlook я получаю предупреждающее сообщение о сертификате с именем внутреннего имени моего старого сервера (например, Exch2010.domain.local), а используемый сертификат предназначен для нашего FQDN как mail.company.com.
Второе редактирование:
Я только что перенес тестового пользователя из 2010 года с закрытым Outlook и попытался подключиться из внешней сети. Он задал мне вопрос, хочу ли я разрешить https://mail.company.com/autodiscover/autodiscover.xml для редактирования моих настроек. Я нажал «разрешить», и ничего не произошло. Почтовый ящик оставался в отключенном состоянии, и в состоянии подключения было одно соединение со статусом «установлено». Подключение было проксировано через mail.company.com и Exch2010.company.local. Я перезапустил Outlook, и произошло то же самое.
Затем я переместил клиента из внешней сети и вместо этого поместил его в нашу внутреннюю сеть. Теперь он дает мне то же сообщение: "Разрешить этому веб-сайту настраивать параметры сервера migration.test@company.com?" но с локальным именем НОВОГО сервера обмена в формате URL, например "https: //exch2016.company.local/autodiscover/autodiscover.xml". Я разрешил и принял предупреждение о сертификате (поскольку в нем говорилось, что снова используется локальное имя - exch216.company.local; что не соответствует сертификату SSL).
Outlook по-прежнему не работает и находится в «отключенном» состоянии. Мой собственный почтовый ящик «установлен», но не обновляется.
Из любопытства я проверил серверы, запустив:
Get-AutodiscoverVirtualDirectory | fl
InternalURL и ExternalURL для всех трех пустых. У меня недостаточно опыта, чтобы понять, правильно это или нет.
По какой-то причине кажется, что серверы внутренне объявляют свои локальные имена вместо правильного «mail.company.com».
Я также проверил серверы, запустив:
Get-ClientAccessServer -Identity SERVER | fl
Все они получили для AutoDiscoverServiceInternalUri значение "https://mail.company.com/autodiscover/autodiscover.xml".
Полное доменное имя для всех них устанавливается как их локальные имена хостов (servername.company.local).
Я не знаю, что попробовать дальше ..
Отредактируйте номер три; в ответ на @Sembee: Привет @Sembee! Спасибо за ваш ответ. Я оставил их пустыми и не внес изменений. Я проверил InternalURI для clientaccessserver на всех трех серверах, и они идентичны. Тесты автообнаружения проходят без проблем и выполняются с самого начала. Повторная конфигурация обзора пользователя заставляет его снова работать (свежие данные из автообнаружения). На данный момент весь трафик проходит через сервер 2016 (afaik), и прокси-сервер в порядке на сервер 2010. Никто не упомянул о каких-либо проблемах. Outlook просто не работает после перехода на 2016 без повторного создания профиля и запуска нового автообнаружения.
Четвертое редактирование: Когда я пришел сегодня на работу, мой собственный ноутбук (вчера / воскресенье не работал) И ноутбук (не работал в субботу), который я использовал для тестирования, оба работали нормально. Это может быть какая-то отложенная синхронизация, которая делает это со мной? В настоящее время я настраиваю еще один тест, чтобы увидеть, ведет ли он себя так же, и можно ли как-то его измерить. Любые указатели будут очень признательны.
Я думаю, что это известная проблема Microsoft, для меня просто переработать MSExchangeAutodicoverAppPool из консоли IIS или используйте следующую команду
Restart-WebAppPool MSExchangeAutodiscoverAppPool
ожидая обновления, вы можете настроить автоматическую перезагрузку этого AppPool в IIS вы можете прочитать по этой ссылке
У нас была такая же проблема. После миграции клиенты Outlook не подключаются. обнаружил, что виртуальный каталог mapi продолжает удалять аутентификацию. Как только это будет возвращено, оно соединится. Если вы измените URL-адреса, аутентификация будет очищена.
Думаю, нужно рассматривать как две части. Сначала посмотрите свою конфигурацию MAPI для внутреннего обзора 2010 или 2013
Убедитесь, что в настройках сервера аутентификация mapi должна выбрать аутентификацию Windows NTLM и согласование аутентификации Windows.
Согласно документам Microsoft, некоторые клиенты все еще могут подключаться как Rpc / http, и он будет работать
После нескольких часов попыток с помощью коллеги; нам удалось заставить это работать как задумано.
Я начал с переустановки Exchange 2016 на обоих новых серверах и настроил их с нуля. Несколько вещей, которые мы сделали во второй раз, заставили это работать.
Мы начали с проверки всей информации в:
Get-OutlookAnywhere | fl
Установка -InternalClientsRequireSsl на false; поскольку мы решили, что это не нужно для внутреннего пользования из-за конструкции сети и того факта, что наш сертификат не содержит внутреннего имени нашего сервера.
Мы также установили аутентификацию на использование NTLM для внешней и внутренней аутентификации для всех серверов. Мы также изменили приоритет проверки подлинности Windows (поставив NTLM) поверх RPC в IIS. После выполнения сброса IIS; вроде все работает как задумано. Я не уверен, пропустили ли мы сброс или перезагрузку IIS с первой попытки, но, по крайней мере, сейчас все работает!
Начнем с простого. Виртуальные каталоги автообнаружения должны быть пустыми. Это нормально, и вы не должны их менять.
Затем все серверы на одном сайте AD должны иметь одинаковую информацию для внутреннего URL-адреса автообнаружения. Кроме того, это должно указывать на новый сервер и быть именем, указанным в доверенном сертификате SSL. Таким образом:
get-clientaccessserver | set-clientaccessserver -AutodiscoverServiceInternalURI https://mail.example.com/Autodiscover/Autodiscover.xml
Когда вы это сделаете, запустите тест автообнаружения в Outlook. Удерживая нажатой клавишу CTRL, щелкните правой кнопкой мыши значок на панели задач. Выберите тестовую автоконфигурацию электронной почты. Снимите выделение со второго и третьего вариантов. Запустите тесты - посмотрите, что возвращается клиенту.
Затем проверьте конфигурацию Outlook Anywhere. Опять же, это должно быть одинаково на всех серверах, потому что оно может проксировать его. Проверьте как внутренний, так и внешний URL.
Почтовые ящики должны перенаправлять автоматически - это может указывать на плохую репликацию домена. Однако это также зависит от того, как быстро вы пытались использовать почтовый ящик после его перемещения на новый сервер. Опять же, вам нужно немного подождать, пока домен реплицирует изменение, чтобы Outlook принял его.