Tag Archives: Exchange 2019

Office Online server – Sorry there was a problem and we can’t open this document

For a current project I am working with Exchange 2019 and for OWA we want to implement Office Online Server. I did this in the past and blogged about it (Install Office Online Server 2016) so I thought it should not be a big deal.

Installed Windows 2016, installed prerequisite software, configured an SSL certificate, installed Office Online Server and created a new Office Web Apps farm.

After testing the https://fqdn/hosting/discovery and configured the organization configuration everything must be good.

When opening an attachment in OWA I do see the OOS environment, it tries to open a document and then generates this error:

“Sorry, there was a problem and we can’t open this document. If this happens again, try opening the document in Microsoft Word.”

When opening an Excel attachment, I get the following error message:
“Unable to open the file. We couldn’t find the file you wanted. It’s possible the file was renamed, moved or deleted.”

I know Office Online Server is sensitive for SSL certificates, but this was a regular Digicert certificate. Name resolution was fine as well. But the check https://fqdn/op/generate.aspx failed as well with the following (pretty useless) error:

“Server Error. We’re sorry. An error has occurred. We’ve logged the error for the server administrator.”

Unfortunately, nothing useful in the eventlog, or in the ULS logging on the Office Web Apps server. Asked colleagues, but they had only experience with Exchange 2016 and OOS.

After two days of searching, fiddling with the server, checking .NET versions (Windows 2016 comes with a newer version of .NET then required by Office Online Server), rebuilding the Office Online Server several times I realized it might be a TLS 1.2 issue. Exchange 2019 is using TLS 1.2 only by default, whereas Exchange 2016 can use multiple versions of TLS.

So, on the Windows 2016 server with OOS, I enabled strong cryptography in .NET and disabled older versions of TLS on Windows to fix the issue.

To enable strong cryptography in the .NET Framework, add the following registry key:


To disabled older versions or TLS, add the following registry keys:


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]

After rebooting the Office Online Server, it worked as expected.

Security Updates Exchange Server December 2020

On December 8, 2020 Microsoft released a number of security updates for Exchange server. Despite the fact that Exchange 2010 is out of support at all, an important security update for Exchange 2010 was released as well.

Exchange versionKB ArticleDownload
Exchange 2010 SP3 RU31KB4593467Download
Exchange 2013 CU23KB4593466Download
Exchange 2016 CU17KB4593465Download
Exchange 2016 CU18KB4593465Download
Exchange 2019 CU6KB4593465Download
Exchange 2019 CU7KB4593465Download


  • The security updates are specific for each Cumulative Updates.
  • The upcoming CU’s for Exchange 2016 and Exchange 2019 will contain this security fix.
  • Install the security updates from an elevated command prompt.

Open attachment in Shared Mailbox using OWA

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.

The error message reads:

Hmmm… can’t reach this page
It looks like the webpage at

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.


On October 13, 2020 Microsoft released a security update for Exchange 2013, Exchange 2016 and Exchange 2019 that addresses the Microsoft Exchange information Disclosure Vulnerability as discussed in CVE-2020-16969 | Microsoft Exchange Information Disclosure Vulnerability

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.

ProductKB ArticleDownload
Microsoft Exchange Server 2013 Cumulative Update 23KB4581424Security Update
Microsoft Exchange Server 2016 Cumulative Update 17KB4581424Security Update
Microsoft Exchange Server 2016 Cumulative Update 18KB4581424Security Update
Microsoft Exchange Server 2019 Cumulative Update 6KB4581424Security Update
Microsoft Exchange Server 2019 Cumulative Update 7KB4581424Security Update

Exchange 2019 CU7 Exchange 2016 CU18

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 😉.


More information

Updated on October 30, 2020