After updating Exchange 2013/2016/2019 you might get an error when trying to open OWA or ECP. This happens because of an expired OAuth certificate.

Open Exchange Powershell and check if the certificate has expired:

Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint

If the certificate has expired, create a new one (do not forget to change the domain name):

New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName "ajni.it"

Set the new certificate for OAuth:

Set-AuthConfig -NewCertificateThumbprint <ThumbprintFromStep1> -NewCertificateEffectiveDate (Get-Date)
Set-AuthConfig –PublishCertificate
Set-AuthConfig -ClearPreviousCertificate

Restart the Exchange IIS App Pools:

Restart-WebAppPool MSExchangeOWAAppPool
Restart-WebAppPool MSExchangeECPAppPool

If you still get the error in OWA/ECP, you either have to wait a couple of hours (some people have reported that they had to wait for up to 6 hours) or change the time zone of the Exchange server to UTC (Universal Coordinated Time).

References:

https://www.frankysweb.de/exchange-server-owa-und-eac-starten-nicht-nach-installation-der-juli-updates/

https://support.microsoft.com/en-us/topic/you-can-t-access-owa-or-ecp-after-you-install-exchange-server-2016-cu6-88b3fe67-5f97-a8a2-8ed8-70034ff15761

When synchronizing on-prem users to Azure AD, there is a chance that Exchange attributes like msexchHideFromAddressLists are missing in Active Directory because the Exchange schema has never been updated, since there has never been a local installation of Microsoft Exchange. In that case, you could either extend the AD schema to include Exchange attributes or you could work with Azure AD synchronization rules, which is safer in my opinion.

On the Azure AD server, open Synchronization Rules Editor

Edit the rule "in from AD - User join". This will disable the rule itself and create a new one. Give the rule a descriptive name and a precedence of 50.

Under Transformations, add a new rule:

Expression msexchHideFromAddressLists IIF(IsPresent([msExchAssistantName]),IIF([msExchAssistantName]="HideFromGAL",True,False),NULL) Update

Now, you can set the attribute msExchAssistantName to HideFromGAL on the AD user. This will tell Azure AD Connect to set msexchHideFromAddressLists to true on the cloud side.

Obviously, you could use another attribute to achieve the same goal. Just change the if statement slightly.

IIF(IsPresent([msExchAssistantName]),IIF([msExchAssistantName]="HideFromGAL",True,False),NULL)

References:

https://jackstromberg.com/2018/08/how-to-hide-users-from-the-gal-in-office-365-synchronized-from-on-premises/

If a computer is in an Active Directory Domain environment with Exchange On-Prem installed, Outlook clients might connect to local Exchange instead of Exchange Online, because they query Active Directory first.

This Registry key will avoid SCP Lookup in Active Directory.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
DWORD ExcludeSCPLookup 1

If you are curious, SCP is located here (you can view it with ADSIEdit inside the Configuration Partition):

CN=Services, CN=Microsoft Exchange,CN=Organization, CN=Administrative Groups,CN=Exchange Administrative Group, CN=Servers,CN=YourServer,CN=Protocols,CN=Autodiscover,

References:

https://jacob.gardiner-moon.co.uk/2016/06/13/outlook-autodiscover-connecting-local-exchange-server-instead-office-365/