A cutover migration from on-premises Exchange to Office 365 is fairly well documented on Docs at https://docs.microsoft.com/en-us/exchange/mailbox-migration/cutover-migration-to-office-365

In this scenario take into consideration that Azure AD connect is in place, and password sync and Seamless SSO is implemented

After the big move some quirks and culprits may arise.

Here are some tips:

Issue 1:
External users are unable to send email to distribution groups, these were allowed before the move.

Resolution:
On the local AD distribution-group object,

define attribute “msExchangeRequireAuthTosendTo : FALSE”

Issue 2:
Users mailbox folders may be displayed in wrong languange, possibly because the users never logged in to OWA, but instead opened Outlook directly.
Example:Inbox instead of Innboks (Norwegian)

Resolution:

Office 365 powershell session:

get-mailbox | set-mailboxregionalconfiguration -localizedefaultfoldername:$true -language nb-NO -Dateformat dd.MM.yyyy -timezone "Romance standard time"

Issue 3:
Office 2016 on RDS repeatedly asks for activation
This happens when the user is assigned a new RDS host (loadbalancing)

setup :
Office 2016 Pro-Plus is installed as Shared Computer Activation on a RDS(remote desktop services) solution which is the recommended installation of Office on RDS.
The customer is running RDS services in a loadbalancing setup
Because of loadbalancing, roaming profiles are defined for the users

Office is using tokens to activate Office for the user, and default writes this to %localappdata%\Microsoft\Office\16.0\Licensing

This creates an issue, as this folder is not a part of the roaming profile, thus not saved back to the roaming profiles store.

Resolution:

Install Office 2016 ADMX files in Ad and create a GPO:

Computer policy/Adminitrative templates/Microsoft Office 2016 (Machine/Licensing Settings.
Policy: Specify the location to save the licensing token used by shared computer activation
Value:%appdata%\Microsoft\Office\16.0

(This folder is a part of the Roaming profile) so it’s saved back.

Issue 4:

A 3rd party program using MAPI calls to send email is no longer functioning.
Error message like “no MAPI client is installed”

Resolution:

As Outlook 2016 is using RPC over HTTPS as primary protocols, MAPI support i deprecated.
A workaround here is to add the following to registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Messaging Subsystem]

Registry type: String
Name: MAPI
Value: 1

This seems to resolve 32 bits applications using 32 bits Office 2016 on x64 bits OS

Issue 5:

External recipients (mostly mac)are receiving attachments as “winmail.dat” and are unable to open it.

Resolution:
Really, this is an old issue on Exchange that is now reappearing on Office 365, and it is about the TNEF protocol/function (Transport Neutral Encapsulation Format)

TNEF can be disabled  with Powershell by the following command:


Set-RemoteDomain Default -TNEFEnabled $false

link:

http://help.outlook.com/140/gg263346.aspx

Issue 6:

This is a stupid one:

Skype for Business refuses to accept logons after adding a new domain to 365 and defining this as default domain, thus changing the users UserPrincipalname
Skype connectivitytests are complaining about Certificate mismatch, while Exchange connections are just fine.

Resolution:

Disable the Skype for Business feature per user, and activate it again.

Thats what i call Fun, huh 馃檪

More articles