Перенос электронной почты из Office 365 в Exchange 2013 (часть 3)

• Перенос электронной почты из Office 365 в Exchange 2013 (часть 2)
• Перенос электронной почты из Office 365 в Exchange 2013 (часть 4)
• Перенос электронной почты из Office 365 в Exchange 2013 (часть 6)

Введение

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

О синхронизации Azure Active Directory

Azure AD Sync устанавливается как инструмент черного ящика с ограниченной доступной конфигурацией, что упрощает настройку и синхронизацию данных с облачными службами Microsoft. Однако под капотом находится мощный двигатель. Microsoft Identity Manager (MIM) используется под капотом с поддержкой базы данных SQL, того же механизма, который используется организациями со сложными требованиями к удостоверениям по всему миру.

При доставке в составе Azure AD Sync MIM автоматически настраивается с помощью соединителей к локальной Active Directory и к Azure Active Directory. Механизм синхронизирует локальную AD и Azure AD в собственной базе данных, известной как метавселенная. После их сравнения изменения экспортируются в обе службы. Для Azure AD это включает создание, обновление и удаление учетной записи. Для локальной AD это более ограничено и используется для обратной записи гибридных атрибутов.

Вы найдете полный список атрибутов, которые синхронизируются по этому URL-адресу.

Теперь, когда мы знаем немного больше о том, что такое Azure AD Sync и что он делает, мы запустим MIM Synchronization Service Manager на нашем сервере Azure AD Sync. Вы найдете этот инструмент на основе графического интерфейса в следующем расположении, если вы установили Azure AD Sync в расположение по умолчанию с именем :

Рис. 1. Расположение файловой системы графического интерфейса управления Azure AD Sync

После первого запуска Synchronization Service Manager вы обнаружите, что сначала он выглядит довольно пустым. Все в порядке, так как мы еще не пытались ничего синхронизировать:

Рис. 2. Вкладка «Операции» Synchronization Service Manager

Две интересующие нас вкладки показаны выше – первые две. На вкладке «Операции» будет отображаться журнал предпринятых действий, что позволит нам изучить предыдущие задания синхронизации. Вкладка «Управление», которую мы рассмотрим далее, используется для настройки каждого агента управления, а также позволяет нам инициировать выполнение каждого агента:

Рис. 3. Вкладка «Агенты управления» диспетчера службы синхронизации

Перенастройка области для Azure AD Sync

Хотя это необязательно, мы решили перенастроить область для Azure AD Sync, чтобы сосредоточиться только на определенном организационном подразделении в нашей локальной Active Directory.

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

Под заголовком выберите , а затем выберите :

Рисунок 4: Свойства агента управления коннектором Active Directory

Затем вам будет предложено ввести действительные учетные данные Active Directory. По умолчанию вам будет предложено ввести учетные данные для автоматически созданной учетной записи службы синхронизации. Поскольку Azure AD Sync создает его во время установки, вы не будете знать пароль учетной записи. Вместо этого можно использовать другую учетную запись AD — она используется только для выбора организационной единицы в графическом интерфейсе и не сохраняется.

Когда откроется окно , мы выберем организационную единицу , в которой мы создали наши соответствующие учетные записи в предыдущей части этой серии:

Рис. 5. Настройка области Azure AD Sync для фильтрации по организационным единицам

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

Дополнительные сведения о поддерживаемых сценариях изменения области синхронизации Azure AD можно найти в статье TechNet Настройка фильтрации для синхронизации каталогов.

Проверка учетных записей, которые Azure AD Sync будет пытаться синхронизировать

Это еще один необязательный шаг, но он поможет вам убедиться, что после повторной настройки области для Azure AD Sync у нас есть возможность дважды проверить, что мы будем синхронизировать с Office 365, правильно.

Для этого мы выполним поэтапный импорт из Active Directory на локальный сервер Azure AD Sync. Это пока не внесет никаких изменений в Office 365, поскольку мы остановили службу синхронизации Azure Active Directory в предыдущей части этой серии.

Сначала выберите агент управления , а затем выберите на панели .

Рис. 6. Выбор действия «Выполнить» для запуска синхронизации

Должно открыться окно . Выберите « , затем нажмите «ОК».

Рисунок 7. Выполнение полного импорта, этап только для агента управления коннектором Active Directory

После нажатия OK состояние агента управления должно измениться на . В зависимости от размера импортируемой организации это может занять несколько минут; это связано с тем, что он должен загружать данные из Active Directory и вставлять их в локальную базу данных SQL Server, которая поддерживает MIM и Azure AD Sync.

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

Рисунок 8: Мониторинг состояния агента управления Active Directory Connector

Ниже вы увидите, что теперь у нас есть некоторые интересные данные в — 244 новых добавления из Active Directory. Если вам интересно, почему это не или , это, во-первых, потому, что это дополнения к локальному экземпляру MIM, а не к Office 365. Во-вторых, наш первый запуск с Office 365 не приведет к немедленным совпадениям, поскольку мы будем выполнять на основе адресов электронной почты каждого пользователя.

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

После того, как откроется окно , мы можем просмотреть сведения об объектах, которые были импортированы из Active Directory на данный момент, выбрав под заголовком , а затем выбрав :

Рисунок 9. Просмотр учетных записей Active Directory, импортированных в Azure AD Sync

Изучите результаты здесь и убедитесь, что они совпадают с тем, что вы ожидаете синхронизировать. Если нет, дважды проверьте область, которую вы установили при настройке фильтрации Azure AD Sync, и повторите попытку поэтапного импорта. Если все выглядит хорошо, пришло время начать синхронизацию учетных записей Active Directory с Office 365.

Выполнение начальной синхронизации с Office 365

Мы можем инициировать синхронизацию Azure AD Sync с помощью PowerShell. После запуска сеанса PowerShell выполните следующие команды:

Рис. 10. Запуск первого задания полной синхронизации

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

После первой синхронизации локальная учетная запись Active Directory не будет присоединена к их аналогам Office 365, поэтому выполните командлет во второй раз. Это будет использовать метод мягкого сопоставления, упомянутый ранее, чтобы связать учетные записи вместе.

Если операция выполнена успешно, мы ожидаем, что последний экспорт агента управления будет выполнять обновления для наших локальных объектов Active Directory, как показано ниже:

Рис. 11. Использование вкладки «Операции» для проверки выполнения второго задания дельта-синхронизации

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

Настройка автообнаружения

Поскольку все почтовые ящики Exchange находятся в облаке, DNS-запись автообнаружения, которая помогает клиентам находить свои почтовые ящики, будет настроена на перенаправление клиентов в Office 365. Теперь, когда мы создали объекты удаленных почтовых ящиков в помещении, мы должны иметь возможность изменить запись DNS. чтобы автообнаружение указывало на локальный Exchange.

Перед переключением записей важно отметить, что предполагается, что Exchange был настроен правильно, включая настройку действительного стороннего SSL-сертификата, содержащего имя (имена) автообнаружения для вашего домена, и он правильно опубликован в Интернете.

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

Первоначальная конфигурация Office 365 показана ниже на портале примера поставщика DNS:

Рисунок 12: Просмотр существующей записи CNAME автообнаружения

После обновления записи для направления трафика в наше локальное первичное пространство имен HTTPS, mail.exchangelabs.co.uk, запись будет аналогична показанной ниже:

Рис. 13. Обновление существующей записи CNAME автообнаружения для разрешения локального Exchange

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

• Устройство пытается обнаружить сведения о сервере для и отправляет имя пользователя и пароль на https://autodiscover.exchangelabs.co.uk/Autodiscover/Autodiscover.xml.
• Локальный Exchange 2013 знает, что это удаленный почтовый ящик, и предоставляет сведения об адресе электронной почты домена службы Office 365 Olivia .
• Устройство повторно пытается обнаружить с теми же учетными данными, пытаясь пройти аутентификацию по адресу https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml через перенаправление автообнаружения.
• Устройство получает сведения о доступе к почтовому ящику Office 365.

Следует помнить, что для правильной работы автообнаружения для пользователей в облаке не только основное имя пользователя в AD должно совпадать с идентификатором входа в Office 365, но и пароли также должны совпадать. Так как мы реализовали синхронизацию хэша паролей DirSync, это должно быть так.

Резюме

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

• Перенос электронной почты из Office 365 в Exchange 2013 (часть 2)
• Перенос электронной почты из Office 365 в Exchange 2013 (часть 4)
• Перенос электронной почты из Office 365 в Exchange 2013 (часть 6)