Forum Discussion
Azure AD before Exchange 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!