Миграция Exchange 2010 к Office 365 с ADFS
Позвольте мне сначала начаться путем объяснения нашей среды.
У нас есть один домен AD - de ***.co.uk
Независимо от которого отдела пользователь находится в, каждый пользователь аутентифицирует со всеми системами (inc обмен) использование их учетной записи домена (user@de ***.co.uk) или (de ***\user), даже если их адресом электронной почты является user@somethingelse.com (это распространено, я знаю),
Мы постепенно - планирование перемещающийся в Office 365 E3, один отдел за один раз, у Нас есть ~300 сотрудников, 47 принятых почтовых доменов и> 600 почтовых ящиков (некоторые из которых могут просто быть заархивированы к PST локально). Мы в IT протестировали 365 E3 с доменом, что мы владеем de *** s ****.co.uk и настраиваем пользователей/почтовые ящики вручную
Мы теперь готовы переместить один отдел для испытания 365 (20 пользователей) однако, мы хотели бы связаться в с нашим по предпосылке AD. Это подмножество пользователей будет иметь домен @le***********.com адреса электронной почты
Из того, что я собрался, я полагаю, что это шаги, которые я должен буду выполнить (исправьте меня, если я неправ),
- Настроенный ADFS
- Добавьте домен @le***********.com к нашим 365 учетным записям ******** (не уверенный, как это получило бы пользователей), ********
- Измените записи DNS le***********.com для указания на Office 365
- Импортируйте каждого пользователи PST в их 365 учетных записей или какой-либо другой метод?
Это - часть ADFS, которая вызывает беспорядок, До сих пор я читал, несколько учебных руководств идут о вещах по-другому (каждый говорит для установки ADFS на DC, другой говорит настроенный 3 новых сервера - один прокси ADFS, один сервер ADFS и один Сервер DirSync) - который является лучшим?
Во время установки ADFS сказано, что сертификат SSL необходим, чтобы быть установленным на IIS - этот сертификат был бы hostname.de ***.co.uk или hostname@le*********.com и друг друг принятый почтовый домен, нуждающийся в их собственном SSL?
Был бы другие пользователи, находящиеся на на обмене предпосылки быть затронутым этим процессом?
С уважением
На основании предоставленной вами информации, вот лучшие сценарии для продолжения.
Аутентификация пользователя : здесь есть 3 модели, с которыми вы можете работать, а именно:
- Пользователи в Office 365 (облачные учетные записи) : управление пользователями будет происходить полностью в облаке. Вы можете создавать пользователей, отключать, сбрасывать пароли и настраивать все настройки с помощью портала Office 365, для этого вам не нужен локальный AD, очевидно, что этот вариант не будет работать с вашей средой, поскольку у вас уже есть локальный AD с Exchange и вы хотите, чтобы управление пользователями контролировалось локально в AD.
- Пользователи в AD с односторонней синхронизацией с Office 365 (полу-федеративные учетные записи) : этот модуль позволит вам создавать учетные записи и выполнять полное управление пользователями на ваши внутренние серверы AD, вы установите и инструмент под названием «DirSync» или более новую версию «ADD Sync» для создания копии пользователей из локального AD в облако,у инструментов есть возможность также синхронизировать пароли учетных записей пользователей из локального AD в облако, что позволит вашим пользователям входить в локальные ресурсы в домене и в Office 365, используя одни и те же учетные данные, создавая полу-единый вход, пользователи при доступе к ресурсам в Office 365 потребуется указать свое имя пользователя и пароль, а аутентификация / проверка пользователей будет происходить на стороне облака. Требования для этого модуля заключаются в установке ранее упомянутых инструментов на любом сервере в вашей локальной сети, нет необходимости в ADFS или прокси-сервере ADFS, вам следует выбрать этот вариант, поскольку его проще всего реализовать и поддерживать.
- Пользователи в 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 в сети, вот поддерживаемый способ переноса электронной почты:
- Прямая миграция электронной почты : с помощью портала Office 365 вы создаете пакетное задание миграции, задание будет искать почтовые ящики пользователей с помощью автообнаружения Exchange, оно будет обращаться к почтовым ящикам пользователей на локальном сервере Exchange и начнет копировать содержимое почтового ящика в облако, все это может произойти, пока пользователь все еще использует почтовый ящик на локальный сервер. После того, как все электронные письма будут успешно скопированы в облако, вы остановите пакет миграции и измените записи DNS, чтобы новые электронные письма / автообнаружение указывали на облачный почтовый сервер вместо того, который находится в локальной сети, пользователям необходимо будет перенастроить для этого для доступа к новому серверу, и вы можете удалить почтовые ящики пользователей с локального сервера, поскольку он больше не используется. Я лично предпочитаю, чтобы вы использовали эту опцию.
- Массовый экспорт / импорт файлов .pst от имени пользователей : вы будете использовать инструмент для экспорта почтовых ящиков пользователей в файлы .pst, вы можете сохранить эти файлы в диск и отправить его в Microsoft для импорта, или вы сохраняете файлы .pst в локальную папку, а затем импортируете их в Office 365 самостоятельно с помощью мастера миграции из Office 365, я бы не стал использовать этот вариант, если у вас нет относительно небольших размеры почтовых ящиков.
- Попросите пользователей выполнить импорт / экспорт .pst : в идеальном мире вы можете попросить пользователя экспортировать свои почтовые ящики в файл .pst, сохранить файлы локально на своих машинах, настроить Outlook для работы с новым почтовым ящиком в облаке, импортировать файл .pst со своих машин в новый почтовый ящик, я бы избегал этого варианта любой ценой, потому что ... ну ... конечные пользователи.
Вы можете дополнительную информацию о миграции электронной почты можно найти здесь: https://support.office.com/en-us/article/Ways-to-migrate-multiple-emai l-accounts-to-Office-365-0a4913fe-60fb-498f-9155-a86516418842
Если вы выберете вариант 2 для аутентификации и вариант 1 для электронной почты, вам не понадобится ADFS или сертификат для завершения миграции. , конечные пользователи будут задействованы только на заключительных этапах прямой миграции.
Надеюсь, это поможет.
ИЗМЕНИТЬ :
Шаги миграции должны быть простыми, следуйте этим советам:
- Добавьте все обслуживаемые домены на портал Office 365 и проверьте их.
- Пользователь инструмент Microsoft IDFix, чтобы убедиться, что форматирование и данные ваших локальных учетных записей совместимы с Office 365.
- Создайте интеграцию ADFS (я бы по-прежнему использовал DirSync только потому, что вы можете установить его где угодно, и вам не нужно для него оборудование , он все равно будет работать так же, как ADFS, без автоматического входа в систему единого входа, но, похоже, ADFS является обязательным требованием в вашем случае)
- Создайте доверие федерации между вашим локальным почтовым сервером и Office 365.
- (Необязательно) Перенаправить входящие сообщения сначала отправьте электронное письмо в облако для лучшей защиты от вирусов и спама.
- Назначьте лицензии пользователям, которых вы хотите перенести в Office 365.
- Начните перемещать пользователей для каждого отдела по своему усмотрению.
- После того, как все учетные записи пользователей были перемещены в облако, удалите доверие федерации между Office 365 и вашим локальным почтовый сервер, сохраните ADFS или DirSync, хотя они вам всегда понадобятся.
- Удалите локальный почтовый сервер по своему усмотрению, виртуализируйте и оставьте его выключенным, у вас есть возможность.