With a lot of my clients connecting to cloud services I get to work with Hybrid configurations quite a bit. Typically setting up ADFS, Azure AD Connect and running the Exchange Hybrid wizard (if we are going to Exchange Online) are all relatively quick and generally the easiest part about the migration. It wasn’t always so.
So this particular blog article has to do with the Exchange Hybrid wizard and for the first time in a while I hit weird roadblock that stopped the Hybrid Wizard in its place. Now, the fix is very easy to put in place, but as you will read later, we will learn that the wizard looks for certain criteria from the certificate when it runs.
The error we received was that there was a valid certificate for the wizard to use. So, we checked the certificates installed on Exchange by running Get-ExchangeCertificate:
In our example above, we have three certificates. We only really care about the top certificate as it has services applied to it. So we’ll narrow our search and list all properties using the Format-List switch:
In this case, the ‘RootCAType’ shows as ‘Registry’. How can we validate that this certificate would (or would not) work for the Hybrid configuration:
https://support.microsoft.com/en-us/help/3064938/-confirm-hybrid-certificate-has-iis-and-smtp-services-assigned-to-it-error-when-you-run-the-exchange-hybrid-configuration-diagnostic
In order for the Hybrid wizard to pick a certificate for securing the SMTP traffic in/out of Office 365, it needs to meet this criteria:
- IsSelfSigned parameter: This parameter value should be False.
- RootCAType parameter: This parameter value should be Third Party.
- Services parameter: This parameter value should be IIS, SMTP (at a minimum).
- NotAfter parameter: This parameter value is the certificate expiration date. The date should not be expired.
The problem is that my client had a ‘RootCAType’ of Enterprise (my example had ‘Registry’). This means that the certificate was issued internally and usually not a certificate that Microsoft would be able to validate.
In this customer case, the third party cert was on their load balancer. Why they had another internally issue cert, I cannot say, but they just need to export that third party certificate, import into Exchange, assign services and do an IISReset and all should be good.
My client did end up getting the correct certificate, assigning services to it and then re-running the wizard with no issues.
