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

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

In the first part of this short series, we look at why you might need multiple tenancies – right or wrong!

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

Introduction

Sometimes before you do something you will regret, you know it’s a bad idea but you go down that path anyway. You have a feeling in the pit of your stomach that it’s the wrong thing to do, but for one reason or another, all the facts in front of you mean you keep on going.

That’s how you should feel if you are considering having multiple Office 365 tenants for your organization. The default position is use a single Office 365 tenant for your company if you can.

If that’s all it takes to convince you, then feel free to stop reading here. I know you want to find out why, though. If you do want to find out why, or worse - you actually want to do it, then keep reading.

Important questions you need to ask

The first question you should ask yourself, and everyone else should be asking you – is why? Why does your organization need multiple Office 365 tenants? Maybe you do have some solid reasons for why it is desirable – if so, then it’s important to make sure you understand what they are, and what the supporting evidence is.

Secondly, you need to work out how you will do it. If you run a single Active Directory, or even multiple AD forests, then it’s not going to be as simple as just adding multiple Office 365 tenants into Azure AD connect.

Thirdly you understand what it will be like to live with. How will people across the multiple tenancies share and distribute information? What will the user experience be like? What will it be like to manage in the longer term?

Common reasons for multiple tenancies

Whilst it is easy to dismiss the idea of using multiple Office 365 tenants, sometimes it can be felt there is not another option. Some of the reasons I’ve heard do have solid underpinnings:

  • We have a strategy to move everything to Office 365, but data must be resident in certain geographies.
  • We must be able to allow full autonomy of administrative control for divisions / operating units within the organization.
  • A variation of the above, we currently run separate environments for each division / operating unit for legal reasons and want to continue with that model.
  • We must avoid latency issues with particular Office 365 workloads, like Skype for Business and SharePoint Online.

Each of these may have alternative solutions to solve the problem in the short and long term, but mean that you will need to consider how you’ll achieve the goal and what the end result will be like.

Let’s example what the implications are for multiple tenancies, so you first of all understand how it will work; and what it’s going to be like to actually live with.

Identity, Custom Domains and Azure AD

The foundation for any Office 365 implementation is identity. Whether you are planning on using simple Cloud IDs, or using synchronized IDs connected to your local Active Directory environment, you must provide login for each user.

Azure AD is the underpinning directory service used by Office 365 to provide access to services. An Azure AD tenant is attached to a single Office 365 tenant, in the same way on-premises Active Directory can only have a single Exchange organization installed.

Each user object is unique in Azure AD and you cannot synchronize a single user into multiple tenancies using supported method with Microsoft tools.

Not only that, you can’t register a DNS domain in multiple tenancies either. That means that if you share an email address domain across the organization, then it is not possible to use that in more than one Office 365 tenant.

Image

To solve this, you need to do three things:

Use different custom domains for each tenant

You can share a DNS domain – well, sort of, so long as you use sub-domains. By registering the sub-domains in each tenant you can share the domain regionally, or by division.

Install multiple copies of Azure AD Connect

Azure AD Connect can synchronize multiple Active Directory forests, but it can’t synchronize to multiple tenants. You will need a separate instance running on a separate server for each Azure AD connect. This applies equally if you have multiple forests.

Ensure that each user object is only synchronized to one tenant

You will need to ensure that the user object itself is only synchronized by one instance of Azure AD connect to a single Office 365 tenant. A single user cannot be represented as a synchronized account in multiple forests. A typical approach will be to filter, perhaps on OU, so only specific parts of AD are synchronized to each tenant.

Of course, this doesn’t mean that you can’t have a consistent Global Address List. You can use scripts, or GAL synchronization tools to create matching contacts across tenants. This can assist with making it easier for users to find one another across tenants and solve mail routing issues.

In the next and final part of this series we’ll take a look at the individual Office 365 services and what impact this will have.

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

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.

Advertisement

Featured Links