Test-OAuthConnectivity Error:Missing signing certificate.

Recently came across this issue where free/busy had stopped working from Exchange on-premises to Exchange Online in an Exchange 2013 Hybrid Environment. On-premises users could not see calendar free/busy information of a user in Exchange Online, but Exchange Online users could indeed see free/busy information for on-premises users and didn't have an issue.

First of all it's safe to say read this article, as free/busy issues can be a dark art to understand and resolve - however, in this instance there wasn't much information on this error so we had to work through it to find the resolution.

When running Test-OAuthConnectivity the following error presented itself:

Information:[OAuthCredentials:GetToken] start building a token for the user domain 'on-premisesdomain.com'

              Error:Missing signing certificate.

              

              Exchange Response Details:

              HTTP response message:

              Exception:

              System.Net.WebException: The request was aborted: The request was canceled. --->

              Microsoft.Exchange.Security.OAuth.OAuthTokenRequestFailedException: Missing signing certificate.

Now Exchange utilises an authconfig certificate which is installed by default when you install Exchange and is used for OAuth services. The default expiry of this certificate is 5 years from the installation date.

You can view the certificate in question by running this command:

Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint |FL
 



What had happened in this instance, is that the certificate had expired 3 months into the Exchange Hybrid deployment.  So to resolve this issue we needed to generate a new cert firstly, and then apply this certificate as the new auth certificate which is performed with the following command:

Set-AuthConfig -NewCertificateThumbprint "Thumbprint of the new cert" -NewCertificateEffectiveDate XX/XX/XXXX

   

And then use Set-AuthConfig -PublishCertificate to make the change.

This command will push the certificate out to all CAS role servers so you don't have to push the cert out yourself.

Finally, re-run the Hybrid Wizard and once completed you will find on-premises users will be able to see the free/busy information for Exchange Online users once more.

Take care,
 @OliverMoazzezi

Microsoft Exchange 2016 Edge on Windows Server 2016

Hey all,

Microsoft have announced they are changing their support policy for Exchange 2016 on Windows Server 2016 today - specifically the Edge role.

You can read more information on the matter here, but for now if you are planning on deploying, or indeed already have Exchange 2016 Edge Servers on Windows Server 2016, you will need to start replacing these with Windows Server 2012 R2 versions.


Oliver Moazzezi – Office Servers and Services MVP

Twitter: @Olivermoazzezi

ReFS and Exchange AutoReseed, what you need to know

There are a lot of articles out there at the moment talking about ReFS and using this file system with Exchange, highlighting where appropriate, the supportability of doing so. I love the fact people are blogging and getting this information out there.

I think it's a great technology and have been using it for some time for Exchange 2013 and also Exchange 2016. But rather than concentrate on what others have already posted. I thought I'd highlight another important area.

In this post I want to highlight what most people haven't – ReFS when using Exchange AutoReseed.

Let's take a look at two DAGs, using Get-DatabaseAvailabilityGroup. One is Exchange 2013 and the other Exchange 2016:

Fantastic. That doesn't tell us too much though.

Let's see what Autoreseed settings are present :

Fantastic. That still doesn't tell us much though about anything to do with the file system you are using for your Exchange databases.

Let's take a look at all Auto* settings:

Again we get more information, including FIPS and BitLocker information but this still doesn't show us that AutoReseed is clear about what file system is in use.

So let's sit back and think about AutoReseed. It will take a spare disk (RAID/JBOD) and format it and basically auto reseed the database that has just disappeared due to a failed disk in your Exchange Mailbox server.

It's a fantastic concept, although admittedly something that's used in larger Enterprise Organisations (and was no doubt conceived in Office 365).

So... You're using AutoReseed. You've made a decision to go with ReFS. So how does AutoReseed know what file system to format the disk in? Well that's down to DiskReclaimer. We can look at the following Technet Article for a breakdown of AutoReseed and DiskReclaimer:

'"AutoReseed" https://technet.microsoft.com/en-us/library/dn789209%28v=exchg.150%29.aspx'

DiskReclaimer is the part of the process that will allocate and format a disk ready for the reseed operation to take place. Let's take a look at all of those Auto* parameters again on our DAGs:

We can see we have DiskReclaimer enabled; -AutoDagDiskReclaimerEnabled is set to True, the default setting.

So whilst we can manually format our disks, we know that the AutoReseed process can do this for us.

So how does it know to format the disk in either NTFS or ReFS?

That's the job of the –FileSystem Parameter of Set-DatabaseAvailabilityGroup, which is sadly lacking in the Parameters section of:

'"Set-DatabaseAvailabilityGroup" https://technet.microsoft.com/en-us/library/dd297934%28v=exchg.150%29.aspx'
(I have reached out to Microsoft to get them to update this page).

Let's take a look:

We can see both DAGs are using NTFS, this is what DiskReclaimer will look to when formatting a disk for AutoReseed.

Let's look at the file system in use for the Exchange 2016 DAG databases on one of the Mailbox Servers:

We can see we are using ReFS.

Therefore we need to ensure the –FileSystem parameter for our Exchange 2016 DAG is set to use ReFS.

Let's update it.

Set-DatabaseAvailabilityGroup "your Exchange 2013 or 2016 DAG here" –FileSystem ReFS

We can now see that the Exchange 2016 DAG in question, which is using ReFS for its Exchange Database and Log disks, is set correctly. This will ensure AutoReseed formats any spares correctly in the event of failed disks.

What happens if this isn't set correctly? Of course it will still work, having some disks as NTFS and some as ReFS – but that's not exactly a great consistent platform to have, and this should be set as part of your Administrative ownership where AutoReseed is used.

You can of course deviate from the default setting and disable DiskReclaimer and format your drives manually – but where's the fun in that?

Oliver Moazzezi – MVP Exchange Server

Twitter: @Olivermoazzezi