Microsoft Way

Exchange 2010 в облаках (Hybrid Configuration)

Ровно в качестве памятки, собрав процесс воедино.
Опять же, клиенты нервничают, когда открываешь документ на ноутбуке и начинаешь его внимательно читать 🙂 Но, право же, я не всегда помню подводные камни.

И, да, сюрприз, Exchange 2010 вполне нормально поддерживается облаком даже в конце 2017 года. Но, разумеется, SP3 и последний роллап на нем быть должны.
Кроме того, будет неплохо иметь более-менее незагруженный сервер на базе Win2012R2 Standart и выше. С выходом в Интернет (хотя бы через прокси — тут все, в общем-то, решабельно). Можно, конечно, прямо существующий контроллер домена, но его, возможно, придется пару лишних раз перегружать. Если с версией ОС есть сложности, в четких рамках описанной ниже задачи можно обойтись и Srv2008R2. А вот если нужно ADFS и всякие там SSO…то задачу эту я описывать здесь не буду.

Итак, по пунктам, как это все реализуется:

1.
Убеждаемся, что имеем в наличии
— Учетку Администратора Предприятия (EntAdmin)
— Учетку Администратора сайта 365 (Global Admin)
— Учетку на управление внешним DNS

2.
Пристально смотрим на ldFix и понимаем, что нам до него пока рано.
Запускам оснастку Пользователи и Компьютеры, смотрим на предмет UPN суффикса у пользователей. Скорее всего, понимаем, что сейчас будем делать сомнительные вещи.
Запускаем оснастку Exch. Пока она запускается, пьем чай, чешем пятку.
В оснастке Exch идем OrgConf, Hub, Email policy. Вникаем в их сущность и добиваемся принудительного назначения «белого» суффикса в адреса.
Запускаем оснастку Домены и Доверие. Добавляем альтернативный UPN суффикс, совпадающий с внешним доменом.
В оснастке Пользователи и Компьютеры меняем пользователям основной суффикс. Множественные выделения здесь помогут. А вот с группами и контактами, скорее всего, нужно будет разобраться вручную через оснастку Exch.
Теперь снова смотрим на ldFix. Да, теперь запускаем и изучаем масштаб катастрофы. При помощи топора и упоминаний скандинавских богов доводим количество конфликтов до нуля. Любителей же администрировать предприятие от имени единственной учетной записи Администратор (в национальном языковом написании) здесь стоит предупредить с торопливыми решениями.

3.
Создаем учетную запись с членством в группе EntAdmin, ставим сложный неистекаемый пароль.
На стороне 365 также создаем сервисную учетную запись, делаем ее Глобальным администратором. Лицензию Офиса для нее необходимости иметь нет.
В админке 365 идем в Пользователи и включаем Синхронизацию каталогов. Можно сразу ввести часть настроек до момента проверки готовности. Возможно, необходимо будет подтвердить владение внешним доменом (если еще нет), это делается через DNS.
Понимаем, что не хотим проблем с паролем у сервисной учетной записи. Для этого нужно изменить ее параметр. И сделать это через страшный синий экран.
Ставим msoidcli, затем AdministrationConfig. Их есть тут
https://go.microsoft.com/fwlink/p/?LinkId=286152
http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185

Открываем PS, но не просто а по ссылке «Azure для PS»
$UserCredential = Get-Credential
Connect-MsolService -Credential $UserCredential

Вводим учетные данные Глобального админа 365.
Для изменения истечения пароля пользователя: Set-MsolUser -UserPrincipalName yasenhron@gdeya.onmicrosoft.com -PasswordNeverExpires $true

Или есть вариант использования модуля версии PS2, тогда в обычном PS
Install-Module -Name AzureAD
$UserCredential = Get-Credential
Connect-AzureAD -Credential $UserCredential

Здесь для изменения истечения пароля пользователя: Get-AzureADUser -SearchString » yasenhron » | Set-AzureADUser -PasswordPolicies DisablePasswordExpiration

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

Кстати, про сломать: при первичной синхронизации будут проверены атрибуты userPrincipalName и proxyAddresses. Можно попробовать их сначала отредактировать у пользователей 365. Проблемой будет, если у существующих пользователей уже была назначена лицензия на Exchange Online. Учетные данные в части логинов объединятся и пароли синхронизируются с оными из AD, но облако будет искренне продолжать считать местонахождением (и сущностью) ящика ранее существовавший в облачной инфраструктуре. Многие часы могут быть потрачены на попытки пробивания головой вертикальных строительных конструкций вокруг, но по документации дальнейшим «правильным» действием является бэкап всех пользовательских данных из облака, удаление пользователя и повторная синхронизация с AD для автоматического создания в облаке новой сущности. Можно пробовать играть атрибутами объекта, но результат будет сомнителен.

4.
На будущем сервере синхронизации проверяем отключенность транскрибирования: «Административные шаблоны» -> «Компоненты Windows» -> «Windows PowerShell»
Запускаем установку AD Connect, по окончании запускаем синхронизацию.
Возвращаемся на 365 и завершаем настройку Синхронизации. Ну или в ином порядке.
В пользователях 365 когда-нибудь появятся доменные. Им необходимо назначить лицензии.
Или если удалось всех (особенно, себя) обмануть, на этапе синхронизации мы заменим 365 пользователей реальными доменными.

5.
А теперь дискотека. В части настройки Exch.
Очень плохой идеей является запуск стандартной процедуры из консоли Exch. Так как у нас все же версия 2010. Есть новая версия, офлайн не существует: https://aka.ms/HybridWizard И если при ее запуске выдается ошибка Dot.Net, а средство диагностики при этом выдает отсутствие ошибок установки и настройки данной компоненты, то можно только посочувствовать.
Для подключения можно использовать любые административные данные, т.к. они нужны только на этапе настроек. Далее синхронизация данных будет выполняться только по ssl (которой TLS есть разновидность, хотя это не совсем так).
По прохождению Полной Гибридной настройки подтверждаем (снова, да) домен через DNS.
И обязательно проверяем, что CNAME autodiscovery указывает на сервер в локальном, а не облачном датацентре. На эту настройку проверка домена со стороны облака будет активно ругаться, но необходимо игнорировать (выбрать в проверке домена «игнорировать») данный казус. Это особенность гибридного развертывания.
Далее дискотека приходит к своей логичной части афтерпати: заставляем всех дружить сертификатами. Здесь очень интересен тот набор, который есть и дополнению не подлежит. В частности, есть компании, имеющие в публичном сертификате только имена www, mail. То есть без указания SAN autodiscovery.domain.com К сожалению, особенностью получения free/busy для ящиков в локальном датацентре (и это особенно актуально для ресурсных вроде конференц зала) со стороны пользователей из облака является попытка подключения (облачного сервера для получения данных) сначала к autodiscovery.
Для изменения общих настроек удобно использовать Set-HybridConfiguration
Да, может оказаться неожиданностью, но формально так: для использования сервиса EOP (онлайн антивирус-антиспам) необходимо количество лицензий по количеству ящиков, которые через него проходят. То есть, если мы заворачиваем весь входящий почтовый поток на облачные MX, то можем этим нарушить условия.

Для администрирования почтовых ящиков на стороне облака с использованием всех возможных танцев, можно сделать так:
Set-ExecutionPolicy RemoteSigned
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

6. А теперь еще и все не так.
Дело в том, что понятие «ресурсный почтовый ящик» несколько отличается на стороне облака. Это связано с несколько различающейся схемой атрибутов объектов.
Для того, чтобы пользователи в облаке могли увидеть, например, переговорные комнаты (rooms) находящиеся своими почтовыми ящиками на локальном сервере организации, необходимо все ресурсные ящики добавить в именованную группу, предварительно ее создав:
New-DistributionGroup –Name AllRoomsForMy365 –roomlist
Add-DistributionGroupMember AllRoomsForMy365 –member BlackRoomWithGhosts

Но если есть проблема с необходимым SAN в сертификате сервера, это несильно поможет. Впрочем, в качестве альтернативы можно создать «удаленный» ресурс, ящик которого будет физически находиться на стороне облака.
Создаем пользователя в локальном домене. А далее:
Get-User -Identity AnotherBlackRoomWithGhosts | Enable-RemoteMailbox -Room -RemoteRoutingAddress abroomwg@MyDomainInCloud.mail.onmicrosoft.com
И добавить его в группу комнат все равно будет нужно.

Также может быть удобно изменить права на просмотр объектов в календаре общего ресурса
Set-MailboxFolderPermission -AccessRights LimitedDetails -Identity myghostroom:\calendar -User default