Exchange Resource Forest and Office 365 – Part II

In my previous blog post I’ve explained more about the Exchange resource forest model where user accounts are located in a dedicated forest with only the user account (and their regular resources) and where Exchange is installed in a resource forest. There’s a forest trust between the resource forest and the account forest, and the mailboxes are configured as linked mailboxes. This is shown in the following figure:


In this blogpost we will add an Azure AD Connect server to enable synchronization between the on-premises Active Directories and Office 365.

Exchange Resource forest and Azure AD Connect

If we want to create a hybrid scenario with our resource forest and Exchange Online we have to implement Azure AD Connect first. Azure AD Connect will synchronize account information from the account forest, and linked mailbox information from the resource forest. To achieve this, we have to setup a multi-forest synchronization model (which is also fully supported by Microsoft).

The Azure AD Connect server will be installed in the account forest. To retrieve the information about the mailboxes from the resource forest, a service account will be used as shown in the following figure:


In a typical environment there’s only one Active Directory containing both user accounts and exchange servers. As such, the user accounts have the corresponding Exchange properties. In a Resource Forest scenario there are two user accounts, where the user account in the Resource Forest is disabled and this disabled account contains the Exchange properties.

The Azure AD Connect server (which is running in the Account Forest) combines the two accounts based on the objectSID and MSExchMasterAccountSid and synchronizes this ‘joined’ account information to Azure Active Directory, as shown in the following figure:


The prerequisites for Azure AD Connect is a Resource Forest scenario are the same as for a regular environment, so I won’t go into too much detail about this. Of course you need an internet routable domain for your accounts (i.e. don@accounts.local won’t work, so this needs to be changed to, your accounts need to be checked for inconsistencies with the IDFix tool and of course you have to configure your tenant in Office 365. For more information regarding the process, please check my blog Implementing Directory Synchronization. It’s a somewhat older blog, but the steps remain the same.

You can download the latest version of Azure AD Connect from the Download Azure AD Connect. I will only show the most important screenshots when running the Azure AD Connect wizard.

Azure AD Connect can be installed using an Express setup, this is the default setting and is sufficient if you have a single forest environment with less than 100,000 objects in Active Directory and where using SQL Express is sufficient. In our Resource Forest environment we have multiple Active Directory forest, so a custom setup is needed, so select Customize in the Express Settings window:


Continue with the wizard until you reach the User Sign-in window. Here you have to select which authentication method is used when users sign-in into Office 365. Make your selection and click Next to continue.


After entering the (Global) tenant administrator credentials, the forests need to be added to the Azure AD Connect wizard. In the Connect your directories window the Active Directory forest where your Azure AD Connect server resides will appear. To add this directory, click Add Directory:


The Add Forest Account window will appear. Here you can select if a new service account for Azure AD Connect will be created, or that an existing service account will be used. An Enterprise Admin Account will be used to create this service account, and configure Azure AD Connect for first use. It must be an Enterprise Admin account because information is written into the Configuration partition of Active Directory. Enter the credentials of the Enterprise Admin (in your Account Forest) and click OK to continue.


Repeat these steps for the Resource Forest, so enter the forest name, select the radio button to create a new service account and enter the Enterprise Admin credentials in the Resource Forest as shown in the following two figures:



Continue with the wizard, select the Domain/OU filtering options for both Forest and make sure you select the containers containing the user accounts in the Account Forest and the corresponding Mailboxes in the Resource Forest as shown in the following two figures:



The Uniquely identifying your users is the most important window in the Azure AD Connect wizard. This is where the user account in the Account Forest and the corresponding mailbox in the Resource Forest are tied together. In the previous blogpost I’ve explained the objectSID and the msExchMasterAccountSID, so this option is selected.


Continue the Azure AD Connect wizard, and in the Optional Features select the Exchange Hybrid Deployment checkbox and click Next to continue.


You’re now ready with the Azure AD Connect wizard. In the Ready to configure window you can chose to start the synchronization immediately, or enable the Azure AD Connect server in staging mode. In this mode it will collect all information and fill the SQL Express database with data, but it won’t write any data to Azure Active Directory until you’ve checked everything. Select the option you want and click install to finish the wizard and install/configure Azure AD Connect.


At the configuration complete window there are some recommendations and/or remarks for your reference, click Exit to stop the Azure AD Connect wizard.


Now, when you logon to the Microsoft Portal you’ll see that synchronization has occurred:


And when you expand the users option you’ll see which users are synchronized.


When you logon to the Exchange Admin Console in Exchange Online and check the Recipients | Contacts folder, you’ll see the users appear here. This makes sense, since the on-premises Mailboxes are represented as Mail-Enabled Users in Exchange Online.



In this blogpost I’ve showed you how to implement Azure AD Connect in an existing Exchange Resource Forest model. The Azure AD Connect server combines the user account from the Account Forest with the mailbox from the Resource Forest and synchronizes this to Azure Active Directory.

In my next blog I’ll create a hybrid environment based on the Exchange resource forest model.

Ps. a special thanks to ‘Trekveer Harry’ for his continuous brainstorm sessions and good ideas Smile

Source based routing in Exchange

In Exchange server Send Connectors are used to route messages from the Exchange organization to external recipients. Routing is based on the namespace of the recipient. You can create an Internet Send Connector with a namespace “*”, which means that all outbound messages are routed via this Send Connector.

You can also create a separate Send Connector with a namespace “”. All messages with destination are sent via this Send Connector, all other messages are sent via the other Send Connector. Routing via specific smart hosts or implementing domain security (i.e. Forced TLS) are good examples of using dedicated Send Connectors.

In Exchange unfortunately it is not possible to route message based on (properties of) the sender in Exchange. For example, users in a communications department should send all messages via a dedicated, high priority Send Connector, or members of the Sales Group should always send their messages via smarthosts in the DMZ, while other users send their messages via Exchange Online Protection. You can think of various examples, specific for your organization.

A customer wanted to implement source-based routing. Based on Active Directory Group membership or a property in Active Directory, outbound email should either be routed via the Symantec Messaging Gateway (SMG) or via Exchange Online Protection.

In Exchange you need a 3rd party solution, and one of the 3rd party solutions is the Transport Agent of Egress Software Technologies ( The Egress Transport Agents is a small software package that is installed on the Exchange 2010 Hub Transport server, of the Exchange 2013/2016 Mailbox server. It can also be installed on an Edge Transport server. It is installed in the C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\SmtpAgents directory, and the Transport Agent is configured using a configuration file.

In my lab environment I’ve installed it on two Edge Transport servers (one Exchange 2013 and the other Exchange 2016). I can route messages via Trend Micro Hosted Email Security (HES) or directly via the Edge Transport servers. Of course, there are two Send Connectors to facilitate each route.

The Edge Transport servers make a routing decision based on a header in the email message. If the message contains a header ‘X-RoutethroughTM’ the message is routed via Trend Micro HES, if this x-header is not present it is routed via the regular Send Connector.

The X-RoutethroughTM header is added on the internal Mailbox server. When a user is a member of a Security Group called TrendUsers, then this X-header is added. This is achieved using a Transport Rule on the Mailbox servers:


When a message is sent from a mailbox which is a member of this Security Group, it is routed via Trend Micro. When sending to a Gmail mailbox it is visible in the message headers:


The Transport Agent does extensive logging, and the outbound messages including the trigger is visible in this logfile:

2018-04-19T10:25:05.9304327Z TID=24 ID=13306 [#016636d20b19] Event: [OnResolved]. Processing message
2018-04-19T10:25:05.9304327Z TID=24 ID=13306 ID=[]
2018-04-19T10:25:05.9304327Z TID=24 ID=13306 Details=[Interpersonal]
2018-04-19T10:25:05.9304327Z TID=24 ID=13306 Delivery=[Smtp/2018-04-19T10:25:05.8246623Z]
2018-04-19T10:25:05.9304327Z TID=24 ID=13306 Subject=[Routing via TM?]
2018-04-19T10:25:05.9304327Z TID=24 ID=13306 From=[]
2018-04-19T10:25:05.9304327Z TID=24 ID=13306 To=[]
2018-04-19T10:25:05.9304327Z TID=24 ID=13306 Attachments=[]
2018-04-19T10:25:05.9304328Z TID=24 ID=13307 [#016636d20b19] Event: [OnResolved]. Rule execution log:
2018-04-19T10:25:05.9304328Z TID=24 ID=13307 > Rule #1. Found header [x-routethroughtm: On]
2018-04-19T10:25:05.9304328Z TID=24 ID=13307 > Rule #1. Recipients: []
2018-04-19T10:25:05.9304328Z TID=24 ID=13307 > Rule #1. Recipient []. Rerouted to [trend.local] via [UseOverrideDomain].
2018-04-19T10:25:05.9304329Z TID=24 ID=13308 [#016636d20b19] Event: [OnResolved]. Message ID=[] processing completed. Result: [Routed].

This was added after the blog was published because of visibility/readability:

message based routing X-header

A message from a mailbox that’s not part of this Security Group shows different headers:


And the Transport Agent logfile:

2018-04-19T10:24:56.1352082Z TID=48 ID=13306 [#1f1e25edd0da] Event: [OnResolved]. Processing message
2018-04-19T10:24:56.1352082Z TID=48 ID=13306 ID=[]
2018-04-19T10:24:56.1352082Z TID=48 ID=13306 Details=[Interpersonal]
2018-04-19T10:24:56.1352082Z TID=48 ID=13306 Delivery=[Smtp/2018-04-19T10:24:56.0250359Z]
2018-04-19T10:24:56.1352082Z TID=48 ID=13306 Subject=[Routing via Edge?]
2018-04-19T10:24:56.1352082Z TID=48 ID=13306 From=[]
2018-04-19T10:24:56.1352082Z TID=48 ID=13306 To=[]
2018-04-19T10:24:56.1352082Z TID=48 ID=13306 Attachments=[]
2018-04-19T10:24:56.1352083Z TID=48 ID=13307 [#1f1e25edd0da] Event: [OnResolved]. Rule execution log:
2018-04-19T10:24:56.1352083Z TID=48 ID=13307 > Rule #1. Header [x-routethroughtm] was not found.
2018-04-19T10:24:56.1352084Z TID=48 ID=13308 [#1f1e25edd0da] Event: [OnResolved]. Message ID=[] processing completed. Result: [NoAction].

And again an added screenshot for readability:

Message based routing X-header

The config file is easy to configure. When using the X-header as shown above it would contain:


Note. Unfortunately I was not able to post the config info itself on my blog, as WordPress does not accept this.

The header rule can be configured extensively using a headerValuePattern or a headerValueNotPattern. These are regular expressions, like:


In this example, all messages with the X-RouteThroughTM header are routed to the trend.local connector. However, if the X-RouteThroughTM header has label “public”, do not route. Also, do not route for recipients in and domains.


Source Based Routing is not possible in Exchange server and you need a 3rd party solution to achieve this. The Transport Agent solution from Egress Software is a highly customizable tool that can achieve this and the last couple of months it has been proven to be stable.

On general Exchange remark though, after upgrading to a newer CU you have to redeploy the Transport Agent. Not a big deal, only a matter of executing a setup.ps1 PowerShell script (but easy to forget)

set-msoldirsyncenabled not available

Now with Microsoft moving from the old MSOL to AzureAD PowerShell commands (see my blogpost on Azure Active Directory PowerShell v2), you get new features but (unfortunately) things are starting to disappear as well.

In the past you could use Azure AD PowerShell to enable or disable directory synchronization using the Set-MsolDirSyncEnabled cmdlet. During a recent lab deployment, I found out that this cmdlet is no longer available. In fact, not a single Msol cmdlet is available anymore, try Get-Command *msol* and nothing is returned.

To get more information regarding Azure AD you can use Get-Command *Set-AzureAD*. This reveals enough information, but nothing that points to directory synchronization.


When logging on to the Azure Portal (of the newly created Office 365 tenant) it is obvious that Azure AD Connect sync is not enabled, as shown in the following screen shot:


When you dive deeper into the Azure Active Directory section of the Azure Portal, you can see that synchronization has never run, and that password sync is disabled (which makes sense at this point):


Nowhere can an option be found to enable directory synchronization, as you had to do previously before configuring directory synchronization. The only option you have is to download Azure AD Connect, using the following link:

So, let’s give it a try….

Logon to the new Azure AD Connect server, download Azure AD Connect and start the wizard. The Express installation will perform the following steps:

  • Configure synchronization of identities in the current AD forest of <your domain>
  • Configure password synchronization from on-premises AD to Azure AD
  • Start an initial synchronization (I’ll get back on this later in this blogpost)
  • Synchronize all attributes
  • Enable auto upgrade


Enter the administrator credentials of your Office 365 tenant and your on-premises Active Directory and you’re ready to go:


One remark: I unchecked the Start the synchronization process when configuration completes option, and checked the Exchange hybrid deployment checkbox.

The reason I unchecked the synchronization process is that I do not want to synchronize all objects from my on-premises Active Directory to Azure Active Directory, but I only want to synchronize objects from the OU=Accounts container in my Active Directory domain.

If you want more information regarding the Exchange hybrid deployment and the write-back of properties from Azure AD to your on-premises Active Directory, you can visit the following Microsoft article:

Exchange Server Hybrid Deployments –

When the configuration is complete you can click the Exit button and you’re good. Please note that at this point no synchronization has taken place yet.


To make a selection based on Organizational Unit for synchronization you can start the Synchronization Service Manager (miisclient.exe) which can be found in the C:\Program Files\Microsoft Azure AD Sync\UIShell directory.


Click on the Connectors tab, and select the Connector (sometimes referred to as Management Agent) for your on-premises Active Directory. Click properties and select Configure Directory Partitions. Here you can select which containers should be used for synchronization to Azure Active Directory, as can be seen in the following screenshot:


Start the initial Azure AD synchronization using the Start-ADSyncSyncCycle -Policytype Initial command and wait for the results:


This will trigger the initial synchronization to Azure Active Directory, but won’t do any subsequent sychronizations. Use the Set-ADSyncScheduler -SyncCycleEnabled $true command to run periodic synchronizations.

When checking the Azure Portal, you can see that user objects are now synchronized from the on-premises Active Directory to Azure Active Directory, as shown in the following screenshot:



So, in short, previously you had to enable directory synchronization manually using the Set-MsolDirSyncEnabled command (or using the wizard in Office 365), but this is no longer the case. When running Azure AD Connect, directory synchronization in your tenant will automatically be enabled.

Exchange 2016 CU9 and Exchange 2013 CU20 released

On March 20, 2018 Microsoft has released two new quarterly updates:

  • Exchange 2016 Cumulative Update 9 (CU9)
  • Exchange 2013 Cumulative Update 20 (CU20)

There aren’t too many new features in these CUs. The most important ‘feature’ is that TLS 1.2 is now fully supported (most likely you already have TLS 1.2 only on your load balancer). This is extremely supported since Microsoft will support TLS 1.2 ONLY in Office 365 in the last quarter of this year (see the An Update on Office 365 Requiring TLS 1.2 Microsoft blog as well).

Support for .NET Framework 4.7.1, or the ongoing story about the .NET Framework. The .NET Framework 4.7.1 is fully supported by Exchange 2016 CU9 and Exchange 2013 CU20. Why is this important? For the upcoming CUs in three months (somewhere in June 2018) the .NET Framework 4.7.1 is mandatory, so you need these to be installed in order to install these upcoming CUs.

Please note that .NET Framework 4.7 is NOT supported!

If you are currently running an older CU of Exchange, for example Exchange 2013 CU12, you have to make an intermediate upgrade to Exchange 2013 CU15. Then upgrade to .NET Framework 4.6.2 and then upgrade to Exchange 2013 CU20. If you are running Exchange 2016 CU3 or CU4, you can upgrade to .NET Framework 4.6.2 and then upgrade to Exchange 2016 CU9.

Schema changes

If you are coming from a recent Exchange 2013 CU, there are no schema changes since the schema version (rangeUpper = 15312) hasn’t changed since Exchange 2013 CU7. However, since there can be changes in (for example) RBAC, it’s always a good practice to run the Setup.exe /PrepareAD command. For Exchange 2016, the schema version (rangeUpper = 15332) hasn’t changed since Exchange 2016 CU7.

As always, check the new CUs in your lab environment before installing into your production environment. If you are running Exchange 2013 or Exchange 2016 in a DAG, use the PowerShell commands as explained in my earlier EXCHANGE 2013 CU17 AND EXCHANGE 2016 CU6 blog.

More information and downloads

Microsoft UC Specialist