Avoid Compliance Nightmares with Microsoft 365 Multi-Geo
Many organizations have data residency requirements. With Microsoft 365 Multi-Geo, organizations can fully embrace the cloud while meeting strict compliance regulations for data location. This article gives administrators a primer on the setup and pitfalls to avoid for Microsoft Multi-Geo.
A Brief History
Before the introduction of Microsoft 365 Multi-Geo, multinational companies around the world who have offices residing in countries with data residency laws were forced to keep SharePoint and Exchange servers on-premises for sensitive data while using the core functions of Office 365 for data that is not sensitive. This is because some countries specifically state that certain data must stay within the country, such as the Personally Controlled Health Records Act of 2012 in Australia, which ensures that all personal medical information is stored locally. France and Germany have strict data residency laws, meaning all data produced by local and national public administrations must be stored within the country’s borders. Germany advocates the idea of national clouds so that all accounting data is held within the country. Microsoft previously had the dedicated Black Forest region, which was used exclusively for German tenants, this was closed in favor of a more regular Office 365 data center.
With Microsoft 365 Multi-Geo, companies can move some of the core Office 365 to different data centers, which allow companies to meet data residency requirements with multi-Office 365 locations within their tenant around the world. Since its release, the following services are enabled for Microsoft 365 Multi-Geo:
- Exchange Online
- SharePoint
- Teams
- OneDrive for Business
Microsoft 365 Multi-Geo Terminology
It should be noted that there is certain terminology used when discussing Microsoft 365, this list includes the following:
- Central location – The location of your tenant.
- Geo code – the three-letter code for geolocation such as APC, EUR, or JPN.
- Geolocation – A location that can be used in a multi-geo tenant to host data, including Exchange mailboxes, Teams, OneDrive, and SharePoint sites.
- Preferred Data Location (PDL) – The user property that is set by the admin that determines where the user’s data resides. The PDL can also determine the data location for a SharePoint site.
- Satellite location – The geolocation where M365 workloads are enabled in a Multi-Geo enabled tenant.
- Geo administrator – The role given to an administrator who can migrate users or SharePoint data from one Geolocation to another.
Microsoft 365 Multi-Geo Locations
The locations that are enabled for M365 Multi-Geo can be found here: https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-multi-geo?view=o365-worldwide#microsoft-365-multi-geo-availability
Microsoft 365 Multi-Geo Requirements
To be able to purchase Microsoft 365 Multi-Geo licenses, the following requirements need to be met:
- A Minimum of 250 Microsoft 365 seats in the tenant with at least 5% of those seats using multi-geo.
- The following licenses are also needed alongside the Microsoft 365 Multi-Geo Licenses
- Microsoft 365 F1, F3, E3, or E5
- Office 365 F3, E1, E3, or E5
- Exchange Online Plan 1 or Plan 2
- OneDrive for Business Plan 1 or Plan 2
- SharePoint Online Plan 1 or Plan 2
- If users are synchronized from On-Prem AD, the Active Directory schema should be uplifted to 2019. To find out your schema version, please use the following PowerShell command:
Get-ItemProperty 'AD:\CN=Schema,CN=Configuration,DC=contoso,DC=local' -Name objectVersion
Microsoft 365 Multi-Geo Migration Steps
It is recommended that to migrate users to other PDLs, the following steps should be taken in order:
- Acquire Correct Licensing
- Create Satellite Locations
- Set User’s PDL
- Migrate User’s OneDrive
- Migrate SharePoint sites
Cybersecurity Risk Management for Active Directory
Discover how to prevent and recover from AD attacks through these Cybersecurity Risk Management Solutions.
Acquire Correct Licensing
The first step is to ensure that the correct licensing has been purchased and assigned to the users who will be using M365 Multi-Geo. This will then enable the Geo Locations tab in the SharePoint Online Admin Center.
Create Satellite Locations
After assigning the correct licensing, to create a Satellite Location, you will need to navigate to SharePoint Online Admin Center, Advanced then Geo Locations, here you will see a map with your Central Location and Satellite Locations highlighted. It should be noted that even if you have no SharePoint sites that need migrating, the Satellite locations must be created here (Figure 1):
![A Microsoft 365 Multi-Geo Primer for Admins](https://s40823.pcdn.co/wp-content/uploads/2022/07/figure-1.png)
In Figure 1, we have one Central Location (North America) and 4 Satellite locations (Canada, United Kingdom, Germany, and EMEA). To add a new Satellite Location, click on Add Location which brings up a new side menu (Figure 2):
![A Microsoft 365 Multi-Geo Primer for Admins](https://s40823.pcdn.co/wp-content/uploads/2022/07/figure-2.png)
Clicking a location and then pressing next will create a new location within 72 hours.
Setting a User’s PDL
There are two ways to set a user’s PDL and they depend on the source anchor of the user’s account. If the user account source anchor is an on-premises Active Directory and if the Active Directory schema has been uplifted to 2019, the PreferredDataLocation attribute must be updated with the three-letter Geo-Code. This can be done using ADSI Edit or the following PowerShell command:
Azure AD Connect must also be updated to include the PreferredDataLocation attribute. Do this by adding the attribute to the Azure AD connector in Azure AD Connect (Figure 3):
![A Microsoft 365 Multi-Geo Primer for Admins](https://s40823.pcdn.co/wp-content/uploads/2022/07/figure-3.png)
If the user account is homed in Azure AD, the following PowerShell can be run, it should be noted that the PreferredDataLocation cannot be updated in MS Graph API at the time of writing this article:
Connect-MsolOnline
Set-MsolUser -UserPrincipalName <UserPrincipalName> -PreferredDataLocation <GeoLocationCode>
It is worth noting that when a user’s PDL is populated, it automatically queues the migration of the user’s Exchange mailbox to the PDL. If the user account is created with a PDL populated, the Exchange mailbox is created in the PDL location. To create a user with a PDL already assigned, you will need to assign the PDL to the user before an Exchange license has been assigned to it. This can be done by populating the Geocode in the PreferredDataLocation field in Active Directory or via this command line using Azure Active Directory PowerShell:
Connect-MsolOnline
Set-MsolUser -UserPrincipalName <UserPrincipalName> -PreferredDataLocation <GeoLocationCode>
Working with SharePoint
When a new Satellite location is created, a brand-new SharePoint namespace is created, for example, if a Satellite location was created in the United Kingdom, the previous SharePoint URL of https://contoso.sharepoint.com will be appended with GBR, so it will change to https://contosogbr.sharepoint.com this is also the case for the admin center. This means policies for unmanaged devices and restricting SharePoint site content can be changed per site.
Migrating SharePoint Sites
Unlike Exchange Online where mailboxes are migrated automatically when a user’s PDL is set, SharePoint Sites need to be migrated manually. There are two ways to migrate SharePoint data from one Satellite location to another, depending on if the SharePoint site is group-enabled. If the site is group-enabled, see the Teams section below, for sites that are not group-enabled, the script below should be run. In this scenario, we are migrating the Turbines site from the Central Location to the GBR satellite location:
Connect-SPOService -URL https://contosohealthcare-admin.sharepoint.com
Start-SPOSiteContentMove -SourceSiteUrl https://contosohealthcare-admin.sharepoint.com/sites/Turbines -DestinationDataLocation GBR
The cmdlet responds to confirm that the migration has started (Figure 4):
![A Microsoft 365 Multi-Geo Primer for Admins](https://s40823.pcdn.co/wp-content/uploads/2022/07/figure-4.png)
SharePoint site migrations can be done in bulk by creating a .CSV with two headings SourceSiteUrl and DestinationDataLocation, for example (Figure 5):
![A Microsoft 365 Multi-Geo Primer for Admins](https://s40823.pcdn.co/wp-content/uploads/2022/07/figure-5.png)
Then use the following script:
#This script is to update the PDL of a SharePoint site that has no Microsoft 365 Group attached to it
Connect-SPOService -URL https://contosohealthcare-admin.sharepoint.com
Import-CSV SharePointPDL.csv | ForEach {Start-SPOSiteContentMove -SourceSiteUrl $_.SourceSiteUrl -ValidationOnly -DestinationDataLocation $_.DestinationDataLocation}
Microsoft Teams
The following data in Teams is Multi-Geo aware:
- User Chat:
- One to One – A conversation with one person will be hosted in the location of the PDL who initiated the chat.
- One to Many – A group conversation will be hosted in the location of the PDL of the person who created the chat
- Private Meeting – Scheduled Meetings in Teams where the chat function has been used. The storage data for meeting chat is based on the PDL of the person who organized the meeting.
It should be noted that if the PDL of the user’s chat data is changed, the chat data will be migrated automatically to the new Geo-Location.
But with Channel messages, both Public and Private channel data is hosted in the PDL of the Microsoft 365 Group.
To set the PDL of a Microsoft 365 group and migrate the SharePoint site owned by the group, the following PowerShell should be run:
Connect-SPOService -URL https://contosohealthcare-admin.sharepoint.com
Set-SPOUnifiedGroup -PreferredDataLocation <PDL> -GroupAlias <GroupAlias>
Get-SPOUnifiedGroup -GroupAlias <GroupAlias>
Start-SPOUnifiedGroupMove -GroupAlias <GroupAlias> -DestinationDataLocation <DestinationDataLocation>
To migrate a Microsoft 365 Group in bulk, the following can be used after creating a .csv with the two headers PreferredDataLocation and GroupAlias:
Connect-SPOService -URL https://contosohealthcare-admin.sharepoint.com
Import-CSV TeamSitePDL.csv | ForEach {Set-SPOUnifiedGroup -PreferredDataLocation $_.PreferredDatalocation -GroupAlias $_.GroupAlias}
Import-CSV TeamSitePDL.csv | ForEach {Get-SPOUnifiedGroup -GroupAlias $_.GroupAlias}
Import-CSV TeamSitePDL.csv | ForEach {Start-SPOUnifiedGroupMove -GroupAlias $_.GroupAlias -DestinationDataLocation $_.PreferredDatalocation}
To view the Geo Location of a Microsoft 365 group, the following should be run:
Get-MultiGeoRegion -EntityType Group -EntityId <GroupObjectId>
Conclusion
Once the licensing has been purchased, setting up Microsoft 365 Multi-Geo is straightforward. If your organization has data residency issues, get enrolled with Microsoft 365 Multi-Geo as soon as possible.
How about the “Advanced Data Residency” add-on subscription/license to Microsoft 365? Our local region is UK but we had an older tenant which was hosted in European Union, and we missed the free move offer. So we purchased ADR licenses for all users and requested the tenant to be moved – which happened after some 6 months. What we haven’t been able to find out is whether we can now end the ADR subscription, or have to keep subscribing to it indefinitely to ensure that the tenant is not suddenly moved back to the EU? I have not been able to get an answer to this via our Microsoft reseller or support – I just get pointed back to the same documents in Microsoft Learn which do not have an answer to this.
The Real Person!
The Real Person!
The answer is that I don’t know. But I doubt that Microsoft will suddenly move data from the UK datacenter region to the EMEA datacenter region without good reason. Once the data is in a region, it stays there. The feeling I have is based on Microsoft SOP for datacenter operations, but I would seek confirmation from Microsoft.
What is the Multi-Geo licenses add-on? I can’t seem to find it
You have to purchase them via a partner or via Microsoft on an Enterprise Agreement or CSP.
Great article. One question….MS state Multi-Geo is only available to EA customers, along with the other requirements. I dont see this referenced in the article above? Can Mutli-Geo licenses therefore just be purchased, perhaps through CSP and used without a company having an EA? Cheers.
Hi Matt. The requirement for EA was dropped in June this year, I have a couple of CSP customers that are now deploying Multi-Geo.
When a Geo-Located user leaves the company, does the Geo license automatically get returned to the “shelf” for use on another user needing Geo-location ?
When a Geo-Located user leaves the company, the the Geo license automatically returned to the “shelf” for use on another user needing Geo-location ?
Hi Thinesh,
the MailboxRegion attribute is part of the mailbox and visible with Get-Mailbox
Get-Mailbox -Identity | Format-List Database,MailboxRegion*
Is there any powershell comments or graph api to get preferred data location of shared mailbox