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

Question

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

У нас есть один домен AD - de***.co.uk

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

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

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

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

• Настройка ADFS
• Добавьте домен @le***********.com в нашу учетную запись 365 ********(не уверен, как это привлечет пользователей)********
• Измените записи DNS le***********.com так, чтобы они указывали на Office 365
• Импортировать PST-файл каждого пользователя в его учетную запись 365 или использовать какой-либо другой метод?

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

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

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

С уважением

Answer 1

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

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

1. Пользователи в Office 365 (облачные учетные записи): управление пользователями будет происходить полностью в облаке. Вы можете создавать пользователей, отключать, сбрасывать пароли и настраивать все параметры с помощью портала Office 365, для этого вам не нужен локальный AD, очевидно, что этот вариант не будет работать в вашей среде, поскольку у вас уже есть локальный AD с Exchange, и вы хотите сохранить управление пользователями под контролем локально в AD.
2. Пользователи в AD с односторонней синхронизацией с Office 365 (полуфедеративные учетные записи): этот модуль позволит вам создавать учетные записи и выполнять все функции управления пользователями на ваших локальных серверах AD. Вы установите инструмент под названием «DirSync» или более новую версию «ADD Sync» для создания копии пользователей из локальной AD в облаке. Инструменты также позволяют синхронизировать пароли учетных записей пользователей из локальной AD в облаке. Это позволит вашим пользователям входить в локальные ресурсы в домене и в Office 365, используя те же учетные данные, создавая полу-SSO-опыт. При доступе к ресурсам в 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/выбор-модели-входа-в-office-365/

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

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

Дополнительную информацию о миграции электронной почты можно найти здесь:https://support.office.com/en-us/article/Способы-миграции-нескольких-учетных-адресов-email-в-Office-365-0a4913fe-60fb-498f-9155-a86516418842

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

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

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

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

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