Designing Microsoft 365 Multi‑Geo for Regional Data Residency: An Architecture Note

Requirements

Regulatory frameworks in many countries now mandate that electronically stored data must reside within defined geographic boundaries. In Microsoft 365, the Multi‑Geo feature allows a single tenant to satisfy these constraints by assigning a Preferred Data Location (PDL) to each mailbox, OneDrive for Business account, and Exchange Online mailbox. The key requirements for a compliant design are:

• All users that must meet local residency rules are assigned a PDL that matches the jurisdiction.
• Data migration to the designated location is completed before the user becomes productive.
• Cross‑geo collaboration remains functional; users can share files and mail across PDLs without being blocked.
• Compliance reporting can confirm that data is stored in the intended region.
• The solution stays within a single Microsoft 365 tenant to avoid the operational overhead of managing multiple tenants.

Minimal Suitable Design

The simplest architecture that satisfies the above requirements is a single tenant with the Multi‑Geo add‑on enabled. The design consists of three core components:

1. PDL Assignment – Each user’s mailbox and OneDrive account is tagged with a PDL via PowerShell or the Microsoft 365 admin center.
2. Migration Engine – Microsoft handles the physical movement of data asynchronously. Users are blocked from accessing their mailbox or OneDrive until the migration state reports Completed.
3. Compliance Dashboard – The Microsoft 365 Compliance Center exposes a Data Residency report that lists the physical location of each user’s data.

PDL Assignment Example

Run the following PowerShell commands in an account that has the Global Administrator role and the Multi‑Geo add‑on license. Replace <UPN> with the user’s UPN and <Region> with the ISO‑3166 region code (e.g., US-EAST, DE-AT).

# Connect to Azure AD
Connect-MsolService

# Set Preferred Data Location for a single user
Set-MsolUser -UserPrincipalName <UPN> -PreferredDataLocation <Region>

# Verify the assignment
Get-MsolUser -UserPrincipalName <UPN> | Select-Object UserPrincipalName, PreferredDataLocation

For Exchange‑only users, the same Set-MsolUser cmdlet applies. For SharePoint root sites, the PDL is inherited from the tenant and cannot be changed per site; they remain in the default location.

Trust & Data Boundaries

All data stays within Microsoft 365’s trust boundary, but the physical storage is partitioned by the PDL. This means:

• Encryption at rest is handled by Microsoft; there is no additional encryption needed for residency.
• Identity and authentication continue to use Azure AD, which is global. The PDL does not isolate identity or the global address list.
• Only the mailbox and OneDrive data are physically relocated; other services (e.g., Teams chat history, SharePoint root sites, Exchange Public Folders) may still live in the default location.

Operational Checks

To ensure the design is working as intended, perform the following checks:

• PDL Verification – Query the user object for the PreferredDataLocation attribute.

  Get-MsolUser -UserPrincipalName <UPN> | Select-Object UserPrincipalName, PreferredDataLocation
  

• Migration Status – Confirm that the mailbox or OneDrive migration has finished.

  Get-MsolUser -UserPrincipalName <UPN> | Select-Object UserPrincipalName, MigrationState
  

• Compliance Report – In the Microsoft 365 Compliance Center, open the Data Residency report and filter by the user’s UPN to see the actual storage region.
• Cross‑Geo Collaboration Test – Share a document from a user in US-EAST with a user in DE-AT and verify that the file opens without errors. Use the OneDrive sync client or SharePoint Online UI to confirm latency is acceptable.

Failure Modes & Design Pivot

The primary failure scenario is incorrect PDL assignment. If a user’s mailbox is left in the default region, the data residency requirement is violated. Detection is straightforward via the migration state and the PreferredDataLocation attribute.

Another failure mode is unsupported region. Multi‑Geo only supports a subset of global locations. Attempting to assign an unsupported <Region> will return an error and leave the user in the default location.

When either of these failures is detected, the design pivot is to move to a multi‑tenant architecture. A separate tenant per jurisdiction can enforce isolation of identity, the global address list, and all services. This is the only option if the compliance requirement mandates strict separation of identity and data.

Limitations & Caveats

• Multi‑Geo is an add‑on license and is not included in all standard M365 subscriptions.
• Data migration is asynchronous; users may experience temporary latency during the migration window.
• SharePoint root sites and certain global services remain in the default location; they cannot be moved via PDL.
• Cross‑geo sharing works, but large file transfers may be slower due to inter‑regional traffic.
• Identity and the global address list are shared across all PDLs; you cannot isolate them by region.

Always verify compliance after migration by running the Data Residency report and by sampling a few users’ mailbox and OneDrive locations. If any user shows the default region, re‑assign the PDL and monitor the migration state until it reports Completed.