Exchange web access

Как соединяться с сервером Exchange 2007

Outlook Web Access (OWA) — веб-интерфейс доступа к ящику

В личном кабинете указан сайт, который должен использоваться для работы с OWA. Сайт работает по протоколу HTTPS.

Соединение по протоколам POP3 / IMAP / SMTP

Может использоваться для почтовых клиентов, отличных от Microsoft Outlook, а также в случае покупки тарифа Exchange без поддержки MAPI.

Все параметры подключения даны на странице с ящиками Exchange.

Альтернативный порт для SMTP сервера — 587. Используйте его в том случае, если у вас не получается отправить почту.

Соединение с коммуникаторами Windows Mobile

Возможность доступна в тарифе ящика «Стандартный» или выше.

В настройках сервера для синхронизации необходимо выбрать сайт, соответствующий сайту для доступа к OWA.

В личном кабинете указан сайт, который должен использоваться для работы с OWA. Сайт работает по протоколу HTTPS. Обычно это owa.1gb.ru.

Логин — полный логин в формате, аналогичном ad1[ваш логин], он показан в личном кабинете на странице с ящиками Exchange. Здесь ad1 — имя домена, логин — имя пользователя, если есть отдельное окно для домена, то ad1 необходимо записать туда, а имя пользователя писать без ad1.

• Пример настройки с фотографиями

Альтернативный порт для SMTP сервера — 587. Используйте его в том случае, если у вас не получается отправить почту.

Соединение по протоколу MAPI (Outlook 2003/2007)

Возможность доступна в тарифе ящика «Расширенный».

Вам потребуются следующие параметры:

По умолчанию, протокол MAPI требует доступа по ряду TCP портов, которые часто закрыты для подключения (порты 135, 6000-6004). В том случае, если MAPI не работает, попробуйте описанные далее варианты:

• Подключение к Exchange с помощью VPN
• Подключение к Exchange с помощью HTTPS (Outlook Anywhere)

Альтернативный порт для SMTP сервера — 587. Используйте его в том случае, если у вас не получается отправить почту.

Подключение к Exchange с помощью VPN

Возможность доступна и для Outlook 2003, и для Outlook 2007.

• VPN соединение нужно настраивать и поддерживать подключенным
• VPN соединение может мешать работе корпоративных сетей на той же схеме адресации
• Протокол VPN соединения (PPTP) работает не из всех сетей, в ряде сетей PPTP работает ненадежно
• Если всё же работает, то работает быстро и технически эффективно (небольшой трафик, наибольшая скорость работы)

Параметры VPN подключения и пример работы описаны на странице https://www.1gb.ru/1152.

Подключение к Exchange с помощью HTTPS (Outlook Anywhere)

Возможность доступна для Outlook 2007.

Старое или внутренне название технологии — RPC over HTTP(S). Outlook Anywhere позволяет подключаться к Exchange серверу по протоколу HTTPS, в том числе — через обычный HTTP(S) прокси.

• Работает в любых сетевых условиях (HTTPS доступ есть практически на любом компьютере)
• Медленнее, чем прямой MAPI или VPN
• В случае использования HTTP-прокси менее безопасно, чем VPN

Важно: для того, чтобы Outook Anywhere заработал на вашем компьютере, необходимо установить сертификат безопасности.

Для настройки Outlook Anywhere в свойствах учетной записи Exchange нужно открыть закладку Connection, внизу поставить галку «Connect to Microsoft Exchange using HTTP», затем установить дополнительные опции с помощью кнопки «Exchange Proxy Settings».

Настройка OWA в Exchange Server 2010

В этой статье речь пойдет о сегментации OWA, используемой для ограничения компонентов, доступных пользователю через интерфейс OWA, и настройке экранов регистрации и завершения работы с OWA

Уильям Лефковиц (william@mojavemediagroup.com) — технический директор Mojave Media Group, автор статей о технологиях систем сообщений и совместной работы. Имеет сертификат MCSE и звание Microsoft Exchange MVP

Outlook Web App (OWA) в Exchange Server 2010 — новое название программы Outlook Web Access, существовавшей около 15 лет со времени выпуска Exchange Server 5.0. После завершения сеанса первой версии Exchange Server с OWA администраторы неизменно желали наделить OWA уникальными особенностями, даже за пределами поддерживаемых настроек. Настройки OWA варьируют от корректировки цвета до полной смены корпоративной символики и радикального изменения интерфейса. Простота настройки OWA зависит от версии Exchange Server, имеющегося инструментария настройки и квалификации администратора.

Современная версия OWA значительно отличается от простого приложения Active Server Pages (ASP) в Exchange 5.0 и 5.5. Благодаря службам Microsoft Exchange Web Services, появившимся в Exchange Server 2007, данные Exchange доступны из различных источников, совместимых с API-интерфейсом веб-служб. В Exchange Server 2010 со службами Exchange Web Services стало проще проектировать пользовательские веб-приложения для доступа к данным Exchange Server. В Exchange 2007 программа OWA дополнена четырьмя выбираемыми пользователем темами. В Exchange Server 2010 RTM параметры настройки OWA не реализованы; в установке по-прежнему присутствуют старые темы Exchange 2007, но они не функционируют. Настройки OWA вернулись лишь в пакете обновления Exchange Server 2010 Service Pack 1 (SP1). В текущем пакете обновления Exchange Server 2010 SP2 нет настроек OWA помимо рассматриваемых в данной статье.

Подход Microsoft к настройке OWA

Для многих рассматриваемых изменений OWA необходимо заменить существующие файлы обновленными. При работе с темами, простыми каскадными таблицами стилей (CSS) и экранами регистрации и завершения работы изменения происходят на уровне файлов. Когда Microsoft обновляет Exchange Server — чтобы устранить ошибки, применить накопительные пакеты исправлений или пакеты обновления — компания не гарантирует, что изменения будут сохранены. Не гарантируется также, что обновления программного кода не повлияют на настройки, внесенные пользователем. Поэтому нужно архивировать свои настройки и убедиться, что после применения обновлений настройки OWA будут работать. Подходы Microsoft по настройкам OWA для всех версий вплоть до Exchange 5.5 описаны в статье «Microsoft support policy for the customization of Outlook Web Access for Exchange» (http://support.microsoft.com/kb/327178). Кроме того, рекомендуется разрабатывать и тестировать свои настройки, будь то полноценные пользовательские приложения OWA или изменения экрана регистрации на уровне файлов для фирменного экрана, в лаборатории, прежде чем перенести результаты своей работы в производственную среду.

Сегментация

Сегментация — полностью поддерживаемый метод настройки OWA. С помощью сегментации администратор просто определяет компоненты OWA, видимые конечному пользователю. Многие компании хотят, чтобы их пользователи имели доступ к полному набору функций через клиента OWA. Однако некоторым пользователям для повседневной деятельности может потребоваться лишь ограниченный набор функций. Например, не так давно я работал на заводе, рабочим которого требовался доступ к электронной почте и контактам, но не календарю, заданиям и публичным папкам. Ограниченный доступ к OWA также может помешать пользователям разглашать или видеть конфиденциальную или выходящую за рамки их полномочий информацию. Ограничение доступа к необязательным компонентам в зависимости от области использования или с помощью политики — также хороший метод обеспечения безопасности, снижающий контактную зону риска. Кроме того, благодаря сегментации можно сократить полосу пропускания канала связи, задействованную во время сеансов OWA.

По умолчанию OWA доступен на сервере Exchange 2010 с установленной серверной ролью Client Access. Для сегментации не требуется никакой дополнительной настройки. В версии Exchange 2007 сегментацией легко управлять через консоль управления Exchange (EMC). Настройка сегментации производится через сервер Client Access в EMC.

В консоли EMC перейдите к серверу Client Access, на котором размещается OWA, щелкните правой кнопкой мыши сайт OWA и выберите пункт Properties. На вкладке Segmentation (экран 1) перечислены компоненты OWA, которые могут быть отключены и включены пользователями сервера Client Access (в таблице 1 приведен список доступных функций). Выбирайте и включайте отдельные функции по одной.

В Exchange Server 2010 появились политики почтового ящика OWA. С помощью этих политик администраторы могут применять сегментацию к отдельным пользователям или группам пользователей, а не ко всем, кто подключен к OWA на определенном сервере Client Access. Хотя в названии функции стоит «почтовый ящик», эти политики технически применяются не к почтовым ящикам, а к веб-приложению, используемому для доступа к данным в почтовом ящике. Когда устанавливается серверная роль Client Access, применяется стандартная политика почтовых ящиков OWA. По умолчанию в ней активированы все перечисленные, сегментируемые функции.

Политики почтовых ящиков OWA формируются в консоли EMC на уровне компании, как показано на экране 2. Выберите Client Access в центре Organization Configuration в консоли EMC; политики почтовых ящиков OWA показаны на средней панели. Чтобы добавить новую политику, щелкните правой кнопкой мыши свободную область в средней панели и выберите пункт New в контекстном меню, или выберите его же непосредственно на панели EMC Actions. Как показано на экране 2, основная цель политики почтовых ящиков OWA — настроить определенный вариант сегментации для пользователя или группы, так как больше в пользовательском интерфейсе настраивать нечего. Полезно назначить политике описательное имя, например региона или подразделения, к которому она применяется, или указать в названии конкретную цель сегментации, например No Journal (нет журнала). На экране 3 показано окно свойств Outlook Web App Properties, в котором можно применить существующую политику почтовых ящиков OWA к почтовому ящику или ящикам. Политики почтовых ящиков OWA можно создавать и корректировать с помощью оболочки Exchange Management Shell (EMS) или команд New-OWAMailboxPolicy и Set-OWAMailboxPolicy.

При использовании этих команд для создания новой политики почтовых ящиков OWA или изменения существующей политики можно включать и выключать список атрибутов. Эти атрибуты применяются непосредственно к функциям, перечисленным в таблице 1. По умолчанию функции активны, поэтому в общем случае при настройке политики почтовых ящиков OWA в EMS следует выбрать переключаемые атрибуты и назначить им значение false, чтобы отключить их. Списки атрибутов для каждой команды приведены в статьях Microsoft «Set-OwaMailboxPolicy» (http://technet.microsoft.com/en-us/library/dd297989.aspx) и «New-OWAMailboxPolicy» (http://technet.microsoft.com/en-us/library/dd351067), а также в справке по командам.

Сегментацию тоже можно настроить с помощью EMS на уровне сервера или пользователя. Команда Set-CASMailbox применяет сегментацию, как определено в конкретной политике почтовых ящиков OWA. Например, следующий код применяет политику почтовых ящиков OWA с именем North America Staff к пользователю Steve, имеющему доступ к почтовому ящику:

Если в имени политики почтовых ящиков OWA имеются пробелы, то в EMS требуется использовать кавычки. Чтобы применить политику почтовых ящиков OWA с именем Executives ко всем пользователям, принадлежащим организационной единице (OU) Active Directory (AD) с тем же именем, используйте код:

С помощью EMS можно получить список пользователей, располагающих доступом к почтовым ящикам, к которым нужно применить политики почтовых ящиков OWA на основе типовых существующих атрибутов (например, Title, Location). Для этого используйте Get-User и направьте вывод в команду Set-CASMailbox. Можно также извлечь данные из текстового файла через EMS с помощью команды Get-Content:

OWAPolicyList.txt — простой текстовый файл, содержащий список адресов электронной почты для почтовых ящиков, по одному адресу на строке:

Конечно, администраторам Microsoft Office 365 необходимо использовать EMS для настройки сегментации в компании. Панель Exchange Control Panel (ECP) для Office 365 не обеспечивает доступ к администрированию политики OWA.

В пакете обновления Exchange 2010 SP2 вновь появилась ранее удаленная версия веб-почты: OWA Mini, в прошлом известная как Outlook Mobile Access (OMA) и присутствовавшая в Exchange Server 2003. Функции обновленной версии OWA Mini представляют собой набор форм внутри OWA. Как часть OWA, OWA Mini (для мобильных браузеров) и OWA Basic (для непротестированных браузеров) также признает флаги сегментации. Пользователи, которым запрещен доступ в основным папкам, например Calendar, не могут обратиться к этим папкам через OWA Mini (экран 4) или OWA Basic.

Благодаря сегментации веб-интерфейс OWA для пользователей становится более простым и строгим. По умолчанию OWA показывает основные папки Mail, Calendar, Contacts и Tasks в нижней левой части окна браузера. В качестве простого примера рассмотрим пользователя с именем Steve Bauer, для которого изначально не применялись политики почтовых ящиков OWA и поэтому все функции были включены. Применим политику почтовых ящиков OWA, которая отключает календарь, задания и выбор тем. На экранах 5 и 6 показаны различия в интерфейсе до и после применения политики.

Сегментацию можно применить и на уровне сервера, с помощью команды Set-VirtualDirectory. Как и при использовании команды Set-OWAMailboxPolicy, можно включать и отключать отдельные функции. В этом случае все, кто подключается к определенному серверу и виртуальному каталогу, такому как owa (Default Web Site), увидят одинаковые функции OWA. Если используется какой-нибудь метод балансировки нагрузки для доступа OWA через несколько серверов Client Access то необходимо применить изменения в настройках сегментации ко всем серверам Client Access в пуле. В противном случае пользователи увидят различные конфигурации OWA в зависимости от сервера Client Access, к которому они подключаются через механизм балансировки нагрузки.

Наконец, обратите внимание, что при создании новой политики почтовых ящиков OWA или внесении изменений в сегментацию на уровне сервера, когда нужно немедленно применить политику или изменения к пользователям, может потребоваться перезапустить сайт OWA. При перезапуске Microsoft IIS изменения в OWA также немедленно вступают в силу. Лучше всего это сделать из командной строки на сервере с помощью следующей команды:

Когда пользователи обращаются к URL-адресу для OWA, первым экраном будет экран регистрации (если не произошла ошибка сертификации). В некоторых компаниях стремятся настроить экран регистрации и завершения сеанса, чтобы подчеркнуть фирменную марку или уверить пользователей, что они находятся в нужном месте. Экран регистрации со знакомой корпоративной эмблемой и цветами придаст пользователям уверенность, что они находятся на нужном сайте. На экране регистрации также можно разместить определенную информацию или заявление об отказе от ответственности. Настройки экранов регистрации или завершения сеанса не влияют на базовые функции OWA.

Exchange web access

Outlook Web Access

Работа Outlook, как клиента Microsoft Exchange Server, безусловно позволяет расширить и упростить действия пользователей рабочей группы по обмену информацией. Но что делать в случае, если участник группы находится вне сети предприятия, а доступ к данным необходим?

Microsoft Exchange Server предоставляет пользователю возможность доступа к своему почтовому ящику, к общим папкам группы и т. д. через Web-интерфейс — Outlook Web Access. Данная возможность аналогична сервису Hotmail (см. раздел 11.3 «Работа с Hotmail»). При этом пользователь имеет доступ не только к своей почте, но и к календарю, контактам, данные о которых берутся с сервера, тем самым пользователь работает с единой информацией как через Outlook, так и через Outlook Web Access.

Вход в Outlook Web Access

Для доступа к данным через Web-интерфейс пользователь должен знать URL-адрес сервера, на котором располагается Outlook Web Access, и, естественно, быть зарегистрированным участником рабочей группы Exchange.

Пример 13.19. Доступ через Outlook Web Access

После того как пользователь выполнил успешный вход, будет загружена основная страница, посредством которой можно создавать сообщения, просматривать календарь и адреса рабочей группы, а также осуществлять доступ к общим папкам. Работа с каждой из возможностей интуитивно понятна, а пользователям Outlook просто очевидна. Здесь, как и в Outlook, существует панель ярлыков, посредством которой можно осуществлять доступ к ин формации (слева), меню, посредством которого можно выполнять необходимые действия (вверху), и панель просмотра информации, отображающая данные.

Для обновления информации, отображаемой на странице, необходимо нажать кнопку Обновить (Refresh) на панели инструментов браузера:

Для отображения информации, не помещающейся на странице, можно воспользоваться гиперссылкой Page, расположенной вверху справа на панели меню. Как правило, это необходимо для пролистывания электронных сообщений пользователя.

После того как сеанс работы с Outlook Web Access завершен, для корректного выхода из системы и завершения работы необходимо щелкнуть по гиперссылке Log Of внизу панели Outlook. Эту же процедуру следует проделать, если вы хотите зайти в систему под другим именем.

Отправка сообщения через Outlook Web Access

Не будем здесь подробно рассматривать работу с Outlook Web Access, надеемся, что она понятна и не вызовет особых затруднений, тем более что интерфейс Outlook Web Access не многим отличается от Outlook, а принципы работы различны лишь с точки зрения загрузки и отображения информации. Но для примера все-таки рассмотрим создание и отправку электронного сообщения через Outlook Web Access.

Пример 13.20. Отправка сообщения через Outlook Web Access

Compose New Mail Message

Add Attachment Now

Tell me when this message has been delivered

Tell me when this message has been read

Как видите, основная функциональность сохранена и сообщение отправлено. Аналогично описанной программе следует поступать и с созданием встреч и контактов посредством Outlook Web Access.

Публикация Exchange Server с помощью ADFS / Web Application Proxy

Публикация Exchange Server поможет в решении задачи удаленного доступа к почтовой инфраструктуре из сети Интернет. Разнообразие средств довольно велико. Среди них присутствуют как коммерческие решения, так и решения с открытым кодом. В рамках данной статьи, будет рассмотрен вариант использования служб федерации Active Directory (ADFS) и их компонента Web Application Proxy.

Публикация Exchange Server с помощью ADFS / Web Application Proxy

Ранее, в 2014 году, я уже затрагивал данную тему в одноименном цикле статей. Тогда преаутентификация достигалась с помощью Integrated Windows Authentication, публикация с помощью WAP. Основная проблема данного метода в том, что сервера WAP должны были присутствовать в домене Active Directory. Это, в свою очередь, накладывало определенные ограничения и вопросы с точки зрения сетевой безопасности.

С того времени произошло уж очень много интересного в развитии продуктов. Во-первых, начиная с Exchange 2013 SP1 появилась возможность аутентификации в OWA и ECP с помощью ADFS. Во-вторых, сервисы федерации обзавелись новым функционалом безопасности. Это дает хорошее основание переписать материал используя новые возможности продуктов. В более ранних статьях я уже делал обзор и развертывание служб федерации. Они пригодятся, если ранее вы не сталкивались с конфигурированием данного сервиса:

Итак, в контексте задачи публикации Exchange Server, компоненты служб федерации будут выполнять следующее:

1. ADFS ответственен за аутентификацию пользователей в веб-приложениях OWA и ECP. На основе доменной аутентификации будут создаваться пользовательские токены безопасности, которым Exchange Server будет доверять.
2. На плечи Web Application Proxy возложена задача проксирования запросов аутентификации на сервера ADFS фермы и проксирование https запросов от клиентов к Exchange инфраструктуре. Другими словами, WAP выступает в качестве реверс-прокси сервера.

К процессу публикации стоит относить не только OWA и ECP, но и другие веб сервисы Exchange. Например, веб-каталоги ActiveSync, EWS и другие. Для их публикации будет использоваться Pass-through метод преаутентификации службами ADFS.

Подготовка служб ADFS к публикации Exchange

Первый шаг состоит в подготовке служб ADFS к публикации Exchange. Но, перед тем как начинать, в Exchange инфраструктуре должны быть корректно настроены URL адреса веб-каталогов OWA и ECP. Если это не сделано, статья «Конфигурирование пространства имен в Exchange Server» поможет вам в этом.

В самом ADFS потребуется создать два новых отношения доверия с проверяющей стороной (Relying Party Trust) для OWA и ECP. В этом поможет PowerShell скрипт, который необходимо выполнить на master ноде:

Не забудьте поменять переменные URL адресов OWA и ECP на собственные.

Результат его работы:

Создание Relying Party Trust для Exchange (OWA / ECP) в ADFS

Интеграция Exchange инфраструктуры с ADFS

На каждом сервере Exchange c Client Access Services необходимо выполнить еще один PowerShell скрипт:

Обратите внимание, что указаны переменные ADFSSigningCertificateThumbprint и ADFSIssuerURL. Значение первой можно получить в оснастке ADFS:

SSL сертификаты в ADFS оснастке

Открыв свойства сертификата ADFS Signing. Более подробно о типах SSL сертификатов в ADFS можно ознакомится в этой статье.

Получение Thumbprint сертификата ADFS Signing

Этот сертификат необходимо экспортировать и импортировать в доверенные ЦС каждого Exchange сервера.

Значение второй переменной можно получить подставить FQDN фермы ADFS. Выполняем его в Exchange Management Shell.

Результат выполнения скрипта на Exchange сервере

Перегружаем IIS командой IISReset.

После перезагрузки веб сервера и его инициализации можно выполнить проверку работоспособности. Перейдем на URL ECP.

Проверка аутентификации в Exchange ECP

Автоматически отработает перенаправление на страницу входа ADFS, где необходимо пройти аутентификацию.

В случае если ADFS Signing сертификат не был импортирован в доверенные ЦС Exchange сервера, будет получена ошибка WrongAudienceUriOrBadSigningCert:

Ошибка WrongAudienceUriOrBadSigningCert при аутентификации с помощью ADFS

После добавления сертификата ошибка пропала, и аутентификация в Exchange с помощью ADFS получилась.

Успешная аутентификация в Exchange с помощью ADFS

Публикация Exchange с помощью Web Application Proxy

Завершающим шагом будет публикация веб-каталогов Exchange сервера в сеть Интернет. Перейдем на сервер Web Application Proxy и откроем оснастку управления. В ней необходимо запустить мастер добавления новой публикации и выбрать тип ADFS:

Публикация Exchange Server в Web Application Proxy

Далее, выбираем тип преаутентификации MSOFBA:

Выбор типа преаутентификации в Web Application Proxy

На следующей странице выбираем из списка Exchange Control Panel:

Выбор Relying Party в Web Application Proxy

На завершающем этапе, добавляем конфигурацию публикации:

Конфигурация публикации веб-приложения Exchange в Web Application Proxy

Аналогичным образом настраиваем OWA.

Оставшиеся каталоги (RPC, EWS, OAB, Autodiscover), будут опубликованы так же, но с отличием в методе преаутентификации. Они не могут использовать аутентификацию на основе утверждений, поэтому будет использоваться Pass—through. Единственное исключение составит каталог Autodiscover, так как в его случае публикация осуществляется отдельного поддомена autodiscover. Это требование работы механизма, заложенного в процесс автообнаружения конфигурации Exchange.

В перечисленных выше веб-каталогах отсутствует каталог, отвечающий за подключение мобильных клиентов по протоколу ActiveSync. Начиная с версии ADFS 4.0 (Windows Server 2016), в функционале служб федерации появилась поддержка метода аутентификации HTTP Basic. Этот факт позволит выполнять преаутентификацию клиентов службами федерации, а не перенаправлять не аутентифицированные запросы прямиком на Exchange инфраструктуру. О том как это настроить, в скором времени, выйдет отдельная статья.

На этом все. Если у вас возникли какие-либо вопросы, пожалуйста, пишите в комментарии.

Restrict disable exchange OWA Outlook Web Access ECP external-internet access and save keep EAS ActiveSync access

Ограничить — отключить эксчендж сервер веб доступ к почте OWA Outlook Web Access ECP внешний доступ , или через Интернет и сохранить доступ к EAS ActiveSync

1)Как отключить и включить OWA группами безопасности. How to disable and enable OWA by security groups.

Создаём политику в powerShell

Exchange admin centerpermissionsOutlook Web App policies
для управления функционалом OWA через политику вкл/выкл.

Назначить политику OWALimited на e-mail адрес

Выключить всем To disable OWA open EMS and type:

Включить всем OWA, To enable it back to all users type:

2)Блокировка по ip IP restrictions https://technet.microsoft.com/en-us/library/cc730889.aspx http://www.iis.net/configreference/system.webserver/security/ipsecurity
I was using IIS to prevent outside addresses from accessing my exchange 2010/2013/2016
https://docs.microsoft.com/en-us/iis/configuration/system.webServer/security/ipSecurity/
follow the link above to add the ‘ip address and domain restriction‘ [Ограничение IP-адресов и имен доменов] role to the server
powershell

then go into IIS and modify just the ECP and OWA domain restriction (i added ip restriction to the root and it will propagate to all of the ECP, EWS, MAPI, OAB, etc and it then prevented users from accessing the server)
i added an allow ip rule 192.168.0.1
mask: 255.255.255.0
to allow the LAN to access the OWA and ECP
and i added the deny everyone else below it
0.0.0.0
mask: 255.255.255.255
seems to be working

Во избежание ошибок OWA , рекомендуется использовать iis-Access for unspecified clients-Deny за место 0.0.0.0

Источник MSExchange OWA код события 108 , Outlook Web App не удалось подключится к веб-службе Exchange из-за ошибки конфигурации Код ответа 403 . Через OwA не удаляются любые письма.

3)Редирект owa на локальный адрес Redirecting owa to external/local adress

4)Удалить внешнюю ссылку на owa ecp ,remove external url + iisreset (не помогает) Delete the external link to owa ecp, remove external url + iisreset (does not help)