Category Archives: Exchange

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:


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 –

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:


It fails during the Prerequisite Analysis with the error message

“This computer requires .NET Framework 4.6.2 ( For more information, visit:

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

Exchange 2016 Edge Transport Server and IPv6

I’ve never paid too much attention to IPv6, except for turning it off completely in case of strange issues. And admit it, most of you do the same.

Security is getting more and more important, and as a messaging consultant you want your Exchange environment top notch. In the Dutch community NGN I was pointed to where you can check your presence on the Internet. Lots of red crosses when it comes to messaging and IPv6, reason for me to start looking into that.

In this blogpost I will focus on the Exchange 2016 Edge Transport server (I have two for inbound and outbound email) and the Exchange 2016 Mailbox server, which is load balanced behind a Kemp LoadMaster LM3600.

Exchange 2016 Edge Transport server

Although a lot of Exchange admins disable IPv6 on their Exchange servers (through a registry key) in case of strange issues, it is not a recommended solution.

I have two Exchange 2016 Mailbox servers, one Exchange 2013 multi-role server and two Edge Transport servers (one Exchange 2013 and the other Exchange 2016) for inbound and outbound SMTP traffic. There are two MX records which point to these Edge Transport servers. Both have an external IPv4 address.

The first step of course is to add an IPv6 address to the network adapter of the Edge Transport servers, your provider should be able to supply you with a sufficient IP range.


This should not result in too much issues. If you want to ping your server on IPv6 make sure that the File and Printer Sharing (Echo request – ICMPv6-In) inbound rule is enabled in Windows Firewall.

The next step is to enable the Edge Transport server for IPv6 usage. The Mailbox server has everything setup by default, but the Edge Transport server is only configured for IPv4.

Continue reading Exchange 2016 Edge Transport Server and IPv6

TrendMicro Hosted Email Security: SPF DKIM and DMARC Part III

In the previous two blogpost I discussed how to configure SPF, DKIM and DMARC for outbound messages using the TrendMicro Hosted Email Security solution, including Office 365 centralized mail transport. In this blog I’ll discuss SPF, DKIM and DMARC for inbound messages (i.e. the verification part) using the TrendMicro solution.

Inbound protection

For inbound protection there’s not too much configuration to do, the only thing when using an online service is enabling the services.

In HEC Console select Inbound Protection and select Domain-based Authentication. Here you’ll find the options for SPF, DKIM and DMARC:


Select the Sender Policy Framework (SPF) option and in the SPF window check the enable SPF checkbox and when needed, check the Insert an X-header into email messages checkbox:


Continue reading TrendMicro Hosted Email Security: SPF DKIM and DMARC Part III

TrendMicro Hosted Email Security: SPF DKIM and DMARC Part II

In my previous blog I showed you how I implemented Trend Micro Hosted Email Security (HES) in my Exchange 2010 environment. Interesting case, it’s an Exchange 2010 hybrid environment with mailboxes in on-premises Exchange 2010 as well as mailboxes in Exchange Online. Centralized mail transport is used, so mail to and from Office 365 always routes via HES and the on-premises Exchange 2010 servers to Exchange Online. In this blog I will focus on implementing SPF, DKIM and DMARC in Trend Micro Hosted Email Security.


SPF in itself is covered in more detail in a previous blog post “SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I” which can be found here:

In this scenario, mail from the domain (including Office 365) is only routed via the Hosted Email Security environment so the SPF record is pretty simple:

v=spf1 ~all

Set this TXT record in your public domain, start sending email and when checking the header information you’ll see your all good here:



DKIM is a little more work to configure and takes a bit more time. DKIM is covered more in detail in part II of a previous series “SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part II” which can be found here:

DKIM is about signing header information using a private key, and to decipher the signature you need a public key which is stored in public DNS, accessible for every mail server on the Internet. No need to worry about the configuration, HES will deliver all the details.

In the HES console select Outbound Protection and select DomainKeys Identified Mail (DKIM) Signing.


Continue reading TrendMicro Hosted Email Security: SPF DKIM and DMARC Part II