Set up and configure regionally hosted meetings in Skype for Business Online



This topic describes how to set up regionally hosted meetings for Skype for Business Online. Before you set up regionally hosted meetings for your organization, be sure to read Plan for regionally hosted meetings in Skype for Business Online.

Regionally hosted meetings is available for limited release only. For more information about the limited release, please contact your Microsoft representative.

To set up regionally hosted meetings, you will perform the following tasks:

Regionally hosted meetings are supported in the following locations: Asia Pacific, Australia, Canada, Europe, Japan, and North America. Users who are outside of these regions will be homed in a data center in the region closest to them; for example, the recommendation for users in the Middle East is to home them on a pool in a European data center.

You will need to update your Azure AD Connect deployment to version 1.1.524.0 or later to ensure you can store the three-digit codes representing the user's preferred data location (PDL) in your on-premises Active Directory.

If you are not yet using Azure AD Connect to connect your on-premises directory with Azure AD and Office 365, see Integrate your on-premises directories with Azure Active Directory and the Download Center.

Configuring your tenant for regionally hosted meetings requires Azure Active Directory PowerShell version or later. To verify your Azure AD PowerShell version, run the following cmdlet:

(Get-Item C:\Windows\System32\WindowsPowerShell\v1.0\Modules\MSOnline\Microsoft.Online.Administration.Automation.PSModule.dll).VersionInfo.FileVersion
If the installed version is older than v1.1.166.0, uninstall the current version, go to Download Details and install AdministrationConfig-V1.1.166.0-GA.msi.

To configure your tenant to support regionally hosted meetings, you will need to:

  1. Sign in to Office 365 as either a 商務用 Skype or Global administrator.

  2. Start Azure AD PowerShell as Administrator and specify the following:

    $cred = Get-Credential
    Connect-MsolService -Credential $cred
    $session = New-CsOnlineSession -Credential $cred -Verbose
    Import-PSSession $session
  3. Enable your tenant for regionally hosted meetings as follows:

    Set-MsolCompanyMultiNationalEnabled -ServiceType MicrosoftCommunicationsOnline -Enable $True
    After you run this cmdlet, you cannot disable or remove support for regionally hosted meetings from your tenant.

The allowed data location (ADL) table defines which regions are supported at the tenant level; that is, to which regions users can be moved. You populate the ADL table by specifying the three-digit codes that represent the supported regions.

The following table lists the supported regional codes and the regions to which they map:


Regional codes for allowed data location (ADL)

Regional mapping


Asia Pacific, India






Europe, Middle East, Africa




North America

To populate the ADL table, run the following Azure AD cmdlet one or more times for each non-default region:

Set-MsolCompanyAllowedDataLocation -ServiceType MicrosoftCommunicationsOnline -Location <regional code>
After you run this cmdlet, you cannot remove ADL entries from the ADL table. Therefore, it is recommended that you only enable regions that will be targets for cross region moves; for example, if you don’t have offices in Canada, don’t add CAN to the ADL.
You do not need to run this cmdlet with a regional code that represents the default region (the region your tenant is homed in). The default region is automatically set after the tenant is enabled for regionally hosted meetings.

To validate that the tenant is enabled for regionally hosted meetings and that the ADL is populated correctly, run the following cmdlet:

Get-CsTenant | fl IsMnc, AllowedDataLocation

The cmdlet lists all the allowed data locations and indicates the default region (Default=true).

After you have set up your tenant for multi-region support, you can move your users to the location of choice by specifying the preferred data location (PDL).

The preferred data location (PDL) is a three-digit regional code that corresponds to the values set in the allowed data location (ADL) table. The PDL is a user attribute that defines where a user will be moved to—assuming there is a match between the PDL and ADL values.

Note that the allowed data location must already be set for the preferred data location to take effect. For example, if the PDL is set to APC but the ADL only contains entries for EUR and NAM, the user won’t be moved, even though the PDL has been set.

The regional code for the PDL is stored in an unused attribute in the on-premises Active Directory—typically an empty extension attribute—which then gets synchronized to the PreferredDataLocation attribute in Azure Active Directory. Once the synchronization completes, the change in the PDL attribute initiates the cross region move within approximately ten minutes of the change or of the user being moved online.

You must have Azure AD Connect version 1.1.524.0 or later to support synchronization of the PreferredDataLocation attribute.

For details about how to sync PDL data between your on-premises Active Directory and Azure Active Directory, see Enable synchronization of PreferredDataLocation.

Setting an existing PDL value to null or blank will cause the user to be moved to the default region (defined as the region where the tenant is located). Keep the following in mind:
  • When a user is moved online, they are automatically assigned a blank PDL, indicating that the user is in the default region.

  • If a user is assigned an invalid PDL (that is, there isn’t a corresponding value in the allowed data location table), the user is moved to the default region.

Before moving any production users, it is recommended that you use PowerShell or the Skype for Business admin center to create test accounts for each region and scenario you want to validate.

For example, if users are currently homed in a Skype for Business Server 2015 pool with an Exchange Online mailbox, you may want to:

  1. Create the test accounts in the on-premises Active Directory.

  2. Create several recurring meetings with yourself as an attendee.

  3. Assign a Skype for Business Online license.

  4. Set the PDL attribute for the test accounts in the on-premises Active Directory

  5. Use Azure AD Connect to trigger a delta or full sync of the data.

  6. Run Move-CsUser to move the test accounts from on premises to online. Accounts are automatically moved cross region based on their PDL.

  7. Validate functionality of all workloads for the test accounts in each target region.

  8. Resolve any issues and either retest or move a small number of production users.

For both online-to-online cross region and on-premises-to-online moves, the user will be signed out of Skype for Business or unable to sign in during the move, which can take anywhere from one to five hours. Therefore, it is recommended that moves occur during non-business hours.

In this scenario, online users are moved cross region by setting the PDL for the target region in the on-premises Active Directory and triggering a delta sync using Azure AD Connect. Once the synchronization with Azure AD completes, the move is triggered within one to ten minutes—depending on when the provisioning service last ran.

There are two options for moving users from an on-premises environment to online:

  • Update the PDL, and then move users online.

  • Move users online, and then update the PDL.

For information about moving users from an on-premises environment to Skype for Business Online in general, see Move users to Skype for Business Online. Be aware, however, that the HostedMigrationOverrideUrl attribute is not valid for regionally hosted meetings. The Move-CsUser command will determine the right target region based on the specified preferred data location.

Move user options

If you are moving users from on-premises to online and cross region, and you want to move them directly to the target region, you should set the preferred data location to the target region a day before you move them online.

After setting the PDL for the target region in the on-premises Active Directory and triggering a delta sync using Azure AD Connect, wait at least 24 hours for replication to occur, and then run the Move-CsUser command to move the user to the target region (assuming the PDL has been synchronized online).

If you are moving a user from an on-premises environment to an online non-default region, be aware that the moved user's presence information will not be visible to users outside the moved user's region until on-premises attributes have replicated from the on-premises environment to Office 365. If this is a concern, you might want to move users online first, and then update the PDL, as described in the next section.
For example, has the allowed data locations NAM (Default), EUR, and APC. If a user is moved to APC by setting the preferred data location first, and then moving the user to online, users in NAM and EUR will not be able to see the moved user's presence until the Active Directory attributes have synced from the on-premises environment to online. The sync replication, which depends on the sync interval for Azure AD Connect and the backlog of changes in Office 365 for Skype for Business tenants, can take up to 8 hours.
To avoid presence unknown issues, users should be moved online in the default location first, and then moved to the desired data location by updating the preferred data location after 24 hours.

During the move, a user’s presence will change from a known state to “Presence Unknown,” and, once completed, will change back, usually to offline. It is possible to track progress of the cross region move and determine when it has completed by running the following Skype for Business Online cmdlet:

Get-CsUserLocationStatus -Identity <user id>

The cmdlet displays status information such as:

-UserLocationMoveState: InProgress
             -Details: Move from <DataLocation 1> to <DataLocation 2> is in progress

The meeting migration service (MMS) runs when there is a change to the Meet URL (which occurs when moving from on premises to online, but not when moving between regions) or when dial-in conferencing coordinates change. All unexpired meetings and new meetings will have updated information if any values change between regions.

The migration service runs after the user has been moved cross region and typically completes in ten to twelve minutes. If it is necessary to re-run MMS for a user, the following cmdlet will trigger it manually:

Start-CsExMeetingMigration -Identity <sipAddress>

To view status, you can run the following:

Get-CsMeetingMigrationStatus -Identity <sipAddress>
If the user’s mailbox is already online, there are no further requirements for the Meeting Migration Service to update meetings. If, however, the user’s mailbox is still on premises, Exchange has minimum version requirements, and OAuth between Office 365 and Exchange on premises must be established. For details, see Configure OAuth between Skype for Business Online and Exchange on premises.

There are some limitations to what the Meeting Migration Service will migrate. For more information, see Setting up the Meeting Migration Service (MMS).

With regionally hosted meetings, no additional configuration is required to set up PSTN conferencing. The assignment of additional PSTN conferencing bridges for the regions to which the organization is expanding will be done automatically. Additionally, the assignment of users to the PSTN conferencing bridge that corresponds to their region will be done automatically as part of their move to other regions. For more information about the PSTN conferencing service with regionally hosted meetings, see Plan for regionally hosted meetings.

You can continue using the Skype for Business admin center to manage the original PSTN conferencing bridge for your organization (the bridge your organization had before regionally hosted meetings was enabled). However, you must use PowerShell to manage the bridges of other regions or users in other regions.

You can continue to use the Skype for Business admin center to:

  • Make changes to the original PSTN conferencing bridge of your organization.

  • Change the PSTN conferencing settings of users in the original region of your organization.

  • Search, acquire, and assign additional service numbers to the original PSTN conferencing bridge of your organization.

You must use PowerShell to:

  • Make changes to the PSTN conferencing bridges of other regions.

  • Change the PSTN conferencing settings of users in other regions.

  • Search, acquire, and assign additional service numbers to PSTN conferencing bridges of other regions.

To validate your regionally hosted meeting configuration, ensure that you:

  • Confirm that the user can join unexpired meetings created in the source region as well as new meetings created in the target region.

  • Validate multi-party AV Conferencing / App Sharing work with other users in multiple regions of the organization.

  • If the account was licensed for Cloud PSTN Conferencing prior to the move, confirm that the user receives an email with dial-in coordinates and PIN information.

  • Confirm that attendees received an email telling them the dial-in conferencing information has changed, and then verify that the local numbers for the region are accurate.

  • Verify that dial-in conferencing works for both existing unexpired and new meetings.

  • Verify that PSTN calls can be placed and received.

  • Collect feedback comparing the experience from before the user was moved to after (for example, is AV Conferencing / App Sharing better, worse or the same).

To validate your tenant availability, use the Skype for Business Online Get-CsTenant cmdlet with the lsMNC parameter as follows:

Get-CsTenant | fl IsMnc, AllowedDataLocation

To validate your user configuration, use the Azure Active Directory Get-MsolUser cmdlet as follows:

Get-MsolUser -UserPrincipalName | select PreferredDataLocation

You can also use the Skype for Business Get-CsOnlineUser cmdlet as follows:

Get-CsOnlineUser <sipAddress> | fl PreferredDataLocation, LineURI, RegistrarPool , AcpInfo

Note that the Registrar pool value will be empty if the user is not homed in the tenant default region.

If you want to monitor the impact of regionally hosted meetings on call quality, you must ensure that Call Quality Dashboard (CQD) is enabled and configured prior to enabling regionally hosted meetings and migrating users. For more information about using CQD, see Turning on and using Call Quality Dashboard in Skype for Business Online.