0365 integration Part 1
The integration of Exchange messaging environments, regardless of their version, into Office 365 is a common feature for companies with external growth that must quickly integrate diverse and varied environments, often within very tight deadlines. We will see that there are several levels of integration depending on the strategy chosen in the short or medium term and that the levels of technical complexity may vary, depending on the transition environment and the tools chosen.
The objective of this article is therefore to specify the different stages of integration, the inherent risks and the possible tools for this type of operation.
Integration and cohabitation
The acquisition of a new entity will potentially generate significant changes in its information system, to the benefit of the parent company. The subsidiary’s business applications will be abandoned in favour of « Corporate » applications. The first subject addressed by this business constraint will concern identity. As the first brick allowing users to authenticate to the information system and business applications, all identities are often quickly created, introducing the notion of a double account for the subsidiary’s users.
Users of the acquired subsidiary then traditionally connect to their environments and new ones are authenticated by the parent company. This double authentication can be partially transparent for Microsoft access if it is possible to establish trusting relationships between the respective Active Directory forests. Most of the time, the implementation of these authentication relationships allows new accounts to keep access to old Microsoft resources, but not all business applications can manage their trusted relationships. They will then ask users for an additional connection to the parent company’s account.
One of the important questions to ask is the question of the final target.
Should you eventually keep the subsidiary’s account environment or, on the contrary, should you make it disappear in favour of the parent company’s?
* In the first case (Conservation), we are not really talking about integration but cohabitation. The two Active Directory environments will coexist in the long term, trust each other and users from both worlds will remain in their respective domains.
* In the second (Integration), the subsidiary’s information system must be « soluble » in that of the parent company. The workstations will be integrated in, the forest(s) of the parent company and the messaging data will have to be migrated to the 0365 tenant of the latter.
Step 1; Give the impression
In the case of an acquisition, one of the problems is to quickly allow the subsidiary’s employees to send with the same SMTP domain (ex :@coporate.com) as that of the parent company. This is like sharing an SMTP namespace over several entities (The parent company and the subsidiary(s)) which you will see is not necessarily obvious, especially if the subsidiary is using Exchange Online.
If the subsidiary you need to integrate comes with its Tenant 0365, you will not be able to extend the name of your SMTP domain to the latter. This is due to a functional limitation that limits the use of a domain name to a single Tenant 0365.
For sending, you will therefore need to use an address rewriting service from your subsidiary. Service, which will convert all messages sent as @filiale.com to @corporate.com. For security reasons, we recommend that you route this outgoing flow to the messaging equipment of the parent company with declared responsibility on the Internet (SPF, MX) for sending and receiving messages. This will prevent your messages from being considered spam.
The following diagram describes how shipping services are organized in a scenario where the Corporate domain is shared by the parent company and two other subsidiaries (Subsidiary-1 & Subsidiary-2). In this scenario, the parent company and subsidiary 1 both have a 0365 Tenant
The address rewriting service is available on an Edge Exchange server. This service does not yet exist on the Microsoft Exchange Online environment.
For reception, the parent company’s equipment must remain in place and must forward messages for the subsidiary’s users to their representatives. This redirection can be done in two ways.
The first is to do routing through the directory, the second is a simple SMTP configuration through directory rewriting services.
* Routing through the directory: In this case, entries in the parent company’s directory are created (« Mailuser » or Mail Contact). These email directory entries have the corporate SMTP address (e. g. john.doe@corporate.com) but also a redirection address (Target Address) Example john.doe@filiale-1.com. This forwarding address will be used by Exchange online or Onpremise to forward the message to the subsidiary’s mailbox. This system can be used with several subsidiaries at the same time if they do not have the same SMTP domain name. See Diagram below. The interest in using mail user objects (AD Users with mail extension), allows users of the subsidiary to have a user account in the Corporate environment and therefore to be able to connect to the various business applications that use the Active Directory.
* Configuration Routing: Configuration routing consists of using the Edge server to rewrite addresses in the opposite direction of sending. From @corporate.com to @subsidiaries.com.
The diagram specifies an incoming routing topology based on the directory and the use of « Target Address » and these famous « Mailuser ».
Both solutions work perfectly and are documented by Microsoft. However, I have a slight preference for Routing through the directory because on the one hand it fits more skillfully into the integration scenario than the first one (we will see why later) and then it allows on the other hand, the creation of distribution lists managed by the parent company within its online Exchange (the final target should not forget it) addressing mailboxes from both environments.
In any case, this « renaming on the fly » will therefore make it possible to give the external illusion of integration but should only be considered as a temporary second-best solution. A step before the integration or rather the dissolution of the subsidiary entity into the parent company’s environment.
This is step 2, which will involve linking the legacy resources and access to the subsidiary’s accounts already present in the parent company’s environment (the famous « mail users » mentioned above). As the starting scenario is to delete the subsidiary’s Active Directory environment, you should not synchronize it in the AD Corporate Azure. If you do this to migrate the associated resources to Office 365, they will remain linked to the local forest. The latter will therefore have to remain in production, which is not the objective.
The next step, therefore, is to ensure that for each account in the subsidiary there is an account in the Corporate environment, its clone in a way that we will name for practical reasons: Surrogate
Step 2, which is therefore to prepare for integration, has two possible paths. The first consists in relying on the functions of Azure AD connect to perform this identity merge, the second consists in relying on third-party tools.
But we will see this in the next part 2.
Laurent TERUIN
lteruin@hotmail.com
Anthony Costeseque
cbopenhost
Teruin laurent
Marion Diné
David ANDRE
David PEKMEZ
Yohan Boullier
BRK3124: How Skype for Business on-premises customers can take advantage of Teams meetings
