Lync Server 2013 Front-End service cannot start in Windows Server 2012

Symptoms

When you deploy Microsoft Lync Server 2013 to a computer that is running Windows Server 2012, the Lync Server 2013 Front End service (RTCSRV) cannot start. There are other potential symptoms that may be related, but they do not involve the RTCSRV service. For example, the replication service may not work from the Edge server internal interface to the Front End server if the Edge server is deployed to Windows Server 2012.

Additionally, the following events are logged in the LS User Services log:

Event ID: 30988
Source: LS User Services
Description:
Sending HTTPS request failed. Server functionality will be affected if messages are failing consistently.

Sending the message to https://URL.contoso.com:444/LiveServer/Replication failed. IP Address is 192.111.1.1. Error code is 2EFE. Content-Type is application/replication+xml. Http Error Code is 0.

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 causes may include network connectivity issues between the two servers.

Event ID: 32178
Source: LS User Services
Description:
Failed to sync data for Routing group from backup store

Cause: This may indicate a problem with connectivity to backup database or some undefined product issue.

Resolution: Ensure that connectivity to backup database is established and consistent. If the error persists, please contact Product Support with server traces.

Cause

This issue occurs because a certificate that is not self-signed was installed in the Trusted Root Certification Authorities store. This is an incorrect configuration that can cause HTTP communication between Lync servers to fail with an untrusted root certificate error. Lync Server 2013 deployments in Windows Server 2012 may experience this issue because Windows Server 2012 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.

Resolution

To resolve this issue, use one of the following methods:

• If you use group policies to deploy certificates, make sure that the Trusted Root Certification Authorities store only contains self-signed certificates (certificates in which the certificate property "Subject" is the same as the certificate property "Issuer"). Move any certificates that are not self-signed certificates from the Trusted Root Certification Authorities store to the Intermediate Certification Authorities store.

• If you import new certificates manually, make sure that you select the computer’s Trusted Root Certification Authorities store for the self-signed certificates, and the computer’s Intermediate Certification Authorities store for the certificates that are not self-signed certificates.

You can use a Windows PowerShell command to find certificates that are put in the Trusted Root Certification Authorities store incorrectly on the local computer. The following command compares the "Issuer" property and the "Subject" property of each certificate in the store, and then outputs details of certificates that do not meet the criteria of a self-signed certificate:

Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File "c:\computer_filtered.txt"