Переключение URL-адреса OWA Exchange 2016 на внешний URL-адрес
Мы наблюдаем странную проблему с недавно развернутым Exchange 2016 в конфигурации Active-Active. Есть два сайта, на каждом по 2 сервера Exchange. Группа DAG охватывает 4 сервера с активными почтовыми ящиками на каждом сайте. Мы используем модель пространства имен Unbound, при этом внешний URL-адрес отличается от внутреннего URL-адреса.
Проблема заключается в том, что пользователь пытается подключиться к почтовому ящику, который размещен на сайте, противоположном тому, на котором они расположены. Соединение установлено, и пользователю отображается диалоговое окно входа в систему, затем после входа URL-адрес перенаправляется на внешний URL-адрес, и пользователю снова предлагается войти в систему.
Моя первоначальная мысль заключалась в том, что Exchange неправильно интерпретирует подключающуюся подсеть. как находящийся за пределами своей подсети, поэтому внешний. Из того, что я прочитал, Exchange знает сайт, поэтому он должен знать, что подсеть других сайтов является внутренней. Мы проверили сайты и службы AD на предмет ошибок неправильной конфигурации, но подсети настроены правильно.
nltest / server: возвращает правильный сайт для каждого из серверов Exchange.
Так что же могло вызвать перенаправление URL-адреса на внешний?
Я буду откровенен. Ваша конструкция и реализация несовершенны.
Почему вы используете два разных URL? Я не реализовывал эту конструкцию много лет, потому что она сбивает с толку конечных пользователей и может вызвать больше проблем, чем решает.
Активная/активная группа DAG редко работает так, как, по мнению большинства людей, она работает/должна работать, если вы потеряете связь между двумя сайтами (что является наиболее распространенным сценарием) тогда один участок будет опущен. Поскольку у вас четыре сервера, я бы переключился на две группы DAG, по одному активному серверу на каждом сайте. Другой пассивный сервер действует как FSW. Дайте каждому сайту свой собственный URL, при этом один и тот же URL будет использоваться внутри и снаружи для всех служб (ActiveSync, Autodiscover (Который знает AD сайт), EWS, OWA).
Это конструкция, которая доказала свою работоспособность, приемлема для конечных пользователей и является наилучшей практикой.