Exchange Zero days are very common these days and there is a freshly baked one today (30th September 2022 as of writing). If you want to know what how the vulnerabilities work, take a look at the reference at the bottom. As a sysadmin I care about securing my systems.

Here are a few steps to mitigate this zero day vulnerability:

In IIS Manager on the Exchange Server, select the Autodiscover virtual directory and open URL Rewrite and add a new rule.

Select Request Blocking

Enter the string

.*autodiscover\.json.*\@.*Powershell.*

Using should be changed to Regular Expression.

Change URL to REQUEST_URI and save the changes.

References:

https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

A good backup tool uses VSS Writers to achieve application consistent backups, which also truncates transaction log files. You can also achieve that without having to do a backup. Here are the few commands:

diskshadow

You can add multiple volumes, if database and log files are located on different disk drives:

add volume D:

add volume E:

begin backup

create

end backup

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/