Общие сведения о разработке клиента EWS для Exchange. Подключение почтовых клиентов к Microsoft Exchange Server

В 5 части этого цикла статей мы рассмотрели создание массива Client Access на каждом сайте Active Directory. Затем мы включили Outlook Anywhere, а также настроили параметры Outlook Provider, чтобы Outlook Anywhere клиенты могли подключаться при возникновении аварийной ситуации.

В этой части цикла мы продолжим с того места, на котором остановились в предыдущей части. Мы начнем с настройки внутреннего и внешнего URL адреса для служб CAS на каждом сервере Exchange 2010 на обоих сайтах Active Directory. Затем мы создадим группу DAG и выполним базовую настройку DAG.

Изменение внутреннего и внешнего Exchange 2010 CAS URL адреса для указания на HLB

Пришло время настроить внутренний и внешний URL адрес для Exchange 2010 CAS служб в каждом центре данных так, чтобы они указывали на каждое решение балансировки нагрузки соответственно.

Подводя краткий итог предыдущим частям этого цикла, можно сказать, что адрес ‘mail.exchangeonline.dk ‘ указывает на VIP адрес, настроенный на решении балансировки нагрузки в основном центре данных, а ‘failover.exchangeonline.dk ‘ указывает на VIP адрес, настроенный на решении балансировки нагрузки в аварийном центре данных. Это означает, что URL адреса нужно настраивать по-разному для каждого центра данных.

Outlook Web App (OWA)

Начнем с URL адресов для Outlook Web App (OWA). Для этого используем следующие команды:

Основной центр данных:

Set-OwaVirtualDirectory -Identity "EX01\OWA (Default Web Site)" -InternalURL /OWA -ExternalURL https://mail.exchangeonline.dk/OWA

Set-OwaVirtualDirectory -Identity "EX03\OWA (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/OWA -ExternalURL https://mail.exchangeonline.dk/OWA

Аварийный центр данных:

Set-OwaVirtualDirectory -Identity "EX02\OWA (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA

Set-OwaVirtualDirectory -Identity "EX04\OWA (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA

Рисунок 1: Настройка URL адресов для OWA Virtual Directory

Панель управления Exchange Control Panel (ECP)

Для панели управления Exchange Control Panel (ECP) мы используем следующие команды:

Основной центр данных:

Set-EcpVirtualDirectory -Identity "EX01\ECP (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/ECP -ExternalURL https://mail.exchangeonline.dk/ECP

Set-EcpVirtualDirectory -Identity "EX03\ECP (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/ECP -ExternalURL https://mail.exchangeonline.dk/ECP

Аварийный центр данных:

Set-EcpVirtualDirectory -Identity "EX02\ECP (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP

Set-EcpVirtualDirectory -Identity "EX04\ECP (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP

Рисунок 2: Настройка URL адресов для ECP Virtual Directory

Exchange ActiveSync (EAS)

Для Exchange ActiveSync (EAS) используем следующие команды:

Основной центр данных:

Set-ActivesyncVirtualDirectory -Identity EX01\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync

Set-ActivesyncVirtualDirectory -Identity "EX03\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync

Аварийный центр данных:

Set-ActivesyncVirtualDirectory -Identity "EX02\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync

Set-ActivesyncVirtualDirectory -Identity "EX04\Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync

Рисунок 3: Настройка URL адресов для EAS Virtual Directory

Offline Address Book (OAB)

Для Offline Address Book используем следующие команды:

Основной центр данных:

Set-OABVirtualDirectory -Identity "EX01\oab (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab

Set-OABVirtualDirectory -Identity "EX03\oab (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab

Аварийный центр данных:

Set-OABVirtualDirectory -Identity "EX02\oab (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab

Set-OABVirtualDirectory -Identity "EX04\oab (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab

Рисунок 4: Настройка URL адресов для OAB Virtual Directory

Exchange Web Services (EWS)

Для Exchange Web Services (EWS) используем следующие команды:

Основной центр данных:

Set-WebServicesVirtualDirectory -Identity "EX01\EWS (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identity "EX03\EWS (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx

Аварийный центр данных:

Set-WebServicesVirtualDirectory -Identity "EX02\EWS (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identity "EX04\EWS (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx

Рисунок 5: Настройка URL адресов для EWS Virtual Directory

Unified Messaging (UM)

В этой тестовой среде мы не используем Unified Messaging (UM), но если у вас другие планы, вам нужно будет настроить для нее URL адрес с помощью следующих команд:

Основной центр данных:

Set-UMVirtualDirectory -Identity "EX01\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx

Set-UMVirtualDirectory -Identity "EX03\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx

Аварийный центр данных:

Set-UMVirtualDirectory -Identity "EX02\unifiedmessaging (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx

Set-UMVirtualDirectory -Identity "EX04\unifiedmessaging (Default Web Site)" -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx

Внутренняя Autodiscover URI

Наконец нам нужно направить внутренний URI службы Autodiscover Service на FQDN решения HLB. Это можно сделать с помощью следующих команд:

Основной центр данных:

Set-ClientAccessServer ‘Identity EX01 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk

Set-ClientAccessServer ‘Identity EX03 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml

Аварийный центр данных:

Set-ClientAccessServer ‘Identity EX02 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml

Set-ClientAccessServer ‘Identity EX04 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /Autodiscover/Autodiscover.xml

Рисунок 6: Параметры Internal Autodiscover URI

Обратите внимание, что мы направили Exchange 2010 серверы в обоих центрах данных на один и тот же autodiscover URI. Также можно направить AutoDiscoverInternalUri на CAS серверах в аварийном центре данных на ‘https://failover.exchangelabs.dk/autodiscover/autodiscover.xml’ таким образом, вы можете оказаться в ситуации, когда SCP недоступны во время аварийной ситуации. Также межсайтовый трафик, генерируемый службой Autodiscover, будет оказывать меньшее влияние на канал WAN, так как запросы autodiscover состоят из мелких текстовых файлов XML.

Создание и настройка баз почтовых ящиков

Итак, мы закончили работу со стороной CAS, и теперь можем сконцентрироваться на создании баз почтовых ящиков, а также создании и настройке группы доступности баз данных (DAG).

В тестовой среде, используемой в этом цикле статей, я создал 12 баз почтовых ящиков, распределенных на двух серверах Exchange 2010 в основном центре данных, как показано на рисунке 7 .

Рисунок 7: Базы почтовых ящиков Exchange 2010

Примечание: Поскольку Outlook 2003 клиенты не используются в этой среде и публичные папки не используются в качестве репозиториев данных, здесь нет никаких баз данных публичных папок. Если у вас иная ситуация, следует учитывать, что нельзя использовать DAG функцию для защиты данных публичных папок (как это было в случае с CCR в Exchange 2007). Вместо этого нужно создать хотя бы одну базу данных публичной папки в каждом центре данных и добавить соответствующие серверы, содержащие эти базы, в список копий для каждой публичной папки.

Как вы видите, я назвал базы DAG01-MDB001, DAG01-MDB002 и т.д. Не потому что я ленив, а потому что просто нет необходимости в использовании длинных и сложных имен для этих баз данных. Для баз данных, являющихся частью группы DAG, лучше использовать стандарты именования, в которых имени базы данных предшествует имя группы DAG, к которой эта база принадлежит. Что касается путей к папкам баз данных и журналов, то лучше использовать нечто вроде E:\DAG_name\Database_name.edb и F:\Dag_name\Database_name.

Примечание: Когда у вас есть несколько копий базы данных, вам вовсе необязательно использовать выделенные LUN для лог файлов, вы можете просто использовать тот же путь, который указан для.edb файла (в нашем примере это ‘E:\DAG_name\Database_name’). Это полностью поддерживается и является рекомендуемым методом, если вы не используете аппаратное решение VSS резервного копирования для создания резервных копий своих баз данных Exchange. Следует ли говорить о том, что необходимо использовать точки подключения, поскольку в противном случае у вас быстро закончатся буквы дисков.

Добавление группы Exchange Trusted Subsystem к серверам Non-Exchange

Те из вас, кто уже разворачивал серверы почтовых ящиков на базе Exchange 2007 CCR или Exchange 2010 Mailbox, принадлежащих к группе DAG, должны знать, что лучше использовать транспортный сервер-концентратор (Hub Transport) на этом же сайте Active Directory в качестве сервера-свидетеля для CCR кластера или DAG.

Поскольку эта среда состоит из Exchange 2010 серверов с несколькими ролями, которые являются частью одной группы DAG, мы не можем использовать Exchange 2010 Hub Transport сервер в качестве сервера-свидетеля, а должны использовать традиционный файловый сервер Windows Server 2008/R2 для этой цели. По этой причине нам нужно добавить ‘Exchange Trusted Subsystem ‘ группу, созданную установкой Exchange 2010, в группу локальных администраторов на соответствующем файловом сервере. Это делается для того, чтобы правильные разрешения были предоставлены Exchange. Для этой цели входим на файловый сервер и открываем диспетчер сервера ‘Server Manager ‘. Разворачиваем ‘Конфигурацию (Configuration) ‘ > ‘Локальные пользователи и группы (Local Users and Groups) ‘ и открываем Свойства (Properties) группы Администраторов (Administrators) .

Рисунок 8: Поиск группы локальных администраторов на файловом сервере Windows Server 2008 R2

Теперь вводим ‘Exchange Trusted Subsystem ‘ в текстовое поле, как показано на рисунке 9 , и нажимаем OK .

Рисунок 9: Ввод группы Exchange Trusted Subsystem

Еще раз жмем OK .

Рисунок 10: Страница свойств группы администраторов

Как уже говорилось, этот шаг необходим только при использовании non-Exchange сервера в качестве сервера-свидетеля.

Создание и настройка группы DAG

Поскольку активные пользователи у нас постоянно находятся в каком-то одном центре данных (модель распределения пользователей активный/пассивный), для этого сценария будет достаточно одной расширенной группы DAG.

Для создания простой группы DAG запускаем мастер создания группы ‘‘. Для этого разворачиваем рабочий центр ‘Organization Configuration’ и нажимаем правой клавишей на ‘Mailbox ‘, после чего выбираем опцию создания новой группы ‘New Database Availability Group ‘ в контекстном меню. В мастере нужно указать имя группы DAG и ввести имя сервера-свидетеля. Наконец, нам нужно указать путь каталога свидетеля. Я назову группу DAG ‘DAG01 ‘ и буду использовать присоединенный к домену файловый сервер (FS01) в качестве сервера-свидетеля. Когда все готово, нажмите ‘New ‘.

Рисунок 11: Создание группы DAG

На заключительной (Completion) странице у нас появляется предупреждение о том, что группа ‘Exchange Trusted Subsystem ‘ не является членом группы ‘Локальных администраторов (Local Administrators) ‘ на указанном сервере-свидетеле. Эту ошибку можно проигнорировать, поскольку мы уже добавили эту группу.

Нажмите Завершить (Finish) для выхода из мастера (Рисунок 12 ).

Рисунок 12: Мастер DAG ‘ заключительная страница

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

Когда речь заходит об использовании DAG, расширенной между двумя центрами данных (AD сайтами), рекомендуется предварительно настроить альтернативный сервер-свидетель, коим в данном сценарии будет файловый сервер (FS02) в аварийном центре данных.

Для этого нам сначала нужно добавить ‘Exchange Trusted Subsystem ‘ группу в группу локальных администраторов ‘(Local Administrators) ‘ тем же способом, который описан выше. Затем нужно указать FS02, как альтернативный сервер-свидетель на самом объекте DAG. Для этого открываем страницу свойств DAG ‘DAG01 ‘. В закладке ‘Общие (General) ‘ мы видим основной сервер-свидетель FS01 и каталог свидетеля для этого сервера. Ниже у нас есть возможность ввести альтернативный сервер-свидетель (рисунок 13 ). Делаем это и нажимаем ‘Применить (Apply) ‘. Оставьте страницу свойств открытой.

Р исунок 13: Указание альтернативного сервера-свидетеля

Назначение статических IP адресов группе DAG

Хотя можно использовать DHCP назначенные IP адреса для группы DAG, я предпочитаю использовать статические адреса, поэтому следующим шагом будет назначение статического IP адреса для группы DAG в каждом центре данных (в каждой подсети).

Примечание: Если вы хотите использовать DHCP назначенные IP адреса, можете пропустить этот шаг.

Чтобы задать статический IP адрес, перейдите в закладку ‘IP Addresses ‘. В закладке ‘IP Addresses ‘ задайте IP адрес в каждой подсети для группы DAG. Затем нажмите ‘OK ‘ для выхода со страницы свойств.

Рисунок 14: Назначение статического IP адреса группе DAG

Итак, мы создали и настроили простую группу DAG.

Материал из Rosalab Wiki

Назначение

В этой инструкции описано подключение различных почтовых клиентов к серверу Microsoft Exchange. Цель - получить систему, по функциональности соответствующую Microsoft Outlook.

Входные данные

В примерах используется сервер Microsoft Exchange 2010 (v14.03.0361.001) Service Pack 3 Update RollUp 18. Тестирование производится внутри корпоративной сети. На DNS-серверах указаны внешние почтовые адреса для почтового сервера. На сервере Exchange должны работать:

OWA (Outlook Web Access) - веб-клиент для доступа к серверу совместной работы Microsoft Exchange
OAB (Offline Address Book) - автономная адресная книга
EWS (Exchange Web Services) - сервис, предоставляющий доступ к данным почтового ящика, хранящимся в Exchange Online (как часть Office 365) и в локальной версии Exchange (начиная с Exchange Server 2007)

Параметры сервера Exchange

Важным моментом для успешной работы не-Microsoft-клиентов на Exchange 2010 является проверка подлинности. Посмотреть её параметры можно на сервере Exchange с ролью CAS (Client Access Server). Запустите оснастку «Диспетчер служб IIS» и откройте вкладку «Сайты»/Default Web Site. Обратите внимание на проверку подлинности в трёх компонентах:

OWA - Состояние «Включён » для «Обычная проверка подлинности » и «Проверка подлинности Windows »:

OAB - Состояние «Включён » для «Обычная проверка подлинности » и «Проверка подлинности Windows »:

EWS - Состояние «Включён » для «Анонимная проверка подлинности », «Обычная проверка подлинности » и «Проверка подлинности Windows »:

Прослойки (посредники) и вспомогательные утилиты

DavMail

Некоторые почтовые клиенты не могут напрямую подключаться к Microsoft Exchange и требуют использования прослойки (посредника). В данном примере в качестве посредника используется прокси-сервер DavMail .

Установите DavMail , получив права администратора при помощи su или sudo:

sudo urpmi davmail

Запустите DavMail :

На вкладке «Main» в поле «OWA (Exchange) URL » введите адрес своего сервера в формате «https:///EWS/Exchange.asmx» или ссылку на OWA

в формате «https:///owa».

Запомните номера портов «Local IMAP port » и «Local SMTP port ». В данном примере это 1143 и 1025, соответственно.

Чтоб каждый раз не запускать вручную сервер DavMail , нужно добавить его вызов в автозагрузку.

Зайдите в меню «Параметры системы → Запуск и завершение → Автозапуск », нажмите на кнопку [Добавить приложение ] и в строке поиска введите «davmail», после чего нажмите [ОК ]:

Теперь локальный прокси-сервер DavMail будет запускаться при старте системы автоматически. Если вам мешает его значок в «Панели задач», есть возможность его спрятать. Для этого в файлe .davmail.properties отредактируйте строку davmail.server=false , поменяв false на true:

Sudo mcedit /home/<имя_пользователя>/.davmail.properties

Почтовые клиенты для подключения к Exchange

Теперь можно приступить к настройке почтовых клиентов.

Thunderbird

Mozilla Thunderbird является основным почтовым клиентом для дистрибутивов ROSA Linux и, скорее всего, он уже установлен в вашей системе и готов к работе. Если же нет, его можно установить из репозиториев ROSA. В данном примере используется версия 52.2.1.

Установите Thunderbird :

sudo urpmi mozilla-thunderbird

Добавьте русскоязычный интерфейс:

sudo urpmi mozilla-thunderbird-ru

Установите дополнение lightning, позволяющее использовать календари:

sudo urpmi mozilla-thunderbird-lightning

Запустите Thunderbird .

В разделе «Учётные записи » в пункте «Создать учётную запись » выберите «Электронная почта ». Появится окно приветствия.

В открывшемся окне нажмите на кнопку [Пропустить это и использовать мою существующую почту ].

В окне «Настройка учётной записи почты » введите в поля «Ваше имя », «Адрес эл. почты » и «Пароль » свои учётные данные.

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

Здесь вам понадобятся номера портов, которые вы запомнили при настройке DavMail .

Для категорий «Входящая » и «Исходящая » измените имя сервера на «localhost».
Укажите для «IMAP » порт 1143, а для «SMTP » - порт 1025.
В поле «Имя пользователя » укажите UPN (User Principal Name) - доменное имя пользователя в формате «ИмяПользователя@ДоменОрганизации.ru».
Нажмите на кнопку [Перетестировать ].

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

Создание календаря пользователя

В категории «Учётные записи » выберите пункт «Создать новый календарь ».
В появившемся окне выберите значение «В сети » и нажмите [Далее ].
Выберите формат «CalDAV » и в поле «Адрес » введите «http://localhost:1080/users/ /calendar»:

Создание адресной книги

Адресная книга Thunderbird не поддерживает протокол CardDAV и может быть подключена только к каталогу LDAP сервера Exchange.

Откройте существующие адресные книги, нажав на кнопку [Адресная книга ] и выбрав пункт «Файл → Создать → Каталог LDAP ».

В окне мастера укажите следующие параметры:
- Название - любое подходящее имя
- Имя сервера - localhost
- Корневой элемент (Base DN) - ou=people
- Порт - 1389 (из Davmail )
- Имя пользователя (Bind DN) - UPN-имя пользователя

Нажмите [ОК ]. Программа попросит ввести пароль.

Зайдите в меню параметров Thunderbird . В категории «Составление » выберите вкладку «Адресация » и под текстом «При вводе адреса искать подходящие почтовые адреса в» отметьте пункт «Сервере каталогов », выбрав имя вашей адресной книги.

Evolution

В репозиториях ROSA также доступен почтовый клиент Evolution (в данном примере используется версия 3.16.4).

Установите Evolution :

sudo urpmi evolution

Установите коннектор Exchange , совместимый с версией 2007 и более поздними:

sudo urpmi evolution-ews

Запустите Evolution .

В окне мастера нажимайте кнопку [Следующая ], пока не перейдёте на вкладку «Учётная запись ».
Заполните поля «Полное имя » и «Электронная почта ».
На вкладке «Получение почты » в списке «Тип сервера » выберите «Exchange Web Services».
В качестве имени укажите UPN-имя пользователя в формате «ИмяПользователя@ВашДомен.ru».
В поле «Host URL » введите «https://ИмяПочтовогоСервераExchange/EWS/Exchange.asmx .
В поле «OAB URL » введите URL автономной адресной книги.
В качестве вида аутентификации выберите «Basic».

При успешной настройке программа запросит пароль:

После ввода пароля Evolution получит доступ к вашему почтовому ящику, адресной книге и календарям.

По любым вопросам, связанным с этой статьёй, просьба обращаться по адресу [email protected].

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

As you all know that the service connectivity for a mail server is the main concern to all of us. In Exchange server 2010, the connectivity is as same as Exchange server 2007. Once you migrate or install the new version, this should be tested with the proper credentials and certificate..or else, you will end up with your mail server IP going to the blacklist, because of the wrong pointers and configurations. First of all, do the internal test. Go to your computer start bar, right side where Date and time is showing, you will find the Outlook icon, hold Ctrl + right click on the outlook icon and click “Test Email Auto Configuration…”

Select the “Use AutoDiscover” and click Test..

Above one is a success one..If failed, do the below. The Exchange Web Service (EWS) is the web service that allows access to the Out of Office service. If either the internal or external URL for the EWS is missing or incorrect, OOF will fail and other services may not work as expected. Using Exchange Management Shell, check the URLs assigned to the web service virtual directory using the Get-WebServicesVirtualDirectory command

First goto CAS server

Type the following Power Shell command for EWS (Exchange Web Service)

Copy code Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl

You will get the result like below

InternalUrl:
ExternalUrl: https://mailv.domain.com/ews/exchange.asmx

InternalUrl: https://mailv.domain.com/EWS/Exchange.asmx
ExternalUrl: https://mailv.domain.com/ews/exchange.asmx

If this is not correct, you need to fix it.. This has to be done on Powershell command on the CAS server.

To do that…Copy code

C:\Windows\system32>Set-WebServicesVirtualDirectory -Identity “ECAS1\EWS (Default Web Site)” -InternalUrl -BasicAuthentication:$true

C:\Windows\system32>Set-WebServicesVirtualDirectory -Identity “ECAS2\EWS (Default Web Site)” -InternalUrl https://mail.domain.com/EWS/Exchange.asmx -BasicAuthentication:$true

C:\Windows\system32>Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl

Identity: ECAS1\EWS (Default Web Site)
InternalUrl: https://mail.domain.com/EWS/Exchange.asmx
ExternalUrl: https://mail.domain.com/ews/exchange.asmx

Identity: ECAS2\EWS (Default Web Site)
InternalUrl: https://mail.domain.com/EWS/Exchange.asmx
ExternalUrl: https://mail.domain.com/ews/exchange.asmx

Now you can see that the URL has been fixed. This is for Web Services.

Now for Autodiscovery….

C:\Windows\system32>Get-AutodiscoverVirtualDirectory

To see the settings

C:\Windows\system32>

C:\Windows\system32>Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri
Identity: ECAS1
https://mailv.domain.com/Autodiscover/Autodiscover.xml

Identity: ECAS2
AutoDiscoverServiceInternalUri: https://mailv.domain.com/Autodiscover/Autodiscover.xml

C:\Windows\system32>Set-ClientAccessServer -Identity ECAS1 -AutoDiscoverServiceInternalUri https://mail.domain.com/Autodiscover/Autodiscover.xml
C:\Windows\system32>Set-ClientAccessServer -Identity ECAS2 -AutoDiscoverServiceInternalUri https://mail.domain.com/Autodiscover/Autodiscover.xml

Now for the Outlook Web Apps, Exchange Control Panel, Exchange ActiveSync, Offline Address book…you have to go to Exchange Management Console (EMC)

Goto one of the CAS server
Open EMC
Goto Server Configuration
Select Client Access
On the Middle top pannel, you can see the CAS server listed.
Select one, on the bottom pannel, you will see like below.

Select each tab and then right click on the object and change the path as required. Once you done with the first CAS servr, do the same for the second as well.

Thats it…you are good to go for production.

С выходом Exchange 2010, клиенты Outlook MAPI используют роль сервера Client Access Server (CAS) на среднем уровне в качестве конечной точки RPC, что привело к тому, что данная роль является еще более важной, чем в предыдущих версиях продукта. По этой причине всем организациям (большим и малым) стоит задуматься о том, чтобы сделать эту роль постоянно доступной посредством установки нескольких серверов CAS на каждом сайте Active Directory, а также использовать компенсацию нагрузки протоколов и сервисов, предоставляемых этой ролью.

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

Рисунок 1: Топология, используемая в этой тестовой среде

Примечание: очень важно выделить тот факт, что я никак не связан с компанией KEMP Technologies. К тому же мне не платили, чтобы я советовал читателям использовать устройства распределения нагрузки, поставляемые этой компанией. Я просто делаю это исключительно по той причине, что у меня есть очень удачный опыт работы с этими устройствами.

Как на счет обратных прокси, таких как TMG/ISA/IAG/UAG?

Можно ли использовать одно из этих решений для компенсации нагрузки различных протоколов и служб на сервере CAS? Конечно же, можно! По крайней мере, можно компенсировать нагрузку для всего, что идет по протоколам HTTP и HTTPS. Однако ни одно из этих решений не может выполнять компенсацию нагрузки для RPC трафика. Читайте дополнительную информацию в этом новостном письме , которое я написал пару месяцев назад. К тому же вам, возможно, не нужно, отправлять трафик с внешних клиентов на решение обратного прокси в своей демилитаризованной зоне и обратно. Наконец, если вы осуществляете компенсацию нагрузки для трафика HTTP/HTTPS, используя одно из вышеупомянутых решений в качестве внутреннего решения HLB, также важно упомянуть, что вам нельзя настраивать их обращение к VIP/FQDN устройства HLB, а вместо этого обратный прокси-сервер будет самостоятельно распределять трафик между CAS серверами массива CAS.

Какой тип родства (affinity) мне следует использовать?

Персистентность (также известная, как родство) представляет собой возможность компенсатора нагрузки сохранять подключение между клиентом и сервером. Она позволяет быть уверенным в том, что все запросы с клиента направляются на один и тот же сервер в NLB массиве или серверной ферме (в случае с Exchange CAS массивом).

Поэтому в зависимости от клиента или службы Exchange есть различные рекомендации относительно того, какие настройки родства использовать. Ниже я указал, какие настройки являются предпочтительными для каждого клиента и службы.

Клиенты Exchange:

Outlook Web App (OWA) - для OWA рекомендуемым способом родства является клиентский IP (IP адрес источника) или Cookie (существующие cookie или созданные аппаратным компенсатором нагрузки, также известные как LB-cookie). Оба способа работают в большинстве конфигураций, но если вы работаете со средами, где клиенты представляются, как исходящие с одного IP адреса источника, следует избегать использования Client IP и вместо этого использовать cookie. Не рекомендуется использовать персистентность на базе SSL ID в OWA, поскольку этом может привести к тому, что пользователям нужно будет повторно проходить проверку подлинности, потому что такие обозреватели, как Internet Explorer 8, создают новые отдельные рабочие процессы, например, при создании нового сообщения в OWA. Проблема здесь в том, что с каждым новым рабочим процессом используется новый SSL ID.
Exchange Control Panel (ECP) - те же рекомендации, что и для предыдущего клиента.

Exchange ActiveSync (EAS) - для Exchange ActiveSync рекомендуемым способом родства являются Client IP (исходный IP адрес) или заголовок авторизации (Authorization header). Если ваша организация использует одного поставщика мобильных/сотовых сетей для всех пользователей, подключающихся к Exchange с помощью EAS, то велики шансы того, что они все будут представляться, как исходящие с одного IP адреса, поскольку NAT часто используется в сотовых сетях. Это означает, что вы не сможете получить оптимального распределения EAS трафика между CAS серверами за NLB массивом. Поэтому для EAS лучше использовать HTTP заголовок авторизации в качестве ключа родства. И опять же, не рекомендуется использовать персистентность на основе SSL ID для EAS, поскольку некоторые мобильные устройства пересматривают параметры SSL безопасности довольно часто.

Outlook Anywhere (OA) - для Outlook Anywhere (также известной как RPC через HTTP) рекомендуемым методом родства будет Client IP (исходный IP адрес), заголовок авторизации или персистентность на основе "OutlookSession" cookie. Если клиенты OA представляются, как исходящие с одного Client IP, то следует использовать заголовок авторизации или "OutlookSession" cookie. Следует помнить, что родство на основе "OutlookSession" поддерживается только в клиентах Outlook 2010.

IMAP и POP3 - IMAP и POP3 не требуют никаких параметров родства, поэтому здесь нет рекомендаций к настройке персистентности.

Сервисы Exchange:

Autodiscover- служба Autodiscover не требует никаких определенных параметров родства, поэтому здесь нет рекомендаций к настройке персистентности.

RPC Client Access Service (RPC CA)- для службы RPC CA, используемой в качестве конечной точки для внутренних клиентов Outlook, рекомендуемым способом родства является Client IP.

Exchange Address Book Service- те же рекомендации, что и для службы RPC CA.

Exchange Web Services (EWS)- для EWS рекомендуемым способом родства является cookie или SSL ID.

Теперь, поскольку многие из вышеуказанных клиентов и служб используют один и тот же порт, зачастую можно указывать лишь один способ родства для всех клиентов и служб, использующих один порт/IP адрес. Если вы хотите использовать различные способы персистентности, допустим для OWA и OA, в зависимости от вашего HLB решения, это может быть возможным (с использованием раздельного родства и т.п.), но это не входит в рамки нашей статьи. Вместо этого я рекомендую вам связаться с поставщиком вашего HLB решения.

Параметры таймаута для каждого протокола и службы

Для каждой виртуальной службы вы можете задавать значения таймаута для сеансов, которые создаются с различных клиентов к HLB решению (память, ЦП и т.д.).

Чтобы оптимально использовать свое HLB решение, не следует задавать слишком высокие значения для этих таймаутов, но также следует опасаться установки слишком низких значений для этих параметров, поскольку это может привести к необходимости клиентов в повторном создании сеанса, а это в свою очередь может заставлять конечных пользователей снова проходить проверку подлинности.

Нет нужды говорить о том, что вам нужно задавать значения таймаутов для протоколов и служб, таких как OWA, ECP, EAS, Outlook Anywhere и RPC CA на довольно высоком уровне (несколько часов, например, рабочие часы), а для таких служб как IMAP, POP, AutoD, EWS, OAB эти значения должны быть относительно низкими (как правило, всего несколько минут). Чтобы не попасть в трудности, свяжитесь с поставщиком вашего HLB решения для получения информации о том, какие настройки рекомендованы для него.

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

Создание необходимых виртуальных служб в решении компенсатора нагрузки

Рисунок 28: Проверка SSL цепи с помощью диагностического инструмента DigiCert SSL Diagnostics

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

На этом заканчиваем данный цикл статей. Да, в конце предыдущей части я говорил то же самое, но в этот раз я говорю наверняка 🙂

Генрик Валзер (Henrik Walther) является Microsoft Exchange MVP и работает в качестве Старшего Технического Консультанта в Interprise, Золотом Партнере Microsoft, расположенном в Дании. Вы можете посетить его web-сайт по адресу: www.exchange-faq.dk (на датском).