Гибридное развёртывание Exchange Server 2013. Часть 3. Запуск мастера гибридного развертывания.

imageВ предыдущей заметке Гибридное развёртывание Exchange Server 2013. Часть 2. Развёртывание базовой инфраструктуры в тестовой среде для последующей реализации гибридного развёртывания  мы практически добрались до мастера, который сконфигурирует гибрид из двух независимых организаций Exchange. Но прежде чем запустить долгожданный мастер, нам нужно выполнить еще пару шагов, которые будут является фундаментом обеспечения безопасной коммуникации двух почтовых систем.

Первый шаг - это назначение сертификата локальному Exchange серверу. В наличии у нас есть сертификат вида:

1
Сертификат имеет расширение .PFX, а это значит, что он содержит закрытый ключ. Этот сертификат мы без труда сможем импортировать на наш локальный Exchange:

2
На этапе выбора хранилища для сертификата оставляем:

3
Итог импорта сертификата:

16

Теперь сертификат нужно назначить Exchange серверу, открываем Exchange Management Shell и получаем список сертификатов на EXC сервере:

Get-ExchangeCertificate

17

Назначаем сертификат:

Enable-ExchangeCertificate -Server "exc01" -Services "IIS,SMTP" -Thumbprint E5D79B09E75A41BD8F49C3E57D65DE317095390C

Вторым шагом нужно сконфигурировать Internal, External URL-адреса для виртуальных каталогов:

EWS:

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl https://cas-test.DomainName.ru/EWS/Exchange.asmx -ExternalUrl https://cas-test.DomainName.ru/EWS/Exchange.asmx  -MRSProxyEnabled $true

Цитата TechNet:

Прокси-сервер службы репликации почтовых ящиков (прокси-сервер MRS) перемещает почтовые ящики между лесами и выполняет миграции удаленного перемещения между локальной организацией Exchange и Exchange Online.

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

OAB:

Get-OabVirtualDirectory | Set-OabVirtualDirectory -ExternalUrl https://cas-test.DomainName.ru/OAB -InternalUrl https://cas-test.DomainName/OAB

OWA:

Get-OwaVirtualDirectory  | Set-OwaVirtualDirectory  -ExternalUrl https://cas-test.DomainName.ru/owa -InternalUrl https://cas-test.DomainName/owa

ECP:

Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -ExternalUrl https://cas-test.DomainName.ru/ecp -InternalUrl https://cas-test.DomainName.ru/ecp

Outlook AnyWhere:

Get-OutlookAnywhere  | Set-OutlookAnywhere -InternalHostname "cas-test.DomainName.ru" -InternalClientAuthenticationMethod negotiate -InternalClientsRequireSsl $true -ExternalHostname "cas-test.DomainName.ru" -ExternalClientAuthenticationMethod negotiate -ExternalClientsRequireSsl $true

AutoDiscover для внутренних клиентов:

Set-ClientAccessServer -Identity EXC01 -AutoDiscoverServiceinternalUri https://autodiscover.DomainName.ru/autodiscover/autodiscover.xml

MAPI OVER HTTP:

Как активировать MAPI OVER HTTP

Set-MapiVirtualDirectory -Identity "EXC01\mapi (Default Web Site)" -InternalUrl https://cas-test.DomainName.ru/mapi -ExternalUrl https://cas-test.DomainName.ru/mapi -IISAuthenticationMethods Negotiate

После редактирования виртуальных директорий перезагружаем IIS сервер на локальном Exchange:

7

Теперь мы готовы запустить мастер гибридного развертывания.

Заходим в “Цент Администрирования Exchange”  через Internet Explorer на локальном сервере Exchange:

8
После нажатия на кнопу Enable нас попросят залогиниться в личном кабинете Office 365 административной учетной записью. После удачной авторизации мы можем из нашего “Центра aдминистрирования Exchange” переключаться между организациями Exchange:

9
Запускаем еще раз мастер гибридного развертывания и видим:

10
Нажимаем на кнопку “Щелкаем здесь” и мастер начинает свою установку:

11
После инсталляции мастера мы увидим: 

12
Далее мастер обнаружил наш Exchange CU10:

13
И вновь нас запрашивают административные учетные данные:

14
Нажимаем Next и получаем ошибку:

Ошибка
Создал запрос в Microsoft. В ответ получил две ссылки (ссылка2), воспользовавшись рекомендациями, изменил часовой пояс на локальном Exchange:

18

После того как создадим наш гибрид мы вновь изменим наш часовой пояс на “родной”. “Родным” часовым поясом для нашего локального Exchange является:
20
Нужно сказать, что перед тем как изменять часовой пояс на UTC –08:00 инженер тех. поддержки  Microsoft посоветовал попробовать изменить время в личном кабинете Office 365  на UTC +03:00, к сожалению ошибка в мастере воспроизвелась.

Запустим мастер гибридной конфигурации еще раз после смены часового пояса:

19
Обязательно включаем Federation Trust:

33
Цитата TechNet:

Доверие федерации — это связь между шлюзом Microsoft Federation Gateway и локальной организацией. Шлюз Microsoft Federation Gateway функционирует в качестве брокера доверия между локальной организацией Exchange и другими федеративными организациями Exchange.

В нашей среде нет сервера с ролью Edge Transport, плюс ко всему нам предлагают включить “Централизованную отправку/получение почтовых писем” через наш локальный Exchange, но мы этого не хотим:

21

У нас всего один сервер и он совмещает обе роли Client Access и MailBox, возможно у вас несколько серверов с ролью Client Access и вы захотите их все сконфигурировать на прием почты из облака:

22
Нажимаем Next

На следующей странице мастера предлагается назначить сервера для “Send Connector Configuration”, в большинстве случаев разумно выбрать все сервера локальной организации c ролью MailBox для взаимодействия с Exchange online.

Далее выбираем наш сертификат:

23

 

Указываем FQDN  нашего сервера с ролью Client Access:

24
Это доменное имя должно быть прописано как A запись на DNS хостинге:

25

Теперь можно нажать кнопку Update:

26

Во время конфигурирования можно наблюдать, что мастер поочередно запускает PowerShell СMDlet’ы:

27
Конечный результат:

53

Или:

Ошибка 2
Office 365 не может достучаться до хоста Autodiscover.DomainName.ru.

Проверяем настройки:

54
Сделаем запрос к внешнему DNS серверу:

55

Как видно у нас все корректно настроено на Firewall’e требуемы порты открыты, но предупреждение HCW8057 при этом может снова и снова воспроизводиться. Если вы уверены, что настройки правильные – смело игнорируем.

Обычно предупреждение пропадает если запустить мастер гибридной конфигурации еще раз приблизительно через сутки.

Запустим локальный Exchange Managment Shell и выполним некоторые Cmdlet’ы касающиеся гибридного развертывания:

Get-HybridConfiguration

Результат:

rsz_229

Наша гибридная конфигурация. Интересный параметр Features где перечислены возможности гибридной конфигурации  не хватает только:

Цитата TechNet:

Centralized. Позволяет транспортным серверам обрабатывать весь объем передачи сообщений между локальной организацией Exchange и организацией Exchange Online, в том числе внешнюю доставку сообщений в Интернет для обеих организаций. Если для этого параметра установлено значение $false, локальные транспортные серверы и организация Exchange Online самостоятельно отвечают за интернет-доставку своих сообщений в отдельности.

Но мы осознанно не стали включать этот параметр.

Посмотрим на объект гибридной конфигурации  в LDAP:

119
В любой момент возможно запустить мастер повторно в работающей среде и внести требуемые изменения:

31Но помните если вы обновили  почтовый сервер до следующего CU нужно запустить мастер через Internet Explorer и “Центр администрирования Exchange”, возможно с выходом нового CU мастер  тоже обновился.
 
Был момент, когда я запускал мастер 10-15 раз подряд и в конечном итоге он перестал у меня запускаться, убиваем процесс и проблема решается:

32
Продолжаем выполнять команды в локальном Exchange Managment Shell:

Get-FederationTrust | ft -AutoSize

Результат:

56
Это наше доверие федерации с  Microsoft Federation Gateway и локальной организацией Exchange.

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

Get-OrganizationRelationship  | fl

Результат:

59
Получаем параметры связи между облачной и локальной организацией Exchange, выполняем команду в Windows Azure Active Directory PowerShell:

Get-OrganizationRelationship  | fl

Результат:

60
В “Центре администрирования Exchange”  связи между организациями тоже видны:

57
58
Проведем некоторые тесты гибридной конфигурации, но прежде чем это сделать нужно создать пользователя с почтовым ящиков в Office 365. У нас уже есть пользователи которые были синхронизированы в предыдущей заметке с локальной Active Directory и Office 365. Все что нужно теперь сделать - это назначить им почтовые ящики с размещением в облаке.

Открываем “Центр администрирования Exchange”:

61
Выбираем Office 365 mailbox, но видим, что создать почтовый ящик существующему пользователю с размещением в облаке нельзя:

65
Чтобы создать почтовый ящик существующему пользователю с размещением в облаке, нужно сначала создать локальный почтовый ящик, а уже потом переместить локальный почтовый ящик в Office 365.

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

64
Мы видим, что MAILBOX TYPE у вновь созданного почтового ящика Office 365:

66
Запускаем синхронизацию и по идее теперь должен появиться почтовый ящик в облаке, но почтовый ящик не будет существовать до момента назначения лицензии пользователю в личном кабинете Office 365:

rsz_67
В разделе “Назначение лицензии”  нажимаем кнопку изменить и назначаем требуемую лицензию:

rsz_68
После этого запускается процесс создания  почтового ящика пользователю в Office 365:

rsz_69
Конечный результат:

70

В “Центре администрирования Exchange”  на закладке Office 365 после назначения лицензии почтовый ящик тоже появился:

71

После создания пользователя можно протестировать наш гибрид.

Для этого открываем локальный Exchange Management Shell и выолняем команды (cсылка на TechNet):

Test-FederationTrust -UserIdentity usercloud1@DomainName.ru  


72

Все шесть шагов  тестирования нашего траста закончились результатом Success.

Get-OrganizationRelationship | ft -AutoSize

73
ссылка на TechNet

Test-OrganizationRelationship -UserIdentity usercloud1@DomainName.ru  -Identity  "On-premises to O365 - 2cfe6e83-5ac5-4f7b-88aa-e9c3a547a691"

rsz_74
Видим, что Cmdlet вернул описание в котором говориться, что значения MailBoxMoveEnabled различаются в локальной и облачной организации Exchange. Возможно эта ошибка возникает, что не сконфигурированы “Migration endpoints”. Миграция почтовых ящиков между организациями Exchange будет рассмотрена в следующих заметках.

Запустим тест Test-OrganizationRelationship  со стороны облака.

Открываем Azure Active Directory PowerShell  подключаемся к Office 365 и выполняем команды:

Get-OrganizationRelationship | ft -AutoSize

image

Test-OrganizationRelationship -UserIdentity usercloud1@DomainName.ru  -Identity "O365 to On-premises - 2cfe6e83-5ac5-4f7b-88aa-e9c3a547a691"

122

123Все шесть шагов закончились с результатом Success, но уже c предупреждениями, если вдруг что-то не заработает из заявленного функционала в гибридной конфигурации будем думать над этими предупреждениями, а сейчас двигаемся дальше… Выполняем еще пару команд на локальном  Exchange сервере:

Test-FederationTrustCertificate

75

Test-OutlookWebServices

76
Теперь проверим нашу гибридную  конфигурацию через набор тестов из Remote Connectivity Analyzer:

Тестируем AutoDiscover и Exchange Web Services (EWS):

77

83
Указываем почтовый ящик для подключения:

84
Почтовый ящик из под которого мы делаем тесты должен иметь тип Office 365:

79
Результат тестирования:

124

Результат тестирования закончился успешно, но с предупреждением  которое указывает на:

131
Эту ошибку можно смело игнорировать, потому что URL ссылку на скриншоте выше для автообнаружения мы в своей конфигурации не используем.

Далее выполняем “Тест сведений о доступности”:

86Указываем почтовые ящики для подключения:

87Обратите внимание, что исходный почтовый ящик находиться в облаке а целевой на локальном EXC сервере:88
Результат тестирования:
 
89
Теперь выполним этот же тест, но исходный и целевой почтовый ящик меняем местами:

90

Тест завершиться удачно при условии, что атрибут User UPN Logon будет совпадать с вашим SMTP доменом:

94

Альтернативный UPN суффикс можно создать в оснастке Active Directory Domain and Trust:

93
92
На практике я всегда стараюсь создавать альтернативный UPN суффикс совпадающий с SMTP доменом и пользователи используют для доступа к ресурсам логин совпадающий с их почтой.

Как и ожидалось тест завершился успешно:

91
В Remote Connectivity Analyzer присутствуют еще тесты которые можно запустить, к примеру тест ActiveSync, подключение Outlook, входящая, исходящая электронная почта SMTP, но мы пойдем другим путем и проверим этот функционал через настроенного клиента Outlook для разных типов почтовых ящиков в гибридном развертывании Exchange.

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

Отступление:

При настройке Outlook’a на “облачный” почтовый ящик  нет разницы входит ПК в домен Active Directory или нет конфигурирование однообразно.

В наличии у нас  чистая машина с Windows 8.1 x64  и MS Office 2013:

95
Указываем наши учетные данные:

96
Облако запрашивает логин и пароль для доступа к почтовому ящику:

98
Логин на который указывает стрелочка под номером один на скриншоте выше берётся из Office365:

99
Он может иметь вид  @ТоЧтоВыУказалиПриРегистрацииВOffice365.onmicrosoft.com  лучше заменить эту строку. Заходим в Office365  выбираем нашего пользователя нажимаем кнопку “изменить” и видим:

100
Сохраняем изменения. Теперь при логине мы будет использовать имя пользователя совпадающее с нашей почтой.

Результат:

101
Запускаем Outlook  и смотрим Connection Status:

1002
Из скриншота выше можно сделать вывод, что наш Outlook удачно подключился к Office365 через MAPI over HTTP.

Office 365  в своей работе использует самую последнюю версию Exchange 2016:

103

Отправим письмо внешнему получателю, например на почтовый ящик gmail.com:

1005
Как мы видим письмо достигло получателя.  Так же мы видим, что корректно “отработала”  SPF запись (стрелочка под номером два) для нашего домена. В данном конкретном случаи “отработала” именно эта строка в TXT записи на DNS:

106
Потому что маршрутизация письма строилась через сервера Office 365:

107
Но самое интересное, что Office 365 подписывает по умолчанию всю исходящую корреспонденцию используя электронно цифровую подпись (DKIM) (стрелочка под номером три):

image
Более того Office 365 использует политику DMARC:

132
Внимательный читатель заметил, что домен используемый для DKIM в Office365 имеет вид @ТоЧтоВыУказалиПриРегистрацииВOffice365.onmicrosoft.com,  если заглянуть в атрибуты пользователя когда реализован гибрид, то мы увидим:

109
Цитата MSDN:

A proxy address is the address by which a Microsoft Exchange Server recipient object is recognized in a foreign mail system. Proxy addresses are required for all recipient objects, such as custom recipients and distribution lists.

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

Теперь откроем “Центр администрирования Exchange” и заглянем в  свойства “облачного” почтового ящика на вкладку Email Address:

111

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

Таким образом получается наш облачный почтовый ящик имеет три почтовых адреса, но DKIM  “отрабатывает” только  на одном. Чтобы проверить это запускаем Windows Azure Active Directory PowerShell подключаемся к Office 365 и выполняем команду:

Get-DkimSigningConfig

110
Это позволяет оснащать электронно цифровой подписью все исходящие письма “облачных” почтовых ящиков  без дополнительных настроек администратора Office 365.

Остался последний шаг проверки работоспособности нашего “облачного” почтового ящика – это получить входящее сообщение из интернета:

rsz_114
и OWA Office 365:

rsz_115

Как мы видим  из скриншотов выше все входящие/исходящие письма для “облачного” почтового ящика  достигают своей конечной точки.

Проделаем все тоже самое для почтового ящика с расположением на локальном Exchange сервере. Как мы помним вся  входящая  корреспонденция для нашего гибрида проходит через “облако”, а исходящая обрабатывается локальным Exchange сервером, чтобы проверить это на практике настроим почтовый ящик и отправим/получим пару писем.

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

Мы создали, настроили почтовый ящик и отправили письма из интернета:

116
Письма удачно достигли получателя, но самое интересное это посмотреть на маршрут входящего письма:
 118
Как и ожидалось наши входящие письма строят свой маршрут через Office 365.

Подведем итоги:

1) Сконфигурировали виртуальные каталоги локального Exсhangе сервера – это обеспечило правильное взаимодействие между двумя организациями Exchange.

2) Пошагово прошлись по мастеру гибридной конфигурации и как итог получили гибридное развертывании Exchange сервера.

3) Протестировали гибрид.

4) Настроили и удачно протестировали “облачный” и “локальный” почтовый ящик. Посмотрели на маршрутизацию почтовых сообщений.

В следующей заметке будем тестировать заявленный функционал гибридного развертывания Exchange.

Всего комментариев: 3 Комментировать

  1. Илья Юфа /

    Добрый день
    Не увидел пункта в 3х частях Единый URL адрес для OWA - может проглядел?

    1. aivonin3093 /

      Илья,

      В следующей заметке будем тестировать заявленный функционал гибридного развертывания Exchange.

      Заметка в процессе.

  2. Обратная ссылка: Гибридный Exchange 2016 – Настройка локальной инфраструктуры – blog.bissquit.com /

Добавить комментарий