delaware
Published in

delaware

Provisioning in a multi geo O365 tenant

We recently had a customer with a multi geo tenant requesting that the location of the user should determine where the data of an O365 Group (with a Team on top of the group) should be stored. This blog post shines a light on the ins and outs of multi geo provisioning.

What is a multi geo tenant anyway ?

Glad you asked ! In short, a multi geo O365 tenant is a tenant where users can have a location set to their AAD profile, that determines where certain data is stored (e.g. their personal OneDrive site collection).

By default users from a given tenant location will not be able to reach the other tenant location:

Satellite locations

For a multi geo tenant, you need to pick a central location. You can add so-called ‘satellite’ locations. Once the tenant is configured for multi geo capabilities, the ‘preferredDataLocation’ property can be set for any user. Lacking to fill out the property means that the user is configured for the central location. The central location is considered the default location, also for certain types of content as is explained a bit further.

Here’s the list of currently available locations:

Group creation

To create an O365 group in the location of your choice, you can leverage the Graph API by including the preferredDataLocation property. Easy peasy !

Detecting a multi geo tenant

This can be done using CSOM or the Microsoft Graph. Note that the Graph call is still in beta. A single geo tenant would only return a single entry without anything filled out in the dataLocationCode property.

Detecting the user location

Now that we know the possible locations in the tenant, we still need to know the location of the user requesting the new Group / Team. Microsoft suggests two ways to determine the user location: via CSOM or via the Graph. I prefer using the Graph whenever possible over CSOM, but in this case I had to resort to the CSOM method as the Graph call would not show the required property, although my app had sufficient application permissions. Here’s the GitHub issue I logged for this.

A snippet implementation to get the user’s preferredDataLocation code and match it with a dataLocationCode that is present in the tenant:

Although it didn’t work out for me, the Graph call is simple enough to obtain the user’s preferredDataLocationCode:

Caveats

There are two important things I want to share about multi geo tenants:

  1. Not everything is stored in the data location you just picked! All files stored in SharePoint are stored in data centers in the desired location, however Teams channel conversations are not. They always reside in the central location of the tenant, even if a satellite location was specified for the underlying O365 Group.
  2. It doesn’t stop with creating a group, often we want to perform some good old SharePoint provisioning! Permission request XML needs to be registered PER tenant.
    If you still use the well known appinv.aspx page to register the permission scope for your app to be able to do CSOM calls against your tenant, do not forget to go to the appinv page for EVERY tenant location. Otherwise your CSOM calls will fail misteriously and you will wonder why! E.g.:

Here’s a link to the official documentation about multi geo tenants that went GA in March 2019.

That’s all I had to share about multi geo tenant group creation. Enjoy !

Originally published at http://digitalworkplace365.wordpress.com on April 22, 2020.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store