What you need to consider with multiple Office 365 tenants (Part 2)

by [Published on 27 Oct. 2016 / Last Updated on 27 Oct. 2016]

In this final part of the series, we’ll look at some of the high level implications on core Office 365 services, with a particular focus on Exchange.

If you would like to read the first part in this article series please go to What you need to consider with multiple Office 365 tenants (Part 1).

What you need to consider with multiple Office 365 tenants Part 2

Introduction

In the first part of this short series, I tried to convince you not to consider multiple tenancies at all. Then I provided some examples I hear from others as to why they feel they need to. We then looked at the core problem – Identity.

Exchange Hybrid migration and co-existence

Given where you are reading this article there’s a strong chance Exchange Online will be one of the key services in Office 365 that you are interested in. And so you should be, because it’s where some of the greatest considerations for multiple tenancies are, and where you need to be pretty imaginative if you want to create a solution that works, and is manageable.

I’ve talked to organizations before about the implications of doing this, and some organizations are lucky enough to have the right in-house expertise to manage and maintain the various parts that allow for a successful multi tenancy implementation; others however take a step back at this point and consider other options, like waiting for improvements to Office 365 and keeping a single Hybrid Exchange environment around for a little longer.

You can only configure Exchange Hybrid with one Office 365 tenant per Active Directory forest

Yes, you have read it correctly. If you have a single AD forest and want to configure Hybrid with multiple tenancies, you are out of luck. The Hybrid Configuration Wizard only supports a single tenancy.

Therefore, you need to pick which Office 365 tenant is your “Hybrid” tenant. It will be the one that benefits from the advantages of the wizard; a fully supported solution by Microsoft with easy to manage mail flow, federation and mailbox moves.

For your other Office 365 tenants, all is not lost. You can implement the core functionality from Hybrid manually, but you support it if it goes wrong. You can manually create mail connectors to route mail to and from your other tenant using the same methods that the Hybrid Configuration wizard uses, but you must ensure that you consider carefully how mail will route between environments. Calendar sharing using Federation is also straightforward to configure. Federated Sharing is an Exchange feature, not an Office 365 feature and possible to configure between any Exchange 2010 environment or higher. Therefore, it’s fairly painless to create the right relationships between tenants and on-premise manually.

Mailbox moves are also fairly straightforward to configure, and require no unusual configuration.

Sharing between tenants is hard to achieve and in some cases, simply not possible

Where it gets interesting is sharing between tenants; to allow Federated Sharing to work, contacts in each respective tenant need to understand not that the user is/was on-premise, but where they live now. If a user in tenant A needs to look up free/busy for a user in tenant B, they cannot ask the on-premise environment for the information. They will instead need a contact record created in tenant A with the onmicrosoft.com routing address directed at tenant B.

This configuration, combined with GAL synchronization software, is straightforward in theory, but also has implications on mail flow. As the same contacts are also used for mail flow, if the routing address is going directly to the tenant it will also use the onmicrosoft.com address to route email. This will by-pass the on-premisemail infrastructure, which may be desired, but result in the messages appearing to be from outside the organization, with implications for out-of-office autoreplies and similar.

If you are looking to share a single email domain, again it can be complicated. As only one tenant can have a unique domain registered, as discussed in part one of this series, then you might choose to route mail through the on-premise Hybrid environment. You will need to ensure your remote routing address values are in place correctly, along with updated primary SMTP addresses matching your vanity sub-domains for mail routing to work correctly along with services like Autodiscover.

Shared resources like Public Folders and Shared Mailboxes cannot be shared across tenants.

Users moving around the organization are hard to manage

On an ongoing basis, if someone moves around within the organization, moving their mailbox is now more complex. Your primary route will be to move the mailbox back on-premise, then over to another tenant. This of course has far wider implications for the others services.

Other Office 365 services

Exchange Online is not the only area you need consider wisely. Other Office 365 services allow in some cases quite good sharing functionality, but not necessarily to the degree you might need.

Skype for Business

You’ll rely on cross-organization Federation features within Skype for Business Online to achieve multi-tenancy communications. This means that anyone you communicate with cross-tenancy is not seen as within the same organization as you, and policies you put in place to restrict functionality with third-parties also applies here (and vice versa).

You can of course use IM, Presence, Audio, Video and Conferencing functionality; if you are using Skype Hybrid functionality you will only be able to pick a single tenancy though; and if you are using Cloud PBX PSTN Calling you cannot share minutes or number pools across tenancies.

OneDrive for Business and SharePoint

From SharePoint and OneDrive’s perspective, cross-tenancy access requires external user access to be enabled at the tenant level, and for each site collection.

Although access to users from other tenants is a baked-in feature, the user interface may be confusing, as options to share with Everyone except external users won’t provide users with the information they need to understand who they are or aren’t sharing with.

Yammer

If you are hoping to use Yammer as the springboard to breaking down some organizational barriers then all is not lost, but it’s not very easy. Yammer Networks are tied to tenancies. You can bring external users into conversations, but not easily. They are brought in via their email address; the best multi-tenancy option is using external groups. These do allow groups to be created with external users from multiple organizations. Management is from the creating Office 365 tenant though, and visibility of groups across tenancies is very limited; furthermore, the user experience is intended at partner organizations working together (external discussions) rather than internal discussions across tenancies.

Office 365 Groups and Planner

Finally, the thing that ties it all together; Office 365 Groups. You cannot create an Office 365 Group and allow it to be used with the same level of fidelity and discoverability across multiple tenancies.

The only services you can share across tenancies are email conversations, and files. These rely on distribution group functionality in Exchange to function, and the SharePoint external sharing functionality. Services like Planner are not available across the tenant boundary, and all users outside the tenant the group is created in are simply guests.

Final thought

If after reading about some of the potential issues you still are still looking to pursue multiple tenancies, then hopefully you are a bit more prepared for the areas you’ll need to consider and understand potential solutions available. Office 365 is an evolving service though, so ensure you follow developments closely as these might mitigate against some of the areas that hold you back from using a single tenant currently.

If you would like to read the first part in this article series please go to What you need to consider with multiple Office 365 tenants (Part 1).

See Also


The Author — Steve Goodman

Steve Goodman avatar

Steve Goodman is an Exchange MVP and works as a Technical Architect for one of the UK's leading Microsoft Gold partners.