UPD1: Исправлена неточность в редактировании прослушивателя на TMG (рис.3)
UPD2: Есть другой способ - Редирект OWA в Exchange 2010 (вариант №2)
Как известно, в Exchange 2010 сайт Outlook Web App расположен по URL-адреса https://YourCAS/owa . В связи с этим, возникает по крайней мере два неудобства: надо руками набирать https и необходимо указывать виртуальный каталог OWA. Было бы гораздо удобнее в браузере просто написать адрес своего постового сервера и автоматом попасть на нужную страничку.
Для того, чтобы служба IIS перенаправила запрос, пришедший на корневой адрес, в тот виртуальный каталог, который вам необходим, нужно сделать следующее:
- Перейти в раздел Default Web Site;
- Открыть опцию HTTP Redirect;
- Поставить галочку “Redirect request to this destination:” и указать ваш адрес OWA;
- Далее, нужно не забыть поставить галочку “Only redirect request to content … (not subdirectories)”;
После того, как все вышеописанное будет сделано, необходимо убрать требование использовать SSL, чтобы мы могли обращаться на HTTP-адрес. Для этого идем в опцию SSL Settings и убираем галочку Require SSL.
На этом настройки завершены, теперь можно подключаться к OWA по адресу http://YourCAS.
Важно!
Если у вас все заработало, то нужно вспомнить, что мы внесли изменения в корневой каталог IIS`a, следовательно, нужно проверить, а не унаследовались ли эти изменения в других виртуальных каталогах.
Обратите внимание, что для каталогов Exchange, Exchweb и Public virtual должно быть установлено перенаправление HTTP на адрес /owa, всем остальным перенаправление по умолчанию не требуется. При этом требование проверки SSL должно быть установлено у всех каталогов, кроме OAB и PowerShell.
Подробнее про дефолтные настройки виртуальных каталогов для серверов Exchange 2007/2010 можно почитать в одном из прошлых моих постов - Виртуальные каталоги Exchange 2007/2010 – настройки по умолчанию.
Редирект OWA на ISA / TMG
С локальными подключениями разобрались, а что же делать с внешними? Если у вас Outlook Web App опубликован в сеть Интернет через шлюз на базе Microsoft Internet Security and Acceleration Server 2006 (ISA) или Threat Management Gateway (TMG), то здесь для настройки переадресации тоже есть достаточно красивое решение.
Для начала нужно дублировать правило публикации OWA. Для этого нажимаем на нем правой кнопкой – Копировать, затем – Вставить. В результате появляется ещё одно точно такое же правило, но с циферкой (1). Теперь переименовываем его, например в OWA-Redirect и редактируем.
Примечание: Почему нельзя просто отредактировать имеющееся? Да просто потому, что, во-первых им кто-то может воспользоваться, а во-вторых оно нам понадобится.
Вносим следующие изменения:
1. На вкладке Action переключаем действие в Deny, в результате становится доступной галочка Redirect HTTP request to this Web page, её необходимо поставить и вписать тот адрес, на котором действительно опубликован Outlook Web App, в моем случае это https://mail.alexxhost.ru/owa
Рис.1: Настройка адреса для перенаправление запросов.
В результате мы сделали так, что все запросы будут пересылаться на «правильный» адрес. Теперь необходимо определиться какие именно запросы мы будем пересылать.
2. Переходим на вкладку Paths, и здесь удаляем все пути, которые остались от прошлого правила. Взамен оставляем лишь один корневой / , как показано на рис.2.:
Рис.2: Редактируем пути.
В результате правило будет обрабатывать все запросы, приходящие «в корень» нашего сайта, в моем случае это будут запросы на mail.alexxhost.ru.
На этом шаге настройку в принципе можно закончить, но для совсем ленивых, т.е. для тех кто не хочет набирать HTTPS, нужно сделать ещё одну ремарку.
3. Открываем свойства прослушивателя и на вкладке Connections ставим переключатель на пункте Redirect authenticated traffic from HTTP to HTTPS.
Рис. 3: Редактируем перенаправление HTTP трафика в HTTPS.
На этом пожалуй все. Теперь внешние пользователи набирая в адресной строке браузера mail.alexxhost.ru попадут на это правило и будут перенаправлены на https://mail.alexxhost.ru/owa а уже по этому адресу пользователя «встретит» «правильное» правило и он получит доступ к OWA не напрягаясь.
34 комментария:
Я наконец, таки нашел как сделать редирект на страницу типа мойдомен.ру/owa на мойдомен.ру
Во правиле публикации owa на кладке "пути" надо создать еще одну с параметрами внутренний адрес "/" и внешний такой же "/" и больше никаких лишних символов. Видел в сети описания с обманом парсера ИСЫ типа /Exchange\ так вот в 2006 это не работает!
Я дописал статью и показал как, на мой взгляд, будет правильно редиректить запросы на ISA/TMG.
Точно! Спасибо огромное все получилось! Делал так же запрещающее правило, но вот пути не менял и поэтому ничего не работало! Теперь все ок, еще раз спасибо!
Супер! Статья, давно искал еще под 2003-й!
Теперь пользую 2007-й, будем ставить 2010-й пригодится!
Автору Огромное спасибо!
Огромное пожалуйста! :)
Почему то не сработал редирект HTTP трафика в HTTPS снаружи. Что ещё можно посмотреть?
Заработал, только пришлось паблишить в TMG http. Безопасно ли это? И если есть другая возможность, прошу помощи?!
Странно... а вы не забыли оставить включенной опцию Enable HTTP connection on port 80 (рис.3)?
Нет, не забыл, сделал всё как написано в статье (кстати, очень хорошая статья, спасибо Вам), но к сожалению снаружи редирект так и не работает, если выключаю паблишь на 80й порт, на Exchange сервер. Куда можно ещё заглянуть?
А у вас случайно TMG установлен не на той же машине, где и роль Exchange Edge? Если да, то вот описание почему не работает и временное решение проблемы - http://scott.jaworski-group.com/2010/01/12/tmg-http-to-https-redirects-not-working/
Да, Вы правы, спасибо за ссылку, помогло.
Редирект настроил, все работает, только одно смущает, сразу вылезает окно для ввода логина и пароля, а хотелось бы чтобы я попадал на стартовую страницу Outlook Web App. Не могу понять почему не она открывается.
Есть мнение?
Смотрите вкладку Делегирование проверки подлинности на TMG.
Все настроил как в статье для внутреннего перенаправления, но при этом отключается перенаправление на /owa для Exchage,Pablic,Exchweb каталогов, когда для них включаешь и сохраняешь настройку, то при этом включается перенаправление для каталога OWA что вызывает ошибки при работе через веб доступ, если выключить для OWA, то автоматом отключается и для Exchage,Pablic,Exchweb . Как сделать чтоб не было этой взаимосвязи?
Странно... У меня все виртуальные каталоги независьмы в этом плане. К сожалению я не являюсь мпециалистом в области настройки IIS, возможно вам смогут помочь на форуме TechNet`a в соответствующем разделе.
Попробуйте сделать отдельный листенер для Autodiscover`a, слушающий адрес autodiscover.mydomen.ru
Алексей, день добрый, дело в том что у меня OutlookAnywhere не опубликован во внешний мир и соответственно нет правила для Autodiscover, вопрос заключался в том что эта связка работает у вас с установленной галкой на внутреннем интерфейсе в пункте Autodescover?, то есть я пытаюсь понять причина в этом, что редирект у меня не отрабатывает или причина кроется в более "глубоком".
С уважением, Владимир.
Владимир, честно сказать не очень хорошо понял ваш последний пост. Напишите мне на электронную почту, мы с вами разберемся более детально.
Алексей, проблема была в том, что проводя эксперимент я настроил, что бы внешние пользователи проходили авторизацию сразу на Exchange, а не в web форме на TMG которая в свое время передает пароль в Exchange , соответственно переделав все как положено а именно как написано у вас все стало корректно работать. Вывод очевиден нужно делать все по правилам))
С уважением, Владимир.
Настроил через IIS и всё заработало, но есть одна проблема с работой в браузере.
OWA всё время отображает ошибку "Произошла непредвиденная ошибка, и запрос обработать не удалось."
Что не так? Где копать?
И локально и с внешки не работает? Браузеры разные пробовали?
Что не так - не знаю. А вот копать стоит начать в сторону логов IIS, возможно запросы не туда куда-то редиректятся.
Не работает везде и в любых браузерах. Я так и понял что нужно искать в IIS, но вот где? Возможно, дело в одной галке где-то.
Как решить проблему с выводом ошибки Произошла непредвиденная ошибка, и запрос обработать не удалось." здесь
http://social.technet.microsoft.com/Forums/sr-Latn-CS/exchange2010/thread/ca5e5e1b-643c-47eb-8c05-1e90c91b08a3
Если в кратце, надо снять редирект на папке /Public.
Не очень понял в чем проблема.
Редирект с папки можно снять просто выбрав пункт Перенаправление протокола HTTP - убрать соответствующую галку.
Странно но у меня такаяже проблемка с https переадресовывает на owa а с http на https нет (внешний redirect)
Должен заместить, что в IIS на Exchange 2010, когда убираешь галку редиректа на OWA, редирект пропадает и для каталогов Exchange, Exchweb и Public virtual. У моего коллеги ситуация анологичная. Проверте и у себя.
Та же проблема. при включении редиректа на /exchange он включается и на /owa тогда получаю ошибку: "Произошла непредвиденная ошибка, и запрос обработать не удалось" если убрать то люди, привыкшие набирать /exchange не могут получить доступ потому что видят Server Error in '/' Application.
Попробуйте воспользоваться другим способом http://www.alexxhost.ru/2011/05/owa-exchange-2010-2.html
http://www.scottfeltmann.com/blog/2011/06/22/exchange-2010-owa-redirection-causing-a-forever-loop/
C:\Windows\System32\inetsrv>appcmd set config “Default Web Site/Exchange” /section:httpredirect /enabled:true -commit:apphost
C:\Windows\System32\inetsrv>appcmd set config “Default Web Site/Exchweb” /section:httpredirect /enabled:true -commit:apphost
C:\Windows\System32\inetsrv>appcmd set config “Default Web Site/Public” /section:httpredirect /enabled:true -commit:apphost
And then this to disable redirection for /owa:
C:\Windows\System32\inetsrv>appcmd set config “Default Web Site/owa” /section:httpredirect /enabled:false -commit:apphost
And done, the redirects work correctly and the /owa loop is removed!
Обратите внимание, что для каталогов Exchange, Exchweb и Public virtual должно быть установлено перенаправление HTTP на адрес /owa
Вот тут вот уберите Public Virtual, пожалуйста. Потому что коли на папке Public редирект оставить, то в OWA, папки даже не разворачиваются.
А бывает так что OWA не работает по другим причинам тогда придется искать решение здесь http://so4net.com/index.php/ru/blog/107-owa-exchange-2010-sp1
Подскажите почему пускает на owa только тех пользователей у которых в AD параметр "Log On To..." установлен в значение "Только для выбранных компьютеров" и почтовый сервер добавлен в этот список?
Потому что если вы ограничиваете список хостов на которые может залогиниться пользователь, то ограничиваете в том числе и для IIS, а как известно именно IIS отвечает за авторизацию пользователя в почтовом ящике Exchange
Добрый день! Наверное, немного не по теме вопрос, но надеюсь на помощь,
В общем, есть ситуация. Мы смигрировали на 2013 Exchange с 2010-й версии. Всё прошло хорошо, всё работает, но есть один маленький неприятный нюанс. Если попытаться открыть owa и войти под пользователем, мейлбокс которого уже смигрирован на новый сервер, то выводится сообщение типа: "Используйте следующую ссылку, чтобы быстрее открыть этот сайт" и далее идёт локальная ссылка на имя cas-сервера нового Exchange 2013 (exch13.contoso.local) Как бы это побороть?
Отправить комментарий