0

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 user@somethingelse.com (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

Z Holt
  • 219
  • 1
  • 6
  • 19
  • Before proceeding with an answer, you need to provide the following information: 1) What kind of Exchange do you have on-premises? 2) ultimately, you're end goal is to keep your Exchange on-premises or remove it? 3) How would you like to manage users and passwords? from a local AD or on the Office 365 system? – Noor Khaldi Sep 30 '15 at 11:13
  • Hi Noor, Current Exchange is 2010 v14.03.0123.003 on a single Windows 2008 R2 server, Ultimately we are planning to retire the on premise server and be able to manage via local AD. – Z Holt Sep 30 '15 at 11:23
  • 300 users, 47 (!) accepted email domains. I would **strongly** suggest you pick a single UPN Suffix for all of your users. Otherwise, brains of your help desk folks will explode. – blaughw Sep 30 '15 at 22:42
  • Our company is a holding company for 15 different businesses, each have several alias' – Z Holt Oct 01 '15 at 08:53
  • If your not using a MS partner to help you, you will still qualify for Microsoft's onboarding service. They will help you plan, deploy, and migrate to O365 at no additional cost to you. To qualify you need to purchase at least 150 seats of E3 (its in your best interest to bulk purchase to get that incentive vs. Smaller seat purchases). You have 90 days from subscriptions purchase to use that benefit. – Jesus Shelby Oct 07 '15 at 02:54
  • I think that would be a great service to use, thank you – Z Holt Oct 09 '15 at 10:30

1 Answers1

2

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.
Noor Khaldi
  • 3,869
  • 3
  • 19
  • 28
  • Many thanks for your very detailed reply! Having thought about it, I think that we would be best using a hybrid migration as 1) We want to move one department at a time 2) We are buying the licences one department at a time If we go down the Hybrid route, would it be possible to move one accepted domain's mailboxes at a time? Would you recommend routing all traffic through the on premise first? How easy is it to retire the on premise server once all mailboxes are moved over? – Z Holt Oct 01 '15 at 09:00
  • 1) You can move one accepted domain at a time, though this will force your users to open a new mailbox in their mail clients since the migrated domain is no longer part of the local mailbox, the faster you migrate the faster you merge the separate mailboxes 2) Route through the cloud first, you'd get the benefits of Antivirus/Spam, managing DNS/SPF is easier too 3) Retiring the last Exchange server is a pain in the A$h! Never found a solid document to completely remove it, what I did is converted it to VM, turned it off and throw it in our archiving system, just in case if ever needed again. – Noor Khaldi Oct 01 '15 at 12:20
  • Would moving one accepted domain at a time entail (1)adding the accepted domain to 365, (2) migrating just the users on that domain via a migration batch (3) Changing accepted domain mx/auto discover record to office 365 – Z Holt Oct 01 '15 at 14:42
  • Also, in outlook some @le******.com users use a @de*****.co.uk alias, in this case would they require 2 outlook profiles? – Z Holt Oct 01 '15 at 14:43
  • I've actually re-worded my original question - [link](http://serverfault.com/questions/726073/complex-exchange-2010-to-office-365-migration-with-multiple-domains) – Z Holt Oct 01 '15 at 15:26
  • My apology, just realized that I made a brain fart, if you do a hybrid deployment with exchange, then you can move the user mailbox directly to the cloud without creating two mailboxes in the mail client, in going to amend my original answer in a bit. – Noor Khaldi Oct 01 '15 at 18:53