Переход с односайтовой на многосайтовую Active Directory нарушил проксирование OWA

Переход с односайтовой на многосайтовую Active Directory нарушил проксирование OWA

Первоначально у нас была следующая установка:

  1. OfficeExch01 имеет роль почтового ящика и роль CAS
  2. OfficeExch01 находится в офисе.
  3. У CoLoExch01 была только роль CAS.
  4. CoLoExch01 имеет выход в Интернет и находится в CoLo.
  5. Три контроллера домена AD на сайте по умолчанию.

Пользователи могут перейти наhttps://webmail.whatever.com/owa, подключился через прокси к OfficeExch01 и все было замечательно.

Ну, мы недавно настроили отдельный сайт AD и поместили контроллер домена и сервер ColoExch01 на новый сайт. Я также сделал этот удаленный DC глобальным каталогом. Теперь пользователи получают следующую ошибку:

Outlook Web Access недоступен. Если проблема не устранена, обратитесь в службу технической поддержки вашей организации и сообщите им следующее: на сайте Active Directory, где хранится почтовый ящик, нет сервера клиентского доступа Microsoft Exchange с необходимой конфигурацией.

Я также вижу ошибки события 41 в журналах:

Сервер клиентского доступа "https://webmail.xxxxxxx.com/owa" попытка проксирования трафика Outlook Web Access для почтового ящика "/o=XXXXX/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=xxxxxxk". Это не удалось, поскольку на сайте Active Directory почтового ящика не удалось найти сервер клиентского доступа с виртуальным каталогом Outlook Web Access, настроенным для проверки подлинности Kerberos. Самый простой способ настроить виртуальный каталог Outlook Web Access для проверки подлинности Kerberos — настроить его на использование встроенной проверки подлинности Windows с помощью командлета Set-OwaVirtualDirectory в командной консоли Exchange или с помощью консоли управления Exchange. Если на целевом сайте Active Directory уже развернут сервер клиентского доступа с виртуальным каталогом Outlook Web Access, настроенным для проверки подлинности Kerberos, проксирующий сервер клиентского доступа может не обнаружить этот целевой сервер клиентского доступа, поскольку на нем не настроен параметр internalUrl. Вы можете настроить параметр internalUrl для виртуального каталога Outlook Web Access на сервере клиентского доступа на целевом сайте Active Directory с помощью Командлет Set-OwaVirtualDirectory.

Просматривая это, я вижу много разговоров о настройках ExternalURL и InternalURL. Однако все работало отлично, пока мы не сделали новый сайт AD. Я также убедился, что виртуальный каталог /owa внутреннего сервера CAS настроен на использование интегрированной аутентификации.

Нужно ли мне что-то сделать, чтобы Exchange увидел, что я внес эти изменения в AD?

решение1

Ну, я думаю, это была какая-то проблема с репликацией. Сегодня утром мы попробовали, и все было в порядке. Я предлагаю всем, у кого такая же проблема, запустить dcdiag и replmon, чтобы убедиться, что все успешно реплицировалось.

Связанный контент