In my previous blogpost, I wrote about how crucial it is to have all of your domains registered, Access Control Entries (ACE) on mailbox and folder level in a row and a reminder to keep things simple and you might revisit your architecture and the need of resource forests.
This header is crucial and can make a huge difference for a call. The non-existence of this header can cause a call to fail or result in a poor performance – I’m not talking about throttling – for your application or script. Especially, when it comes to multi-geo environment this is header is very important.
When your connecting to Exchange Online you will hit first one of the front door services of your local egress point.
But back to our topic. From Exchange perspective you will hit the FE or so-called Café servers. These servers will make their decision for routing based on this header. If the header doesn’t exist, your request will be sent to the mailbox server of the authenticated user. There are a few scenarios documented, where this header shall be set:
Besides the Public Folder and ApplicationImpersonation requests, it is nowhere written that you MUST set this header. Nevertheless, I meanwhile set the header in every script I wrote (e.g.: Get-CalendarItems) for performance reasons and to address the multi-geo environment. If you have multi-geo in place and you don’t have the header set, your request will be routed to the wrong mailbox server.
I’ve seen many applications, also from large vendors, which don’t do this, and they just fail with their product, just because of the missing header (e.g.: products for Voicemail, reporting, etc.).
And Exchange Web Services (EWS) is not the only protocol:
Outlook for REST API is also a protocol, which highly depends on. You can find the statement here:
Use the Outlook REST API (version 2.0)
For optimal performance, when making a REST request using the new root URL, add an x-AnchorMailbox header and set it to the user's email address.
Some will may argue that Outlook for REST API is not the recommended version anymore. This is also communicated by Microsoft, when you look at the banner.
This might be true for any application your developing, but I can tell you that Outlook – doesn’t matter for Windows or Macs – is using this in both protocols: EWS and REST.
I had quite some cases open with Microsoft and meanwhile a lot of issues have been solved.
If your vendor does not yet support this, we’ve identified the following as the only workaround:
Create for every geo-satellite a dedicated account and use this in your application.
Of course, this brings a lot of administrative effort and overhead with as you now must make sure the right account is used for the right mailboxes.
When you have deployed in your environment UM services, you might have to check if some of your users are in one of the following countries located:
These locations have local regulations, which doesn’t allow Microsoft to provide this feature. This might change for locations – I think there was New Zealand also listed -, but Unified Messaging in Exchange Online is anyways retiring: Retiring Unified Messaging in Exchange Online
Therefore, you either have the choice to migrate these users and don’t give them UM or switch to Cloud Voicemail. But something you must consider and plan for your migration as this can delay your projects.
The more mailboxes you have moved to Exchange Online, the less resources and therefore less servers you will need to keep on-premises. Thus, is in general correct and reduces administrative effort e.g.: HW maintenance, patching etc.
But there can be certain clients, which can impact your remaining environment and therefore also all other users, which have their mailboxes already in Exchange Online.
As long as you have a single mailbox on-premises, you have to point Autodiscover to on-premises endpoint. When now your servers cannot respond to your clients, these clients won’t be able to find the correct endpoint.
You can read more about the issue on my blog here. You don’t have to run into the same issue necessarily but bear in mind that you have to monitor your remaining server’s health and resources closely.
You can plan for many things, but sometimes issues, which are causing delays for your project, pops up from side you never thought about. I can only urge you to check whether your vendors support X-AnchorMailbox header in their products as this is most likely something you will run into rather than the UM topic. But if you have UM, it might be a good idea to check your users UsageLocation attribute.
I’m still collecting glitches and will continue to share them.
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.