Wednesday 27 June 2018

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 ''
              Error:Missing signing certificate.
              Exchange Response Details:
              HTTP response message:
              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,

Thursday 21 June 2018

Enabling Azure Password Protection Preview

Here's a quick video of how to enable Azure Password Protection which is currently in Preview. Previously you had a pretty painful experience to upload a custom banned password list to Office 365. This simplifies the process and adds additional services and features.

Check out part 2 next week where i'll enable advanced configuration when you have directory synchronisation from an on-premises Active Directory and have to install and configure the Azure Password Protection proxy service and deploy the APP agents to your Domain Controllers.

Take care!

Wednesday 13 June 2018

The curious case of changing background colour for Office 365 Message Encryption

An interesting issue cropped up earlier this week when working with a customer to brand their OMEv2 experience to their corporate website and utilise the same colours and logo where appropriate. We had already branded Office 365 and we were to utilise an HTML colour code from their website into Office 365 Message Encryption.

Now Microsoft are usually very good with their documentation, but this did initially bring around some frustration as changing background colour simply didn't work.

The article explaining the Set-OMEConfiguration cmdlet is here, and states the following:

The BackgroundColor parameter specifies the background color. Valid values are:

  • An HTML hexadecimal (hex triplet) color code value (for example, #FFFFFF is white).
  • $null (blank). This is the default value.

However it doesn't work with an HTML colour code as you can see below.

Interestingly utilising Get-Help Set-OMEconfiguration -full didn't shed anymore information on the matter than what I was reading on, even after using Update-Help

 Utilising Get-Command Set-OMEConfiguration -Args -backgroundcolor didn't really give me any insights and nor did expanding the parameter set using $a = Get-Command Set-OMEConfiguration 
$a.ParameterSet [0] | select -ExpandedProperty parameters

 However this did give me information on what values it was expecting, which could be anything.

In a moment of frustration I just typed a colour in. for example Black, and the change was honoured.

 Which frankly is hilarious. As my client wanted a certain blue whilst I was not able to give him the exact blue they wanted I found I could support light blue - although it had to be added as lightblue, 'light blue' was not accepted.

 This made me think how many blue options were available to me. It's safe to say you can't have navy blue but royal blue is fully supported.

I've raised this to Microsoft to hopefully get the cmdlet match what's on and give us our HTML colour codes. I am pleased to confirm however $null does indeed work and remove any background colour change you have made :)

Update! 15/06/18 - 48 hours after raising this to Micosoft they have acknowledged the issue and created this article for the list of 140 available colours , as well as updating the original article.

Take care!