Миграция автономного клиента Office 365 на Exchange 2010 (часть 3)

• Миграция автономного клиента Office 365 на Exchange 2010 (часть 2)
• Миграция автономного клиента Office 365 на Exchange 2010 (часть 4)
• Миграция автономного клиента Office 365 на Exchange 2010 (часть 5)
• Миграция автономного клиента Office 365 на Exchange 2010 (часть 6)
• Миграция автономного клиента Office 365 на Exchange 2010 (часть 7)
• Миграция автономного клиента Office 365 на Exchange 2010 (часть 8)

Введение

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

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

Наш пример сценария

В оставшейся части этой серии мы сосредоточимся на одном сценарии, который мы хотим реализовать. Наша компания, метко названная начала свою жизнь с Office 365. После периода быстрого расширения директор по информационным технологиям Exchange Labs решил, что организации будет лучше работать с Exchange собственными силами, используя локальное решение.

В начале проекта у Exchange Labs не было собственной инфраструктуры Active Directory или Exchange, и они были реализованы готовыми для добавления учетных записей пользователей. Топология инфраструктуры Exchange Labs в настоящее время довольно проста:

Рисунок 1: Высокоуровневая диаграмма нашей текущей среды

На приведенной выше диаграмме вы увидите, что и наш Exchange Online, и Exchange On-Premises совместно используют обслуживаемый домен. Однако на данный момент локальный домен не отправляет и не получает электронную почту из Интернета, а просто настроен в новой среде Active Directory и готов к попытке подключения к нашему арендатору Office 365. Вся входящая почта, предназначенная для exchangelabs.co.uk, предназначена для Office 365.

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

• Создайте локальные учетные записи пользователей в Active Directory, чтобы они соответствовали пользователям в Office 365.
• Синхронизируйте локальную Active Directory с Office 365.
• Настройте гибридную среду, чтобы пользователи могли постепенно мигрировать из Office 365.
• Оставьте поток входящей почты без изменений, при этом входящая почта сначала доставляется в Office 365, пока все пользователи не будут перенесены на локальную систему Exchange 2010.
• Перенесите почтовые ящики в локальную среду, не влияя на доставку почты или точность почтовых ящиков пользователей.
• После локального переноса пользователей внедрите службы федерации Active Directory 2.0.

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

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

Предварительные условия

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

Сначала в арендаторе Office 365 мы рассмотрим зарегистрированные домены:

Рисунок 2. Текущие обслуживаемые домены в арендаторе Office 365

Увидим в тенанте, зарегистрированы два домена:

• exchangelabs.co.uk
• exchlabs.onmicrosoft.com

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

Рисунок 3. Обслуживаемые домены в нашей локальной организации Exchange 2010

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

Далее мы рассмотрим пользователей в арендаторе Office 365. Мы хотим убедиться, что каждый пользователь, которого мы хотим перенести, использует обслуживаемый домен как часть своего идентификатора Microsoft Online Services:

Рисунок 4. Текущие пользователи в нашем арендаторе Office 365

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

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

Рисунок 5. Текущие получатели в нашей локальной организации Exchange

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

Рисунок 6: Проверка пользовательских объектов с помощью Active Directory Users and Computers

Наша последняя задача в Active Directory — убедиться, что мы сможем создавать пользователей с соответствующими именами участников-пользователей. Если ваше доменное имя не соответствует суффиксу имени участника-пользователя у пользователей идентификаторов Microsoft Online Services, вам потребуется добавить его в качестве суффикса имени участника-пользователя в . В нашем случае наше доменное имя Active Directory — , поэтому нам не нужно вносить дополнительные изменения, однако, если доменное имя Active Directory было, например, , нам нужно было бы добавить как суффикс имени участника-пользователя:

Рис. 7. Добавление альтернативного суффикса имени участника-пользователя

Наши оставшиеся задачи в Exchange и Office 365 обеспечивают готовность сред для нашей последующей работы по внедрению гибридного режима Exchange и инструмента Windows Azure Active Directory Sync (DirSync).

Для гибридного режима Exchange нам необходимо убедиться, что выполнены предварительные условия для гибридного режима, такие как работающий внешний доступ к Exchange AutoDiscover и веб-службам, открытые порты брандмауэра, чтобы разрешить входящий и исходящий SMTP-трафик между Office 365 и нашим сервером. локальная организация и исходящие подключения HTTPS из Exchange и DirSync. В первой части моей статьи «Использование мастера гибридной конфигурации в Exchange 2010 с пакетом обновления 2 — планирование» эти предварительные требования рассматриваются более подробно.

Наконец, нам нужно включить синхронизацию Active Directory в нашем арендаторе Office 365, чтобы позволить DirSync подключаться к учетным записям Office 365 и изменять их, а также предотвратить дальнейшие изменения свойств учетной записи пользователя через портал Office 365. Мы найдем возможность включить DirSync в , как показано ниже:

Рисунок 8: Включение синхронизации с Active Directory

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

Экспорт информации о пользователях, контактах и группах

Прежде чем мы сможем внедрить DirSync, нам нужно создать локальные учетные записи Active Directory, чтобы они соответствовали учетным записям в Office 365, иначе DirSync не сможет правильно сопоставить учетные записи с нашими существующими пользователями в Office 365.

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

Для выполнения этой задачи мы будем использовать Exchange Online PowerShell для подключения к Office 365 и извлечения необходимых данных, прежде чем создавать пользователей, контакты и группы на основе этой информации.

Сначала откройте командную строку PowerShell 2.0 и введите следующие команды, как описано в статье Microsoft «Подключение Windows PowerShell к службе»:

$cred = Получить учетные данные

$session = New-PSSession -ConfigurationName Microsoft.Exchange -Authentication Basic -ConnectionUri https://ps.outlook.com/powershell -AllowRedirection:$true -Credential $cred

Import-PSSession $session

После подключения к сервису мы экспортируем информацию в несколько XML-файлов, содержащих объектную информацию:

Get-User -ResultSize Неограниченный | Экспорт-Clixml.Users.xml

Get-Mailbox -ResultSize Неограниченный | Экспорт-Clixml.Mailboxes.xml

Get-Recipient -ResultSize Неограниченный | Экспорт-Clixml.Recipients.xml

$DGs = Get-DistributionGroup -ResultSize Неограниченный

$DGs | Экспорт-Clixml.DistributionGroups.xml

$DGMembers = foreach ($DG в $DG) { Get-DistributionGroupMember -Identity $DG.Identity | Выберите @{Name="Group";Expression={$DG.Name}},PrimarySMTPAddress}

$DGMembers | Экспорт-Clixml.DGMembers.xml

Наконец, мы завершим наш сеанс Exchange Online с помощью следующей команды:

Remove-PSSession -Session $session

Ниже вы увидите ожидаемый результат:

Рисунок 9. Вывод наших команд сбора данных в Office 365.

В результате работы этих скриптов должны быть сгенерированы четыре файла:

• Users.xml — содержит базовую информацию о пользователе.
• Почтовые ящики. xml — содержит подробную информацию о почтовом ящике
• Recipients.xml — содержит дополнительную информацию о почтовых ящиках, пользователях с поддержкой почты и контактах.
• DistributionGroups.xml — содержит основную информацию о группах рассылки.
• Члены DGM. xml — содержит список членства в группах

Вы найдете дополнительные сценарии, предоставленные корпорацией Майкрософт, которые позволяют настраивать или извлекать дополнительные данные в Microsoft Technet, на странице .

Резюме

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

• Миграция автономного клиента Office 365 на Exchange 2010 (часть 2)
• Миграция автономного клиента Office 365 на Exchange 2010 (часть 4)
• Миграция автономного клиента Office 365 на Exchange 2010 (часть 5)
• Миграция автономного клиента Office 365 на Exchange 2010 (часть 6)
• Миграция автономного клиента Office 365 в Exchange 2010 (часть 7)
• Миграция автономного клиента Office 365 на Exchange 2010 (часть 8)