Exchange 2013 Hybrid – Content was blocked because it was not signed by a valid security certificate

Hello again. The last few days have given me lots of new things to do, so apologies if you are being inundated with blog posts!

So today I went to enable a new Exchange 2013 Hybrid configuration. I used the Start Menu launcher for ‘Exchange Administrative Centre’, which to be honest I don’t usually do. This took me to https://localhost/ecp/?ExchClientVer=15. I then went to Hybrid and enabled the Hybrid Configuration. I logged into Office 365 and was greeted by this friendly message of doom:

Content was blocked because it was not signed by a valid security certificate

This error is quite easily solved; do not use localhost as the server name when you access the ECP. Use your client access namespace instead. For example, if my CAS name was, I would browse to

Just be sure to put and your CAS name into your Intranet Zone too or you’ll then get an error about Cookies!

412 - Cookies are disabled

Thanks for reading!

Exchange 2013 installation and annoying Outlook certificate Security Alert

I know, I know….why am I blabbering on about an Exchange version which is 3 years old?! The answer is because I still install it all the time, mainly for the purposes of Exchange Hybrid deployments. And this is probably old news to most of you, but if you didn’t know, Exchange 2013 can be particularly annoying when you first install it.

Once the install is completed, an SCP record is registered in Active Directory for your shiny new server (which still has all of its out of the box settings). If you faff around at all after the installation has completed, drinking tea and making merry at the water cooler, you will find that your users start moaning at you about the certificate errors they are receiving.

Outlook Certificate Error

This is because your new server has, without your consent, started merrily responding to Autodiscover and EWS requests made through Active Directory. This new server doesn’t have your public certificate installed, and also is using internal server names for it’s URLs.

What you need to do on Exchange 2013 to get around this is:

  • Install your trusted 3rd party SAN/wildcard certificate and assign it to the IIS service. Restart IIS
  • Configure, as a minimum, the Autodiscover, EWS and OAB Internal URLs to reflect your Exchange namespace
    • set-webservicesvirtualdirectory -identity ‘Servername\EWS (default web site)’ -internalurl ‘’
    • set-oabvirtualdirectory -identity ‘Servername\OAB (default web site)’ -internalurl ‘’
    • set-clientaccessserver -server servername -autodiscoverserviceinternaluri ‘’

This should mitigate the problem while you actually configure your server. Unfortunately it’s just part of the way Autodiscovery works, and personally I’d rather it was this way round, rather than having to remember to enable the SCP record at some point. Because knowing me, I’d forget.

You could also mitigate this problem by following the guidance on my blog post about Autodiscover optimisation and disabling SCP lookups temporarily for your users. If you are going to be using Hybrid in the future, this may be desirable anyway.


Script to change Exchange internal URLs

All Exchange consultants will have been through this situation at least once now; a customer is using a split namespace in their Exchange environment with a .local name internally, and due to the new requirements for purchasing SAN certificates, they can no longer purchase certificates with a .local name on them. One way of remedying this is to change all the Exchange internal URLs to use the public name, and add in an internal DNS zone and record to point the public name at the Exchange environment.

Changing the URLs for multiple virtual directories and servers can be a pain. There are many scripts like this out there on the internet, but I frankenstein’ed this one to fit the needs I had. I wanted it to prompt for the server name, public FQDN and autodiscover FQDN and then change the directories on that particular server to reflect the names I had entered. I also love simplicity, so I wanted the most simple script possible. If you wanted to change this to do the external URL’s, then just do a find and replace internal with external! This script will work on Exchange 2010 and 2013.

Also, if you are using a wildcard certificate, be sure to run the below command to force the name match, otherwise you may get certificate errors on your clients!

Set-OutlookProvider -identity EXPR -certprincipalname msstd:*

Here is the script I use:

#get variables
write-host "Set Exchange 2010 Internal URLS" –Foregroundcolor Yellow
$urlpath = Read-Host "Type CAS Array FQDN starting with https://"
$autodpath = Read-Hosts "Type Autodiscover FQDN starting with https://"
$CASserver = Read-Host "Type internal server FQDN"
#change urls for all internal directories
Set-AutodiscoverVirtualDirectory -Identity "$CASserver\Autodiscover (default web site)" –internalurl “$autodpath/autodiscover/autodiscover.xml”
Set-ClientAccessServer –Identity "$CASserver" –AutodiscoverServiceInternalUri “$autodpath/autodiscover/autodiscover.xml”
Set-webservicesvirtualdirectory –Identity "$CASserver\EWS (default web site)" –internalurl “$urlpath/ews/exchange.asmx”
Set-oabvirtualdirectory –Identity "$CASserver\OAB (default web site)" –internalurl “$urlpath/oab”
Set-owavirtualdirectory –Identity "$CASserver\OWA (default web site)" –internalurl “$urlpath/owa”
Set-ecpvirtualdirectory –Identity "$CASserver\ECP (default web site)" –internalurl “$urlpath/ecp”
Set-ActiveSyncVirtualDirectory -Identity "$CASserver\Microsoft-Server-ActiveSync (default web site)" -InternalUrl "$urlpath/Microsoft-Server-ActiveSync"
#get commands to to doublecheck the config
get-AutodiscoverVirtualDirectory -Identity "$CASserver\Autodiscover (default web site)" | ft identity,internalurl
get-ClientAccessServer –Identity "$CASserver" | ft identity,AutodiscoverServiceInternalUri
get-webservicesvirtualdirectory "$CASserver\EWS (default web site)" | ft identity,internalurl
get-oabvirtualdirectory "$CASserver\OAB (default web site)" | ft identity,internalurl
get-owavirtualdirectory "$CASserver\OWA (default web site)" | ft identity,internalurl
get-ecpvirtualdirectory "$CASserver\ECP (default web site)" | ft identity,internalurl
get-ActiveSyncVirtualDirectory "$CASserver\Microsoft-Server-ActiveSync (default web site)" | ft identity,internalurl

Exchange 2013 Cumulative Update 8 now available

Exchange 2013 Logo

Exchange 2013 CU8 has been made available to the general public as of 17th March 2015. Along with the usual bug fixes, a few minor new features have been announced. From my point of view, the best new feature must be the automatic profile migration for Exchange Active Sync clients when being migrated to Office 365. This was the last piece in the puzzle of Office 365 migration as far as automatic reconfiguration goes, so I’m happy to see this included.

For a full list of updates and bug fixes, you can check out the Exchange Team Blog post at

Download link:

Thanks for reading 🙂

Exchange 2013 CU7 and more!

Today Microsoft have released a new slew of updates for On Premise Exchange environments!

There have been various hotfixes and scripts released to fix a multitude of sins in Exchange 2013 CU6, and Microsoft have rolled these hotfixes and more into their latest CU7 release. This update does require a Schema Update, so please run setup /prepareschema first. See for more information. Additionally there are some UM Language Packs for Exchange 2013 CU7 available.

In other news, the Exchange 2010 CU8 update has been recalled at the time of writing and is not available for download. This is because deployment of said update can lead to Outlook being unable to connect to Exchange :-/ If you have already installed, it is recommended that you rollback the update.

Lastly is the Exchange 2007 SP3 UR15 for all those retro Exchange nerds still running Exchange 2007. See KB here for information

Check out for the full rundown!

Exchange 2013 CU6 – Hybrid Configurations and Hardware Load Balancing…

Exchange 2013 CU6 was released at the end of August, and it’s fair to say it wasn’t Microsoft’s most elegant CU release ever. If you are already using a Hybrid Configuration, the following problems are faced after installation:

– You cannot use the On Premise Exchange Admin Center to create new Office 365 mailboxes, move mailboxes to Exchange Online, or create In-Place Archive mailboxes.

– You also cannot perform administration of Office 365 through the EAC, because when you click on the Office 365 management tab, it takes you to a marketing page for Office 365 rather than the 365 login page.

There has been a script released by Microsoft to fix this behaviour, which is available here:

It’s lucky that this script is available, because Microsoft made some changes to Exchange Online in the last few weeks. These changes mean that if you now attempt to create or manage a Hybrid Configuration in Exchange 2013 CU5 or older, you will see the following error:

Subtask CheckPrereqs execution failed: Check Tenant Prerequisites

Deserialization fails due to one SerializationException: 

Microsoft.Exchange.Compliance.Serialization.Formatters.BlockedTypeException: The type to be (de)serialized is not allowed: Microsoft.Exchange.Data.Directory.DirectoryBackendType

This can be resolved by, you guessed it, upgrading to Exchange 2013 CU6. Just remember to run the script which I linked to above after installation!

Another problem which a colleague of mine witnessed a few days back was related to CU6 and CAS Load Balancing. If you use a hardware load balancer such as a Kemp or NetScaler, and you install CU6, you will need to make some configuration changes to your availability monitors. Application aware load balancers will monitor Exchange Server 2013 using the Default Web Site in IIS, and a design change has been made in CU6 which will cause the load balancer to mark the Exchange 2013 server as down.

If you attempt to access the Default Web Site of an Exchange 2013 CU6 CAS server, it will return a status 302 and redirect you to the OWA site. A load balancer will see this and mark the server as being down. To resolve this problem, configure your load balancer to monitor https://CASFQDN/protocol/healthcheck.htm. For example, to monitor OWA you would use https://CASFQDN/owa/healthcheck.htm. The KB for this issue is here:

Exchange Server 2013 CU6 has been a bit of a box of tricks so far, but if you are about to modify or create a Hybrid Configuration, then you MUST upgrade in order to be successful. Hopefully this article will help you in your quest for Hybrid greatness!

Exchange 2013 – File Share Witness on an Azure VM

My last TechEd session of the year was on Exchange 2013 HA and Site Resilience. This session came with an exciting announcement. As of January 1st 2015, Microsoft will support using an Azure IaaS VM as a File Share Witness for an on-premises DAG. This provides the ability for deployments with a 2 datacenter DAG solution to add a FSW in a 3rd datacenter, providing the ultimate in Site Resiliency for Exchange Database Availability Groups. It’s worth pointing out that this is not the same as a Cloud Witness in the new Windows Server Technical Preview. The Exchange team have not yet decided whether they will do the work to make sure the Cloud Witness feature will be supported in Exchange 2013. The high level steps for doing this will be as follows: – create Azure networking and establish VPN (if not already in place) – configure Azure VMs (directory server and file server) – configure Exchange 2013 to use Azure FSW This is exciting news and is sure to be a guaranteed hit for those with a DAG stretched over 2 datacenters as it allows Quorum to be maintained when a single Datacenter is lost.

Controlling Autodiscover using Group Policy

27/03/2015 – Update: This has turned into my second most popular blog post, and is also one of the first I ever wrote. For that reason, I have given it a major update and hopefully made it more readable and helpful!

Autodiscover is a very important part of any Exchange deployment these days, whether it is a cloud-based Office 365 deployment or an On Premise deployment. It is the primary method by which your clients discover where their Exchange Server is located and what configuration is set. Manual configuration of Outlook profiles is still possible, but is very much a thing of the past.

How does Autodiscover work in Outlook?

When you configure a new Outlook profile, or open Outlook with a profile already configured, the client will go through a series of lookups to discover the correct server to connect to. This process looks something like this:

1. SCP object lookup – Outlook performs an Active Directory query for Service Connection Point (SCP) objects. When an Exchange Server is installed, it registers an SCP object in Active Directory. As this is the first lookup that Outlook does, this means that if your Outlook client can contact a Domain Controller, and you happen to have an Exchange Server installed in your forest, it will find the SCP record and attempt to connect to that Exchange Server.

2. Root domain query based on your primary SMTP address – Outlook uses the root domain of your primary SMTP address to try to locate the autodiscover service, and then tries to connect to that URL to retrieve the autodiscover XML file: https://autodiscover/autodiscover.xml. For example, my Outlook client will look up If it can find the autodiscover XML file here then it will obtain it’s configuration information from that file.

3. Query for the autodiscover sub-domain – Outlook uses the autodiscover sub-domain to try to locate the service. This is the most commonly configured way of deploying autodiscover from my experience. Outlook will attempt to connect to that URL to retrieve the autodiscover XML file: For example, my Outlook client will look up If it can find the autodiscover XML file here then it will obtain it’s configuration information from that file.

4. HTTP redirect – Outlook uses HTTP redirection if Outlook cannot reach the Autodiscover service through method 2 or 3. This is an unlikely scenario as all Exchange traffic should be going over HTTPS, not HTTP.

5. SRV record query in DNS Outlook uses an SRV record lookup in DNS to try to locate the Autodiscover service. It is not uncommon to use SRV records, is frequently used for providing autodiscover services for customers with multiple Primary SMTP domains. This feature has been deprecated with the launch of the Autodiscover Domain feature in Exchange 2013 and 2010 SP3 RU1. More information on the concept of Autodiscover for multiple domain names can be found in this excellent article:

Why would I want to control this behaviour?

There are many situations in which you may want to control which of these lookups are actually performed. Here are a few examples:

1. You are performing a Cutover migration from Exchange>Office 365. In this case, when you make the switch and move your MX records to Office 365, you will need to do one of two things:

a. Remove Exchange completely from your environment before attempting to configure new Outlook profiles for your users. Doing this will remove the SCP record from Active Directory.

b. Configure your Outlook clients to skip the SCP lookup.

Both of these methods will ensure that your clients discover their autodiscover settings using method 3 (as long as you have your DNS configured properly!). If you don’t do this, your Outlook clients will always discover their Exchange server using method 1 (SCP lookup). Of course, you could manually configure each Outlook profile, but that is way more hassle than it’s worth!

2. You are moving back to an On Premise environment from Office 365 (god forbid!). If you are doing this you must disable SCP lookups before implementing Exchange, as otherwise your Outlook clients will find your Exchange Server before they find your Office 365 autodiscover settings. SCP lookups can then be re-enabled once you have offboarded.

3. You may simply want to optimise your autodiscover experience. For example, if you are using pure Office 365 (no Hybrid), you might aswell disable all types of lookup except for method 3, as that is the only method which will work. This can lead to speed improvements, particularly when launching Outlook.

How do I control Autodiscover?

The best way of doing this is to use the magic of Group Policy! Firstly, if you don’t already have it, download and install the .adm or .admx file for managing your preferred version of Office, be it Office 2007, 2010 or 2013. The Autodiscover settings for Office 2013 are built into the ADMX file for the whole application, whereas Office 2010/2007 use a special Autodiscover .adm file.

Office 2007:

Office 2010:

Office 2013:

To learn how to install these files, please see the ‘Loading the ADMX templates’ section of this article:

You may already have these files installed and have a Group Policy object for managing Office settings. If you do, then edit your existing policy. If not then create a new Group Policy Object and link it to the required OU. Edit your policy and navigate to the following setting:

    • Outlook 2013: User Configuration>Policies>Administrative Templates>Microsoft Outlook 2013>Account Settings>Exchange
    • Outlook 2010/2007: User Configuration>Administrative Templates>Classic Administrative Templates>Microsoft Outlook 2010>Account Settings>Exchange>AutoDiscover

As counter-intuitive as it sounds, Enable the ‘Disable Autodiscover’ parameter and select between the options shown in the screenshot below. In this example I’ve just disabled the SCP lookup.

Disable Autodisover GPOYou can confirm what lookups your Outlook client is performing by doing an Autodiscovery test. If you’ve never done this before, here’s how:

1. Go to the Outlook icon in your taskbar, hold Ctrl and right-click on it. You should see a couple of hidden options, select ‘Test E-mail AutoConfiguration’


2. Untick ‘Use Guessmart’ and ‘Secure Guessmart Authentication’, enter your e-mail address and password and test.

3. Once the test is complete, go to the Log tab to see which lookups were performed and which was successful.

Hopefully this blog post will help you out, please leave comments with suggestions or feedback. Thanks for reading!

Assosiated TechNet article: