What to Expect from Multi-Geo for Office 365

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.

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.

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.

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.

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:

• Understanding Multi-Geo Capabilities in Office 365
• Exchange Online Multi-Geo Capabilities
• Multi-Geo Capabilities in OneDrive and SharePoint Online