Общие сведения о разработке клиента EWS для Exchange. Параметры сервера Exchange

24.12.2012

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

Уильям Лефковиц ([email protected]) - технический директор 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, имеющему доступ к почтовому ящику:

Set-CASMailbox -Identity Steve -OwaMailboxPolicy: «North America Staff»

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

Get-CASMailbox -OrganizationalUnit Executives | Set-CASMailbox -OWAMailboxPolicy:Executives

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

Get-Content «c:\files\OWAPolicyList.txt» | Set-CasMailbox -OwaMailboxPolicy «North America Staff»

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

[email protected]

Конечно, администраторам 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.

Экран 4. OWA Mini

Благодаря сегментации веб-интерфейс 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 также немедленно вступают в силу. Лучше всего это сделать из командной строки на сервере с помощью следующей команды:

Iisreset -noforce Logon- and Logoff-Screen Customization

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

Экраны регистрации или завершения сеанса OWA представляют собой автономные веб-формы, в которых используется несколько графических файлов. gif и таблицы CSS для шрифтов и форматирования. Для пользователей, входящих в OWA впервые, имеется дополнительный экран, также зависящий от настроек, поскольку файлы CSS и изображения у него такие же, как у экрана регистрации. Начальный экран регистрации состоит из девяти gif-файлов, упорядоченных и расположенных в соответствии с logon.css. Другие аспекты экрана регистрации также обусловлены информацией в CSS-файле, в том числе тип шрифта и цвета, используемые вне gif-файлов изображения. Те же самые файлы применяются для экрана настройки первой регистрации и экрана завершения сеанса. Чтобы изменить данные файлы, достаточно сделать это лишь однажды; обновления отражаются на всех трех страницах. Стандартные версии экранов регистрации, настроек первой регистрации и завершения сеанса показаны на экранах 7, 8 и 9.

Экран 7. Стандартный экран регистрации

Экран 8. Стандартный экран регистрации в первый раз

Экран 9. Стандартный экран завершения сеанса

Файлы, используемые для экранов регистрации и завершения сеанса, находятся на сервере Exchange с серверной ролью Client Access, в каталоге \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\ \Themes\Resources. Переменная относится к уровню Exchange Server. Exchange 2010 SP2 показывает папку с меткой 14.2.247.5. Exchange 2010 SP2 Rollup 1 добавляет папку 14.2.283.3. OWA использует самый новый источник.

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

Самый простой способ настроить экран регистрации состоит из двух шагов: замените gif-файлы на более подходящие эмблемы компании и соответственно измените logon.css и owafont.css. Естественно, эти поверхностные изменения - не единственные, но таким образом можно добиться максимального эффекта с минимальными усилиями. Gif-файл с текстом Outlook Web App, показанный на экранах 7, 8 и 9, называется lgntopl.gif (имя файла означает logon, top, left - регистрация, верх, слева). Работать с ним проще всего, если вы хотите просто добавить свой логотип, не изменяя стандартной цветовой схемы OWA. При подготовке этой статьи я взял gif-файл и добавил вымышленный логотип Las Vegas Webmail, позаимствовав известный знак Las Vegas из Las Vegas Strip в Неваде, как показано на экране 11. Размер gif-файла остался прежним (456 x 115 пикселов), поэтому в результате простой замены файлов на сервере Client Access пользователи, выполняющие регистрацию в OWA на данном сервере Client Access, увидят новый логотип. Если применить файл другого размера и не внести изменений в файл CSS, то графическое форматирование будет рассогласовано. Местонахождение каждого изображения на странице определяется данными в файле CSS и зависит от расположения пикселов, поэтому если изменить размеры gif-файлов, придется учесть эти изменения в файле CSS. Очевидно, для глубокой настройки экрана регистрации, не ограничивающейся изменением вида существующих изображений, необходимо некоторое знание CSS.

Экран 11. Настроенный экран регистрации OWA

Стиль текста на экране регистрации также определяется инструкциями в файле logon.css. Файлы CSS - простые текстовые файлы, которые можно изменить в текстовом редакторе или одном из многочисленных редакторов CSS. Но сегодня все программы разработки для Интернета также пригодны и для изменения CSS. Microsoft Expression Web - отличный инструмент для работы с CSS-файлами; Microsoft Visual Studio также может служить мощным редактором CSS, хотя использовать его лишь для этой цели явно нерационально. Цвета в CSS определяются шестнадцатеричными кодами цветов: символом (#) с последующим 6-значным кодом. Большинство редакторов CSS располагают цветовыми палитрами с шестнадцатеричными числами. В Интернете также имеются ресурсы быстрого доступа (например, VisiBone). Специалисты по маркетингу, художники и веб-программисты, как правило, определяют точные цветовые коды для печатной продукции и Интернета, представляющие цветовую схему для корпоративных логотипов.

В таблице 3 перечислены некоторые цвета, определенные в файле logon.css для экрана регистрации. Для этого примера я изменил цвет шрифта в файле logon.css с оранжевого на пурпурный, и сделал фон поля ввода имени пользователя и пароля вместо светло-оранжевого светло-серым. Я также выделил рамку вокруг полей ввода, изменив разреженный серый цвет на более насыщенный синий, изменив цветовой код и увеличив частоту пикселов в рамке. Чтобы внести эти изменения, я изменил значения fff3c0 на cccccc, ff6c00 на 800080 и a4a4a4 на 000080 в файле logon.css. Потребовалось проверить несколько версий, чтобы точно определить, какие элементы файла CSS применяются на странице. Предусмотрительно сохранив резервную копию logon.css, я поместил новый файл в каталог \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\14.2.283.3\Themes\Resources на сервере Client Access. Я также скопировал новое изображение lgntopl.gif в тот же каталог. На экране 12 показаны простые изменения, внесенные в экран регистрации OWA. Конечно, ваши возможности не ограничиваются этими простыми настройками. Имея хорошие знания об особенностях применения CSS и графики, можно подготовить собственные экраны регистрации и завершения сеанса, неузнаваемые по сравнению со стандартными вариантами OWA.

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

Применение настроек

Изменения OWA не реплицируются между серверами Client Access. Если несколько серверов Exchange с установленной серверной ролью Client Access предоставляют OWA, то любые настройки необходимо применять на каждом сервере. Только в этом случае все пользователи будут видеть одинаковые экраны. Пользователи будут получать экраны OWA с того сервера Client Access, на который направлены их браузеры. Это может быть как достоинством, так и недостатком. Иногда полезно, чтобы различные группы пользователей по-разному взаимодействовали с OWA в корпоративной среде.

Если вы не хотите работать на файловом уровне в Exchange Server, но нуждаетесь в изменениях экранов регистрации и завершения работы, то некоторые компании, специализирующиеся на корпоративной символике, предоставляют услуги для различных настраиваемых программных решений, в том числе OWA 2010. Многие вносят глубокие изменения в экраны регистрации OWA, так что приложение становится неузнаваемым. Пример такого поставщика (с несколькими снимками экрана для клиентских решений) - Techstur.com. Если воспользоваться услугами такой компании, будьте готовы решать проблемы, которые могут возникнуть после выпуска новых пакетов обновления для OWA.

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

Приветствую всех читателей нашего Блога! Сегодня я расскажу вам о том, как за несколько минут настроить публикацию почтового сервера Exchange Server 2013 /2016 с помощью IIS ARR (Application Request Routing ). Но для начала немного о том, что такое публикация и для чего она нужна.

Основная задача публикации это защита сервера от внешнего негативного воздействия. Сервер публикации Reverse Proxy (RP) , располагается в сети периметра (DMZ ) и передает (проксирует) запросы на почтовые сервера, в том случае, если запросы соответствуют определенным шаблонам. Логика работы RP на основе компонента ARR следующая: если поступает запрос с именем узла mail.contoso.com по протоколу HTTPS , тогда перенаправить запрос на ферму серверов mail.contoso.com . Все просто и понятно. Веб сервер используется по той простой причине, что в Exchange 2013/2016 ВСЕ подключения (кроме POP и IMAP конечно!) идут через HTTPS и неважно что вы используете, браузер или толстый клиент Outlook .

Некоторые особенности RP серверов на основе IIS ARR :

Сервер RP может не быть членом домена.
Сервер должен иметь доступ к внутренней сети организации (конкретно к почтовым серверам) и внешней сети Интернет. Один из вариантов реализации это два сетевых адаптера .
RP должен разрешать FQDN (полное доменное имя ex1-srv.contoso.com , ex2-srv.contoso.com и т.д.) почтового сервера в его IP адрес. Если в сети периметра не используется DNS сервер, необходимо прописать имена серверов и IP в файле C:\Windows\System32\Drivers\etc\hosts .
Убедитесь, что вы правильно настроили внутренние и внешние URL для виртуальных каталогов на почтовом сервере и правильно сконфигурировали сервера. Прежде чем приступать к публикации, проверьте, что все отлично функционирует в пределах локальной сети.
DNS-суффикс сервера RP (в том случае, если он не включен в домен) нужно настроить вручную так, чтобы он был идентичен доменному (RP.contoso.com ).
Убедитесь, что виртуальные каталоги (OWA, ECP, EWS и т.д.) опубликованы для внешних подключений с пространством имен mail.contoso.com

Приступим к установке.

1 ) Запустить PowerShell с привилегиями Администратора и выполнить

Import-Module ServerManager Add-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Net-Ext,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,NET-Framework-Core,NET-Win-CFAC,NET-Non-HTTP-Activ,NET-HTTP-Activation,RSAT-Web-Server

Проверим что все получилось, введя в браузере сервера RP http://127.0.0.1

2 ) Устанавливаем Microsoft Web Platform Installer . В поиске Microsoft Web Platform Installer набираем ARR и устанавливаем пакет Application Request Routing 3.0 + дополнительные компоненты предложенные установщиком.

4 ) Переходим в Server Farms и создаем новую ферму серверов. Назовем ее Contoso.com

Добавим сервера в ферму (Если роли разнесены, то добавляем только CAS сервера). Вводим FQDN сервера и нажимаем ADD

Нажимаем Finish , затем YES на предложение создать правила.

5) Необходимо настроить ферму, в которую мы добавили наши почтовые сервера. Открываем ферму contoso.com и переходим в раздел Caching . Убираем чекбокс Enable Disk Cache и нажимаем Apply

Переходим в раздел Health Test . В качестве URL для проверки доступности серверов я укажу:

https://autodiscover.contoso.com/Autodiscover/HealthCheck.htm

URL для проверки доступности имеет вид https:////HealthCheck.htm это URL по умолчания для Exchange Server 2013/2016. Для каждого протокола существует свой URL и его нет необходимости настраивать дополнительно, это все часть компонента Managed Availability . Можно указать другие URL для соответствующих протоколов:

https://mail.contoso.com/EWS/HealthCheck.htm
https://mail.contoso.com/OAB/HealthCheck.htm
https://mail.contoso.com/OWA/HealthCheck.htm

Настройки для раздела Health Test (после внесения изменений, не забываем нажимать Apply )

После внесения всех настроек нужно проверить, что все работает. Нажмем Verify URL Test и убедимся, что все серверы прошли проверку, ответив Pass. Если сервер не будет доступен, то на него не будут пересылаться запросы от внешних клиентов. Компонент ARR выведет его из балансировки до тех пор, пока снова не “увидит” сервер клиентского доступа.

Переходим к разделу Proxy , выставляем настройки:

Time-Out: 200 seconds
Response Buffer threshold: 0

не забываем нажимать Apply после внесения изменений.

Load Balance, Monitoring and Management и Server Affinity не трогаем.

6 ) Переходим к созданию правил перенаправления запросов.

В оснастке IIS открываем URL Rewrite

Создаем правило для Autodiscover

Для добавления шаблона во вкладке “Conditions” нажать “Add” и ввести параметры:

Аналогично ввести “{HTTPS} ON”

В самом низу выбираем действие, которое необходимо выполнить, если запрос соответствует шаблону. В нашем случае, это перенаправление на ферму серверов (не забывайте выбрать https ) и чекбокс запрещающий выполнение следующих (нижних) правил.

Готово.

Аналогичным образом создаем правило для mail.contoso.com и, ели есть желание, для activesync.contoso.com .

В получившемся списке, первым должно идти правило Autodiscover , затем activesync , после mail . Правила отрабатывают по очереди, одно за другим. Перемещать правила в списке можно с помощью стрелок вверх и вниз, находящихся слева.

Последний штрих. Перейдите в “Request Filtering”

и задайте значение 2147483648 для параметра “Maximum allowed content lenght”.

Всё готово! Теперь необходимо настроить внешние DNS сервера, для разрешения имен Autodiscover и mail (а если настраивали, то и activesync ) в IP IIS ARR .

По просьбам трудящихся закрываем ECP

Общая информация

Если у вас есть учётная запись на сервере MS Exchange 2007 или выше, вы можете создать в The Bat! ящик и настроить его на работу с почтой по протоколу EWS (Exchange Web Services). Устанавливать дополнительные программы или использовать профиль Outlook, как в случае с MAPI, при этом не нужно. Помимо писем, The Bat! будет загружать также другие компоненты MS Exchange, такие как календари, контакты, задачи, заметки.

При первом подключении к серверу The Bat! импортирует загруженные контакты в адресную книгу. Если для писем, заданий или событий в календаре назначены напоминания, The Bat! добавит их в собственный Планировщик. Все остальные компоненты MS Exchange носят лишь информационный характер.

Создание нового почтового ящика EWS

В диалоговом окне Создание нового почтового ящика введите ваш электронный адрес и пароль для доступа к учётной записи Exchange, выберите "Веб-службы Exchange (EWS) " в поле со списком Протокол и нажмите на кнопку Далее .

The Bat! использует службу автообнаружения Exchange , чтобы автоматически получить с вашего сервера Exchange информацию для настройки учётной записи. Если ваш сервер Exchange настроен правильно, The Bat! обнаружит конечную точку сервера Exchange и отобразит ее адрес в соответствующем поле.

Если программа обнаружит конечную точку, нажмите Далее .

Если найти конечную точку сервера Exchange не удастся (поле "Конечная точка сервера Exchange " останется пустым), вы можете:

Изменить учётные данные и проверить соединение
Ввести конечную точку сервера Exchange вручную

В поле Электронный адрес или пользователь введите ваше имя пользователя или UPN , чтобы программа обнаружила конечную точку:

(вход по домену/пользователю )

Или

(вход по UPN )

На первом снимке экрана для доступа используется имя домена и имя пользователя, разделённые обратной косой.

На втором снимке экрана для доступа используется UPN: имя для входа, знак "@" и имя домена.

Нажмите кнопку Проверить! , чтобы The Bat! начал поиск конечной точки сервера Exchange. Каждый раз мастер настройки будет запускать несколько заданий одновременно, чтобы найти лучшее решение. Все найденные конечные точки Exchange будут добавлены в выпадающее меню. Анимация будет отображаться, пока процесс поиска не завершится.

Обратите внимание : если вы не знаете, какое имя пользователя нужно указать для доступа к серверу Exchange, введите данные доступа, которые вы используете для доступа к вашей учётной записи через OWA (Outlook Web Access).

Если программе не удастся определить конечную точку сервера Exchange, попросите администратора вашего сервера предоставить вам конечную точку и данные доступа (UPN и пароль либо имя пользователя и пароль).

Позже вы можете изменить настройки доступа в меню Ящик -> Свойства почтового ящика -> Транспорт .

Если конечная точка сервера Exchange автоматически не обнаружилась или недоступна, это может означать, что администратор сервера Exchange заблокировал доступ по протоколу EWS. Для проверки попытайтесь соединиться с https://mail.company.com/ews/exchange.asmx: при этом должно появиться окно аутентификации.
После успешной аутентификации вы должны получить WSDL-определение EWS. Если вы не получили его, обратитесь к администраторам вашего сервера Exchange с просьбой изменить соответствующие настройки сервера.
Чтобы получить конечную точку сервера Exchange, вы можете также использовать страницу, предоставленную Microsoft: https://testconnectivity.microsoft.com
На вкладке Exchange Server выберите раздел Microsoft Exchange Web Services Connectivity Tests и после тестирования изучите детали – вы должны увидеть значение EwsUrl. Этот адрес используйте в качестве конечной точки сервера Exchange в The Bat!

Вы можете также задать параметры проверки сертификатов. Предупреждение системы безопасности может появиться, если ваш сервер Exchange использует самоподписанный сертификат либо сертификат, срок действия которого истёк:

Чтобы не получать предупреждение системы безопасности, вы можете включить опцию Не проверять сертификат узла .

Внимание : вы можете не проверять сертификат, только если вы доверяете источнику.

Когда процесс автообнаружения завершится, нажмите Далее .

Поле Ваше имя отобразит ваше имя на сервере Exchange. Если соединение было установлено, то в этом поле вы увидите полное имя, которое программа получила с сервера. В ином случае, в этом поле отобразится то имя, которое вы указали на первом шаге создания ящика.

Во втором поле будет указано название вашего ящика в дереве папок.

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

Нажмите Готово , чтобы завершить процесс создания нового ящика. Как только ящик появится в дереве папок, программа установит соединение с сервером и загрузит папки с их содержимым.

Получение писем и структура папок

The Bat! загрузит все папки с их содержимым (за исключением папок Deletions, Archive и Recoverable) при первом соединении с сервером.

Кроме стандартных папок, программа загрузит папки Календарь, Контакты, Задачи и некоторые другие, которые будут отображать такие компоненты MS Exchange, как события, контакты, задачи, заметки, RSS-подписки. The Bat! также может загружать содержимое общих папок Exchange. Если у вас есть права на общую папку, вы увидите её в папке All Public Folders.

Программа отобразит все атрибуты, используемые в Outlook, которые соответствуют функциональности The Bat! и RFC822, такие как Тема, Отправитель, Получатель, Копия, Скрытая копия и другие заголовки, флаги, прикрепленные файлы, теги, шифрование, дату и время получения и создания письма, размер.

Программа может загружать письма, полученные с определенного дня. При создании ящика вы можете включить опцию Загружать элементы, созданные после и указать дату. Письма, полученные раньше этого дня, The Bat! не загрузит. Включить эту опцию можно также в свойствах ящика в разделе «Транспорт».

Если вы подключены к социальным сетям в Outlook (Twitter, Facebook, LinkedIn), папки с контактами этих социальных сетей также отобразятся в дереве ящиков в The Bat! Каждый такой контакт содержит прикрепленную визитную карточку vCard, фото или другие файлы, которые вы назначили этому контакту.

The Bat! может также загружать контакты из корпоративной сети. Для этого при создании ящика включите опцию Загружать контакты Active Directory . Эту опцию можно включить также в свойствах ящика в разделе «Транспорт». Контакты из корпоративной сети сохраняются в папке EWS ящика Active Directory. Контакты в этой папке нельзя удалять или перемещать. Программа автоматически импортирует контакты из корпоративной сети в адресную книгу EWS.

Когда вы первый раз установите соединение с сервером, The Bat! создаст адресную книгу и импортирует в неё загруженные контакты. Имя такой адресной книги состоит из названия ящика и пометки “”:

Вы можете изменить название этой адресной книги, но она по-прежнему будет связана с ящиком EWS. Если вы удалите адресную книгу, контакты исчезнут из интерфейса The Bat! Вы сможете импортировать их вновь из файла <имя контакта>.vcf, прикрепленного к каждому контакту. При следующем соединении с сервером The Bat! обнаружит, что адресная книга отсутствует и создаст новую.

Если вы назначили напоминание письму, задаче либо событию в Outlook или OWA, The Bat! добавит это напоминание в Планировщик, как только вы загрузите это письмо/задачу/событие. Программа оповестит вас о событии в назначенное время.

Если вы создадите элемент на сервере Exchange, The Bat! загрузит его при соединении с сервером. Однако элементы, созданные в The Bat! не будут передаваться на сервер, они хранятся локально.

Синхронизация

Когда The Bat! загружает элементы MS Exchange, они сохраняются локально. Если при этом на сервере эти элементы изменяются, The Bat! не отобразит их до тех пор, пока вы не очистите кэш папки.

Если вы удаляете элементы при помощи клавиши Delete, они удалятся с сервера Exchange.

Если вы удаляете элементы, используя альтернативное удаление (сочетание клавиш Shift+Delete), они также удалятся с сервера (в данном случае используется Exchange soft delete mode). Если вы восстановите удаленные элементы в The Bat! через меню Папка -> Просмотреть удаленные письма (чтобы восстановить удаленное письмо, выделите его и нажмите клавишу Delete), они сохранятся лишь локально.

Если вы удалите письмо, загруженное в The Bat!, с сервера Exchange, оно не удалится из программы, однако, если вы очистите кэш папки, письмо повторно не загрузится.

При перемещении и копировании писем и элементов Exchange в папки ящика EWS, они загружаются и на сервер в соответствующие папки. При перемещении письма из папки оно удаляется из папки на сервере.

The Bat! поддерживает синхронизацию флагов Прочитанное/Непрочитанное, Помечено флажком и принимает флаг Парковано (“is draft” в терминологии Exchange). Например, если вы пометите письмо как прочитанное в The Bat!, в другом почтовом клиенте оно также отобразится как прочитанное. Флаги Отвечено и Переслано/Перенаправлено не синхронизируются.

The Bat! синхронизирует приоритет писем и пометку конфиденциальности (Sensitivity). Пометка конфиденциальности отображается как тег. Чтобы изменить ее, нажмите правой кнопкой мышки на письмо и выберите пометку в разделе «Теги». Атрибуты, которые не поддерживаются в The Bat!, отображаются как теги. Синхронизация цветовых групп не поддерживается.

Управление папками

Папки в The Bat! отображаются на языке, установленном в вашей учётной записи на сервере (OWA -> Параметры -> Региональные -> Язык -> Сохранить). Если вы поменяете язык в настройках OWA, названия папок в The Bat! также изменятся.

Если вы переименуете, переместите или удалите папку в The Bat!, эти изменения отобразятся и на сервере, а значит, и в других почтовых клиентах. Если вы создадите папку в The Bat!, она появится на сервере. Если структура папок на сервере изменяется (вы переименовываете, создаете, удаляете или перемещаете папки), The Bat! также обновит структуру папок при соединении с сервером.

Если вы не хотите видеть папку в дереве ящиков, но хотите сохранить ее на сервере, вы можете скрыть ее: выберите папку, нажмите клавишу Delete и выберите опцию Скрыть папку .

Чтобы скрывать папки, необходимо также включить опцию в меню Ящик -> Свойства почтового ящика -> Транспорт :

Если эта опция отключена, скрытые папки восстановятся при следующем соединении с сервером.

Таким образом, вы можете включить опцию Сохранять список скрытых папок и скрывать папки. Чтобы вновь отобразить все скрытые папки, отключите эту опцию и вызовите команде «Получить новую почту».

Вы можете также очистить кэш папок, нажав на кнопку Очистить кэш в меню Папка –> Свойства папки -> Свойства EWS . После очистки The Bat! загрузит с сервера элементы Exchange заново.

Информация, содержащаяся в этом документе, может относиться к функциям и продуктам предварительной версии и может претерпеть значительные изменения до окончательного коммерческого выпуска. Настоящий документ предоставляется "как есть" и служит только для информационных целей. Корпорация Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, в связи с этим документом

Советы по разработке с использованием EWS для Exchange.

Область применения: Exchange Online | Exchange Server 2013 | Office 365

В этой статье приведены общие сведения о создании приложения веб-служб Exchange (EWS). С помощью этих сведений можно определить, подходит ли API EWS для вашего приложения и какой тип реализации клиента вам нужен. Эта статья также содержит рекомендации по созданию приложений для Office 365, Exchange Online и версий Exchange, начиная с Exchange 2007, с использованием одной базы данных кода. Кроме того, она помогает решить, для какой среды лучше разрабатывать решения - для локальных серверов Exchange Server или Exchange Online.

Прежде чем приступать к созданию приложения, необходимо определить, подходит ли вам API EWS. Если вы разрабатываете решение для Exchange Server или Exchange Online, EWS - предпочтительная технология клиентского доступа. Разработка решений клиентского доступа для версий Exchange, начиная с Exchange 2007, в основном ориентировалась на EWS. EWS используется для работы новых функций клиентского доступа, реализованных в Outlook. К последним относится отображение состояния "нет на месте" и сведений о доступности, впервые доступное в Exchange 2007, а также функции подсказок и получения помещений, представленные в Exchange 2010. И для внутренних, и для внешних партнеров, разрабатывающих клиентские приложения Exchange, это говорит в пользу обязательности вложений в EWS.

API EWS - основной API клиентского доступа для клиентских приложений Exchange. Но в некоторых случаях для разработки клиентских приложений могут пригодиться другие API Exchange. Например, Exchange ActiveSync обладает следующими преимуществами перед EWS:

Чтобы сделать протокол Exchange ActiveSync более компактным, проведена разметка структуры XML.

Exchange ActiveSync позволяет с помощью политик управлять клиентским доступом и использовать другие надежные решения для обмена мобильными сообщениями на предприятии.

MAPI RPC/HTTP - это еще один вариант для программирования клиентских приложений Exchange. Но тем не менее MAPI RPC/HTTP не обладает интуитивно понятным интерфейсом для связи между клиентами и сервером.

Дополнительные сведения о технологиях разработки для Exchange см. в статье .

Существует несколько способов разработки для Exchange с использованием EWS. Выбор оптимального варианта зависит от платформы разработки, инструментов, доступных реализаций и требований к приложениям для организации. Для создания клиентских приложений EWS доступны четыре основных варианта:

управляемый API EWS;

автоматически созданные прокси EWS;
настраиваемый клиентский API EWS.

Управляемый API EWS

API веб-службы EWS может подойти вам больше, чем управляемый API EWS, по одной из следующих причин:

ваше приложение не использует.NET Framework;

вы не хотите распространять сборку управляемого API EWS;

для приложения требуются функции, не доступные в управляемом API EWS.

Дополнительные сведения см. в статье .


Теперь управляемый API EWS доступен в виде проекта с открытым кодом на сайте GitHub . С помощью библиотеки с открытым кодом вы можете: добавлять исправления ошибок и улучшения в API; получать исправления ошибок и улучшения до того, как они станут доступны в официальном выпуске; получать доступ к самой полной и актуальной реализации API, которую можно использовать для справки или для создания новых библиотек на новых платформах.

Теперь управляемый API EWS доступен в виде проекта с открытым кодом на сайте GitHub . С помощью библиотеки с открытым кодом вы можете:

добавлять исправления ошибок и улучшения в API;

получать исправления ошибок и улучшения до того, как они станут доступны в официальном выпуске;

получать доступ к самой полной и актуальной реализации API, которую можно использовать для справки или для создания новых библиотек на новых платформах.

Www.microsoft.com

Внутренние и внешние URL Exchange 2013 нужны для доступа к тем или иным службам из различного расположения — из локальной сети или интернета. По умолчанию при установке сервера заданы лишь внутренние URL и ссылаются они на fqdn сервера, а внешние URL отсутствуют полностью. .

Эта статья является пятой из цикла, в котором освещены вопросы обязательных задач по настройке сервера Exchange 2013 сразу после его установки. Если вам интересны другие задачи, рекомендую обратиться к головной статье по настройке — или основной статье тематики — .

Перейдем к основной цели этой статьи — изменению внутренних и внешних URL-адресов.

Настройка

Для этого проходим в директорию EAC — Серверы\Серверы — выделяем мышкой нужный сервер (у меня это exch02)\Изменить (значок карандаша) — Мобильный Outlook .

В поле Укажите имя внешнего узла (например, contoso.com) для подключения пользователей к вашей организации . прописываем необходимый нам внешний адрес. У меня это будет mail.bissquit.com. Также не лишним будет изменить имя внутреннего узла на аналогичное. Вам решать одинаковыми будут внешние и внутренние имена или разными, но сделать их идентичными выглядит более чем логично.

Если не меняли тип проверки подлинности, то вылезет предупреждение:

У меня нет более ранних версий Exchange, поэтому предупреждение игнорирую.

Через Powershell это сделать можно используя командлет Set-OutlookAnywhere :

PowerShell

Проверим результат:

Далее изменим настройки виртуальных каталогов, добавив в них внешний URL-адрес (по умолчанию он отсутствует) и задав аналогичный адрес для внутренних подключений. Через веб-интерфейс EAC можно выполнить соответствующие действия в каталоге Серверы\Виртуальные каталоги — выделить мышкой нужный каталог, нажать Изменить (значок карандаша), установить необходимые внутренние и внешние URL-адреса.

Повторить действия для каждого виртуального каталога, кроме Autodiscover (Default Web Site). Пример изменения свойств виртуального каталога ecp ‎(Default Web Site) ‎:

Для изменения настроек через PowerShell будет достаточно много команд, поскольку для каждого типа виртуального каталога существует отдельный набор командлетов:

Для изменения виртуального каталога панели управления — Set-EcpVirtualDirectory .
Для изменения виртуального каталога Веб-служб Exchange — Set-WebServicesVirtualDirectory .
Для изменения виртуального каталога служб Microsoft Exchange ActiveSync — Set-ActiveSyncVirtualDirectory .
Для изменения виртуального каталога автономной адресной книги — Set-OabVirtualDirectory .
Для изменения виртуального Outlook — Set-OwaVirtualDirectory .
Для изменения виртуального каталога PowerShell — Set-PowerShellVirtualDirectory .

Итак, ближе к делу:

PowerShell

Set-EcpVirtualDirectory "exch02\ecp (Default Web Site)" -InternalUrl https://mail.bissquit.com/ecp -ExternalUrl https://mail.bissquit.com/ecp Set-WebServicesVirtualDirectory "exch02\EWS (Default Web Site)" -InternalUrl https://mail.bissquit.com/EWS/Exchange.asmx -ExternalUrl https://mail.bissquit.com/EWS/Exchange.asmx Set-ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync -ExternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync Set-OabVirtualDirectory "exch02\OAB (Default Web Site)" -InternalUrl https://mail.bissquit.com/OAB -ExternalUrl https://mail.bissquit.com/OAB Set-OwaVirtualDirectory "exch02\OWA (Default Web Site)" -InternalUrl https://mail.bissquit.com/owa -ExternalUrl https://mail.bissquit.com/owa Set-PowerShellVirtualDirectory "exch02\PowerShell (Default Web Site)" -InternalUrl https://mail.bissquit.com/PowerShell -ExternalUrl https://mail.bissquit.com/PowerShell

Set -EcpVirtualDirectory "exch02\ecp (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / ecp -ExternalUrl https : / / mail . bissquit . com / ecp

Set -WebServicesVirtualDirectory "exch02\EWS (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / EWS / Exchange . asmx -ExternalUrl https : / / mail . bissquit . com / EWS / Exchange . asmx

Set -ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / Microsoft-Server -ActiveSync -ExternalUrl https : / / mail . bissquit . com / Microsoft-Server -ActiveSync

Set -OabVirtualDirectory "exch02\OAB (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / OAB -ExternalUrl https : / / mail . bissquit . com / OAB

Set -OwaVirtualDirectory "exch02\OWA (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / owa -ExternalUrl https : / / mail . bissquit . com / owa

Set -PowerShellVirtualDirectory "exch02\PowerShell (Default Web Site)" -InternalUrl https : / / mail . bissquit . com / PowerShell -ExternalUrl https : / / mail . bissquit . com / PowerShell

Переходим к следующей главе.

Настройки локального DNS-сервера

Поскольку мы указали одинаковые внутренние и внешние URL-адреса для сервисов Exchange 2013, нужно разобраться как правильно настроить записи локального DNS-сервера (забегая вперед, скажу, что это называется Split DNS).

Примечание: дело в том, что домен mail.bissquit.com будет разрешаться во внешний адрес шлюза и таким образом отправляться наружу и при попадании на шлюз разворачиваться обратно в локальную сеть. Страшного в этом ничего нет, но это явно лишний маршрут, который будет проделывать весь трафик, направляющийся к вашему Exchange 2013 из локальной сети..

На контроллере домена необходимо пройти в оснастку «DNS» и создать новую зону прямого просмотра:

Все настройки оставляем по умолчанию, только указываем необходимое имя, у меня это bissquit.com. После создания зоны необходимо добавить одну CNAME-запись. Нам нужно, чтобы mail.bissquit.com разрешалось во внутренний адрес сервера Exchange 2013:

Примечание: обратите внимание, что добавление к обслуживанию домена второго уровня может оказаться крайне плохой идеей, если этот домен (или его поддомены) подвязан к каким-то внешним ресурсам. В этом случае ваш локальный DNS-сервер будет считать себя ответственным за всю эту зону и возвращаться ответ, что, например, домена сайт не существует.

Запись создана, проверим как работает:

Имя mail.bissquit.com разрешается во внутренний адрес, все нормально, как нам и нужно. Однако при попытке «пропинговать» другой поддомен, для которого мы записи в новой зоне не создавали, разрешить имя не получается. Это происходит потому, что наш DNS-сервер считает себя ответственным (авторитативным) за весь домен bissquit.. Отправить DNS-запросы для записи сайт наружу можно с помощью делегирования:

В имени укажите необходимый домен:

Далее пропишите один (а ещё лучше несколько) из NS-серверов вашего провайдера, у которого администрируете DNS-записи. Если не знаете ни одного NS-сервера, запустите nslookup в командной строке, задайте тип записи (set type=ns), введите необходимое доменное имя (у меня это bissquit.com):

Ещё раз проверим:

Как видите, все работает. Спасибо статье на блоге Алексея. Небольшой недостаток этого метода в том, что нужно вручную прописывать все внешние поддомены. Правда у меня их пока немного, всего один.

Итак, на этом настройка DNS закончена. По большому счету к настройке внутренних и внешних URL-адресов администрирование сервера DNS относится лишь косвенным образом, но этот момент важно рассмотреть, поскольку в документации на Technet при выполнении настройки URL-адресов даются лишь общие сведения о том, какие записи DNS необходимо создать, но как это сделать и какие есть нюансы не объясняется:

После настройки внутреннего URL-адреса в виртуальных каталогах сервера клиентского доступа необходимо настроить частные записи DNS для Outlook Web App и других возможностей подключения. В зависимости от конфигурации нужно будет настроить частные DNS-записи так, чтобы они указывали на внутренний или внешний IP-адрес либо полное доменное имя сервера клиентского доступа. Ниже приведены примеры рекомендуемых DNS-записей, которые необходимо создать для подключения внутренних клиентов.

FQDN Тип DNS-записи Значение
Mail.contoso.com CNAME Ex2013CAS.corp.contoso.com
Owa.contoso.com CNAME Ex2013CAS.corp.contoso.com

FQDN	Тип DNS-записи	Значение
Mail.contoso.com	CNAME	Ex2013CAS.corp.contoso.com
Owa.contoso.com	CNAME	Ex2013CAS.corp.contoso.com