May 3, 2019 – Microsoft Cloud Infrastructure Technical Journal

Multi Geo capability is a little complex topic to wrap up in a single article as Office 365 is a diverse platform with multiple set of business tool offerings. Eventually, Multi-geo configuration can affect to most of these workloads at highest level. That’s where the whole article was split in to 4 stages in order to give you a better and comfortable reading experience with necessary breaks.

Part 1: Get Started

Part 2: Planning and recommendation

Part 3: Configuration

Part 4: Managing and Maintaining

I have gone through the introductory and concept briefing in the part 01 of this article series. Now let’s continue with this 2nd stage which describes planning and recommendations for Office 365 Multi-geo.

Test run – Highly Critical

Try out with a test user/s first. Consider having some test users for each use case as shown below and try out the changes with these users before you roll out in production.

Have an existing test user who has an active Office365 account with Exchange, SharePoint, OneDrive being used (with available content)
Try to add the capability for this user only
Move the user to new PDL
Move OneDrive content accordingly
Test the functionality for Exchange, OneDrive and SharePoint

Initial rollout (pilot run, targeted run) – Critical

After you have tested with the above single user, use a small group of people (5 would be ideal) as the pilot run. In most cases this group would be from IT staff as they are well aware of the approach and changes, technically.

every user should have the preferred data location (PDL) defined so that when the new workloads are created (such as those who do not use OneDrive right now perhaps later) they’ll be provisioned in the new PDL. Office365 will use central Location for those users with no PDL defined. The recommendation is, better to set PDL for all users.

Prepare a list of users with their User Principle Name (UPN) and include your Test users, pilot users and other groups batches in order. This will help you in the configuration stage and will make the procedures easily and well tracked.

Considerations for Hybrid Scenarios

Azure AD Connect supports Multi Geo by allowing synchronization of the PreferredDataLocation attribute for user objects from AADC version 1.1.524.0 onwards. However, this may vary for each organization and if you are fully cloud with no on-premise dependency, please ignore.

The schema of the object type User in the Azure AD Connector is extended to include the PreferredDataLocation attribute. The attribute is of the type, single-valued string.
The schema of the object type Person in the metaverse is extended to include the PreferredDataLocation attribute. The attribute is of the type, single-valued string.

PreferredDataLocation attribute is not synchronized by default. This functionality is currently intended for larger organization (Its eventually the size than the scenario at the moment). You have to plan for an Local AD (on –premise) attribute which will hold the “Office 365 Geo Location” for your hybrid users as there is no PreferredDataLocation attribute by default in on-premise Active Directory. Further, PreferredDataLocation attribute can be managed by PowerShell for Azure Cloud User Objects but not for Synchronized Objects. For synchronized objects (Hybrid), you must make use of AD Connect application.

Before you start on technical configurations, I would highly recommend you to digest these articles and beware of the outcomes:

stay tuned for the part 03 (technical steps)

DISCLAIMER NOTE: This is an enthusiast post and is not sponsored by Microsoft or any other vendor. Please do not copy/duplicate the content of the post unless you are authorized by me to do so.