Exchange 2010 migration to Office 365 with ADFS

Question

Let me first start off by explaining our environment.

We have one AD domain - de***.co.uk

Regardless of which department a user is in, every user authenticates with all systems (inc exchange) using their domain account (user@de***.co.uk) or (de***\user), even if their email address is [email protected] (this is common, i know)

We are planning on gradually moving to Office 365 E3, one department at a time We have ~300 employees, 47 accepted email domains and >600 mailboxes (some of which may just be archived to pst locally). We in IT have tested 365 E3 with a domain that we own de***s****.co.uk and set up users/mailboxes manually

We are now ready to move one department to trial 365 (20 users) however we'd like to link in with our on premise AD. This subset of users will have an email address domain @le***********.com

From what i have gathered, I believe that these are the steps I will have to perform (please correct me if i'm wrong)

• Set up ADFS
• Add @le***********.com domain to our 365 account ********(not sure how it would get the users )********
• Change DNS records of le***********.com to point to Office 365
• Import each users pst to their 365 account or any other method?

It's the ADFS part that is causing confusion, So far I have read several tutorials go about things differently (one says to install ADFS on a DC, another says set up 3 new servers - one ADFS proxy, one ADFS server and one DirSync Server) - which is best?

During the setup of ADFS, it is said that an SSL certificate is needed to be installed on IIS - would this certificate be hostname.de***.co.uk or hostname@le*********.com and each other accepted email domain needing their own SSL?

Would the other users residing on the on premise exchange be affected by this process ?

Regards

Answer 1

Based on the information you have provided, here's the best scenarios to proceed to proceed with.

User Authentication: there are 3 models that you can work with in here, which are:

1. Users in Office 365 (Cloud Accounts): user management will happen entirely in the cloud. You can create users, disable, reset passwords and configure all setup using the Office 365 portal, you don't need a local AD for this, obviously this option won't work with your environment since you already have a local AD with Exchange and you want to keep user management controlled locally in AD.
2. Users in AD, with one way sync to Office 365 (Semi-Federated Accounts): this module will allow you to create accounts and do the entire user management on your in-premises AD servers, you will install and a tool called "DirSync" or the newer version "ADD Sync" to create a copy of the users from your local AD to the cloud, the tools have the option to also synchronize the user account passwords from local AD to the cloud, which will allow your users to login to local resources in the domain and to Office 365 using the same user credentials, creating a semi-SSO experience, users will need to provide their username and password when accessing resources on Office 365 and user authentication/verification will happen on the cloud side. the requirements for this module is to install the previously mentioned tools in any server in your local network, no need for ADFS or ADFS Proxy, you should go with this option since it's the easiest to implement and support.
3. Users in AD, with two way sync with Office 365 (Full-Federated Accounts): this is the most advanced option of the three, this option utilizes all the setup from the previous option "Users in AD with one way sync to Office 365" plus it adds the ability to force user authentication/verification will happen on your local AD servers using ADFS and ADFS proxy server, you will need to have a deployment of ADFS/ADFS proxy and AAD Sync either on your local network or on an Azure hybrid network, you will get a full SSO experience with this option as users in the domain will be able to access the Office 365 without the need to provide a username and password, I wouldn't recommend going with this option since installing, configuring and supporting it is an IT horror story.

You have tons of information to read here for further referencing: https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/

Email migration: since you have Exchange 2010 in the network, here are the supported way to migrate your emails:

1. Cutover email migration: using the Office 365 portal, you create a migration batch job, the job will search for the user mailboxes using Exchange Autodiscover, it will access the user mailboxes on the local Exchange server and start copying the mailbox content to the cloud, al this can happen while the user is still using the mailbox on the local server. Once all the emails have copied successfully to the cloud, you will stop the migration batch and change the DNS records so new emails/Autodiscover point to the cloud mail server instead of the one in the local network, users will need to be reconfigured in order to access the new server, and you may remove the user mailboxes from the local server since it's not being used anymore. I personally prefer that you use this option.
2. Bulk Export/Import .pst files on behalf of users: you will use a tool to export the user mailboxes into a .pst files, you can save those files to a disk and send it to Microsoft for importing, or you save the .pst files into a local folder and then import them to Office 365 your self using a migration wizard from Office 365, I wouldn't bother with this option unless you have relatively small mail box sizes.
3. Ask your users to perform the .pst import/export: in a perfect world, you may ask your user to export their mailboxes into a .pst file, save the files locally on their machines, configure Outlook to work with the new mailbox on the cloud, import the .pst file from their machines to the new mailbox, I'd avoid this option at all costs because... well... end users.

You can find further information for the email migration here: https://support.office.com/en-us/article/Ways-to-migrate-multiple-email-accounts-to-Office-365-0a4913fe-60fb-498f-9155-a86516418842

If you select option 2 for the authentication and option 1 for the emails, you won't need ADFS or a certificate to complete the migration, end users will only be effected during the final stages of the cutover migration.

Hope this helps.

EDIT:

Your migration steps should be easy, follow these tips:

1. Add all the accepted domains to the Office 365 portal and verify them.
2. User the Microsoft IDFix tool to insure that your local accounts formatting and data are compatible with the Office 365.
3. Create the ADFS integration (I still would go with DirSync only because you can install it anywhere and you don't need hardware for it, it would still run the same as ADFS without the SSO auto-login, but seems ADFS is a requirement in your case)
4. Create a federation trust between your local mail server and Office 365.
5. (Optional) Redirect incoming email to the cloud first for better antivirus/spam handling.
6. Assign licenses to your users whom you want to move to Office 365.
7. Start moving the users for each department as you see fit.
8. Once all the user accounts have been moved to the cloud, remove the federation trust between Office 365 and your local mail server, keep ADFS or DirSync though you will always need those to be present.
9. Remove the local mail server as you see fit, Virtualize and keep it turned off you have the option.