Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server

Bhalchandra_Atre-MSFT please also fix the buggy script "C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Test-MitigationServiceConnectivity.ps1"

It does not do what the contained subscription says, which is: "This script tests if Microsoft Exchange Emergency Mitigation Service is able to access the cloud endpoint."

It DOES NOT test "if Microsoft Exchange Emergency Mitigation Service is able to access the cloud endpoint.". Instead of connecting to the service and asking it if it works it just uses "Invoke-RestMethod".

This is different from what the service does. The Service uses the Exchange Proxy setting to connect to the cloud endpoint and the winhttp proxy to get the CRL's for HTTPS verification, whereas Invoke-RestMethod uses the proxy configuration of the current user. At least the TLS Handshake seems to be the same but is limited to TLS1.2. This is hardcoded in the ps1 as well:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Why not use TLS 1.3 if available like this?

[Net.ServicePointManager]::SecurityProtocol = [System.Enum]::GetValues([Net.SecurityProtocolType]) | Where-Object { $_.Value__ -ge ([Net.SecurityProtocolType]::Tls12).Value__ }

Exchange Server Self Monitoring is also broken because it does NOT report connectivity issues of the Microsoft Exchange Emergency Mitigation Service.

The Microsoft Exchange Emergency Mitigation Service also seems to use SSL pinning and is therefore incompatible with SSL inspection as it ignores trusted CA's used for it. Did not find this in the documentation Can this be configured?