Skype for Business Event ID 30988 & 32178

Issue

Skype for Business Server Front-End Service (RtcSrv) will not start.

The following errors are logged in the LS User Services log.

Event ID: 30988
Log Name: Lync Server
Source: LS User Services

Description:
Sending HTTP request failed. Server functionality will be affected if messages are failing consistently.
Sending the message to https://sfbfe1.x500.co.uk:444/LiveServer/Replication failed. IP Address is 192.168.190.1. Error code is 0x2EFE. Content-Type is application/replication+xml. Http Error Code is 0x0.
Cause: Network connectivity issues or an incorrectly configured certificate on the destination server. Check the eventlog description for more information.
Resolution: Check the destination server to see that it is listening on the same URI and it has certificate configured for MTLS. Other reasons might be network connectivity issues between the two servers.

Event ID: 32178
Log Name: Lync Server
Source: LS User Services

Description:
Failed to sync data for Routing group {3C471A30-D8BA-5DCC-BD6F-EDFB8713CD3C} from backup store.
Cause: This may indicate a problem with connectivity to backup database or some unknown product issue.
Resolution:  Ensure that connectivity to backup database is proper. If the error persists, please contact product support with server traces.

Troubleshooting

I have seen this happen a handful of times recently, a couple down to human error, the other down to software updates installing new certificates.

This issue occurs because a certificate that is not self-signed is installed in the Trusted Root Certification Authorities store.  This is an incorrect configuration that can cause HTTP communication between Skype for Business servers to fail with an untrusted root certificate error.  Skype for Business Server 2015 deployments on Windows Server 2012 R2 experience this issue because Windows Server 2012 R2 implements checks for a higher level of trust for certificate authentication.

Note: A self-signed certificate is defined as a certificate in which the “Issuer” property and the “Subject” property on the certificate are the same.  This is normal and expected for Root Certification Authorities.

For example:

Issued to: COMODO RSA Code Signing CA
Issued by: COMODO RSA Certification Authority
Valid from: 09/05/2013
Valid to: 08/05/2028
Serial Number: 2E7C87CC0E934A52FE94FD1CB7CD34AF

Issued to: VeriSign Class 3 Code Signing 2010 CA
Issued by: VeriSign Class 3 Public Primary Certification Authority – G5
Valid from: 08/02/2010
Valid to: 07/02/2020
Serial Number: 5200E5AA2556FC1A86ED96C9D44B33C7

The above certificates ending up in an incorrect Certificate Store was a result of a McAfee update (detailed here).

You can identify these by running the following PowerShell command:

Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Select Issuer, Subject, Thumbprint | fl

Resolution

Remove incorrectly placed certificates from the Computer Account\Trusted Root Certification Authority\Certificates Store.

Reboot the server (it must be a reboot, service restarts won’t suffice), and the RtcSrv service will successfully start.

Advertisements

Leave a Reply

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

WordPress.com Logo

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

Google+ photo

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

Twitter picture

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

Facebook photo

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

w

Connecting to %s