The essential Office 365 migration guide
A comprehensive collection of articles, videos and more, hand-picked by our editors
For some organizations, a single Office 365 tenant may not be enough. Certain scenarios, such as ensuring data...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
stored in the cloud is within certain regions, could mean that your company needs to provision mailboxes or manage end users in more than one tenant.
Traditionally with Office 365, the Windows Azure Active Directory Sync Tool (DirSync) operated on a basis of one Active Directory to one Office 365 tenant. This often means a global organization must choose one region for their Office 365 tenant even though users will be distributed globally.
Recent DirSync improvements mean that some restrictions have been lifted. It's possible to have a single Active Directory forest synchronizing with multiple Office 365 tenants, potentially across geographic regions. In this tip, we'll first look at why you should consider a single tenant. Then, we'll run through the technical steps and limitations with the installation.
You should still consider a single Office 365 tenant where possible
The main reason why organizations consider multiple Office 365 tenants is because they have a global end-user base. Office 365 tenants are based in the confines of a single region, and an organization might want their end users' mailboxes to be close and avoid the latency associated with traversing the Internet.
Because of Office 365's design, letting end users access their mailboxes on a different continent isn't necessarily a problem. Microsoft's idea with Exchange Online access is that end users are always directed to their closest Office 365 data center and then routed via Microsoft's low latency network links to their mailbox (Figure 1).
For global organizations, this means that clients in each region should use local DNS services to look up IP addresses and use local Internet links. Having a central DNS in one region and local Internet links in others could mean that end users aren't accessing Office 365 the way Microsoft intended.
There are reasons why multiple tenants may be required, and the primary reason is to ensure at-rest data stays within the confines of a certain region to meet the organization's local legislation. Following a merger or acquisition -- when a company has multiple Office 365 tenants but needs to move to a single Active Directory -- is another example. In this case, different divisions within the organization may want to retain control over their specific areas.
Limitations of using multiple tenants with a single AD
Before you start planning your deployment, you need to be fully aware of the imposed limitations. Although having multiple Office 365 tenants can work well, some restrictions might not make it a suitable option. Let's examine some of the key limitations.
Multiple Office 365 tenants mean multiple DirSync Servers. For each tenant, you need to install a separate copy of DirSync. This means more servers, or at least more virtual machines to install, maintain and keep up to date. For medium or large organizations, it's a relatively easy process, as DirSync is self-contained.
An AD user, contact or group can only be synced to one Office 365 tenant. You must use DirSync filtering to ensure that each individual AD object is synced to only one tenant. This is critical, and if you don't ensure that you "split" the scope of each DirSync server, you'll have serious problems and an unsupported installation. Microsoft offers guidance for configuring DirSync filtering on TechNet. You can configure filtering to scope each DirSync server to particular domains, particular OUs or AD attributes.
This means that, on its own, DirSync won't provide a full Global Address List (GAL) between all tenants. DirSync will only build a GAL based on the objects it syncs. If you want a full GAL, you will need to complement DirSync with scripts to create contacts in each tenant based on non-synced objects.
Accepted Domains and User Principal Name suffixes can't be shared between multiple Office 365 tenants. Each custom domain in Office 365 is unique to a single Office 365 tenant. If you have a single global domain -- for example, contoso.com -- you can only use this in a single Office 365 tenant. This means you'll either need to use sub-domains (such as us.contoso.com or uk.contoso.com) for each tenant or let different divisions keep their own brand names.
If you need to use multiple tenants and a single domain name, a hybrid Exchange installation may be a good option. This will let you use Centralized Transport features to route all inbound and outbound mail through on-premises Transport servers. In combination with Exchange's edge transport server role, you can rewrite addresses to remove sub-domain branding.
You can only configure hybrid Exchange functionality for one Office 365 tenant. Exchange 2010's and Exchange 2013's Hybrid Configuration Wizard will only work against a single Office 365 tenant. It's configured once per forest.
This shouldn't discourage you from using it to configure the base setup against one tenant. You can still use some hybrid features, including organization sharing, secure mail flow and remote mailbox moves. However, you must manually configure these settings for additional tenants.
You can't move mailboxes directly between Office 365 tenants. This final caveat with multiple tenants applies even if you don't use DirSync. You cannot move mailboxes between Office 365 tenants, regardless of their region locations. In a scenario where you want to move a mailbox between tenants, you need to move the mailbox to an on-premises server and then move the end user to a different location in Active Directory to sync to the other Office 365 tenant. Finally, you'll move the mailbox up to the other Office 365 tenant. Other third-party options may not help, as the underlying AD object can only exist in one Office 365 tenant at the same time.
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners. Goodman has worked extensively with Microsoft Exchange since version 5.5 and Office 365 since its origins in Exchange Labs and Live@EDU.