All posts by jaapwesselius

Exchange Resource Forest and Office 365 – Part IV

In the past three blogposts I’ve showed you the basics of Linked Mailboxes in a Resource Forest, how to implement Azure AD Connect is this environment and how to setup Exchange Hybrid in a Resource Forest model.

Another challenge is how to provision users in a Resource Forest setup, especially when it comes to provisioning mailboxes directly in Office 365.

In a normal, single forest environment you would create a new user in Active Directory and execute the Enable-RemoteMailbox command in Exchange PowerShell to directly create a Mailbox in Office 365. In a Resource Forest model you will run into some issues though….

In this blogpost I will show you how to manually create Linked Mailboxes and the accompanying user accounts and how to create a Linked Mailbox, but directly in Office 365. I’ll show you the unsupported way using ADSI Edit (for educational purposes) and the supported way to achieve this.

Provision a Linked Mailbox

To provision a Linked Mailbox a new user account in the Account Forest need to be created and a (somewhat) identical, but disabled user account need to be created in the Resource Forest.

The most basic option to do this is to execute the following commands in PowerShell on a Domain Controller in the Resource Forest:

Import-Module ActiveDirectory
$AccountsCred = Get-Credential Accounts\administrator
$Password = ConvertTo-SecureString -String "P@ss1w0rd!" -AsPlainText -Force

New-ADUser -Name "C.Smith" -Server ACCDC01.accounts.local -Credential $AccountsCred -UserPrincipalName -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Accounts,DC=Local" -AccountPassword $Password -Enabled:$TRUE

This will create a new user account in the Accounts Forest. Next is to create a similar, but disabled user account in the Resource Forest by executing the following command:

New-ADUser -Name "C.Smith" -Server RESDC01.resources.local -UserPrincipalName C.Smith@resources.local -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Resources,DC=Local" -AccountPassword $Password -Enabled:$FALSE

To create a new Linked Mailbox for this user account, we can execute the Enable-Mailbox with the -LinkedDomainController and -LinkedMasterAccount options against this new user account in the Resource Forest. This should be executed in the Exchange Management Shell, but you can also start a Remote PowerShell session in the current regular PowerShell window using the following commands:

$AdminCred = Get-Credential resources\administrator
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://RESEXCH01/PowerShell/ -Authentication Kerberos -Credential $AdminCred
Import-PSSession $Session

Note. You can also execute Import-Module ActiveDirectory in an Exchange Management Shell window on the Exchange server, but my Exchange 2010 server is running on Windows 2012. This is PowerShell 2.0 and generates an error when importing the Active Directory module.

So, the command to create the Linked Mailbox and user the user account we’ve just created in the Accounts Forest should be:

Get-User C.smith | Enable-Mailbox -LinkedCredential $AccountsCred -LinkedDomainController ACCDC01.accounts.local -LinkedMasterAccount "C.Smith"

With commands shown in the previous blog on Linked Mailboxes we can check the objectSID and the MsExchMasterAccountSID:


Azure AD Connect will make sure (just like in the previous blog posts) based on the objectSID and MsExchMasterAccountSID that the new user account and mailbox information will be synchronized with Azure Active Directory and it will appear in the Office 365 address book.

Now we can move this Mailbox to Office 365, but it’s not the most efficient way to create new Mailboxes, especially when the new Mailboxes should be created in Azure Active Directory.

Enable-RemoteMailbox in a Resource Forest with ADSI Edit (Not Supported)

The Enable-RemoteMailbox PowerShell command seems like a much more efficient way to provision Mailboxes in Office 365. The problem however is to connect the user account in the Account Forest with the disabled account in the Resource Forest. Let’s give it a try…

Create two users, one regular account in the Account Forest and one disabled account (acting as a placeholder) in the Resource Forest. When Azure AD Connect kicks in you’ll see two user accounts appear in Office 365 for this user.


The unlicensed account originates from the Account Forest, the blocked account originates from the Resource Forest. This is treated as two separate accounts because Azure AD Connect cannot create the joined identity as it does with a regular Linked Mailbox, because there’s no objectSID value stamped on the MsExchMasterAccountSid property. There’s no MsExchMasterAccountSid at all since there’s no Linked Mailbox, and we’re at this point not planning to create a Linked Mailbox either, sigh…

An option (but totally unsupported) to overcome this is to stamp the objectSID value of the regular user account on the MSExchMasterAccountSid property of the disabled account, prior to the next synchronization cycle of Azure AD Connect. When properly set, Azure AD Connect connects the two accounts and synchronizes only the regular user account with Azure AD Connect and only this user account will appear in Azure Active Directory.

You can try this by copy-and-paste this value using ADSI Edit, it gladly accepts the hexadecimal value as shown in the following figure:


Using PowerShell is easy for scripting, but involves a bit more work. Right after creating the two user accounts you have to retrieve the objectSID value of the user account in the Account Forest using the following commands:

$objectSID = Get-ADUser -Filter {SAMAccountName -eq "j.doe"} -properties * -server accdc01.accounts.local -Credential $AccountsCred | Select SID

The command $objectSID.SID.Value will show the value of the objectSID:


Setting the objectSID on the MsExchMasterAccountSid doesn’t work with the Set-ADUser command so a little workaround is needed:

$ObjUser = [adsi]"LDAP://CN=John Doe,OU=Users,OU=NL,DC=resources,DC=local"

Now the two accounts are tied together (when it comes to Azure AD Connect) and you can execute the Enable-RemoteMailbox command:

Get-User -Identity j.doe | Enable-RemoteMailbox -RemoteRoutingAddress

Again, this works fine but it is not supported. I primarily explained this to show what’s going on under the hood.

Enable-RemoteMailbox the supported way

A better and most likely supported way (thanks to fellow MVP Mike Crowley) is to create a Remote Mailbox and connect the disabled user account in the Resource Forest to the user account in the Account Forest using the Set-User command (with the -LinkedMasterAccount option) before Azure AD Connect runs and synchronizes the information to Azure Active Directory.

All steps would be:

  1. Create a user account in the Account Forest
  2. Create a disabled user account in the Resource Forest
  3. Enable-RemoteMailbox this disabled user account
  4. Set the LinkedMasterAccount properties

In PowerShell this would be:

Import-Module ActiveDirectory
$AccountsCred = Get-Credential Accounts\administrator
$ResourceCred = Get-Credential resources\administrator

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://RESEXCH01/PowerShell/ -Authentication Kerberos -Credential $ResourceCred
Import-PSSession $Session

$Password = ConvertTo-SecureString -String "P@ss1w0rd!" -AsPlainText -Force

# Create the user account in the Account Forest
New-ADUser -Name "Clyde Smith" -SAMAccountName C.Smith -Server ACCDC01.accounts.local -Credential $AccountsCred -UserPrincipalName -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Accounts,DC=Local" -AccountPassword $Password -Enabled:$TRUE

# Create the disabled account in the Resource Forest
New-ADUser -Name "Clyde Smith" -Server RESDC01.resources.local -SAMAccountName C.Smith -UserPrincipalName C.Smith@resources.local -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Resources,DC=Local" -AccountPassword $Password -Enabled:$FALSE

# Create a Remote Mailbox for this user (in the Resource Forest)
Get-User "C.Smith" | Enable-RemoteMailbox -RemoteRoutingAddress

# Set the LinkedMasterAccount properties
Get-User "C.Smith" | Set-User -LinkedCredential $AccountsCred -LinkedDomainController ACCDC01.accounts.local -LinkedMasterAccount "Clyde Smith"

Now two user accounts are set, the Remote Mailbox in Office 365 is created, the account in the Resource Forest is linked to the account in the Account Forest. All set and fully supported!


When using an Exchange Resource Forest with Linked Mailboxes and you want to provision new Mailboxes in Office 365, the most common way is to create a Linked Mailbox and move the empty Mailbox directly to Office 365. While this works will it is not the most efficient way and moving mailboxes can be time consuming, even when they’re empty.

Another way is to create two user accounts and fiddle around with ADSI Edit and create a Remote Mailbox in Office 365. This is fun to do in a lab environment, but not supported.

The best way to achieve this is to create two user accounts, and create a Remote Mailbox on the disabled account in the Resource forest. Once created use the Set-User command with the -LinkedMasterAccount option to link the Remote Mailbox to the user account in the Account Forest. The only catch here is to run all commands before Azure AD Connect kicks in, otherwise you will get unexpected results (i.e. multiple accounts in Azure Active Directory).

Exchange Resource Forest and Exchange Hybrid – Part III

In my previous two blogposts I’ve explained more about the Exchange Resource Forest model and how to implement Azure AD Connect into such an environment. In this blogpost I’ll show you more about creating a hybrid environment with an Exchange Resource Forest model.

Exchange 2010 Hybrid

If you have been following my blog, or maybe my work as a consultant you most likely know I’m not a big fan of installing Exchange 2016 into an existing Exchange 2010 environment when creating a hybrid environment. It adds a lot of additional complexity since you are halfway a migration to Exchange 2016, you need network and client access changes and most likely hit users multiple times. Better is to create an Exchange 2010 hybrid scenario and when the migration to Exchange Online is done, upgrade the Exchange 2010 remains to Exchange 2016.

My Resource Forest environment is built on Exchange 2010 (that’s what most of my customers are still running) and I will create another Exchange 2010 hybrid environment, but this time built on the Exchange Resource Forest. The solution will look something like this:


The only more challenging part is the use of an Edge Transport server for inbound and outbound SMTP, but if your SSL certificates are ok, you’re good to go. In our example, the Edge Transport server is used for inbound and outbound SMTP, but the hybrid SMTP will be sent directly from Exchange Online to the Exchange 2010 multi-role server. Centralized Mail Transport will be used, so all mail will always go via the Edge Transport server, even outbound mail from Exchange Online.

Note. Before you continue, you have to make sure that your certificates are ok, that a valid 3rd party certificate is used and bound to IIS and SMTP, and that your load balancer is configured correctly. A common pitfall is that address translation occurs, and that all inbound connections originate from the IP address of the load balancer. In this case inbound SMTP ends up on the wrong connector, causing secure traffic between Exchange 2010 and Exchange Online to fail.

Logon to the Exchange 2010 server and download the Hybrid Configuration Wizard at and start the wizard by clicking the Install button.

Click the Next button a couple of times, the wizard will detect the optimal Exchange server to be used to create the hybrid configuration (this is the server where the hybrid configuration wizard is running, and is known as the ‘hybrid server’) and logon to the Office 365 tenant using a tenant administrator account as shown in the following figure:


Continue with the wizard, select Full Hybrid (or minimal hybrid if you need to), and create a federation trust (and enter this crazy TXT record in public DNS). When you reach the radio button for Configure my Client Access and Mailbox server window, you can select the enable centralized mail transport checkbox if you want to.


Select the Hub Transport server (or Mailbox server when running Exchange 2013 or Exchange 2016) that should be used for secure communication with Exchange Online. This server is configured in an Office 365 Send Connector and a Receive Connector from Office 365 is created on this server.


Select a proper certificate (which should already be present on the Exchange server of course), enter the Organization FQDN that’s used to access your on-premises environment (i.e. and you’re ready to finalize the hybrid configuration wizard. The options you’ve selected in the wizard are now pushed to the Exchange server and Active Directory when you click the update button.


And after a minute or two the Hybrid Configuration Wizard should be finished, and of course no warning message should be shown:


We’ve now configured a hybrid configuration with an on-premises Exchange 2010 server that’s in a Resource Forest.

Move Mailbox

An easy way to test the new hybrid configuration is to test a mailbox move from Exchange 2010 on-premises to Exchange Online. To do so, logon to the Exchange (Online) Admin Center, go to Recipients | Migration and start a new migration batch. Select move to Exchange Online and select a user to move to Exchange Online as shown in the following figure:


Enter the on-premises administrator account to find a proper migration endpoint (through Autodiscover):


It will automatically detect and show the migration endpoint on the Exchange 2010 server:


Click Next to continue, enter a migration batch name, increase the bad item and large item limit if needed and follow the wizard. The migration batch is automatically started, but manually completed. I typically complete migration batches off business hours, but for a test or lab environment you can safely select to complete the batch automatically. When you click the new button a new migration batch is created, and the mailbox move is automatically initiated. When the mailbox is moved to Exchange Online you can logon to Office 365 and start testing.


The first test is to see if mail flows between Exchange 2010 on-premises to Exchange Online. In the previous figure the mailbox ‘Jaap Wesselius [Linked]’ is a mailbox that was not migrated, so this works fine. Checking the header of this message reveals the same:


The figure might be a bit blurry, but in the last column we can see that TLS 1.2 is used for communications between Exchange Online and Exchange 2010.

Sending from Gmail to the mailbox in Exchange Online reveals that Gmail sends the message to the Edge Transport server, which sends in to the Exchange 2010 server and to Exchange Online:


Inbound messaging is working as well. When mail is sent from Exchange Online to Gmail, we can see in the headers that mail goes from Exchange Online to the Exchange 2010 server, to the Edge Transport server and to Gmail.


Another important topic to test is free/busy information between Exchange 2010 and Exchange Online. When an on-premises mailbox wants to schedule a meeting with two migrated mailboxes in Exchange Online the following should be visible:


The Exchange 2010 server will contact Exchange Online using Exchange Web Services (EWS) to check the availability for the users Don and Duw.

Vice versa, when user Don wants to schedule a meeting the following should be visible:


The server in Exchange Online now contacts the Exchange 2010 server (via the load balancer) using EWS to check the availability of the on-premises mailboxes.

It happens a lot that availability information or free/busy information in the on-premises environment is not available. This can be an Autodiscover issue, a certificate issue or a pre-authentication issue in the load balancer. Enough stuff to troubleshoot in this case.

If free/busy is working properly, cross-premises Mail Tips are most likely working as well since this is also using EWS:


So, it looks like everything is working as expected.


In this blog post and the previous two blog posts I’ve explained more about the Exchange Resource Forest model, how linked mailboxes are related to their corresponding accounts, how to implement Azure AD Connect in a Resource Forest environment and how to setup a hybrid environment in this model.

This was built on top of Exchange 2010 but is very similar for Exchange 2013 or Exchange 2016. If all prerequisites are met it doesn’t make any difference if you’re running a single forest environment with Exchange installed or a Resource Forest model.

Since the Resource Forest is a fully supported scenario by Microsoft, the hybrid environment in a Resource Forest is fully supported as well.

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)