Last September Microsoft released their quarterly Cumulative Updates for Exchange, Exchange 2016 CU18 and Exchange 2019 CU7. This was quickly followed by a security update, KB4581424 that addresses the CVE-2020-16969 Microsoft Exchange Information Disclosure vulnerability.
Unfortunately, the Exchange 2016 CU18 and Exchange 2019 CU7 contain a nasty bug. If you use OWA, open a shared mailbox and try to access an attachment, OWA redirects to Office 365 instead of the on-premises Exchange 2016/2019 server to download it. This happens in an hybrid environment, but also in a pure on-premises Exchange deployment without any Office 365 connection.
Microsoft is aware of this issue and it will be fixed in the next Cumulative Updates for Exchange 2016 and Exchange 2019. Looking at the quarterly cadence this should be by the end of this year.
If you have a Microsoft Premier support contract and this is an issue that impacts your business you can open a support ticket and request a fix for this. This service is available for Premier support customers only.
This fix is a replacement for the KB4581424 security update, as such it contains all the fixes in KB4581424, plus the OWA Attachment hotfix. If you are a Premier support customer and do have this fix available, make sure that you uninstall the KB4581424 first before installing this update. One workaround that I’ve seen in a newsgroup is not to open the Shared Mailbox as “Open another mailbox” but as “Add shared folder”. This should work also, but I have not tested it. I do have a customer with a Premier support contract, I can confirm the problem is fixed in the interim update.
After migrating all mailboxes to Exchange 2016 and Exchange Online it is time to decommission the old Exchange 2010 servers. One of the servers could not be removed and the dreaded “This mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, or arbitration mailboxes” was shown:
This typically means that there is some sort of mailbox (arbitration or archive) is still available in the database, causing this issue. Unfortunately using the -Verbose switch did not reveal any other useful information.
Also, when trying to use Remote PowerShell directly (Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010, which bypasses RBAC and sometimes help) dit not help either this time.
Note. I was able to find dozens of similar threads on the Internet about this warning, but not a single one applied to my scenario. Ok, I found one where they removed the mailbox database using ADSI Edit, but on the long term that will cause other issues I’m afraid. You can do this, but there are still references to this mailbox database in Active Directory, so stuff will be lingering if you do this. Also, a lot of the threads are about Exchange 2013 and higher, but we were decommissioning Exchange 2010.
Last resort is to look directly into the mailbox database properties in Active Directory using LDP.exe. In LDP, navigate to the mailbox database and open the details (or dump it to a text file). Using the dump a user account was found that still referenced this mailbox database for an archive mailbox:
The user account was fixed and we were able to remove the mailbox database.
An information disclosure vulnerability exists in how Microsoft Exchange validates tokens when handling certain messages. An attacker who successfully exploited the vulnerability could use this to gain further information from a user.
To exploit the vulnerability, an attacker could include specially crafted OWA messages that could be loaded, without warning or filtering, from the attacker-controlled URL. This callback vector provides an information disclosure tactic used in web beacons and other types of tracking systems.
The security update corrects the way that Exchange handles these token validations.
Please be aware that the updates are CU specific. The fact that an update for Exchange 2013 is released indicates the importance of this Security Update.
When installing, start the Security Update from an elevated command prompt (Run As Administrator) and as always, test the security update thoroughly.
Microsoft Exchange Server 2013 Cumulative Update 23
On September 15 Microsoft released two updates for their on-premises Exchange servers:
Exchange 2019 Cumulative Update 7
Exchange 2016 Cumulative Update 18
Note. This is the second-last Cumulative Update for Exchange 2016! As Microsoft has announced earlier, Exchange 2016 will be out of mainstream support this October. The last Cumulative Update is expected in December 2020.
Both updates contain security and nonsecurity updates, the recently released security update for Exchange 2016 and Exchange 2019 that addresses the CVE-2020-16875 vulnerability is also included in these CU’s.
Both updates also contain the latest Daylight Saving Time (DST) Updates.
In earlier posts it was mentioned that no changes in Active Directory are introduced, so there was no need to run Setup with the /PrepareAD and /PrepareDomain option. However, when you check the Microsoft documentation you’ll notice that AD and Domain versions are increased, so this time there is a need to run /PrepareAD and /PrepareDomain. If you run the /PrepareAD, make sure you have sufficient permission to execute this command (member of the Enterprise Admins Security Group).
The same is true when upgrading for Exchange 2016. you must run Setup.exe /PrepareSchema, Setup.exe /PrepareAD or Setup.exe /PrepareDomain.
Autodiscover EventID 1 can occur after installing Exchange 2019 CU3 or after installing Exchange 2016 CU14. I’ve blogged about this before on EventID 1 MSExchange Autodiscover. I am not sure if this still is the case 😉.
Exchange 2019 CU7 is only available on the Volume License Service Center (VLSC)