Гибридное развёртывание Exchange Server 2013. Часть 2. Развёртывание базовой инфраструктуры в тестовой среде для последующей реализации гибридного развёртывания

imageБазовое гибридное развертывание Exchange 2013 от вашей IT инфраструктуры требует установки и настройки минимального количества дополнительных программ, но главная загвоздка состоит в том, что нужно строго придерживаться определенной последовательности при установке. Если пренебречь этим, то мы будем получать ошибки, которые будут сбивать нас с верного пути.

В этой заметке я постараюсь показать вам путь, который был неоднократно “отработан” мной при реализации базового гибридного развертывания в тестовой и реально работающей IT инфраструктуре.

Предварительные требования:

  1. Нужно иметь в наличии зарегистрированное доменное имя, которое будет использоваться как SMTP домен.
  2. DNS хостинг, который позволит создать требуемые DNS записи для доменного имени.
  3. SSL сертификат. Минимальные требования к сертификату можно прочитать по ссылке.

В этой серии заметок я использую реальный WildCard сертификат, который в поле Subject Alternative Name содержит:

  • *.DomainName.com – действительный почтовый домен компании, в которой я работаю.
  • *.DomainName.ru -  домен используемый в тестовых средах. 

Первым делом мы запускаем “Помощник по развертыванию Exchange Server”. В помощнике присутствуют пункты, на которые вы сами сможете ответить без особого труда:

Гибридное развертывание –> Гибридное развертывание на основе Exchange 2013 –> Exchange Server 2013 –> Далее…

В этой заметке мы будем останавливаться только на самых интересных:

Единый вход (Single sign-on):

rsz_101
Единый вход (Single sign-on) очень удобная возможность, которая облегчает работу пользователям, у которых почтовые ящики будут находиться в облаке, и инженерам технической поддержи. Первым нет надобности помнить несколько паролей, а вторые администрируют пароли для любых почтовых ящиков в локальной Active Directory.

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

Single sign-on в гибридной реализации Exchange позволяет упростить доступ к online-архиву для локальных почтовых ящиков. При доступе к online-архиву в облаке пароль нужно будет вводить однократно при условии, что будет поставлена галочка “Сохранить пароль” в окне запроса учетных данных в Outlook. Пароль при доступе к online-архиву не будет запрашиваться до момента смены пароля у пользователя.

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

В Exchnage 2013 можно создавать личные архивы:

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

Гибридное решение Exchange может существовать без Single sign-on в этом пункте помощника мы выбираем НЕТ.

Маршрутизация входящей почты:

03

На этом шаге нужно хорошо подумать, прежде чем сделать выбор. Возможно у вас в компании уже имеется хорошо отлаженная анти-спам система. Она вам привычна в использовании, вы знаете все ее тонкости и можете быстро решать возникающие проблемы. Имеется правильно работающий отказоустойчивый канал связи до вашей почтовой системы. Большая часть получателей почтовых сообщений располагаются на локальных Exchange серверах. В этом случаи логично “пустить” всю входящую почту для обеих организаций Exchange on-premises и Exchnage Online через ваши локальные почтовые сервера.

Если ваша компания не имеет своей анти-спам системы, и вы реализуете гибридное развертывание Exchange сервера, в этом случаи вернее будет выбрать первый вариант. Служба Exchange Online Protection (EOP) не дает вам ту возможность в управлении, нежели локальная анти-спам система, но от большей части спама она вас избавит. Отдельно за EOP платить в гибридной развертывание не требуется. Управление  EOP осуществляется через личный кабинет Exchange online.

В контексте этой заметки на данном шаге мы выбираем  “Вся входящая почта через EOP” 

Пограничный транспортный сервер:

04

В нашей тестовой среде пограничный транспортный сервер не предусмотрен, поэтому отвечаем НЕТ.

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

На следующей странице “Перед началом работы” помощник предлагает ознакомиться с общими сведения, компонентами и примером гибридного развертывания. Общие сведения можно прочитать в заметке “Гибридное развертывание Exchange Server 2013. Часть 1. Вступление”, а вот про компоненты гибридного развёртывания стоит упомянуть:

  1. Серверы Exchange 2013 – в помощнике говориться, что для локальных серверов Exchange 2013 должен быть установлен CU1 или более новый, но это неправда нужно установить самый последний CU для Exchange 2013 на момент реализации гибридного развертывания, в противном случае в мастере гибридного развертывания будут возникать ошибки.
  2. Microsoft Office 365 – пробная версия Exchange Online, в которой возможна тестовая реализация гибрида, предоставляется на один месяц.
  3. Exchange Online Protection – облачная анти-спам система.
  4. Мастер гибридной конфигурации – это мастер, который запускается на локальном Exchange сервере:
    05
  5. Система проверки подлинности Windows Azure Aсtive Directory - Что такое Microsoft Azure Active Directory
  6. Синхронизация Active Directory  - это наиважнейший компонент в гибридном развертывании. Синхронизация формирует единый глобальный список адресов (GAL), иначе адресная книга между локальным Exchange сервером и Exchange online. Наша задача, как администратора почтового сервера, содержать адресную книгу в актуальном состоянии. Если пренебречь этим, мы начнем получать жалобы о невозможности доставки почтовых сообщений до адресатов.

Рассмотрим ситуацию:
На локальном Exchange сервере был создан почтовый ящик. Входящая почта в организацию направлена через EOP, т.е. через облако. И чтобы письмо пришло во вновь созданный локальный почтовый ящик, нужно инициализировать процесс синхронизации (по умолчанию синхронизация запуская каждые три часа). Если вдруг синхронизация “сломалась” и не прошла после создания локального почтового ящика, внешний отправитель при попытке доставить почтовое сообщения получит “отлуп”:

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

В гибридном развертывании в контексте синхронизации есть понятие главный источник. Главный источник определяет, где будет осуществляться создание, управление объектами Active Directory такими как пользователи, контакты и группы. Другими словами, главный источник – это место, где объект был первоначально создан. В гибридном развертывании у объекта может быть только один главный источник – это локальная Active Directory. После того, как мы активируем синхронизацию в Office 365 и настроем локальный сервер синхронизации Azure Active Directory, главным источником объектов будет наша локальная Active Directory.

На следующей странице помощника по гибридному развертыванию нам предлагают пройти регистрацию в Office 365, что мы и делаем. Советую вводить реальные данные ФИО, почту, телефон. Была ситуация, когда собиралась демонстрационно-тестовая среда и учетная запись заблокировалась, - пришлось звонить в тех. поддержку Microsoft. Тех.поддержка требует назвать NameCompany.onmicrosoft.com – ваше доменное имя в Exchange Online (оно формируется во время регистрации).

в имени NameCompany.onmicrosoft.com вместо NameCompany может быть все, что угодно, необязательно название вашей компании или ваш почтовый домен.

После того, как мы зарегистрировались, можно залогиниться в личный кабинет Office 365.

В личном кабинете Office 365 видим крупную кнопку “ГЛАВНАЯ”, нажимаем и попадаем в Центр администрирования Office 365. Выбираем “ДОМЕНЫ”:

09

выбираем “Добавить домен”…

10
Мастер дает нам ознакомительную вводную информацию о том, что такое DNS и доменные имена.

Указываем домен:

11

Далее мастер просит создать TXT или MX запись в DNS для идентификации нашего домена:

22

Что мы и делаем:

23

Выдерживаем тайм-аут  ~5 минут после создания TXT или MX записи в DNS и нажимаем кнопку “Проверить”. Если все правильно сделано, то мы увидим:

15
Далее мастер предлагает изменить домен для нашего пользователя. Этот шаг пропускаем, так как  все изменения будем вносить после первой синхронизации локальной Active Directory c Office 365.

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

Далее мастер задает вопрос “Вы хотите, чтобы корпорация Майкрософт настроила записи DNS для Office 365?”  отвечаем НЕТ, так как всеми записями в DNS для нашего почтового домена мы управляем сами.

Еще вопрос  “Какие службы вы собираетесь использовать в домене DomainName.ru?” отвечаем Outlook.

Далее мастер просит создать MX, CNAME, SPF записи в DNS, что мы и сделаем, но скорректируем эти записи под наши нужды:

  1. Предложенная  мастером MX запись имеет верное значение, указывающие на службу  Exchange Online Protection. Это значит, что ВСЯ входящая почта будет маршрутизироваться через облако.16
  2. С первого взгляда непонятная, но очень важная CNAME запись c именем узла MSOID, - обязательно создаем её:
    17
    Зачем нужна запись CNAME в Office 365 для MSOID?
  3. Чтобы понимать, какие значения должны быть в SPF записи, нужно упомянуть о возможной логике исходящей почты в гибридном развертывании. Самый распространенный выбор, что каждая организация Exchangе обрабатывает исходящую почту самостоятельно. Маршрут письма отправленного из почтового ящика, который находится в облаке, будет строиться через транспортные серверы Exchange online, но а маршрут исходящего письма локального почтового ящика будет проходить через локальные сервера Exchangе. Возможен вариант, что ВСЯ исходящая почта в гибриде будет обрабатываться серверами локальной организации Exchange.
    Цитата с TechNet:
    Такой подход удобен в основном в сценариях обеспечения соблюдения требований, где вся почта, адресованная в Интернет и поступающая из него, должна обрабатываться локальными серверами

    В нашем случае исходящая почта будет обрабатываться каждой организацией отдельно. На основании этого мы должны создать правильную SPF запись, в которой будут присутствовать облачные и локальные серверы Exchange:18

  4. CNAME запись для AutoDiscover должна указывать на локальные Client Access сервера. Цитата с TechNet:
    Запись автообнаружения в DNS для локальной организации должна отправлять запросы autodiscover.contoso.com на локальные серверы клиентского доступа. Вы можете использовать запись DNS типа CNAME или A. DNS-запись CNAME должна ссылаться на полное доменное имя сервера локальной службы Exchange 2013 с установленной ролью сервера клиентского доступа. DNS-запись типа A должна указывать на внешний IP-адрес сервера клиентского доступа Exchange 2013 или брандмауэра в зависимости от конфигурации сети

    19

После того, как мы создали все требуемые записи в DNS, нажимаем в мастере кнопку “Записи добавлены”:

20
Мастер справедливо  нам указывает на “ошибку”, но мы знаем, что у нас все правильно, и смело игнорируем эту “ошибку”.

Конечный результат для нашего домена:

21
Exchnage Online время от времени проверяет ваши записи в DNS на корректность, но мы нажали кнопку  “Игнорировать эти ошибки” на предыдущем шаге и встроенная проверка DNS записей автоматически отключилась.

Возвращаемся в помощник по гибридному развертыванию на страницу “Проверка предварительных требований”:

  1. Локальная Active Directory. Установлена и настроена.
  2. Сервер Exchange 2013 c последним CU. Установлен и настроен.
  3. Сервер Exchange 2013 должен быть установлен, как минимум, на Windows Server 2008 R2 SP1 Standard. В своей тестовой среде мы установили Exchange 2013 на Windows Server 2012 R2 Standard.
  4. Локальный сервер синхронизации Azure Active Directory (он же DirSync).

Из выше перечисленного списка предварительных требований у нас отсутствует только сервер синхронизации. Для его установки я обычно использую специально созданную отдельную виртуальную машину на Hyper-v с Windows Server 2012 R2 Standard. Сервер синхронизации обязательно должен входить в домен Active Directory.

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

Скачиваем сервер синхронизации Azure Active Directory и запускаем установку.

Сервер синхронизации устанавливается очень просто Далее –> Далее–> Готово.

При успешном результате мы увидим:

24
Нажимаем Next и запускаем Wizard, который нужно сконфигурировать.

На первом шаге нас просят предоставить административные учетные данные от Azure Active Directory – это административные учетные данные от личного кабинета Office 365:

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

26

Чтобы синхронизация заработала, ее необходимо активировать в личном кабинете Office 365:

27
28
29

Теперь можно сделать еще одну попытку аутентификации сервером синхронизации в Azure Active Directory, если попытка завершилась удачей  Wizard запросит учетные данные Enterprise Administrator’a от локальной Active Directory. Создаем отдельного пользователя и даем ему членство в группе Enterprise Admins:

34

Нажимаем Next и ставим галку Enable Hybrid Deployment.Эта галка дает право Exchnage Online изменять некоторые атрибуты в локальной Active Directory. Более подробно можно прочитать по ссылке в разделе “Гибридное развертывание”:

31

Нажимаем Next и ставим галку Enable Password Sync:

32

Цитата TechNet:

Password Sync (синхронизация паролей) — это функция средства синхронизации Azure Active Directory, которая синхронизирует пароли пользователей из вашей локальной Active Directory с Azure Active Directory ("Azure AD"). Эта функция позволяет вашим пользователям входить в свои службы Azure Active Directory (например, Office 365, InTune, CRM Online и т. д.) с помощью того же пароля, который они используют для входа в локальную сеть. Важно отметить, что эта функция не обеспечивает решение единого входа, поскольку при этом не происходит обмен токенами в процессе синхронизации пароля.

Нажимаем Next и запускаем синхронизацию:

35
Удостоверимся, что локальный сервер синхронизации корректно отработал:

33
GUI клиент можно найти по пути C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe 

Как мы видим, синхронизация осуществляется через программу Synchronization Service Manager, которая входит в состав  Forefront Identity Manager 2010 R2.

Синхронизации завершилась удачно и это значит, что объекты должны появиться в Office 365.

В локальной Active Directory были созданы пользователи:

36
После удачной синхронизации объекты пользователей появились в Office 365:

rsz_37
Синхронизации работает правильно и главным источник синхронизации  является локальная Active Directory.

Иногда  бывает, что нужно срочно запустить синхронизацию. Запускаем на сервере синхронизации PowerShell и выполняем команды:

Import-Module DirSync 
Start-OnlineCoexistenceSync

Расписание синхронизации можно скорректировать (по умолчанию синхронизация выполняется каждые три часа):

C:\Program Files\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.Config

40
После изменения перезапускаем службу “Windows Azure Active Directory Sync Service”

41
Чтобы управлять своей облачной организацией Exchange через PowerShell, на сервер синхронизации установим модуль PowerShell Azure Active Directory:

  1. Первым устанавливаем Microsoft Online Services Sign-In Assistant for IT Professionals RTW. Перезагружаемся.
  2. Вторым устанавливаем Azure Active Directory для Windows PowerShell (64-разрядная версия)

В результате появиться ярлык Azure Active Directory для Windows PowerShell:

42
Запускаем и пробуем подключиться к Exchange Online:

$LiveCred = Get-Credential

Вводим наши административные учетные данные от личного кабинет Office 365:

43

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

45
Чтобы увидеть наш домен и пользователей в Exchange Online, нужно выполнить еще одну команду:

Connect-MsolService

После выполнения этой команды у нас снова будут запрошены учетные данные от личного кабинета Office 365.

Смотрим:

44

 

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

  • Мы успешно прошли проверку домена в Office365 и создали требуемы записи MX, SPF, CNAME, AutoDiscover в DNS.
  • Была настроена правильно работающая синхронизация, главным источником которой является локальная Active Directory.
  • Установили модуль Azure Active Directory PowerShell с помощью которого есть возможно вносить изменения в конфигурацию Exchange Online.

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

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