Назад | Перейти на главную страницу

Миграция с Exchange 2010 на Office 365 с ADFS

Позвольте мне сначала рассказать о нашей окружающей среде.

У нас один домен AD - de ***. Co.uk

Независимо от того, в каком отделе находится пользователь, каждый пользователь аутентифицируется во всех системах (включая обмен), используя свою учетную запись домена (user@de***.co.uk) или (de *** \ user), даже если их адрес электронной почты это user@somethingelse.com (я знаю, это обычное дело)

Мы планируем постепенно переходить на Office 365 E3, по одному отделу за раз. У нас есть ~ 300 сотрудников, 47 обслуживаемых доменов электронной почты и> 600 почтовых ящиков (некоторые из которых могут быть просто заархивированы в pst локально). Мы в ИТ протестировали 365 E3 с доменом de *** s ****. Co.uk, которым мы владеем, и вручную настроили пользователей / почтовые ящики.

Теперь мы готовы перевести один отдел на пробную версию 365 (20 пользователей), однако мы хотели бы подключиться к нашей локальной AD. Эта группа пользователей будет иметь адрес электронной почты в домене @le ***********. Com.

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

Это часть ADFS, которая вызывает путаницу. До сих пор я читал несколько руководств, в которых говорится о разных вещах (один говорит об установке ADFS на DC, другой говорит, что нужно настроить 3 новых сервера - один прокси ADFS, один сервер ADFS и один сервер DirSync) - что лучше?

Во время установки ADFS говорится, что на IIS необходимо установить SSL-сертификат - будет ли этот сертификат hostname.de ***. Co.uk или hostname@le*********.com и друг другу принятые почтовые домены, нуждающиеся в собственном SSL?

Будет ли затронут этот процесс других пользователей, находящихся на локальной бирже?

С уважением

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

Аутентификация пользователя: здесь есть 3 модели, с которыми вы можете работать, а именно:

  1. Пользователи в Office 365 (облачные учетные записи): управление пользователями будет происходить полностью в облаке. Вы можете создавать пользователей, отключать, сбрасывать пароли и настраивать все настройки с помощью портала Office 365, для этого вам не нужен локальный AD, очевидно, что этот вариант не будет работать с вашей средой, поскольку у вас уже есть локальный AD с Exchange и вы хотите, чтобы управление пользователями контролировалось локально в AD.
  2. Пользователи в AD с односторонней синхронизацией с Office 365 (полуфедеративные учетные записи): этот модуль позволит вам создавать учетные записи и осуществлять полное управление пользователями на ваших локальных серверах AD. Вы должны установить и инструмент под названием «DirSync» или более новую версию «ADD Sync» для создания копий пользователей из вашего локальный AD в облако, инструменты имеют возможность также синхронизировать пароли учетных записей пользователей из локального AD в облако, что позволит вашим пользователям входить в локальные ресурсы в домене и в Office 365, используя одни и те же учетные данные, создавая В режиме полу-единого входа пользователи должны будут указать свое имя пользователя и пароль при доступе к ресурсам в Office 365, а аутентификация / проверка пользователей будет происходить на стороне облака. Требования для этого модуля заключаются в установке ранее упомянутых инструментов на любом сервере в вашей локальной сети, нет необходимости в ADFS или прокси-сервере ADFS, вам следует выбрать этот вариант, поскольку его проще всего реализовать и поддерживать.
  3. Пользователи в AD с двусторонней синхронизацией с Office 365 (учетные записи с полной федерацией): это самый продвинутый вариант из трех, этот вариант использует все настройки из предыдущего варианта «Пользователи в AD с односторонней синхронизацией с Office 365», а также добавляет возможность принудительной аутентификации / проверки пользователя в вашем локальном AD. серверов, использующих прокси-сервер ADFS и ADFS, вам потребуется развернуть прокси-сервер ADFS / ADFS и синхронизацию AAD либо в вашей локальной сети, либо в гибридной сети Azure, вы получите полный опыт единого входа с этой опцией в качестве пользователей в домене сможет получить доступ к Office 365 без необходимости указывать имя пользователя и пароль, я бы не рекомендовал использовать этот вариант, поскольку его установка, настройка и поддержка - это ужасная история для ИТ-специалистов.

У вас есть тонны информации, которую вы можете прочитать здесь для дальнейшего использования: https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/

Перенос электронной почты: поскольку у вас есть Exchange 2010 в сети, вот поддерживаемые способы переноса электронной почты:

  1. Прямая миграция электронной почты: используя портал Office 365, вы создаете пакетное задание миграции, задание будет искать почтовые ящики пользователей с помощью автообнаружения Exchange, оно получит доступ к почтовым ящикам пользователей на локальном сервере Exchange и начнет копирование содержимого почтового ящика в облако, все это может происходят, пока пользователь все еще использует почтовый ящик на локальном сервере. После того, как все электронные письма будут успешно скопированы в облако, вы остановите пакет миграции и измените записи DNS, чтобы новые электронные письма / автообнаружение указывали на облачный почтовый сервер вместо того, который находится в локальной сети, пользователи должны быть перенастроены, чтобы для доступа к новому серверу, и вы можете удалить почтовые ящики пользователей с локального сервера, поскольку он больше не используется. Я лично предпочитаю, чтобы вы использовали эту опцию.
  2. Массовый экспорт / импорт файлов .pst от имени пользователей: вы будете использовать инструмент для экспорта почтовых ящиков пользователей в файлы .pst, вы можете сохранить эти файлы на диск и отправить их в Microsoft для импорта, или вы сохраните файлы .pst в локальную папку, а затем импортируете их в Office 365 самостоятельно с помощью мастера миграции из Office 365, я бы не стал использовать этот вариант, если у вас нет относительно небольших размеров почтового ящика.
  3. Попросите пользователей выполнить импорт / экспорт .pst: в идеальном мире вы можете попросить пользователя экспортировать свои почтовые ящики в файл .pst, сохранить файлы локально на своих машинах, настроить Outlook для работы с новым почтовым ящиком в облаке, импортировать файл .pst со своих машин в новый почтовый ящик, я бы избегал этого варианта любой ценой, потому что ... ну ... конечные пользователи.

Вы можете найти дополнительную информацию о переносе электронной почты здесь: https://support.office.com/en-us/article/Ways-to-migrate-multiple-email-accounts-to-Office-365-0a4913fe-60fb-498f-9155-a86516418842

Если вы выберете вариант 2 для аутентификации и вариант 1 для электронных писем, вам не потребуется ADFS или сертификат для завершения миграции, конечные пользователи будут задействованы только на заключительных этапах прямой миграции.

Надеюсь это поможет.

РЕДАКТИРОВАТЬ:

Шаги по миграции должны быть простыми, следуйте этим советам:

  1. Добавьте все обслуживаемые домены на портал Office 365 и проверьте их.
  2. Используйте инструмент Microsoft IDFix, чтобы убедиться, что форматирование и данные ваших локальных учетных записей совместимы с Office 365.
  3. Создайте интеграцию ADFS (я бы по-прежнему использовал DirSync только потому, что вы можете установить его где угодно, и вам не нужно для него оборудование, он все равно будет работать так же, как ADFS, без автоматического входа в систему SSO, но кажется, что ADFS является требованием в ваш случай)
  4. Создайте доверие федерации между локальным почтовым сервером и Office 365.
  5. (Необязательно) Перенаправляйте входящую электронную почту сначала в облако для лучшей защиты от вирусов и спама.
  6. Назначьте лицензии своим пользователям, которых вы хотите переместить в Office 365.
  7. Начните перемещать пользователей для каждого отдела по своему усмотрению.
  8. После того, как все учетные записи пользователей будут перемещены в облако, удалите доверие федерации между Office 365 и вашим локальным почтовым сервером, оставьте ADFS или DirSync, хотя они всегда будут нужны вам.
  9. Удалите локальный почтовый сервер по своему усмотрению, виртуализируйте и оставьте его выключенным, у вас есть возможность.