Tag Archives: Exchange

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 “fabrikam.com”. All messages with destination user@fabrikam.com 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 (www.egress.com). 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=[jaap@Wesselius.info]
2018-04-19T10:25:05.9304327Z TID=24 ID=13306 To=[jaapwess@gmail.com]
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: [jaapwess@gmail.com]
2018-04-19T10:25:05.9304328Z TID=24 ID=13307 > Rule #1. Recipient [jaapwess@gmail.com]. 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=[administratie@Wesselius.info]
2018-04-19T10:24:56.1352082Z TID=48 ID=13306 To=[jaapwess@gmail.com]
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 @secure.com and @secure.eu 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)

Your browser is currently set to block JavaScript

I hate this…. And most likely you too otherwise you didn’t end up here

When logged on to an Exchange server, ready for starting the Hybrid Configuration Wizard, you try to logon to Exchange Online you end up with a warning (or ‘error’) message:

We can’t sign you in

Your browser is currently set to block JavaScript. You need to allow JavaScript to use this service.

To learn how to allow JavaScript or to find out whether your browser supports JavaScript, check the online help in your web browser.

Like the screenshot below:


To enable JavaScript on your computer you have to enable Active Scripting. To do so, go to Internet Options, select the Security tab and choose Custom Level.



Now scroll all the way down (or press page down 12 times ) and enable Active Scripting:


You will get a warning message “Are you sure you want to change the settings for this zone”, click Yes and click OK.


Restart your Internet Explorer browser and you can login on Exchange Online and continue with the Hybrid Configuration Wizard (or whatever you were trying to achieve).

Exchange 2016 CU7 and Exchange 2013 CU18

Microsoft has released its quarterly updates for Exchange:

  • Exchange 2016 CU17.
  • Exchange 2013 CU18.

It has been quiet around these updates, and they do not bring a whole lot of features.

Important to note is that the minimum Forest Functional Level (FFL) has been raised to Windows Server 2008 R2. Personally I think this is an indication that more exciting stuff is along the way, especially around Exchange 2016 (my personal expectation, don’t shoot the messenger :-))

There are schema changes in Exchange 2016 CU7, so when installing this update you have to execute the following commands:

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

When it comes to the .NET Framework, Microsoft is working on a new .NET Framework release (version 4.7.1). The upcoming quarterly update of December 2018 will support this version of the .NET Framework.

More information (well, not a lot more) can be found here: https://blogs.technet.microsoft.com/exchange/2017/09/19/released-september-2017-quarterly-exchange-updates/


create Shared Mailbox in Exchange Hybrid

Every now and then I get a question regarding creation of Room- or Shared Mailboxes in Office 365 when Exchange Hybrid is in place.There are multiple solutions available, but at the same time there are some restrictions as well. In this blog post I’ll discuss Room Mailboxes, Equipment Mailboxes and Shared Mailboxes.

Room Mailbox

To create a room Mailbox in your hybrid environment create a user account for this room mailbox first. In this example I’m going to create a Room Mailbox called ‘conference room 1st floor’ and have it created directly in Office 365 (for your information, I’ve tested this with Exchange 2010 hybrid as well as Exchange 2016 hybrid).


To create the Mailbox in Exchange Online, you can use the Enable-RemoteMailbox cmdlet in Exchange PowerShell. This will mail-enable the account in your on-premises environment and will automatically create a mailbox in Exchange Online the next time Azure AD Connect runs. For the Enable-RemoteMailbox cmdlet you need to use the -RemoteRoutingAddress (which should point to the Mailbox in Exchange Online) and for a Room Mailbox you have to use the -Room option. If you want to create a Shared Mailbox you can use the -Shared option, the result will be the same.

To create the Room Mailbox in Exchange Online we can use the following command:

Get-User -Identity Conference1 | Enable-RemoteMailbox -Room -RemoteRoutingAddress conference1@inframan.mail.onmicrosoft.com


When Azure AD Connect has run, the account has been provisioned in Azure AD and the Room Mailbox has been created. It is visible in Exchange Online EAC and permissions can be granted to other users can manage the Room Mailbox.


Resource (Equipment) Mailbox

To create a Resource (aka Equipment) Mailbox the process is very similar. First create a user account for the Equipment Mailbox in Active Directory and fill the appropriate attributes, like this:


To create the Equipment Mailbox directly in Exchange Online, execute the following in PowerShell (on your on-premises Exchange server):

Get-User -Identity AVEquipment | Enable-RemoteMailbox -Equipment
-RemoteRoutingAddress avequipment@inframan.mail.onmicrosoft.com


Again, when Azure AD Connect has run, the account is provisioned in Azure AD and the Mailbox is created in Exchange Online:


Shared Mailboxes

Createing Shared Mailboxes is a bit problematic, after all these years there’s still no option like -Shared when using the Enable-RemoteMailbox cmdlet in Exchange PowerShell so we have to figure out another way to create a Shared Mailbox in Exchange Online when using Azure AD Connect and a Hybrid environment.

<more to come soon>


Improve autodiscover performance

Autodiscover can be a lengthy process, especially if you are in a hosted environment or if your mailbox is in Office 365.

The autodiscover process consists of five different steps, it depends on your environment where autodiscover stops and returns the information. Autodiscover is using the following mechanisms:

  • Service Connection Point (SCP) in Active Directory. This is used by domain clients.
  • Root domain discovery, used by non domain joined clients or clients not being able to access Active Directory. All other steps are used by these clients as well.
  • Autodiscover.contoso.com (standard autodiscover mechanism)
  • Autodiscover redirect to autodiscover site (often used by hosting companies)
  • Autodiscover SRV records in DNS (sometimes used by hosting companies)
  • Autodiscover redirect to Office 365 (outlook.com)

If your mailbox is in Office 365, outlook will go through all these steps until it finds the information in Office 365. All steps will fail with the accompanying time-out and this will take quite some time. This can be seen in the Outlook Test Email AutoConfiguration option:


Continue reading Improve autodiscover performance