Data Residency for Exchange Online
Data Residency Commitments Available
Tenant has a sign up country/region included in Local Region Geography, the European Union or the United States.
For current language please refer to the Privacy and Security Product Terms webpage and view the section titled "Location of Customer Data at Rest for Core Online Services".
If Customer provisions its tenant in Australia, Brazil, Canada, the European Union, France, Germany, India, Japan, Norway, Qatar, South Africa, South Korea, Sweden, Switzerland, United Arab Emirates, United Kingdom, or United States, Microsoft will store the following Customer Data at rest only within that Geo: Exchange Online mailbox content (e-mail body, calendar entries, and the content of e-mail attachments)
Advanced Data Residency add-on
- Tenant has a sign-up country/region included in Local Region Geography or Expanded Local Region Geography.
- Tenant has a valid Advanced Data Residency subscription for all users in the tenant
- The Exchange Online subscription customer data is provisioned in Local Geography or Expanded Local Geography
Please refer to the ADR commitment page to understand the specific commitments provided via Product Terms. Examples of the committed data include: all types of mailboxes, including user mailboxes, resource mailboxes, and archive mailboxes.
- Tenants have a valid Multi-Geo subscription that covers all users assigned to a Satellite Geography.
- Customer must have an active Enterprise Agreement.
- Total purchased Multi-Geo units must be greater than 5% of the total eligible seats in the tenant.
Customers may assign a Satellite Geography supported by Multi-Geo to a supported mailbox type. See the Microsoft 365 Multi-Geo availability section of the Microsoft 365 Multi-Geo page for details. The Data at Rest for Office 365 Services for the mailbox as defined by the product terms shall be stored in the assigned Satellite Geography. Supported mailbox types includes Exchange Online user primary and archive mailboxes, resource mailboxes, Microsoft 365 Group mailboxes, and shared mailboxes.
Multi-Geo Capabilities in Exchange Online
Customers may assign a Satellite Geography supported by Multi-Geo to a user. See the Microsoft 365 Multi-Geo availability section of the Microsoft 365 Multi-Geo page for details. The user's Data at Rest for Office 365 Services as defined by the product terms shall be stored in the assigned Satellite Geography. This includes all types of Exchange Online mailboxes, including user mailboxes, resource mailboxes, Microsoft 365 Group mailboxes, shared mailboxes, and archive mailboxes.
You can place mailboxes in Satellite Geography locations by:
- Creating a new Exchange Online mailbox directly in a Satellite Geography location.
- Moving an existing Exchange Online mailbox to a Satellite Geography location by changing the user's preferred data location.
- Onboarding a mailbox from an on-premises Exchange organization directly into a Satellite Geography location.
Mailbox placement and moves
After Microsoft completes the prerequisite Multi-Geo configuration steps, Exchange Online will honor the PreferredDataLocation attribute on user objects in Azure AD. Exchange Online synchronizes the PreferredDataLocation property from AAD into the MailboxRegion property in the Exchange Online directory service. The value of MailboxRegion determines the Macro Region Geography or Local Region Geography where user mailboxes and any associated archive mailboxes will be placed. It is not possible to configure a user's primary mailbox and archive mailboxes to reside in different Geography locations. Only one Macro Region Geography or Local Region Geography may be configured per user object.
- When PreferredDataLocation is configured on a user with an existing mailbox, the mailbox will be put into a relocation queue and automatically moved to the specified Macro Region Geography or Local Region Geography.
- When PreferredDataLocation is configured on a user without an existing mailbox, when you provision the mailbox, it will be provisioned into the specified Macro Region Geography or Local Region Geography.
- When PreferredDataLocation is not specified on a user, when you provision the mailbox, it will be provisioned in the Primary Provisioned Geography.
- If the PreferredDataLocation code is incorrect (e.g. a typo of NAN instead of NAM), the mailbox will be provisioned in the Primary Provisioned Geography.
Multi-geo capabilities and Skype for Business Online regionally hosted meetings both use the PreferredDataLocation property on user objects to locate services. If you configure PreferredDataLocation values on user objects for regionally hosted meetings, the mailbox for those users will be automatically moved to the specified Macro Region Geography or Local Region Geography after Multi-Geo is enabled on the Microsoft 365 tenant.
Feature limitations for Multi-Geo in Exchange Online
- Security and compliance features (for example, auditing and eDiscovery) that are available in the Exchange admin center (EAC) aren't available in Multi-Geo organizations. Instead, you need to use the Microsoft 365 Security & Compliance Center to configure security and compliance features.
- Outlook for Mac users may experience a temporary loss of access to their Online Archive folder while you move their mailbox to a new Geography location. This condition occurs when the user's the primary and archive mailboxes are in different Geography locations, because cross-geo mailbox moves may complete at different times.
- Users can't share mailbox folders across Geography locations in Outlook on the web (formerly known as Outlook Web App or OWA). For example, a user in the European Union can't use Outlook on the web to open a shared folder in a mailbox that's located in the United States. However, Outlook on the Web users can open other mailboxes in different Geography locations by using a separate browser window as described in Open another person's mailbox in a separate browser window in Outlook Web App.
Cross-geo mailbox folder sharing is supported in Outlook on Windows.
- Public folders are supported in Multi-Geo organizations. However, the public folders must remain in the Primary Provisioned Geography location. You can't move public folders to satellite geo locations.
- In a Multi-Geo environment, cross-geo mailbox auditing is not supported. For example, if a user is assigned permissions to access a shared mailbox in a different Geography location, mailbox actions performed by that user are not logged in the mailbox audit log of the shared mailbox. Exchange admin audit events are also only available for the default location. For more information, see Manage mailbox auditing.
Administering Exchange Multi-Geo
Administering Exchange Online mailboxes in a Multi-Geo environment
Exchange Online PowerShell is required to view and configure Multi-Geo properties in your Microsoft 365 environment. To connect to Exchange Online PowerShell, see Connect to Exchange Online PowerShell.
You need the Microsoft Azure Active Directory PowerShell Module v188.8.131.52 or later in v1.x to see the PreferredDataLocation property on user objects. User objects synchronized via AAD Connect into AAD cannot have their PreferredDataLocation value directly modified via AAD PowerShell. Cloud-only user objects can be modified via AAD PowerShell. To connect to Azure AD PowerShell, see Connect to PowerShell.
In Exchange Online Multi-Geo environments, you don't need to do any manual steps to add Geographies to your tenant. After you receive the Message Center post that says multi-geo is ready for Exchange Online, all available Geographies will be ready and configured for you to use.
Connect directly to a geo location using Exchange Online PowerShell
Typically, Exchange Online PowerShell will connect to Primary Provisioned Geography location. But, you can also connect directly to Satellite Geography locations. Because of performance improvements, we recommend connecting directly to the Satellite Geography location when you only manage users in that location.
The requirements for installing and using the Exchange Online PowerShell module are described in Install and maintain the Exchange Online PowerShell module.
To connect Exchange Online PowerShell to a specific Geography location, the ConnectionUri parameter is different than the regular connection instructions. The rest of the commands and values are the same.
Specifically, you need to add the ?email=<emailaddress> value to end of the ConnectionUri value. <emailaddress> is the email address of any mailbox in the target Geography location. Your permissions to that mailbox or the relationship to your credentials are not a factor; the email address simply tells Exchange Online PowerShell where to connect.
Microsoft 365 or Microsoft 365 GCC customers typically don't need to use the ConnectionUri parameter to connect to Exchange Online PowerShell. But, to connect to a specific Geography location, you do need to use ConnectionUri parameter so you can use ?email=<emailaddress> in the value.
Connect to a Geography location in Exchange Online PowerShell
The following connection instructions work for accounts that are or aren't configured for multi-factor authentication (MFA).
- In a Windows PowerShell window, load the EXO V2 module by running the following command:
- In the following example, firstname.lastname@example.org is the admin account, and the target geo location is where the mailbox email@example.com resides.
Connect-ExchangeOnline -UserPrincipalName firstname.lastname@example.org -ConnectionUri https://email@example.com
- Enter the password for the firstname.lastname@example.org in the prompt that appears. If the account is configured for MFA, you also need to enter the security code.
View the available Geography locations that are configured in your Exchange Online organization
To see the list of configured Geography locations in Microsoft 365 Multi-Geo, run the following command in Exchange Online PowerShell:
Get-OrganizationConfig | Select -ExpandProperty AllowedMailboxRegions | Format-Table
View the Primary Provisioned Geography location for your Exchange Online organization
To view your tenant's Primary Provisioned Geography location, run the following command in Exchange Online PowerShell:
Get-OrganizationConfig | Select DefaultMailboxRegion
Find the Geography location of a mailbox
The Get-Mailbox cmdlet in Exchange Online PowerShell displays the following multi-geo related properties on mailboxes:
- Database: The first 3 letters of the database name correspond to the Geography code, which tells you where the mailbox is currently located. For Online Archive Mailboxes the ArchiveDatabase property should be used.
- MailboxRegion: Specifies the Geography location code that was set by the admin (synchronized from PreferredDataLocation in Azure AD).
- MailboxRegionLastUpdateTime: Indicates when MailboxRegion was last updated (either automatically or manually).
To see these properties for a mailbox, use the following syntax:
Get-Mailbox -Identity <MailboxIdentity> | Format-List Database,MailboxRegion*
For example, to see the Geography location information for the mailbox email@example.com, run the following command:
Get-Mailbox -Identity firstname.lastname@example.org | Format-List Database, MailboxRegion*
The output of the command looks like this:
Database : EURPR03DG077-db007 MailboxRegion : EUR MailboxRegionLastUpdateTime : 2/6/2018 8:21:01 PM
If the Geography location code in the database name doesn't match MailboxRegion value, the mailbox will be automatically be put into a relocation queue and moved to the Geography location specified by the MailboxRegion value (Exchange Online looks for a mismatch between these property values).
Move an existing cloud-only mailbox to a specific geo location
A cloud-only user is a user not synchronized to the tenant via AAD Connect. This user was created directly in Azure AD. Use the Get-MsolUser and Set-MsolUser cmdlets in the Azure AD Module for Windows PowerShell to view or specify the Geography location where a cloud-only user's mailbox will be stored.
To view the PreferredDataLocation value for a user, use this syntax in Azure AD PowerShell:
Get-MsolUser -UserPrincipalName <UserPrincipalName> | Format-List UserPrincipalName,PreferredDataLocation
For example, to see the PreferredDataLocation value for the user email@example.com, run the following command:
Get-MsolUser -UserPrincipalName firstname.lastname@example.org | Format-List
To modify the PreferredDataLocation value for a cloud-only user object, use the following syntax in Azure AD PowerShell:
Set-MsolUser -UserPrincipalName <UserPrincipalName> -PreferredDataLocation <GeoLocationCode>
For example, to set the PreferredDataLocation value to the European Union (EUR) geo for the user email@example.com, run the following command:
Set-MsolUser -UserPrincipalName firstname.lastname@example.org -PreferredDataLocation EUR
As mentioned previously, you cannot use this procedure for synchronized user objects from on-premises Active Directory. You need to change the PreferredDataLocation value in Active Directory and synchronize it using AAD Connect. For more information, see Azure Active Directory Connect sync: Configure preferred data location for Microsoft 365 resources.
How long it takes to relocate a mailbox to a new geo location depends on several factors:
- The size and type of mailbox.
- The number of mailboxes being moved.
- The availability of move resources.
Move an inactive mailbox to a specific Geography
You can't move inactive mailboxes that are preserved for compliance purposes (for example, mailboxes on Litigation Hold) by changing their PreferredDataLocation value. To move an inactive mailbox to a different Geography, do the following steps:
Recover the inactive mailbox. For instructions, see Recover an inactive mailbox.
Prevent the Managed Folder Assistant from processing the recovered mailbox by replacing <MailboxIdentity> with the name, alias, account, or email address of the mailbox and running the following command in Exchange Online PowerShell:
Set-Mailbox <MailboxIdentity> -ElcProcessingDisabled $true
Assign an Exchange Online Plan 2 license to the recovered mailbox. This step is required to place the mailbox back on Litigation Hold. For instructions, see Assign licenses to users.
Configure the PreferredDataLocation value on the mailbox as described in the previous section.
After you've confirmed that the mailbox has moved to the new geo location, place the recovered mailbox back on Litigation Hold. For instructions, see Place a mailbox on Litigation Hold.
After verifying that the Litigation Hold is in place, allow the Managed Folder Assistant to process the mailbox again by replacing <MailboxIdentity> with the name, alias, account, or email address of the mailbox and running the following command in Exchange Online PowerShell:
Set-Mailbox <MailboxIdentity> -ElcProcessingDisabled $false
Make the mailbox inactive again by removing the user account that's associated with the mailbox. For instructions, see Delete a user from your organization. This step also releases the Exchange Online Plan 2 license for other uses.
Note: When you move an inactive mailbox to a different geo location, you might affect content search results or the ability to search the mailbox from the former geo location. For more information, see Searching and exporting content in Multi-Geo environments.
Create new cloud mailboxes in a specific Geography location
To create a new mailbox in a specific Geographic location, you need to do either of these steps:
Configure the PreferredDataLocation value as described in the previous Move an existing cloud-only mailbox to a specific Geographic location section before you create the mailbox in Exchange Online. For example, configure the PreferredDataLocation value on a user before you assign a license.
Assign a license at the same time you set the PreferredDataLocation value.
To create a new cloud-only licensed user (not AAD Connect synchronized) in a specific Geographic location, use the following syntax in Azure AD PowerShell:
New-MsolUser -UserPrincipalName <UserPrincipalName> -DisplayName "<Display Name>" [-FirstName <FirstName>] [-LastName <LastName>] [-Password <Password>] [-LicenseAssignment <AccountSkuId>] -PreferredDataLocation <GeoLocationCode>
This example create a new user account for Elizabeth Brunner with the following values:
- User principal name: email@example.com
- First name: Elizabeth
- Last name: Brunner
- Display name: Elizabeth Brunner
- Password: randomly-generated and shown in the results of the command (because we're not using the Password parameter)
- Location: Australia (AUS)
New-MsolUser -UserPrincipalName firstname.lastname@example.org -DisplayName "Elizabeth Brunner" -FirstName Elizabeth -LastName Brunner -LicenseAssignment contoso:ENTERPRISEPREMIUM -PreferredDataLocation AUS
For more information about creating new user accounts and finding LicenseAssignment values in Azure AD PowerShell, see Create user accounts with PowerShell and View licenses and services with PowerShell.
If you are using Exchange Online PowerShell to enable a mailbox and need the mailbox to be created directly in the Geographic location that's specified in PreferredDataLocation, you need to use an Exchange Online cmdlet such as Enable-Mailbox or New-Mailbox directly against the cloud service. If you use the Enable-RemoteMailbox cmdlet in on-premises Exchange PowerShell, the mailbox will be created in the Primary Provisioned Geography location.
Onboard existing on-premises mailboxes in a specific Geography location
You can use the standard onboarding tools and processes to migrate a mailbox from an on-premises Exchange organization to Exchange Online, including the Migration dashboard in the EAC, and the New-MigrationBatch cmdlet in Exchange Online PowerShell.
The first step is to verify a user object exists for each mailbox to be onboarded, and verify the correct PreferredDataLocation value is configured in Azure AD. The onboarding tools will respect the PreferredDataLocation value and will migrate the mailboxes directly to the specified geo location.
Or, you can use the following steps to onboard mailboxes directly in a specific Geographic location using the New-MoveRequest cmdlet in Exchange Online PowerShell.
Verify the user object exists for each mailbox to be onboarded and that PreferredDataLocation is set to the desired value in Azure AD. The value of PreferredDataLocation will be synchronized to the MailboxRegion attribute of the corresponding mail user object in Exchange Online.
Connect directly to the specific Satellite Geography location using the connection instructions from earlier in this topic.
In Exchange Online PowerShell, store the on-premises administrator credentials that's used to perform a mailbox migration in a variable by running the following command:
$RC = Get-Credential
In Exchange Online PowerShell, create a new New-MoveRequest similar to the following example:
New-MoveRequest -Remote -RemoteHostName mail.contoso.com -RemoteCredential $RC -Identity email@example.com -TargetDeliveryDomain <YourAppropriateDomain>
Repeat step #4 for every mailbox you need to migrate from on-premises Exchange to the satellite geo location you are currently connected to.
If you need to migrate additional mailboxes to different satellite geo locations, repeat steps 2 through 4 for each specific location.
The multi-geo reporting feature is currently in Preview, is not available in all organizations, and is subject to change.
Multi-Geo Usage Reports in the Microsoft 365 admin center displays the user count by Geographic location. The report displays user distribution for the current month and provides historical data for the past 6 months.
Because it takes time to move each user to the new datacenter Geography for a single tenant, some users will still be in the old datacenter Geography during the move, while others will be in the new datacenter Geography. This means that some features that involve accessing multiple mailboxes may not fully work during a period of the move process, which can last weeks. These features are described in the following sections.
Open "Shared Folder" in Outlook Web Access
Some users open a shared mail folder from another mailbox (that the user has read or write permissions to) in Outlook Web Access using the "Shared Folder" feature. The following table describes how access to shared folders works during a mailbox move. Please note that users with full permissions to a shared mailbox can open the mailbox by using Outlook Web Access during the move.
|User has mailbox folder permission to another mailbox
If User A and Mailbox B aren't in the same Geography during the tenant move, User A can't open Mailbox B's folder in Outlook Web Access if User A only has permission to a specific folder in Mailbox B.
To add a shared folder, right-click the user name in the left navigation panel and select Add shared folder.
|User with full mailbox permission to another mailbox
If User A has "Full Access" permission to Mailbox B, then User A can click the shared folder in the left navigation panel in Outlook Web Access to open a window showing Mailbox B. A user can open a shared mailbox using Outlook Web Access during the move without any adverse impact. The limitation only applies to folder-level sharing in a mailbox.
The process of email data migration to Microsoft 365 during the Exchange Online is a common scenario and is supported. Cloud migration between datacenter geos does not interfere with any on-premises to cloud mailbox migrations.
How can I determine customer data location?
You can find the actual data location in Tenant Admin Center. As a tenant administrator you can find the actual data location, for committed data, by navigating to Admin->Settings->Org Settings->Organization Profile->Data Location.