For testing purposes, I had to install a few Windows 7 and Windows 10 machines (with Office 2007, Office 2010 and Office 365 ProPlus) at a customer environment. It was a standard environment with a regular WSUS environment. In this customer environment there were approx. 5000 clients with Windows 7 (I know…) and Windows 10 all working fine with WSUS.
Several of my test machines had problems downloading updates from the WSUS environment, Windows Update returned the Code 80072F8F Windows Update encountered an unknown error as shown in the following screenshot:
Emptying the C:\Windows\SoftwareDistribution and restarting the Windows Update service did not help.
When using Google to search for this error a lot was returned (even recent issues which is the reason for my blogpost), but most of them were certificate related where the self-signed certificate on the WSUS server was expired. In my scenario this was not a problem since a valid 3rd party certificate was used on the WSUS server.
The WindowsUpdate.log in C:\Windows revealed more information. One thing I found was DownloadFileInternal failed for https://wsus.contoso.com:8531/selfupdate/wuident.cab: error 0x80072f8f.
When using a browser to navigate to this URL a got a certificate warning (which I did not expect btw) about verifying the certificate: This certificate cannot be verified up to a trusted certification authority as shown in the following screenshot:
From this point on it was easy, install the intermediate and root certificate in the certificate store of the workstation and Windows Update ran successfully – although it takes a very long time to deploy all updates, especially on Windows 7 with Office 2010 🙂
When configuring an Exchange 2010 hybrid environment a Receive Connector is created on the Exchange 2010 server. This Receive Connector is configured with the FQDN entered in the Hybrid Configuration Wizard (see previous blog post on Exchange 2010 Hybrid) and the source IP addresses of the Microsoft Exchange Online servers. If one of these servers access the Exchange 2010 environment, they end up on the Office 365 Receive Connector (based on the IP address) and the correct SSL certificate is returned. This way mutual TLS is established between Exchange 2010 on-premises and Exchange Online.
It sometimes happens that the wrong certificate is used for SMTP communication between Exchange on-premises and Exchange Online, thus resulting in SMTP mail flow failure between the two.
You can check this in the Exchange Admin Center (EAC) in Exchange Online. Logon to the EAC in Exchange Online, select Mail Flow and click the Connectors tab. You’ll see two connectors. One connector for mail from Exchange 2010 to Exchange Online, and one connector for mail from Exchange Online to Exchange 2010.
Continue reading Exchange 2010 Hybrid cannot establish Mutual TLS wrong certificate is used
Autodiscover is a standard feature in Exchange Server 2007 and higher that’s being used by Outlook 2007 and higher. Looking at the number of questions I get regarding autodiscover I’ve written a number of blogposts that will look into Autodiscover in depth:
In Part I I’ve explained how domain joined clients work with autodiscover information that’s stored in Active Directory. In Part II I’ve explained how the same (domain joined) client behaves on an external network like the Internet.
Both posts work with the self-signed certificate, but it’s much better (and recommended!) to use a 3rd party certificate or a certificate of an internal PKI environment. Continue reading Autodiscover in Exchange part III