New ExoConnectorCheck vs. documentation - Health Checker

[Niehweune]

Provide Version Number
24.02.15.1640

Describe the issue
The New ExoConnectionCheck reports an issue if a send connector is present that routes mail to Exchange Online when there is no TLS certificate explicitly configured on the connector.
The documentation link referred does not mention explicitly setting the TLS certificate (at least not on the send connector), nor does the PowerShell command include the TlsCertificateName parameter.

Expected behavior
If it is now required to explicitly specify a TlsCertificateName on the send connector, documentation should be updated accordingly.
If not, this should not be reported as an issue (but additional checks may be required to verify correct configuration).

Script Output
EXO Connector Present: True
Send Connector - <connectorname>: Misconfigured to send authenticated internal mail to M365.
CloudServicesMailEnabled: True
TLSCertificateName set: False
More Information: https://aka.ms/HC-ExoConnectorIssue

Additional context
Exchange automatically selects a suitable certificate that matches the FQDN on the send connector, as long as it is valid and enabled for SMTP.
So the check might instead (or additionally) involve verifying if such a certificate is present, and if it is issued by a public authority (e.g. not self-signed and not issued by a AD CA).

[richfaj]

Certificate with an accepted domain has been a requirement for sending mail to/from unaccepted domain for a while now. However, explicitly setting a certificate on the send connector is not a requirement. In the scenario where there is no explicit certificate specified on the connector, the best matching certificate is selected based on the FQDN set on the connector.

To ensure the expected certificate is always selected, it is best practice to specify a TlsCertificateName. This is the same way the Hybrid Configuration Wizard does it.

Both configurations below are valid, where explicit being preferred:

// Implicit
New-SendConnector -Name <DescriptiveName> -AddressSpaces * -CloudServicesMailEnabled $true -Fqdn <CertificateHostNameValue> -RequireTLS $true -DNSRoutingEnabled $false -SmartHosts <YourDomain>-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidation

// Explicit
New-SendConnector -Name <DescriptiveName> -AddressSpaces * -CloudServicesMailEnabled $true -Fqdn <HostNameValue> -RequireTLS $true -DNSRoutingEnabled $false -SmartHosts <YourDomain>-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidation -TlsCertificateName <X509CertificateName>

Perhaps warn only when the FDQN is not set?

[worldsdream]

Any update on this?

As the documentation shows:

New-SendConnector -Name "My company to Office 365" -AddressSpaces * -CloudServicesMailEnabled $true -Fqdn mail.contoso.com -RequireTLS $true -DNSRoutingEnabled $false -SmartHosts contoso-com.mail.protection.outlook.com -TlsAuthLevel CertificateValidation

The script shows the warning:

EXO Connector Present: True
Send Connector - : Misconfigured to send authenticated internal mail to M365.
CloudServicesMailEnabled: True
TLSCertificateName set: False
More Information: https://aka.ms/HC-ExoConnectorIssue

So the documentation needs to change or the health checker script. It's not clear right now.

Thank you.

[lusassl-msft]

We will investigate this. This is caused by the change made via PR #1984 .

[arindamthokder]

Perhaps warn only when the FDQN is not set?

But in Hybrid when HCW is run, the connector FQDN is usually blank. Only TLSCertificateName is set.
IMO, we should check (TLSCertificateName is set) or (fqdn parameter is set).

[JeremyTBradshaw]

Just checking in, wondering if an update is being planned for this one. The link in the OP as well as Set-SendConnector / New-SendConnector do not mention -CloudServicesMailEnabled as being dependent or impacting to -TlsCertificateName nor -Fqdn.

Real life observation of both an HCW-created "Outbound to Office 365", and a custom "To-internet-via-EOP" send connector, created by following the link in the OP's New-SendConnector example - works perfectly fine. Both use CloudServicesEnabled TRUE and the latter has no TlsCertificateName set, rather has Fqdn set. The latter causes red line in HealthChecker.ps1 output.