Azure AD before Exchange migration?

[Craig Arnoldt]

Hello.

I am working on a plan to migrate an organisation from on-prem Exchange 2007 to Exchange Online.

I want to set up Azure AD to sync passwords.

There are only about 170 mailboxes so I was thinking a cut over migration would be easiest but I have read you must disable Azure AD sync to perform to use the cutover method.

My question is what shall I do first? The cutover then the password sync? or Password sync, disable it and then cutover?

Any advantages or disadvantages of these ideas?

Thank you.

[#2]

For your situation, you need to deactivate the Azure AD Connect  if it is running (this can take up to 72 hours) All users will be removed and put to the deleted users tab. When you restore the users they will become Cloud only and then perform a cutover migration to Office 365.

In the process of cutover migration, users will also be created in Office 365. After you delete the migration batch, you can assign the users Exchange Online licenses so that they will be provisioned with the migrated mailboxes. When all of this is done, you can reactivate Azure AD connect with SMTP matching so that AD users are matched with Office 365 users.

[#3]

Hi Jerry.

Thanks for the imformative answer.

I haven't performed the AD sync yet. Should I do that first then the cut over migration, or, do the cut over and then the AD sync?

Thank you.

[#4]

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.

[#5]

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.

[#6]

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!

[#7]

If you want directory sync then rule out cutover migration. You can't do the dir sync before the migration, and it's challenging to retrofit it after the migration.

Choose a migration method that uses dir sync up front. That means either Staged or Hybrid. Staged is a fairly blunt instrument and is still a cumbersome user experience and support burden, but at least you can manage it in smaller groups than an all-in-one-big-bang-cutover migration.

Hybrid is the best balance of administrative control and user experience. Since you want directory sync anyway you will need an Exchange server on-prem for ongoing management of the Exchange attributes in AD. 2007 is end of life, so you will need either 2010 or 2013 for that purpose. You can get a free "hybrid license" to fulfill that role.

[#8]

You can do cutover migration first which will create the Cloud only identities, than you can enable Azure AD Connect to Sync the user. Azure AD Connect will use smtp attribute to match the accounts.

Since cutover migration will create the users, the attributes are on the cloud and on-premise accounts should match so Azure AD connect will do the softmatch of the existing users and only create users that are not present. Having said that, it is always better to use Hybrid setup based on Exchange 2010 or 2013. 

[#9]

Yes, you can do Cutover and than sync has has said in this thread and then soft match.

Here you have the process https://support.microsoft.com/en-us/help/2641663/how-to-use-smtp-matching-to-match-on-premises-user-...

[#10]

My company does these fairly often with customers, doing a cutover migration when they have dir sync.

The big thing to know BEFORE you run the sync is that you need to do a custom setup of AADC and you need to ignore the ms_exchangeGUID attribute when you sync.

If you do not, O365 will think the users already have mailboxes, and you will not be able to provision blank mailboxes for them.

If you have already ran the sync, then you need to disable dir sync, delete the users, purge the users from deleted users, then re-run the sync with the ms_exchangeguid attribute ignored.

If you have any questions feel free to ask or message me directly! While this is not "supported" by Microsoft I have seen this done many times and can talk to you about the positives and negatives if you want to feel more informed before moving forward.

[#11]

Hi,

We have dir sync with 200 users in Exch2010 server, now we want to migrate to O365 exch online

Tried to uninstall AD sync but somehow all users were still in Azur Dir

What should i do next?

Thanks

---

@Adam Ochs wrote:
My company does these fairly often with customers, doing a cutover migration when they have dir sync.

The big thing to know BEFORE you run the sync is that you need to do a custom setup of AADC and you need to ignore the ms_exchangeGUID attribute when you sync.

If you do not, O365 will think the users already have mailboxes, and you will not be able to provision blank mailboxes for them.

If you have already ran the sync, then you need to disable dir sync, delete the users, purge the users from deleted users, then re-run the sync with the ms_exchangeguid attribute ignored.

If you have any questions feel free to ask or message me directly! While this is not "supported" by Microsoft I have seen this done many times and can talk to you about the positives and negatives if you want to feel more informed before moving forward.

---

[#12]

All your users should appaers as sync user. after 72 hours (as far as i can remind) without synchro your user will appears as cloud only. Thus you will be able to delete it directly from the tenant.

[#13]

@laurent Teruin is correct here! the users will remain, they should just no longer show as synced from your AD, just as cloud based objects.

The interface says 72 hours, but in my experience you should see this change in closer to 24 or so.

[#14]

Thanks, Adam. Very informative. If you could clear one thing for me: when you say ‘ignore the ms_exchangeguid attribute when you sync’, do you mean apply optional filtering in AAD Connect? If so, would you mind providing a couple of instructions?

Thanks.