Forum Discussion
Azure AD before Exchange migration?
Because you require directory synchronisation after your migration to Exchange Online, it is important to know that the only supported way to manage your synchronized objects with mail (box) attributes is via an on-premises Exchange server. Other ways might work, but are not supported.
In this case (because you have 2007) that Exchange server license would be "free", see here for eligibility. That server would only be used to setup a hybrid connection to Exchange Online.
Knowing that you would end up with an updated Exchange server anyway (max. 2013 when coexisting with 2007), you might want to consider the Hybrid Mailbox move as an option which has benefits over Cutover. It's more seamless for the users (they don't have to re-create an Outlook profile) and less risky as you can pilot and test before moving all mailboxes over. You also don't have to re-match on-premises users with their cloud user accounts (which is actually not even supported, if I recollect correctly).
Yes, the downside is that you would still require an Exchange server, but it's mainly for management purposes and can be used as an SMTP relay server for applications/devices etc.. If resources are an issue, you could probably get away with even less than what is minimaly supported for Exchange (tricky if you are not virtualizing).
This is a great (albeit somewhat older) blogpost: http://clintboessen.blogspot.nl/2013/11/office-365-migration-solutions-for.html
Not fully valid for E2007, but still valuable overal: https://blogs.technet.microsoft.com/exchange/2016/11/28/new-exchange-online-migration-options/
TL;DR: Because you require directory synchronisation, consider adding a 2013 server and migrate via Hybrid mailbox move. That 2013 will be your management server after migration.
Hi Dave.
There's some great detail in your answer. In this company pretty much all the on-prem Windows software on the (virtual) servers is pirated including Exchange 2007. Moving to Office 365 offers a legitmate way forward for this organisation. I am very reluctant to maintain any sort of on-prem Exchange server. Moving to the cloud, for this company, will reduce the administrative IT burden so they can focus on maintaining a local Dynamics AX install (which is legal) and local domain joined PCs.
The password sync, in my view, is just so they can sign into their local AD with their domain joined PCs and also use the same password in Office 365 and Outlook configurations. From what I've read this is a supported scenario but I'm happy to be corrected.
I'm still confused at what I should do first. The Azure AD sync with on-prem AD (for password syncing) then the cut over. or do the cut over migration first with AD sync later.
Thank you.
The challenge is that you keep directory synchronisation enabled after your mailbox move. That means that certain (Exchange) attributes are read-only in Exchange Online and cannot be changed directly. Only via the on-premises Active Directory which then synchronizes those changes. This is a given and a direct consequence of using directory synchronisation.
However, the only supported way to edit on-premises AD objects for Exchange (Online) is via Exchange management tools, which means you require an on-premises Exchange. Luckily this is a free license under certain circumstances (having Exchange 2007 or no Exchange server is one of those, if it was 2010 or higher you wouldn't qualify. Part because since 2010 you can setup a hybrid Exchange environment).
The only cost you have is a Windows Server License and resources running that server (albeit limited compared to Exchange that is actually hosting mailboxes).
Now, adding an SMTP address to an object is not rocket science (but I stress, only supported via Exchange tools). But more fancy stuff like Shared Mailboxes, Archive mailboxes etc. are a whole different ballgame. Those things only really work well when using Exchange tools. It's also possible to use Exchange powershell on-prem to automate provisioning etc. when you have an on-prem Exchange server.
Knowing that you keep directory synchronisation and thus still require an on-premises Exchange server (which would be 2010 or more likely 2013), you could consider adding that server first, setup (minimal) hybrid and then do a Mailbox move instead of a cutover which has downside like requiring to recreate an Outlook profile after the cutover finishes (which a hybrid mailbox move does not). This has also the benefit that you do not have to disable and re-enable directory synchronisation (which can take several ours to be processed) AND be sure to match those objects correctly (tricky, especially when there are still Exchange attributes present from the on-prem Exchange environment).
Even for 150 mailboxes, I would opt for this scenario. Less risk, less end-user support required, fully supported migration.
But to answer you question; You can only do a cutover when there are no user objects in Azure AD/Exchange Online (cutover process creates those users), so disable dir. sync., remove users from EXO, do cutover, remove on-prem Exchange, edit synced objects attributes, enable dir. sync, match users.
However, you need to edit the on-prem users attributes in order to prevent that those attributes will overwrite the Exchange Online attributes (when dir. sync, certain on-prem attributes have priority over those in Exchange Online; your AD is the Start of Authority).
So, this is quite complex, error prone if you do not exactly know what you are doing and not supported (no on-prem Exchange and possibly the user matching bit).
It's my opinion that this migration scenario is a bigger burden than having an on-prem Exchange server (and using that to Hybrid mailbox move).
I hope I've clarified this even further. Good luck!