Сопоставьте почтовый ящик Office 365 с новым локальным пользователем в гибридном развертывании
Существует множество различных сценариев миграции в Exchange Online. Некоторые из них просты, а другие болезненно сложны. Сегодня мы рассмотрим конкретный сценарий, в котором у клиента есть два леса Active Directory (AD), назовем их и :
- установлен Exchange (не имеет значения, какая версия), и клиент хочет настроить развертывание Exchange Hybrid для сосуществования/миграции с Exchange Online (ну, допустим, это не Exchange 5.5);
- У есть стороннее решение для обмена сообщениями, и клиент хочет перенести эти почтовые ящики непосредственно в Office 365, но перенести учетные записи AD в , чтобы можно было вывести из эксплуатации.
Проблема с этим сценарием заключается в том, что, как правило, средство миграции, используемое в , нормально переносит почтовые ящики в Office 365, но создает учетные записи AD в как «обычных» пользователей, а это означает, что Exchange Hybrid не знает, что эти пользователи на самом деле имеют почтовый ящик в Office 365.
Таким образом, клиент не может использовать гибридный сервер для управления какими-либо объектами, перенесенными из , только теми, которые уже существовали в и были «правильно» перенесены.
Одна из причин оставить хотя бы один гибридный сервер в локальной среде даже после переноса всех почтовых ящиков в Office 365 заключается в том, что администраторы могут легко управлять почтовыми ящиками с единой общеизвестной консоли. Помните, что, поскольку источником полномочий является локальная служба AD (из-за AADSync или DirSync), все изменения необходимо вносить локально. Если больше нет сервера Exchange для управления/обновления почтовых атрибутов, администраторам приходится обращаться к сторонним инструментам или, например, .
Невозможность управлять половиной перенесенных объектов, очевидно, не очень хороша ни для клиента, ни для консультанта, выполняющего работу в этом отношении! ?
Чтобы преодолеть это, нам нужно внести несколько изменений в эти учетные записи AD, чтобы локальный Exchange распознал их, чтобы мы могли ими управлять. Давайте рассмотрим пример пользователя с именем « », у которого есть почтовый ящик в Office 365. Как видите, он не синхронизируется с помощью AADSync (или DirSync):
Рис. 1. Экран пользователя на портале администрирования Office 365
В локальной AD есть учетная запись с тем же именем участника-пользователя, но вообще без почтовых атрибутов:
Рисунок 2: Локальная учетная запись Active Directory
В некоторых случаях вполне вероятно, что инструмент миграции также скопирует (перенесет) почтовые атрибуты для пользователей из в . Однако в этом случае мы предполагаем наихудший сценарий, когда никакие почтовые атрибуты не копируются.
Прежде чем поместить учетную запись в область действия AADSync, мы используем командлет Exchange , чтобы преобразовать учетную запись в пользователя с включенной поддержкой почты, чтобы Exchange распознал ее. Для этого командлета мы используем основной SMTP-адрес пользователя:
Enable-MailUser cloud.only –ExternalEmailAddress [электронная почта защищена]
Рисунок 3: Enable-MailUser с помощью EMS
Как только это будет сделано, пользователь появится в списке контактов в Центре администрирования Exchange (EAC). Это связано с тем, что теперь у него есть все необходимые атрибуты для распознавания пользователя почты:
Рисунок 4. Почтовый пользователь теперь виден в Центре администрирования Exchange
Поскольку эта среда Exchange уже настроена как гибридная среда, автоматически добавит дополнительный адрес всем получателям для правильного потока почты. Это означает, что нам не нужно обновлять ни один из адресов электронной почты пользователя, кроме случаев, когда:
- У пользователя были дополнительные SMTP-адреса в исходном лесу, которые по-прежнему необходимы в Office 365;
- Нам нужно добавить в качестве адресов X500 (если в источнике это была среда Exchange).
Для этого сценария я предполагаю, что ни один из них не требуется, поэтому у нас уже есть все необходимые адреса:
Рисунок 5: Атрибут proxyAddresses пользователя
Однако мы хотим, чтобы этот пользователь был не просто MailUser, а RemoteMailbox. Если мы посмотрим на атрибут в AD, то увидим, что для него установлено значение :
Рисунок 6: Пользовательский атрибут msExchRecipientTypeDetails
Согласно совету msExchangeRecipientTypeDetails Active Directory Values, опубликованному несколько месяцев назад на MSExchange.org, 128 относится к MailUser.
Итак, как нам изменить его на RemoteMailbox ? Для этого мы обновим этот атрибут до 214748364, что является значением для RemoteMailbox. Однако нам также необходимо обновить два других атрибута. Мы можем сделать это с помощью ADSI Edit, Attribute Editor или PowerShell:
Set-ADUser cloud.only – заменить @{msExchRecipientDisplayType = "-2147483642"}
Set-ADUser cloud.only — заменить @{msExchRecipientTypeDetails = «2147483648»}
Set-ADUser cloud.only — заменить @{msExchRemoteRecipientType = «4»}
Рисунок 7: Обновление атрибутов с помощью PowerShell
Используя Редактор атрибутов, мы можем проверить, что все эти атрибуты были установлены правильно:
Рис. 8. Проверка правильности установки атрибутов
Просто небольшое объяснение того, почему мы установили для значение 4. со значением 4 представляет почтовый ящик при использовании запроса на перемещение. Этот атрибут может иметь другие значения, например 100, которое используется для общих почтовых ящиков, или, например , 1, которое представляет почтовый ящик, когда используются командлеты .
Оба значения 1 и 4 представляют почтовый ящик в Office 365 с соответствующим локальным пользователем. Так почему же мы используем 4, а не 1? Эти два значения разделяют два пути кода: подготовка нового сотрудника и перемещение существующего локального пользователя в облако.
В конце переноса прокси-сервер службы репликации почтовых ящиков (MRS-прокси) преобразует локальный почтовый ящик в (со 4 «Мигрированный»), а облачный — в почтовый ящик.
Когда администраторы хотят подготовить новый почтовый ящик в облаке, они могут:
- Запустите командлет в локальной среде, который создаст пользователя с включенной поддержкой почты в локальной AD (со 1 «Переход») и связанным почтовым ящиком в Office 365;
- Или командлет для включения поддержки почты для существующего локального пользователя (со 1 «переход») и создания связанного почтового ящика в Office 365. После включения почты для пользователя синхронизация службы каталогов синхронизирует пользователя с поддержкой почты. к службе, и связанный почтовый ящик будет создан.
Поскольку в нашем сценарии почтовые ящики были перенесены (только не посредством обычного процесса миграции удаленного перемещения), мы устанавливаем для значение 4, чтобы обеспечить согласованность и четкость того, что это перенесенные пользователи. При нормальных обстоятельствах мы вполне можем установить его равным 1.
Если мы сейчас вернемся к Центру администрирования Exchange, пользователь будет указан как тип почтового ящика Office 365 в разделе почтовые ящики !
Рис. 9. Почтовый ящик, отображаемый в EAC
Мы также можем перепроверить это с помощью командной консоли, чтобы убедиться, что это действительно RemoteMailbox, запустив :
Рисунок 10: Проверка RemoteMailbox с помощью EMS
Но мы еще не закончили… Если мы проверим свойства пользователя, адрес маршрутизации будет установлен на основной SMTP-адрес пользователя:
Рисунок 11: Свойства почтового ящика в Центре администрирования Exchange
Как мы знаем, это должен быть адрес пользователя , чтобы электронные письма правильно пересылались в почтовый ящик в Office 365. В противном случае электронные письма просто будут отклонены, поскольку у пользователя нет локального почтового ящика..
Мы можем исправить это, используя несколько методов, и все они приведут к одному и тому же результату. Два из этих методов включают непосредственную настройку атрибута AD пользователя с помощью ADSI Edit или следующего командлета PowerShell:
Set-ADUser cloud.only – Замените @{targetAddress = «SMTP: [электронная почта защищена]»}
Или мы можем исправить это через Exchange Shell:
Set-RemoteMailbox cloud.only –RemoteRoutingAddress «SMTP:[электронная почта защищена]»
Рисунок 12: Обновление адреса маршрутизации почты
Теперь все, что осталось сделать, это поместить пользователя в область действия AADSync, дождаться синхронизации (или запустить ее вручную) и убедиться, что в Office 365 все в порядке:
Рис. 13. Экран пользователя на портале администрирования Office 365.
Работа выполнена!
Причина, по которой я использовал PowerShell для всех изменений, заключается в том, что это позволяет легко выполнить это для многих пользователей за один раз. Например, если у нас есть сведения о пользователях в CSV-файле, мы можем поместить все эти командлеты в сценарий, просмотреть весь CSV-файл и обновить всех пользователей за считанные секунды!
Обратите внимание: на этом этапе вы не сможете перенести почтовый ящик обратно в локальную среду! Это связано с тем, что атрибут ExchangeGUID не установлен локально. Чтобы это исправить, получите из почтового ящика в Office 365:
Get-Mailbox cloud.only | Выберите ExchangeGUID
Вернувшись в локальную среду, обновите для удаленного почтового ящика (очевидно, обновив значение, полученное на первом шаге):
Set-RemoteMailbox cloud.only-ExchangeGUID «4e4f00b7-ee3f-4182-aaad-448dbe4c82c9»