I was thinking about some of the features of Office 365 that would benefit our larger customers and saw an email from a colleague about Microsoft’s Ignite session on Multi-Geo.
Microsoft has been hard at work for the past few years to build out functionality in Office 365 to support regional data at rest service ability. It is now coming to the end of the journey, where soon (Q1 2018 – as of this writing) this service will be available for the general use (GA).
This is a major upgrade of the service for those companies that are international and need data at rest regional locations but would like the benefits of common Exchange Online services. Basically this means that Exchange mailboxes, OneDrive for Business data, and eventually SharePoint Online data can be moved between regions to serve companies that need Office 365 service data to reside in specific Office 365 regions.
This functionality will aid customers that have used Office 365 in multi-tenant configurations to support data at rest compliance.
Since the initial implementation of this service offering will concentrate in Exchange mailbox data, this article will concentrate on those changes and requirements to move Exchange mailbox data from region to region.
It has been made clear by Microsoft that this is not a follow me function to move data for those that travel within an organization. And it not necessarily a performance enhancement for regional data location.
Microsoft’s Exchange Online single-geo configuration:
Image content from here.
The back-end account and resource (Exchange) forests are contained in a single region.
Microsoft’s Exchange Online multi-geo configuration:
Image content from here.
The back-end account forest crosses all regions and is called the cross region account forest (CRAF).
I thought it would make it easier to understand the pre-release steps if I created a simple flow chart:
What I noticed right away is this item for PreferredDataLocation(PDL) and thought what is that? It is the data that makes a lot of the Multi-Geo function. We will get to that a bit later.
The tenant transition from a normal Account Forest to the Cross Region Account Forest (CRAF) will take some time. This time to convert could take hours to days based on current conversion timeframes and based on tenant size.
Exposed Cmdlets for PowerShell and Multi-Geo
Microsoft has given a list of the new cmdlets that would be used in conjunction with Multi-Geo:
1. Set-MsolCompanyMultiNationalEnabled -ServiceType “Servicetype” -Enable $true
- Set Multi-Geo for a particular service (Exchange, OneDrive for Business)
- Sets the default Geo to where your tenant is located
2. Set-MsolCompanyAllowedDataLocations -ServiceType “Servicetype” -Location “RegionCode”
- Adds additional Geos for particular Office 365 services
3. Get-MsolCompanyAllowedDataLocations
- Displays Multi-Geo configuration
PreferredDataLocation – AAD Connect Hybrid
Hybrid customers will need AAD Connect v1.1.524.0 or greater to sync the PDL data from on-premises to Office 365.
The PDL attribute is not extended into the on-premises Active Directory schema. Customers have to pick and configure an on-premises attribute to use. Examples given by Microsoft have been to map this to one of the CustomAttribute1-15.
The PDL value will need to be one of the regional values such as NAM (North America), EUR (Europe), AUS (Australia), JPN (Japan), APC (Asia Pacific), etc..
Hopefully Microsoft will change this when the service is released for general use and set-up AAD Connect to extend the schema and use a specific attribute.
Flow chart of how on-premises PDL attribute synchronizes to Exchange Online:
Mailboxes when they are in Exchange Online will be moved automatically based on the PDL information to the proper region. This happens when the “mailbox load balancing service” scans every 6 hours for mailboxes that are not in the correct region based on the PDL/MailboxRegion data.
The service will initiate a move request and the mailbox will move to the correct region location. These requests are not instantaneous and are queued in the back-end Exchange Online servers. These regional mailbox moves work like any other move and thus do not impact the end users during the move process.
Network considerations in Multi-Geo
It is highly recommended to think about network egress points for the client systems. If the customer centrally routes internet traffic to Office 365 then moving the data to a regional location will make the user experience less than optimal and force them to loop to the central egress point back to where their mailbox data resides in the region. Definitely think about implementing regional network egress points to support the quickest routes to the regional mailbox data.
Microsoft has been working very hard to provide this functionality for those customers who need regional data at rest. I think that this service would greatly simplify customers Office 365 configurations that are currently designing a multi-tenant solution. Or those customers that are deciding how to handle the data residency requirements for their Office 365 set-up.
Thanks for reading. Let me know what your thoughts are about this service.
Further information can be found here.
