This issue is mainly present if you are trying to migrate from Exchange on-prem to Exchange Online and you’re not going with the hybrid route. The “double mailbox” way consists in having an online mailbox and a local one, and manually (or automatically using tools) migrating the content online.
The issue is that, if you are synchronizing your on-prem AD with Azure AD, you are most probably including your msExchMailboxGUID into the replicated fields. This attribute will tell Exchange Online not to create an online mailbox, as an on-prem one already exists.
Once you will have cleared this field from the online user, Exchange Online will be able to create another mailbox, populating the msExchMailboxGuid of the online user, leaving you with the possibility of exporting and importing data into your online mailbox.
Please note that this will also automatically clear the following attributes from the online user:
To proceed with the creation of the online mailbox, follow these steps:
Open your AD Connect server.
Stop the Sync with Powershell (launch it as admin and keep it open after this command): Set-ADSyncScheduler -SyncCycleEnabled $false
Open the Synchronization Rules Editor as an admin.
Select the In from AD – User Exchange rule, click Edit, then click on yes.
Under Precedence write 250 (or the first free one), then click Next until you arrive in the Transformations page. Here look for msExchMailboxGuid, then change the row’s settings to make them match with the image below:
Once you are done, click Save, then open the original rule. Note down the Precedence (usually it’s 108), then delete the rule. Go into your newly cloned rule and change the Precedence to the one you noted down.
Before you enable the scheduler and perform a full sync, you should test out the changes. This is the documentation link to test everything out without committing changes to Azure AD: Verify changes to AD Connect rules | MS Docs
Reenable the scheduler: Set-ADSyncScheduler -SyncCycleEnabled $true
Perform a full synchronization: Start-ADSyncSyncCycle -PolicyType Initial
You should now be able to create a second mailbox for your synchronized user by assigning a valid license.
Since Microsoft will soon start to turn off Basic Authentication for Exchange Online, you’ll have to enable Modern Authentication client-side if you still have some machines running Outlook 2013 and want them to connect to Office 365. This is quickly done by adding some registry keys. Modern authentication is already enabled by default in Office 2016 and later versions.
This process will activate the Modern Authentication workflow for all the apps included in Office 2013 (Outlook 2013, Excel 2013, Word 2013, OneNote, etc.), not just Outlook.
While this procedure will allow you (for now) to connect to Office 365, it is critical to remember that connection to Office 365 and Exchange Online via Office 2013 is not supported anymore. You should update to a newer and supported version soon, as things might stop working without notice.
To enable the feature, either open an elevated CMD and paste these commands in or add the entries manually via Registry Editor.
If just enabled a Conditional Access Policy blocking legacy authentication to Exchange Online, enabled Security Defaults, or Microsoft disabled it for your tenant, you might see some Apple Mail clients not connecting anymore.
This issue is happening because the profile might be still configured to use Exchange ActiveSync to connect to Exchange Online, and EAS (along with other legacy protocols) will be retired in October 2022.
Apple supports an automatic switch to modern authentication for its profiles, but only if it was freshly configured after iOS 12.
Unfortunately, it seems that backing up and restoring profiles does not trigger the switch to modern auth, so if you moved to a new iPhone and didn’t reconfigure the profile manually, you’ll need to remove and recreate it.
Apple will add support for the automatic migration to modern auth in iOS 15.6. Once you update your Apple device, the Mail app will use the saved credentials to establish a new authentication flow. From that moment onward, you’ll authenticate to Azure AD (Microsoft online Identity Provider) and get a new OAuth access token. The “old” stored credentials will then be removed. The process is fully transparent to users.
This way, the domain-joined clients will not be able to ask Active Directory an SCP entry and directly query the AutoDiscover (which should be fine, if you migrated to Office 365, as it’s one of the requirements).