Skype for Business – Exchange 2013 OWA Sign in Fails – Error – Exception: UCWEB Failure: Code=TlsFailure, SubCode=TlsRemoteDisconnected, Reason=\r\nMicrosoft.Rtc.Internal. UCWeb.Utilities.UCWException: Unknown error (0x80131500)

Had an issue recently where OWA integration with Exchange 2013 and Skype for Business was not working and users were failing to sign into IM when using OWA.

I checked the logging file location on the Exchange Server for OWA Instant Messaging in the following directory

%Exchange install drive%\Microsoft\Exchange server\V15\Logging\OWA\InstantMessaging

I had multiple Exchange 2013 servers so i had to check all on the servers log files for references to the sign and i found a lot of these

Microsoft.Rtc.Internal.UCWeb.UCWAuthenticatedEndpoint, MethodName: InstantMessageOCSProvider.SignInCallback, InstantMessageServiceError: SipEndpointConnectionFailure, Exception: UCWEB Failure: Code=TlsFailure, SubCode=TlsRemoteDisconnected,

It referenced TLS so i immediately thought certificates would be the next place to check.

Summary of Fix

This relates to a Certificate issue either the Skype for Business server doesn’t trust the Certificate used for OWA or the Certificate doesn’t contain the SANs of the FQDN of the Exchange Servers.

As i was using UM i already had an internal certificate will all SANs but the certificate thumbprint was incorrect in the web.config file on the exchange servers. Below is what i did to fix it.

Checking Exchange Certificates

The Certificate assigned for use with OWA and SfB must follow there guidelines as defined on TechNet

The certificate that you use for Outlook Web App must be a certificate that is trusted by Skype for Business Server. One way to ensure that the certificate will be trusted by both Skype for Business Server and Exchange is to use your internal certificate authority to create a certificate on the mailbox server, making sure that the server FQDN is used for the subject name and that this FQDN appears in the certificate alternate name field. After the certificate has been created it can then be imported to your backend servers.

The net result is that the same certificate is used for two purposes:

1) communication between Exchange unified messaging and Skype for Business Server; and,

2) the integration between Outlook Web App and Skype for Business Server.

Web.Config file checks

With Exchange 2013 OWA there is a web.config file on the Exchange Server used to define the Lync Pool Name and Certificate in the following directory

%Exchange install drive%\Microsoft\Exchange Server\V15\ClientAccess\Owa

Under <AppSettings> you should have the IMServerName and Certificate thumbprint to be used so i checked this out.

<add key="IMCertificateThumbprint" value="1FE2CE2C19S4DDF9CF3F4686E46B729DDEC18811" />
<add key="IMServerName" value="" />   

Check Certificates on Exchange Servers

Next i went to Exchange servers and from Exchange Management Shell checked the certificate thumbprint that was referenced in the web.config file.

Next opened MMC on the Exchange Server and checked the Certificate for the common name and Subject Alternative Names. Here I noticed that the certificate was a self signed certificate and didn’t contain any SANs for the other exchange server therefore the Lync Server would not trust this so was probably my issue.

There was already a certificate on the Exchange Server for UM issued from the internal CA that was created which contained all the Exchange Server FQDNs which was in use for Exchange UM. I noted the thumbprint and updated the web.config on all Exchange Servers.

Update Web.Config and recycle OWA App Pool on all Exchange Servers

After updating the web.config with the correct server thumbprint i recycled the OWA from cmd prompt as administrator on each Exchange Server.

C:\Windows\System32\Inetsrv\Appcmd.exe recycle apppool /"MSExchangeOWAAppPool"


I retested and OWA works 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.