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 |
Переходим к следующей главе.
Поскольку мы указали одинаковые внутренние и внешние 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
Информация, содержащаяся в этом документе, может относиться к функциям и продуктам предварительной версии и может претерпеть значительные изменения до окончательного коммерческого выпуска. Настоящий документ предоставляется "как есть" и служит только для информационных целей. Корпорация Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых, в связи с этим документом
Советы по разработке с использованием 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, по одной из следующих причин:
ваше приложение не использует.NET Framework;
вы не хотите распространять сборку управляемого API EWS;
для приложения требуются функции, не доступные в управляемом API EWS.
Дополнительные сведения см. в статье .
Теперь управляемый API EWS доступен в виде проекта с открытым кодом на сайте GitHub . С помощью библиотеки с открытым кодом вы можете: добавлять исправления ошибок и улучшения в API; получать исправления ошибок и улучшения до того, как они станут доступны в официальном выпуске; получать доступ к самой полной и актуальной реализации API, которую можно использовать для справки или для создания новых библиотек на новых платформах. |
Если у вас есть учётная запись на сервере 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 " останется пустым), вы можете:
(вход по домену/пользователю
)
(вход по 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 использует самоподписанный сертификат либо сертификат, срок действия которого истёк:
Вы можете добавить его в хранилище сертификатов Windows (View Certificate | Install Certificate | Next | Place all certificates in the following store | Browse | | OK | Next | Finish).
Чтобы не получать предупреждение системы безопасности, вы можете включить опцию Не проверять сертификат узла .
Внимание : вы можете не проверять сертификат, только если вы доверяете источнику.
Когда процесс автообнаружения завершится, нажмите Далее .
Поле Ваше имя отобразит ваше имя на сервере 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 заново.
В 5 части этого цикла статей мы рассмотрели создание массива Client Access на каждом сайте Active Directory. Затем мы включили Outlook Anywhere, а также настроили параметры Outlook Provider, чтобы Outlook Anywhere клиенты могли подключаться при возникновении аварийной ситуации.
В этой части цикла мы продолжим с того места, на котором остановились в предыдущей части. Мы начнем с настройки внутреннего и внешнего URL адреса для служб CAS на каждом сервере Exchange 2010 на обоих сайтах Active Directory. Затем мы создадим группу DAG и выполним базовую настройку DAG.
Пришло время настроить внутренний и внешний URL адрес для Exchange 2010 CAS служб в каждом центре данных так, чтобы они указывали на каждое решение балансировки нагрузки соответственно.
Подводя краткий итог предыдущим частям этого цикла, можно сказать, что адрес ‘mail.exchangeonline.dk ‘ указывает на VIP адрес, настроенный на решении балансировки нагрузки в основном центре данных, а ‘failover.exchangeonline.dk ‘ указывает на VIP адрес, настроенный на решении балансировки нагрузки в аварийном центре данных. Это означает, что URL адреса нужно настраивать по-разному для каждого центра данных.
Начнем с 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) мы используем следующие команды:
Основной центр данных:
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) используем следующие команды:
Основной центр данных:
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 используем следующие команды:
Основной центр данных:
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) используем следующие команды:
Основной центр данных:
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), но если у вас другие планы, вам нужно будет настроить для нее 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
Наконец нам нужно направить внутренний 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 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 запускаем мастер создания группы ‘‘. Для этого разворачиваем рабочий центр ‘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: Указание альтернативного сервера-свидетеля
Хотя можно использовать DHCP назначенные IP адреса для группы DAG, я предпочитаю использовать статические адреса, поэтому следующим шагом будет назначение статического IP адреса для группы DAG в каждом центре данных (в каждой подсети).
Примечание: Если вы хотите использовать DHCP назначенные IP адреса, можете пропустить этот шаг.
Чтобы задать статический IP адрес, перейдите в закладку ‘IP Addresses ‘. В закладке ‘IP Addresses ‘ задайте IP адрес в каждой подсети для группы DAG. Затем нажмите ‘OK ‘ для выхода со страницы свойств.
Рисунок 14: Назначение статического IP адреса группе DAG
Итак, мы создали и настроили простую группу DAG.
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)
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.
