Exchange Online Migration: Unmentioned Pitfalls

There are several ways outlined by Microsoft that can be found here. This blogpost goes over migrating from an integrated Exchange server infrastructure to Exchange Online with a hybrid deployment. I will not cover third-party migrations, as this is not relevant for the topics mentioned in this post.

NotAcceptedDomainException

Depending on the age of your Active Directory and changes of your SMTP namespaces due to projects like Mergers & Acquisitions (M&A), divestiture, spinoff or just renaming. The result is most likely in all cases the same: You will find a lot of artifacts from these namespaces as additional SMTP addresses in the AD attribute proxyaddresses. Once you start with your migration and you didn't follow the detailed list of Prerequisites for hybrid deployment here, you will most likely run into issues, when you create your MigrationBatch or when you need to grant someone Send As permissions. If you haven’t yet registered your custom domains in your tenant OR performed a clean-up of your Active Directory, you won’t be able to perform these actions.

This topic is mostly underestimated and can cause delays for migration projects and lower end-user experience.

Thus, I can only highlight to check your environment up-front and avoid possible impact.

If you have already failed MigrationUser or want to check currently synced recipients you can use my function, which returns also the missing domain. The bad thing about failed MigrationUser is that it won’t tell you, which domain is missing.

You can find the function in my GitHub repository here.

SourcePrincipalMappingException

Ben Winzenz wrote a great article about this topic, which can be found here. The underlying issue cannot be avoided. Over times peoples will grant other users either as Delegate or directly on folders permissions. Or users were granted FullAccess to Shared Mailboxes. There is nothing wrong with this, but how many keep track of these permissions and perform a clean-up?

As long as the granted user objects are still available in AD, there is no issue. But when these objects were deleted, the Mailbox Replication Service (MRS) won’t find an object for a corresponding SID, stamped on a folder in the mailbox. This will count as error towards the BadItemLimit and might cause the move to fail (depending on the limit, which was set). When you run into this, it's crucial that you either increase the BadItemLimit OR you must re-create the move as the MRS is evaluating permissions only during the initial sync. Fixing permissions after you run into this, won’t help and is by design.

Microsoft published a KB article for this here and provided increasing of the limit as a solution.

I highly recommend NOT following this as you might lose data (there was already a bug, which causes flagging of calendar items wrongly as bad!).

My solution would be to clear tombstoned permissions upfront. There are two ways for mailbox and folder level clean-up.

Mailbox Level

You can query Active Directory attribute msexchmailboxsecuritydescriptor, as Exchange writes existing permissions on a mailbox out to this attribute. Thus, it makes it easy to read and this can be achieved with high performance without the need of Exchange management Shell (EMS). You will need EMS only for fixing permissions. A script I wrote for this purpose, can be found on GitHub here and another post about this here.

Folder Level

This is not as easy as on mailbox level. You either need to have FullAccess to all mailboxes you want to check or ApplicationImpersonation permissions. I recommend in large environments ApplicationImpersonation as this will give you the best performance. In the end, you need to parse on each folder the existing ACLs. If there are invalid entries, they will be reported as UnknownEntries in the EWS SOAP response. A script can also be found on GitHub here and details and how to use it here.

Resource/Multi Forests

There was a time Resource Forests were hyped. Resource Forests were THE solution, in such cases, where you didn’t want to extend your schema for Exchange or Lync. The concept worked out very well back then but will bring in complexity on your way to Office 365.

In general, this is a supported scenario and described by Microsoft here. Usually you can distinct between the Resource and the Account (where the users actually authenticate) Forests. But there can be a lot more complex scenarios, where a forest can be Resource AND Account at the same time.

In these cases, simplicity is the goal. This means you might have to evaluate, whether it makes sense to collapse forests. Yes, AAD Connect supports multiple forests, but you need to keep in mind that any change made on an object in one forest needs to be replicated to all the other forests.

Conclusion

As outlined, there are many things, which needs to be considered and are not listed on the well-known documentations. As this was just a subset of things and the list will be continued in my next post.

Ease Your Transition to Office 365

While ENow is not a migration company, our software does enable IT Pros to assess their organizations readiness for Office 365 and accelerate their migration. In particular, ENow's solution helps organizations verify appropriate network connectivity, validate hybrid components (ADFS & AAD Connect) are setup correctly, and that mail routing is functioning.

For more information on how ENow can ease your transition to Office 365, please chat with the bot in the bottom right corner.