At the recent Ignite conference Microsoft publicly unveiled their plans to allow Office 365 customers to place their data in specific geographic regions. They’re calling this capability “multi-geo”, and it will support Exchange Online, OneDrive, and SharePoint Online.
Microsoft has been working on this for more than 18 months and already has some early adopter customers using multi-geo today. If you want to get involved in the preview program you can reach out to your Microsoft account representative to find out more.
Data Residency Challenges for Multi-National Organizations
Historically the geographic location of Microsoft’s datacenters has caused problems for multi-national customers who need to meet different data residency requirements for the countries that they operate in. When you sign up for an Office 365 tenant, you need to choose the location that your tenant will be provisioned in. If you choose North America, all of your data is stored in North American datacenters. If you choose EMEA, your data is stored in European datacenters. Some countries have what Microsoft calls “go local” options as well, such as Australia and Japan, where a region is bound to a specific country, so you can specifically choose the country to locate your data in (previously our Australian data was stored in Asia Pacific, which has datacenters in Singapore and Hong Kong).
If your data residency needs did not allow all of the data for your organization to live in that one region or country, you were forced to either:
- Maintain on-premises infrastructure to service those regions that have data residency requirements
- Provision multiple, separate Office 365 tenants in the various regions that your organization operates in
Both options increase the complexity of your overall solution, requiring additional infrastructure and complicating your administrative scenarios. In the case of multiple Office 365 tenants, it also creates user experience problems such as not being able to use the same SMTP namespace in multiple tenants, friction for cross-tenant collaboration, and challenges with cross-tenant free/busy and calendar sharing.
Multi-geo aims to solve those problems by allowing customers to select where data is stored on a per-user basis. So if you have 10,000 staff in North America, and 5,000 staff in Australia, you can host the Exchange Online, OneDrive, and SharePoint Online data for the 10,000 NAM users in North America, and the 5,000 AUS users in Australia, but all within the same Office 365 tenant so you maintain all the benefits of a single SMTP namespace, single GAL, ease of administration, and ease of sharing and collaboration.
Multi-Geo Architecture
One of the benefits of cloud services is that we don’t need to worry about all the server and networking infrastructure that runs behind the scenes. However, it is interesting to know how Microsoft solves problems at the scale of Azure and Office 365. During Ignite the Microsoft presenters shared some information about how multi-geo works.
For Exchange Online, a regular tenant includes Azure AD services, an Exchange Online account forest, and an Exchange Online resource forest. The Azure AD service is global, something that has caused concern for customers I’ve spoken to in the past who view their data residency requirements as applying to Azure AD data (e.g. accounts, metadata, etc) as well as their other data (e.g. emails, documents, databases). Those customers seem to be in the minority though, and most customers seem happy with the current state of play for Azure AD as a global service.
![What to Expect from Multi-Geo for Office 365](https://www.practical365.com/wp-content/uploads/2017/10/office-365-multi-geo-exo-01.png)
Azure AD account information synchronizes with the Exchange Online account forest, which is local to a region. Mailbox data is stored in the Exchange Online resource forest, which is also local to a region. This account/resource forest model will be familiar to anyone who has worked with complex, multi-national organizations in the past which often designed their Exchange environments this way as a means of providing separation between different entities within the larger organization, as well as to simplify merger and divestiture scenarios.
When a customer is enable for multi-geo, their mailboxes for each geo that they enable in their tenant will be hosted in an Exchange Online resource forest for that geo. The account will be hosted in a “Cross Region Account Forest” (CRAF) that spans multiple geos so that each resource forest is able to communicate with directory infrastructure that is local to that geo, mitigating the risk of cross-geo networking issues impacting service.
![What to Expect from Multi-Geo for Office 365](https://www.practical365.com/wp-content/uploads/2017/10/office-365-multi-geo-exo-02.png)
OneDrive for Business and SharePoint Online work in a similar fashion, with geo-specific instances used to store user OneDrive data and SharePoint sites in the desired region.
![What to Expect from Multi-Geo for Office 365](https://www.practical365.com/wp-content/uploads/2017/10/office-365-multi-geo-spo-01.png)
Administration Changes for Multi-Geo
When your tenant is enabled for multi-geo there is no change to the location of your users’ data until you as the administrator drive that change. Microsoft does not move user data between regions automatically.
The first change is to enable the regions for your tenant that you will allow user data to reside in. After that, each user account is configured with a preferred data location (PDL). If no PDL is specified for an account, it defaults to the geo where your tenant was first created. If the PDL for an account is different to the geo where their data is currently located, Microsoft detects that and will initiate the move of the mailbox and OneDrive data for the user to their preferred geo. The PDL attribute is available in Azure AD now, and for customers using directory synchronization the current versions of Azure AD Connect will allow you to specify an on-premises attribute (such as CustomAttribute1) to store the PDL setting for synced user accounts.
As this is still a preview feature of Office 365 not all of the administrative tools are ready for multi-geo. An example provided during the Ignite presentation is that some Exchange Online cmdlets still need to be updated. The admin portals for OneDrive and SharePoint Online are also being updated to provide a selection menu for the regions you’ve enabled in your tenant, so that you can specify different policies and configurations for different regions.
![What to Expect from Multi-Geo for Office 365](https://www.practical365.com/wp-content/uploads/2017/10/office-365-multi-geo-onedrive-01.png)
Although the OneDrive and SharePoint approaches allow different policies per region, Exchange Online isn’t quite there. Mail flow and processing will behave the same as it always have, and features such as mail flow rules and retention policies are not currently able to be targeted at specific geos. It’s still possible to target mail flow rules to groups that represent specific regions, and assign retention policies for each user that matches the requirements of their geo, but that puts the onus on you as the administrator to align your targeting with the regions in your multi-geo tenant. Ideally in the future Exchange Online will have geo-targeting as a capability, which should make life easier for admins.
Multi-Geo User Experience
One of the key points throughout Microsoft’s presentations is that the user experience for multi-geo tenants is completely seamless. Users are not interrupted or inconvenienced by the migration of data from one geo to another, nor are they made to jump through extra hoops to collaborate with users in different regions. A single GAL is available to users in Outlook, and a single “people picker” for the entire organization is available in other apps such as OneDrive. To the user, there is no change from a single-geo tenant.
Of course, as an administrator you can apply different policies and restrictions to suit your needs, such as configuring different OneDrive sharing policies for each region. Users might notice that they can’t do something that their colleagues in other parts of the world can do. But that’s an impact that you are creating yourself due to your own requirements.
Is Multi-Geo for You?
Each of the Microsoft presenters at Ignite made it clear that multi-geo is designed to meet data residency requirements. It is not intended as a performance improvement. Performance problems with Office 365 services are most likely to be caused by network issues rather than the location of a user’s data. Moving data closer to the user might shave a few milliseconds off the latency, but Microsoft will not be recommending multi-geo as a performance solution nor should you expect to gain better performance by using multi-geo in your organization.
Early impressions are good, with customer case studies shown off during Ignite that demonstrated the benefits of multi-geo and the problems it has solved for those early adopter customers.
As of today, Exchange Online and OneDrive multi-geo are available in preview. Both are expected to reach general availability in the first half of 2018. SharePoint Online multi-geo is in development, expecting to reach preview in the first half of 2018 as well. There is no timeline for general availability of SharePoint Online multi-geo yet.
General availability is one thing, but whether multi-geo is available for all customers remains to be seen. Currently there is an application and approval process to be accepted in the preview program. Whether there is an approval step required after general availability is unknown. But it seems that multi-geo will not be something you can just turn on by yourself.
Licensing is also an unanswered question. I fully expect multi-geo to come at an additional cost to the existing Office 365 licenses.
There was no word on multi-geo for Microsoft Teams. Although multi-geo will work for Office 365 Groups, which presumably means that a team’s shared files will be stored in the appropriate geo, the actual Teams conversation data needs to be considered as well. Hopefully we’ll see announcements about this in the future.
For customers who have already deployed multiple tenants there is the question of how to migrate to a multi-geo tenant instead. For Exchange Online the solution might be simple thanks to announcements at Ignite about Microsoft developing the capability to easily move mailboxes between tenants, instead of relying on third party tools. OneDrive and SharePoint migrations might still rely on third party tools, until Microsoft looks at providing native solutions. These things tend to be demand-driven though, so unless it’s a major roadblock for a significant customer, we could be waiting for some time.
Multi-Geo Resources from Ignite
You can check out the Ignite sessions on multi-geo for Office 365 at the following links:
does Microsoft 365 E5 Developer package support the multi-geo. If yes pls elaborate the steps to add the multi-geo for my tenant. if NO, mention the subscription that I need to buy and cost of them. Thanks in Advance 🙂
Hi Paul,
I have one question about the way back to the central location. I know that the mailbox is moved back automaticaly when PDL changed.
Environment: Central location is EUR and one of our geo location is NAM
So now my question: When I remove the multi-geo license from a user that is located in NAM and change the PDL to EUR, what does happening with resources that do not move automaticaly like OneDrive?
I would say you’d have to manage the data before removing the license as the data would then be stored in the previous location, anything new would go to the default tenant location after the license was removed as Multi-Geo would no longer apply to that user???
When performing SPOUserAndContentMove getting an error “user move is not enabled for this tenant” Error Code 55. Can you please let me what might be an issue
After enabling multi-Geo, we have move the mailbox from EU to APAC
We have hit by the problem.
The Mobile email stop working with Blackberry Work and Native email Client connect via Active Sync Protocol and when we checked the attribute for APAC migrated users they have been hit by the attribute mismatch issue.
X-FEPROXY and X-Calculated BE-Target is still routing to Euro MS DC though the mailbox is hosted to APC MS DC.
‘
The case is open with MS from more than Month but no looks like they are struggling to find the root cause.
Just want to under if o365 tenant friending and Multi-Geo is the same. We are moving out to a local tenant in office365 and recently heard about o365 tenant friending. So wanted to know if can manage local tenants from single dashboard with a single Dir sync
what version of azure ad connect should be used to sync attribute from on prem AD to office365for multigeo ?
can i add two location to single user (like GBR and EUR both) with multigeo?
will this also allow to finally be able to change the country setting in O365, i.e. moving my company from EU to AUS , i need to change country and CC details. Only option so far is to set up a new account and delete old one , losing all the data if you don’t feel like exporting PSTs ( come on its 2018)
The Real Person!
The Real Person!
That is not the purpose of multi-geo. But tenant to tenant migrations can be performed without losing mailbox data, and without exporting to PST.
Can we do Direct migration from USA On-Prem to Canada OneDrive directly or we need to migrate from USA On-Prem to USA Cloud then move files from USA Cloud to Canada Cloud.
I want to make a script in which this task happens on the daily and weekly basis.
The Real Person!
The Real Person!
You can choose the country when you sign up to Office 365.
We have USA office 365 and now we added Office 365 Canada.
The Real Person!
The Real Person!
I don’t understand your question then. Are you trying to move from one tenant to another? That is a manual migration that you will need to perform yourself.
If you’re talking about multi-geo, setting the preferred data location (PDL) on the account is how you control where the data for that user will live.
Pingback: Containers & Microservices Change Security ; Jumpstart SharePoint Search; Multi-Geo Office 365