Category Archives: Exchange

Exchange 2016 CU10 and Exchange 2013 CU21 released

On June 19, 2016 Microsoft released Exchange 2016 CU10 and Exchange 2013 CU21, exactly 90 days after the previous CUs. Perfectly aligned with their regular quarterly release 🙂

Besides regular hotfixes there are a couple of important things to notice:

  • Exchange 2016 CU10 and Exchange 2013 CU21 need the .NET Framework 4.7.1. This is a hard requirement, so if .NET Framework 4.7.1 is not installed, the setup application will halt and generate an error message. You can use the Get-DotnetVersion.ps1 script that fellow MVP Michel de Rooij wrote to check the .NET version in advance.
  • A new requirement is the VC++ 2013 runtime library. This component provides WebReady Document Viewing in Exchange Server 2010 and 2013 and Data Loss Prevention in Exchange Server 2013 and 2016. In the (near) future the VC++ 2013 runtime library will be forced to install.
  • Standard support for Exchange 2013 ended on April 10th, 2018 and thus Exchange 2013 entered extended support. Exchange 2013 CU21 is the last planned CU. Customers need to install this CU to stay in a supported configuration, and to be able to install future Security Releases.
  • When running a hybrid configuration with Exchange Online, customers are required to install the latest Cumulative Update for Exchange 2013 or Exchange 2016, or install the latest Update Rollup for Exchange 2010 SP3.
  • None of these releases bring Active Directory Schema changes. You have to run Setup.exe /PrepareAD to activate new features like the following:
  • A new feature in Exchange 2016 CU10 and Exchange 2013 CU21 is the option to create shared mailboxes in Office 365 using the *-RemoteMailbox cmdlets. For example, after creating a user account in Active Directory you can use the following command to create a Shared Mailbox in Office 365 directly:
    Enable-RemoteMailbox -Identity <account> -Shared -RemoteRoutingAddress account@contoso.mail.onmicrosoft.com

Microsoft also released Update Rollup 22 for Exchange 2010 SP3. This Update Rollup brings support for Windows 2016 Domain Controllers (and corresponding Domain Functional Level and Forest Functional Level) and it fixes an issue with Web Services impersonation.

As always you should thoroughly test the new Cumulative Updates or Update Rollups in your test environment before installing in your production environment.

Installing a Cumulative Update hasn’t changed much over the years, so you can follow my previous blogpost about installing Exchange 2013 CU9, which is especially important when installing a Cumulative Update in a Database Availability Group.

More information and downloads:

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:

image

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:

image

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:

image

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:

image

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:

image

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.

Summary

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)

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

Exchange 2016 Database Availability Group and Cloud Witness

When implementing a Database Availability Group (in Exchange 2010 and higher) you need a File Share Witness (FSW). This FSW is located on a Witness Server which can be any domain joined server in your internal network, as long as it is running a supported Operating System. It can be another Exchange server, as long as the Witness Server is not a member of the DAG you are deploying.

A long time ago (I don’t recall exactly, but it could well be around Exchange 2013 SP1) Microsoft started to support using Azure for hosting the Witness server. In this scenario you would host a Virtual Machine in Azure. This VM is a domain joined VM, for which you most likely also host a Domain Controller in Azure, and for connectivity you would need a site-2-site VPN connection to Azure. Not only from your primary datacenter, but also from your secondary datacenter, i.e. a multi-site VPN Connection, as shown in the following picture:

image

While this is possible and fully supported, it is costly adventure, and personally I haven’t seen any of my customers deploy it yet (although my customers are still interested).

Windows 2016 Cloud Witness

In Windows 2016 the concept of ‘Cloud Witness’ was introduced. The Cloud Witness concept is the same as the Witness server, but instead of using a file share it is using Azure Blob Storage for read/write purposes, which is used as an arbitration point in case of a split-brain situation.

The advantages are obvious:

  • No need for a 3rd datacenter hosting your Witness server.
  • No need for an expensive VM in Azure hosting you Witness server.
  • Using standard Azure Blob Storage (thus cheap).
  • Same Azure Storage Account can be used for multiple clusters.
  • Built-in Cloud Witness resource type (in Windows 2016 of course).

Looking at all this it seems like a good idea to use the Cloud Witness when deploying Windows 2016 failover clusters, or when deploying a Database Availability Group when running Exchange 2016 on Windows 2016.

Unfortunately, this is not a supported scenario at this point. All information you find on the Internet is most likely not officially published by the Microsoft Exchange team. If at one point the Cloud Witness becomes a supported solution for Exchange 2016, you can find it on the Exchange blog. When this happens, I’ll update this page as well.

More information

Using a Microsoft Azure VM as a DAG witness server – https://technet.microsoft.com/en-us/library/dn903504(v=exchg.160).aspx

Exchange and .NET Framework support

Last week I had to upgrade a few Exchange 2013 CU15 servers to Exchange 2013 CU18. In a typical scenario upgrading to a newer Cumulative Update it’s not a big deal, not even when skipping a few versions, but in this scenario most likely you will hit the following error message:

image

It fails during the Prerequisite Analysis with the error message

“This computer requires .NET Framework 4.6.2 (https://support.microsoft.com/kb/3151802). For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.MinimumFrameworkNotInstalled.aspx

The Exchange Server setup operation didn’t complete. More details can be found in ExchangeSetup.log located in the (SystemDrive):\ExchangeSetupLogs folder.”

Exchange Server 2013 CU18 requires the .NET Framework 4.6.2 for installation which was obviously not installed on these servers.

Continue reading Exchange and .NET Framework support