1. 检查RtcReplicaRoot文件夹共享权限

2. 在windwos server 2012 R2操作系统下增加注册表HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
   Add the following DWORD values:
   New DWORD ClientAuthTrustMode Hex Value=2
   New DWORD SendTrustedIssuerList Hex Value=0
   重启边缘服务器解决问题

   Successful replication of the management store within a Lync environment is key to ensuring that each server is aware of the most current topology, configurations, and policies. Replication failures between the master central management store (typically residing on the first Front End server in the pool) and other servers (replicas) can result in an inconsistent environment where servers have differing opinions on both what their own roles and responsibilities are, as well as others. This failure might result in immediate unexpected behaviour, or remain unnoticed for an extended period without obvious indication. The remainder of this post focuses on some of the more common fixes for Lync Edge server replication failure. Having recently stripped most of the hair from my head over this issue, consider this a checklist for anyone else who is in danger of becoming follically challenged.
   The Get-CsManagementStoreReplicationStatus shell cmdlet can be used to review or confirm the replication status within your environment. Our goal is to correct the below screenshot so that the UpToDate field for each server reads true. At this time our Lync Edge server appears to have a replication issue indicated by the False value – bad times.

In the absence of any useful event logs or Edge traces, consider the following remedial actions. In the majority of cases at least one of the below will prove applicable and resolve your replication problem (assuming that you have configured your Edge server correctly in the first instance).
#1 Invoke-CsManagementStoreReplication
Attempt manual instigation of the replication process using the above cmdlet to see if the issue persists. Once invoked, you can execute the earlier mentioned cmdlet of Get-CsManagementStoreReplicationStatus to review the results. Note that all servers listed will probably report false for a short period while the replication process completes, and realistically you are likely to find that your Lync Edge server replication problem will continue. Check event logs on both the Front End server that hosts the master CMS and the problem Edge server for any reported issues, but if nothing else this acts as confirmation of the problem.
#2 Port 4443 (Edge Replication Port)
Unlike internal Lync servers whose replication traffic is passed over SMB/445, our Edge server will use HTTPS/4443. Confirm that the server is listening and accessible via this port using some or all of the actions listed below:
I.) telnet EdgeServerFQDN 4443 – You should be able to telnet over 4443 from the CMS master (Front End) to the Edge server by either IP address or FQDN. The telnet client can be installed through server manager as a windows feature, and executed from a command prompt. Note that a successful connection results in a blank window, and a failure with an appropriate message.
II.) netstat -nap tcp | find “4443” – Execute this command from a command prompt on the Lync Edge server to ensure the server is listening for connections on port 4443. This should either yield a single ‘listening’ result, or an additional ‘established’ result if a replication cycle is in progress.
III.) https://LyncEdgeFQDN:4443/ReplicationWebService – Should be accessible via a web browser from your CMS master (Front End Server). The Windows Communication Foundation Service page should be returned.
If you identify a replication port issue, check to ensure the Lync Server Replica Replicator Agent service is running on the Edge server, and that all firewalls are allowing this traffic through on 4443 as required.
#3 Recreate the XDS-Replica Directory
The XDS-Replica folder is located within the C:\RtcReplicaRoot directory. If the permissions on the XDS-Replica folder or its subfolders are insufficient then this can lead to replication issues. Follow the below steps to recreate the folder. Also note that it is expected for you to have restricted access to this folder regardless of your privileges.
– Right click C:\RtcReplicaRoot\xds-replica and select properties
– On the security tab, select advanced, and click change (Owner)
– Add an appropriate account (i.e. administrator) as the new owner and select OK
– Check the ‘Replace owner on subcontainers and objects’ box
– Click OK, and Yes to the Windows Security Warning
– Delete the xds-replica folder
– Access Programs and Features from Windows Control Panel
– Select Microsoft Lync Server 2013, Core Components, and choose ‘Repair’
– Access the Lync Edge servers ‘Services’ management console
– Set ‘Lync Centralised Logging Service Agent’ service to Automatic (Delayed)
– Set ‘Lync Replica Replicator Agent’ service to Automatic (Delayed)
– Start both services
– Execute Invoke-CsManagementStoreReplication from Lync Management Shell
– Execute Get-CsManagementStoreReplicationStatus and review
Alternatively, Microsoft article kb2759117 discusses repairing of permissions on this folder as opposed to recreating it.
#4 SChannel Registry Keys
There are two registry entries that (depending on the cause of your issue) may resolve Lync Edge server replication problems. In reading and practice it appears that this is only relevant to Windows Server 2012 and its TLS/SSL behaviour. Using RegEdit, browse to the below registry container:
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
Add the following DWORD values:
New DWORD ClientAuthTrustMode Hex Value=2
New DWORD SendTrustedIssuerList Hex Value=0

Restart the Lync Edge server and check / invoke Central Management Store replication. I was recently able to resolve a problem of this nature using these keys (which is what prompted me to post this article), but was also required to implement them on the CMS master (Front End Server) in order to correct the issue.
#5 Invalid Root Store Certificates
A root store that contains certificates which are not actually root certificates can cause replication and services issues within Lync (Edge replication is just one symptom of such a problem). The second of the two registry keys mentioned above should address this issue, and prevent incorrectly stored certificates from causing a problem. However if you have implemented the key without any results, or indeed would rather not make the registry change, then check for invalid certificates in the root store.
All certificates in the root store should have the same value as the Issuer and the Subject when looking at the details tab of any given certificate. On the certificate path tab there should be just a single certificate listed under the Certification Path. This problem can present itself when certificates are published to servers through group policy. In larger environments it may not be feasible to inspect all root store certificates; the below PowerShell command can be used to compare the Issuer and Subject values, and pipe any non-confirming certificate details to a text file. Simply move any flagged certificates to the correct store or remove them completely.
Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$.Issuer -ne $.Subject} | Format-List * | Out-File “c:\computer_filtered.txt”
If you have an Edge server replication issue, then consider all of the above. This is not a definitive list of things you should go through and do in a chronological order (indeed I wouldn’t recommend that!)…. but it is a list of the most likely causes to any difficulty you might be having. Hopefully consolidating it will prove useful.