Notes from the field: Microsoft 365 Multi-Geo

Posted on By Mark Wilson
This content is 2 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Generally, Office 365/Microsoft 365 data is located in the datacentre region that relates to the country where the company’s registered address is. If your company is registered in Amsterdam, you’ll be in West Europe. If you’re registered in New York, you’ll be in a US datacentre somewhere. Registered in the UK… it depends on when your tenant was created but it could be in West Europe (if it’s an older tenant, like mine) or in the UK…

For global organisations, this can be a challenge. If your data is on the other side of the world then you may find that latency adversely impacts access to resources. The Microsoft global network is designed to efficiently route traffic from local points of presence to Microsoft datacentres over fast links, but sometimes that’s not enough. In these cases, check out the Microsoft docs on network planning and performance tuning for Microsoft 365.

The other challenge relates to data residency and, as you can expect, there are some options.

One would be to establish multiple tenants. But that means multiple Azure AD instances. Added to which, a DNS name can only be registered in one place. This means I can’t have users with @markwilson.co.uk addresses (for example) in more than one tenant. For a global organisation with everyone using an @company.com address for identity, email and instant messaging, that’s going be a challenge.

Another option is Microsoft 365 Multi-Geo. This service allows the provisioning and storage of data at rest in the locations of your choice. Note that this is not designed for performance optimisation – in fact, the Microsoft website specifically calls this out:

“Note that Microsoft 365 Multi-Geo is not designed for performance optimization, it is designed to meet data residency requirements”.

Microsoft 365 Multi-Geo documentation

On the face of it, Multi-Geo sounds great, but it has some pretty significant licensing restrictions:

“Microsoft 365 Multi-Geo is available as an add-on to [selected] Microsoft 365 subscription plans for Enterprise Agreement customers with a minimum of 250 Microsoft 365 seats in their tenant, and a minimum of 5% of those seats using multi-geo. User subscription licenses must be on the same Enterprise Agreement as the Multi-Geo Services licenses.”

Microsoft 365 Multi-Geo documentation

In my case, with a US-headquartered organisation where the UK organisation was tiny in comparison, Microsoft 365 Multi-Geo became cost-prohibitive. With around 80,000 US seats and only up to 1500 in the UK, they would have needed almost three times the number of licences in order to hit the 5% minimum seat count in the UK satellite location. And it needs to be on an Enterprise Agreement (not Cloud Services Provider), although that’s probably not such a challenge when operating at this scale.

For the vast majority of Microsoft 365 clients that I work with Multi-Geo is not even a consideration. But if it is for you, then go in with your eyes open. The reliance on the US-HQ IT team for Microsoft 365 led to a total change of strategy for my client… and that meant the project was no longer led from the UK, and therefore they no longer needed my team’s services.

Notes from the field: some common dependencies for Microsoft 365 deployments

Posted on By Mark Wilson
This content is 2 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

My blog posts take a while to get published these days. I struggle to find the time to write them and often a few notes can remain in draft form for a long time. Some of those notes never make it. Others possibly shouldn’t.

This is one of those posts where I’m not sure whether to publish or not. It’s based on an email I sent to a client, in 2018, as we were starting to work together. That client was about to embark on a migration to Windows 10 and Office 365, and these notes were intended to set them in the right path.

We all know that Office 365 is under constant development, and some of the advice below might not be current. I don’t think it’s too far off the mark but your mileage may vary. I’ve also added a few comments where I know we’d look to do things differently today. Those comments are marked with square parentheses.

All of these dependencies were things I identified before we got into design… but many more came out as we got into the detail.

Preparing the identity platform

[Identity is key to any successful Microsoft cloud implementation. And Azure AD is Microsoft’s cloud identity platform.]

Recommendation:

  • IdFix tool used to ensure that there are no directory issues that will cause synchronisation issues.
  • Azure AD Connect synchronising without error between on-premises Active Directory and Azure Active Directory. Even with on-premises authentication via ADFS or similar, user objects will be required in Azure AD in order to populate the Exchange GAL.

[in this case, I could be reasonably sure that both of these are already in place for the existing Skype for Business Online deployment.]

Useful links:

Preparing for Exchange hybrid

[It’s common to run Microsoft Exchange in a hybrid configuration when migrating mailboxes to Office 365. Generally, the hybrid will remain in place even after user mailboxes have been migrated to the cloud, for management purposes. There are constraints around the versions of Exchange Server that can be used though.]

  • The hybrid server must be running the latest or immediately previous (i.e. n or n-1) cumulative update or update rollup available for the version of Exchange installed on-premises
  • Domain names that will be used for email should have the appropriate records created and verified in DNS.
  • Ports should be enabled to allow traffic to flow as outlined in the above article. It may be useful to run the Remote Connectivity Analyzer (RCA) tools to verify this.
  • In addition, I recommend that the other Exchange servers in the organisation are upgraded to run with the latest available updates.

Useful links:

Preparation for deployment of Windows 10 images using SCCM

[System Center Config Manager (SCCM) is now part of Microsoft EndPoint Manager (MEM) and I’m not sure I’d recommend an SCCM-based deployment these days. My first preference would be to use Microsoft’s own Windows images, in Azure AD-joined configuration managed with Intune (also part of MEM). This topic would make a blog post on its own…]

Config Manager needs to be updated to align with the version of Windows 10 being deployed: Support for Windows 10 in Configuration Manager.

[Even when I wrote the notes 3 years ago, it seems I was guiding the client towards a Modern Device Management approach with Intune…]

Preparation for the use of Office applications (desktop and web)

[Office 365 ProPlus is now Microsoft 365 Apps for Enterprise but the advice below is unchanged apart from the product name.]

Office 365 ProPlus (i.e. subscription-based Office application) requirements are the same as for Office Professional Plus 2016 (i.e. perpetually-licensed applications) and are detailed at Microsoft 365 and Office Resources.

With regards to documents (including spreadsheets, presentations, etc.) containing macros, etc. It would be advisable to perform some basic compatibility testing: Check file compatibility with previous versions.

Office 2016 and 2019 are supported under the Fixed Lifecycle Policy.

Use of a supported browser is critical to the use of Office 365 web-based components although many organisations are held back by legacy software releases.

General Microsoft 365 system requirements may be found at the Microsoft 365 and Office Resources link above. Most notably:

“Microsoft 365 is designed to work with the latest browsers and versions of Office. If you use older browsers and versions of Office that are not in mainstream support:

  • Microsoft won’t deliberately prevent you from connecting to the service, but the quality of your Microsoft 365 experience will diminish over time.
  • Office 2019 connections to Microsoft 365 services will be supported until October 2023.
  • Microsoft won’t provide code fixes to resolve non-security related problems.

[Microsoft’s guidance previously stated that “Office 365 doesn’t support interoperability with any software that isn’t supported by its manufacturer.”]