Tag Archives: OWA

Exchange Server OWA and ECP not working

Since a couple of days my OWA and ECP are not working anymore. This happens on both Exchange 2019 CU11 and Exchange 2016 CU22, in two AD sites both with external access. I didn’t notice before since Outlook Mobile and Outlook on the desktop continue to work. After logging in, the Something went wrong message appears, in the navigation bar you can see it is an Error 500 message.

I think (but I’m not sure) that this started after applying the latest November 2021 Security Updates and this is usually caused by starting the Security Update without elevated privileges. There’s an Microsoft article about this: OWA or ECP stops working after you install a security update – Exchange | Microsoft Docs.

I am pretty sure that I installed the Security Update with elevated privileges, but also after reinstalling the Security Update (with elevated privileges!) the error continues. The Microsoft article also mentions settings in IIS Manager (Application settings > BinsearchFolder), but that was not the issue (settings were ok).

When authentication fails, two entries are written in the Application Eventlog, EventID 1003 (MSExchange Front End HTTP Proxy) and EventID 1309 (ASP.NET 4.0.30319.0). The latter clearly shows it has something to do with certificates:

It turned out that the Exchange Server Auth Certificate was expired, just a few days ago. You can see this when running the following command:

[PS] C:\>(Get-AuthConfig).CurrentCertificateThumbprint | Get-ExchangeCertificate | Format-List

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule,
CertificateDomains : {}
HasPrivateKey      : True
IsSelfSigned       : True
Issuer             : CN=Microsoft Exchange Server Auth Certificate
NotAfter           : 11/28/2021 12:23:07 AM
NotBefore          : 12/24/2016 12:23:07 AM
PublicKeySize      : 2048
RootCAType         : Unknown
SerialNumber       : 268E6FB9B7312AB24AAA6BA76D06190D
Services           : SMTP
Status             : Invalid
Subject            : CN=Microsoft Exchange Server Auth Certificate
Thumbprint         : A7F9CAA2C9016DB2A80F1E2972E2ED0E2FAE089D

As shown in the following screenshot:

Use the New-ExchangeCertificate command to create a new self-signed certificate for authentication purposes:

[PS] C:\>New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName @()

Overwrite the existing default SMTP certificate?

Current certificate: 'D7081FC32B9BFBEF0C0581584976F690D5F86E74' (expires 11/30/2026 5:21:19 PM)
Replace it with certificate: '309263C8C5B2DA9612E8A6FA9FFFCDEBAC93335D' (expires 11/30/2026 9:00:56 PM)
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): n

Thumbprint                                Services   Subject
----------                                --------   -------
309263C8C5B2DA9612E8A6FA9FFFCDEBAC93335D  ....S..    CN=Microsoft Exchange Server Auth Certificate

As shown in the following screenshot:

When the certificate is created, the AuthConfig needs to be configured, it needs to be published and the old (and expired) certificated needs to be removed. Use the Set-AuthConfig command to achieve this:

[PS] C:\>Set-AuthConfig -NewCertificateThumbprint 309263C8C5B2DA9612E8A6FA9FFFCDEBAC93335D -NewCertificateEffectiveDate (Get-Date)

The new certificate effective date is not at least "48" hours in the future and may not be deployed on all necessary
servers. Do you wish to continue?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y
[PS] C:\>Set-AuthConfig -PublishCertificate
[PS] C:\>Set-AuthConfig -ClearPreviousCertificate

As shown in the following screenshot:

Restart the Microsoft Exchange Service Host service and perform an IISRESET. If you cannot run IISRESET you can also recycle both the OWA and ECP App pool:

[PS] C:\> Restart-WebAppPool MSExchangeOWAAppPool
[PS] C:\> Restart-WebAppPool MSExchangeECPAppPool

The certificate is stored in Active Directory in CN=Auth Configuration, CN=, CN=Microsoft Exchange, CN=Services,DC=, DC= as shown in the following screenshot:

Since it is published in Active Directory, the new certificate will be automatically available for all Exchange servers in your organization. It can take up to an hour before it is fully published and available, so don’t worry when it doesn’t work immediately.

Please be aware that you do this only on one Exchange server. If you (accidentally) do this on multiple Exchange servers, you will see multiple Auth Certificates appear on your Exchange server. But only the last one created will be active though.

Only two steps remain:

  • Remove the old Auth Certificate on all Exchange servers. You can do this using EAC or using PowerShell (Remove-ExchangeCertficate -Server -Thumbprint <old certificate).
  • Run the Hybrid Configuration Wizard again to update the new certificate in Azure Active Directory.

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.

Office 365 Message Encryption OME

Office 365 Message Encryption (OME) is a Microsoft solution to send mail safely, fully encryption with multiple layers of protection. Instead of sending an email to a recipient via SMTP, the message is encrypted and stored on a Microsoft viewing portal. An informational message is sent to the recipient with a one-time password which the recipient can use to logon to the viewing portal and read the (decrypted) message as shown in the following picture:

Office 365 Message Encryption Overview

To configure OME you have to enable Azure Rights Management first. To do this, open the Office 365 Admin portal and select Settings | Services & Add-ins. In the details pane select Microsoft Azure Information Protection. Click Manage Microsoft Azure Information Protection Settings as shown in the following screenshot:

Enable Azure information Protection

Click Activate and after a few moments you will see a confirmation.

Azure Rights Management is activated

If you open Exchange Online Powershell and execute Get-IRMConfiguration you will see that AzureRMS is enabled as shown in the screenshot below. Please note that the LicensingLocation is empty, this is important in subsequent steps.


According to Microsoft documentation you should now be able to test the IRM configuration using the Test-IRMConfiguration command, but this will fail with a “Failed to acquire RMS templates” error as shown in the following screenshot:

Test-IRMConfiguration Fails

The reason for this (took me some time to figure out) is that the LicensingLocation property is empty. To populate this property, we can retrieve the correct value from the Azure AD Right Management service using PowerShell. This can be installed using the Install-Module AIPService command.

After installing, open the Exchange Online PowerShell module and execute the following commands:

PS C:\> $RMSConfig = Get-AadrmConfiguration

PS C:\> $RMSConfig

PS C:\> $LicenseUri = $RMSConfig.LicensingIntranetDistributionPointUrl

PS C:\> $LicenseUri

PS C:\> Set-IRMConfiguration -LicensingLocation $LicenseUri

PS C:\> Set-IRMConfiguration -InternalLicensingEnabled $true

Note. The only reason for executing the $RMSConfig and $LicenseUri commands is to check is there are any values in these variables. The output is shown in the following screenshot:


When you execute the Test-IRMConfiguration command again you will see it succeeds:


So how do you know this works?

The easiest way is to use OWA. To create an additional “encrypt” button in OWA, execute the following command in the Exchange Online PowerShell window:

PS C:\> Set-IRMConfiguration -SimplifiedClientAccessEnabled $true

Now when creating a new message in OWA this button is clearly visible. Send a new message (to your own test account for example in Gmail) and click the Encrypt button. A message will appear that this message is encrypted, nice to know, the recipients cannot remove the encryption, only the sender of the message can change this. You can use the change permissions button to change it from encrypt only to do not forward or confidential.

Encrypt button in OWA

After a few second the email will appear in Gmail, but not directly. You have to open the decrypted message on the viewing portal. A one-time password can be used (which is sent to the same email address, i.e. the Gmail address we used here) or you can use the Gmail account to logon. The latter is also true if the recipient is a hotmail mailbox or even nicer, an Office 365 mailbox.

OME in Gmail

When you click Read the message it will be opened on the viewing portal.

view ome

A message is displayed again that this is an encrypted message. When you reply to the message, an encrypted message is returned to the original sender. If you have selected do not forward in the permissions drop down box earlier, the recipient does not have this option and can only reply to the message.

It also works fine in Outlook (I have tested this with Outlook 2016 Click-2-Run, still have to test other versions). If you create a new message and select Options, you can select Connect to Rights Management Server and get templates under Permissions as shown in the following screenshot:

Outlook Connect to Rights Management Server

This will retrieve the RMS templates from Exchange Online that were created earlier in this blog post. In a few seconds you will see the following options:

  • Encrypt Only
  • Do not forwards
  • Confidential
  • Confidential View Only

Outlook Set permissions on this item

When you select Encrypt Only  as shown in the following screenshot an encrypted message will be sent to the intended recipient:

Outlook Encrypt Only

From this point the behavior will be the same as with Outlook Web App as discussed earlier in this blog post.


Outlook Message Encryption as outlined in this blog post is a way to send encrypted messages to recipients. It’s not encryption in transit like TLS or S/MIME, but the encrypted message is stored on a Microsoft server. The recipient will receive an email that an encrypted message is waiting, and the recipient can logon to a special website using a one-time password (or using a Microsoft or Gmail account).

Since the RMS (Rights Management Service) templates are used it is also possible to use additional features like do not forward (the forward button is greyed out) or tag a message as confidential. This can be used in combination with transport rules to add additional features or mail flow when it comes to confidential information, functionality that’s not available when using good old email.

Office Web Apps 2013 server not working, CPU Utilization 100%

Recently I had to reinstall my entire infrastructure, and one of the servers was the Office Web Apps server. Unfortunately the server was willing to do anything, the only thing I got was a white screen, or the ‘old’ WebReady Document view appeared. The discovery URL (https://webapps.exchangelabs.nl/hosting/discovery) was working fine, so at least something was working.

Another thing that was clearly visible was that processor utilization regularly peaked to 100%, sometimes staying at 100% for a longer period of time:


Continue reading Office Web Apps 2013 server not working, CPU Utilization 100%

MEC RECAP – It was great

All good things come to an end and that’s also true for MEC 2014. On the day after MEC 2014 it is time to rethink the event. Overall it was an awesome event, despite the dull keynote session although the videos shown there were great, especially the one featuring David Espinoza and Greg Taylor on email innovation:


Continue reading MEC RECAP – It was great