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

• Миграция автономного клиента Office 365 в Exchange 2010 (часть 3)
• Миграция автономного клиента 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. Напомним, что они могут включать слияния и поглощения компаний, изменение ИТ-стратегии, новые требования или изменения в организационной структуре. структура.

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

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

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

Выбор баз данных почтовых ящиков и локальных учетных данных

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

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

Вы найдете список баз данных почтовых ящиков в консоли управления Exchange (EMC) в разделе на вкладке . Либо откройте командную консоль Exchange (EMS) и используйте для получения списка баз данных Exchange 2010:

Рисунок 1. Выбор локальной базы данных почтовых ящиков для переноса почтовых ящиков Office 365 в

Нам понадобится только базы данных, как показано выше; нам не нужны никакие другие детали, такие как префикс имени сервера. Для наших ходов мы будем использовать .

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

Подходящие учетные записи для перемещения почтовых ящиков включают:

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

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

Рисунок 2: Группа ролей управления получателями в Active Directory

Перемещение почтовых ящиков

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

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

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

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

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

New-MoveRequest [электронная почта защищена] -Outbound -RemoteHostName mail.exchangelabs.co.uk -RemoteTargetDatabase DB01 -RemoteCredential $Credential -TargetDeliveryDomain exchangelabs.co.uk

Рисунок 3. Инициирование перемещения почтовых ящиков из Office 365

После успешного создания двух новых запросов на перемещение мы можем использовать стандартные командлеты и для отслеживания хода выполнения, опять же с помощью :

Рисунок 4: Мониторинг хода перемещения почтовых ящиков

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

Рисунок 5. Изучение локальных пользователей с включенной поддержкой почты, преобразованных в почтовые ящики

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

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

Марти Get-MailUser | Выберите имя, основной SMTP-адрес, внешний адрес электронной почты.

Рисунок 6. Изучение почтовых ящиков Office 365, преобразованных в пользователей с включенной поддержкой почты

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

Рисунок 7: Изучение свойств перенесенного почтового ящика

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

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

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

Рисунок 8: Просмотр разрешений на полный доступ к перенесенному почтовому ящику

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

Рисунок 9: Подтверждение того, что разрешения на полный доступ сохраняются после миграции

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

Клиентский опыт

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

Рис. 10. Представление Backstage в Microsoft Office с URL-адресом Outlook Web App

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

Рисунок 11: Приглашение Outlook для конечного пользователя

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

Рисунок 12: Попытка восстановить учетную запись Outlook

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

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

Наконец, пользователи Outlook Web App должны быть проинформированы об обновленных URL-адресах для доступа к электронной почте. Гибридная конфигурация (о которой мы подробно расскажем в последующих частях этой серии) включает , которые имеют URL-ссылки на противоположный URL-адрес Outlook Web App, предоставляя пользователям новый URL-адрес после миграции. Этот тип простой миграции не включает гибридную настройку, поэтому Office 365 не знает, где предложить конечным пользователям искать доступ к OWA.

Резюме

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

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

• Миграция автономного клиента Office 365 на Exchange 2010 (часть 3)
• Миграция автономного клиента 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)