Troubleshooting: Exchange – Unable to open OWA, ECP, or EMS after a self-signed certificate is removed from the Exchange Back End Website

Troubleshooting: Exchange - Unable to open OWA, ECP, or EMS after a self-signed certificate is removed from the Exchange Back End Website

Troubleshooting: Consider the following scenario when you are using Microsoft Exchange Server 2013 or Microsoft Exchange Server 2016

  • You remove the Microsoft Exchange Self-Signed certificate from the Exchange Back End Website by using Certificates MMC, Remove-Exchangecertificate, IIS Manager, or another method.
  • You clear the IIS cache by restarting or IISReset.
  • You are installing a new SSL Certificate to your Exchange system.

In this scenario, several client protocols such as ECP, OWA, ActiveSync, and Exchange Management Shell cannot connect. The following issues may occur:

  • OWA and ECP display a blank page.
  • ActiveSync users cannot receive emails.
  • Exchange Management Shell will not connect and displays the following Error:
    New-PSSession : [dc.local.mcrlegal.com] Processing data from remote server dc.local.mcrlegal.com failed with the following error message: The WinRM Shell client cannot process the request. The shell handle passed to the WSMan Shell function is not valid. The shell handle is valid only when WSManCreateShell function completes successfully. Change the request including a valid shell handle and try again. For more information, see the about_Remote_Troubleshooting Help topic.
    At line:1 char:1
    + New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Microsoft.Excha …
        + CategoryInfo          : OpenError: (System. Manageme….RemoteRunspace: RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : -2144108212,PSSessionOpenFailed
    Failed to connect to an Exchange server in the current site.
    Enter the server FQDN where you want to connect.:

Cause


During the setup process, a self-signed certificate called Microsoft Exchange is bound to the Exchange Back End Website on port 444. This is for communication between the Default Web Site Front End where the third party CA-issued certificate is installed on, and Exchange Back End web sites.
By default when the Front End gets a new SSL Certificate bound/assigned to its HTTPS binding the Back End magically un-assigns the Self Signed certificate that was previously assigned. When the certificate is removed or changed, the Default Web Site will no longer be able to proxy connections to the Exchange Back End website.

Resolution


To resolve this issue, add the certificate back to the Exchange Back End website Or Create a new self-signed certificate, and then bind it to the Exchange Back End website.

Note:  These steps should be taken on the Exchange Mailbox server role:

  1. Start Management Shell on the Mailbox server.
  2. Type New-ExchangeCertificate.
    Note: If you are prompted to overwrite the default certificate, select No.
  3. Start IIS Manager on the Mailbox Server.
  4. Expand Site, highlight Exchange Back End, and select Bindings from the Actions pane in the right side column.
  5. Select Type https on Port 444.
  6. Click Edit and select the Microsoft Exchange certificate.
  7. From an administrator command prompt, run IISReset.

 

Recent Posts

S/MIME for Outlook O365 Windows

Add to Favorites S/MIME Advantages of S/MIME Certificates S/MIME (Secure/Multipurpose Internet Mail Extensions) certificates offer several advantages when it comes to securing email communications. Here

Read More »

Abbreviations

Add to Favorites There are literally thousands of IT abbreviations out there. Many are concerned with the technical aspects of the computer, while others deal

Read More »

SSL Installation on Qmail

Add to Favorites SSL Installation on Qmail Qmail is a secure, reliable, efficient, simple message transfer agent. It is designed for typical Internet-connected UNIX hosts.

Read More »