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

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

Введение

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

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

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

Автообнаружение

Поскольку наша организация Office 365 до этого момента (и до сих пор) существует только в облаке, DNS-запись автообнаружения, которая помогает клиентам находить их почтовые ящики, будет указывать на Office 365. Поскольку мы создали объекты удаленных почтовых ящиков локально, мы должны иметь возможность чтобы изменить запись DNS для автообнаружения, чтобы она указывала на нашу локальную организацию Exchange 2010.

Прежде всего, важно отметить, что мы исходим из того, что были соблюдены рекомендации по развертыванию Exchange 2010 и имеется подходящий SSL-сертификат с альтернативным именем субъекта (SAN/UCC) с нашими внешними именами для Exchange 2010. Если это не так, 't — это обнаружится, когда мы проверим предварительные условия чуть позже.

Изменить саму запись автообнаружения относительно просто; нам потребуется обновить запись , чтобы вместо она указывала на нашу локальную организацию Exchange. Ниже вы увидите начальное состояние записи автообнаружения в нашей сторонней консоли управления DNS:

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

А затем, после изменения разрешения на , наше внешнее пространство имен для локального Exchange 2010:

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

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

1. Устройство пытается обнаружить , почтовый ящик Office 365 и отправляет имя пользователя и пароль на https://autodiscover.exchangelabs.co.uk/AutoDiscover/AutoDiscover.xml.
2. Exchange on-premises знает, что это удаленный почтовый ящик, и предоставляет сведения об адресе электронной почты домена службы Office 365 Джима .
3. Устройство повторно пытается обнаружить с теми же учетными данными, пытаясь пройти аутентификацию по адресу https://autodiscover-s.outlook.com/AutoDiscover/AutoDiscover.xml с помощью перенаправления AutoDiscover.
4. Устройство получает сведения о доступе к почтовому ящику Office 365.

Следует помнить, что для правильной работы автообнаружения для пользователей в облаке должно совпадать не только имя пользователя (локальное имя пользователя и идентификатор Microsoft Online Services в Office 365), но и пароль. также. Поскольку мы не знали паролей пользователей в Office 365, когда создавали локальные учетные записи Active Directory, наш подход заключался в сбросе паролей при переносе почтовых ящиков. Это означает, что служба автообнаружения технически работает правильно, но она будет работать правильно для каждого пользователя только тогда, когда мы будем готовы переместить их почтовые ящики в локальную среду Exchange.

Предварительные условия для мастера гибридной конфигурации

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

Мы будем следовать первой части серии «Использование мастера гибридной конфигурации в Exchange 2010 с пакетом обновления 2», чтобы охватить предварительные условия для обеспечения правильной работы подключения.

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

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

Чтобы выполнить эти шаги, мы откроем и перейдем к корневому каталогу , затем выберем на панели Actions:

Рисунок 3: Создание нового доверия федерации

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

Затем мы откроем и воспользуемся командлетом , чтобы получить запись DNS Text (TXT), которую нам нужно добавить в нашу внешнюю зону DNS для :

Get-FederatedDomainProof -DomainName exchangelabs.co.uk | фл Доказательство

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

Рисунок 4: Использование командной консоли Exchange для получения записи TXT с подтверждением для нашего общего домена

Затем полную строку подтверждения в виде одной строки следует добавить во внешнюю зону DNS, как показано ниже:

Рисунок 5: Создание записи TXT для проверки во внешнем DNS

В приведенном выше примере вы увидите, что у нас уже есть запись TXT для записи (SPF), рекомендованной Microsoft при настройке Office 365. Запись SPF позволяет принимающим почтовым серверам знать, каким IP-адресам отправителя следует доверять для этого. домен.

Рекомендуется обновить это, чтобы либо добавить локальные исходящие IP-адреса Exchange (рекомендуется), либо полностью удалить запись SPF (не рекомендуется, но многие организации не используют записи SPF). В контексте TXT-записи Federation Proof вам будет приятно узнать, что несколько TXT-записей для одного имени хоста или доменного имени действительны в DNS и не влияют на процесс проверки.

Запуск мастера гибридной конфигурации

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

Сначала откройте и в разделе убедитесь, что выбрана вкладка , затем выберите :

Рисунок 6: Создание объекта гибридной конфигурации

После завершения работы простого мастера будет создан базовый объект, в котором будут храниться настройки мастера гибридной конфигурации. Затем мы добавим нашего арендатора Office 365 в консоль управления Exchange, щелкнув правой кнопкой мыши корневой узел и выбрав :

Рис. 7. Подключение EMC к Exchange Online

Откроется окно , в котором вы сможете ввести понятное имя для нашего арендатора Office 365. В разделе , выберите в раскрывающемся списке, затем нажмите OK:

Рисунок 8. Выбор Exchange Online и ввод понятного имени для подключения

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

Рисунок 9: Запуск мастера гибридной конфигурации

Когда откроется мастер , нажмите « , чтобы пропустить введение, и на странице » введите учетные данные локального администратора и администратора организации Office 365:

Рис. 10. Ввод локальных учетных данных и учетных данных арендатора

На странице мы выберем домен клиента Office 365, который мы используем совместно с нашей новой локальной организацией Exchange:

Рисунок 11: Выбор общих обслуживаемых доменов

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

Рис. 12. Проверка записи TXT, подтверждающей федерацию

В разделе добавьте локальные серверы, которые будут действовать как «гибридные» серверы для конфигурации. Для многоролевой реализации Exchange это могут быть серверы Exchange 2010 на вашем сайте с выходом в Интернет, но для более сложных реализаций у вас могут быть выделенный клиентский доступ и транспортные серверы-концентраторы:

Рисунок 13: Выбор серверов для участия в гибридных отношениях

На странице мы введем общедоступные IP-адреса, которые используются для отправки почты в Office 365 — входящий коннектор для Office 365. Для исходящего соединителя требуется полное доменное имя (FQDN), которое будет использоваться Office 365 для ретрансляции почты локальным получателям:

Рисунок 14: Ввод входящей и исходящей информации SMTP

На странице мы введем наши окончательные настройки. Сначала мы выберем сертификат транспорта, который будет использоваться для потока почты. Этот сертификат, установленный на всех серверах, которые будут отправлять и получать почту между Office 365 и локальной средой, будет использоваться нашими соединителями отправки и получения Exchange, а общее имя сертификата будет настроено в Office 365 Forefront Online Protection для Обмен на безопасную почту.

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

Рисунок 15: Выбор параметров безопасности почты и потока

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

Рисунок 16: Выполнение HCW

Мы ожидаем, что это займет несколько минут, и, как и любая другая задача, может завершиться ошибкой. Если у вас возникли проблемы, рекомендуется начать с части 4 серии «Использование мастера гибридной конфигурации в Exchange Server 2010 SP2».

Резюме

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

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