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

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).

11 thoughts on “What you need to consider with multiple Office 365 tenants (Part 2)”

  1. This is a good article. Thanks.
    I have just started at a company with 2 separate child companies that I am considering migrating to office 365.

    I was thinking of multi tenants but after reading this, im probably not going to do it. The one issue we have is separate billing and licensing.

    I would be interested to know if you know a solution around that? Also if there is anything that has changed in O365 since you wrote this article that would mitigate any of the problems mentioned?

    I look forward to your response.
    And thanks again for the great article!
    Will

  2. Not much has changed, not, but stay tuned for announcements at Microsoft Ignite next week (24th October 2017 onwards). Licensing management is not something that is management by Office 365 – you need your own processes to manage who gets what.

  3. We are looking at a Single Domain multi-tenant with different email domains, have you seen from your experience that configuration of mail routing manually to cause any major issues? What third party tools have you worked with to assist in mailbox data migrations? Thanks.

  4. Great article, we have a different scenario and would like to know what our options are. We are currently a sub-domain and we are planning on moving away from the forest to create our own domain. However, we would like our parent organization to keep managing O365 services for us. Is it possible for us to migrate to our own On-prem AD which we will sync to our own Azure AD tenant and then both Azure AD tenants being part of the same O365 tenant?

  5. We currently have Two Domains and Two associated Tenants (and email domains). Email address for each domain are different.
    Due to our desire to start authenticating everyone against AD – it is in our best interest to merge our two Domains. They contain employees and students respectively. We have no desire to merge Tenants however. Currently, we are Federated in both cases, but with different products. One domain uses Ethos (an Ellucian) product for federation, the other domain use ADFS. We will continue with this split Federation scenario after our Domain merger.

    Currently we have a ADConnect Server for each domain/tenant combination. The ADConnect for the domain2 syncs 3 OU specifically. It anchors on the ‘mail’ attribute (not UPN) because the domain ‘abc.contoso.com’ isn’t the same as the email domain – efg.contoso.com
    The ADConnect for domain1 syncs about five OUs. It anchors on the default – which is UPN I believe, since the on-premise domain contoso.com is the same in this case as the email domain – contoso.com .

    Lastly, I understand one Tenant would perhaps have been more ideal years ago – but that bridge has been crossed. Also, we aren’t experiencing any problems with Two Tenants – just the Two on-premise domains and authentication.

    Question:
    Can we just continue with the two ADConnect servers, one syncing (contoso.com domain, five OUs (employees (anchor upn)) ) to Tenant1, one syncing (contoso.com, 3 different OUs for Students (anchor mail attribute) to the Tenant2. OUs would be synced appropriately using ADConnect filtering, and no object would ever be duplicate. The Tenants have always been completely separate – the Federation will remain separate in any event (no planned changes to current Federation scenario).

  6. Any updates on this? We have 4 email domains(4forest) and need a viable solution for hybrid mode in O365. OKTA is going to help us with SSO authentication since we do not have a true DMZ. Please update.

  7. Multiple forests and multiple email domains are not a reason for multiple tenants – the normal solution would be one tenant, multi-forest Hybrid. If you are considering OKTA, consider using Password Hash sync and Azure AD, if you don’t want to publish AD FS.

  8. We have multiple forest and multiple tenants (due to geographical separation separation and acquisition of companies). Each forest have their local administation and their local email infrastructure (some with local exchange servers and some with 0365 mail service).
    We want to share the same email domain and want to know how to proceed.

  9. we are planning to go for multi tenant model, would like to understand more on Hybrid Configuration and Temporary External relay, if you have any blogs on these 2 topics, would love to go through those, thanks.

  10. Solution for Quickbooks database server manager windows firewall is blocking QuickBooks- Firstly configuring firewall ports- to do so firstly open the Quickbooks database server manager then click on the monitor tab then note the port number listed on your application, to open settings- click Windows+I keys together then click on update and Security option then select the Windows security option from the left side and then click on firewall and network security option after that select the advanced settings option from the list then a new window will open then click on the inbound rules option and select the new rule option then select the post and click on next then click the TCP and select specified local ports option. Different Port Numbers are depending upon the version that you are using then click on Next and select Allow the Connection then select next and make sure that all three options are selected again click on next and give a name to the new rule then after writing a name select next then select finish. Repeat the above process for “Outbound Rule” and check that the error still exists.
    https://mathomatic.org/quickbooks-firewall-error/

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top