Moving the Lync RtcReplicaRoot Folder Drive
A fairly frustrating item in any Lync deployment is the fact that you cannot control what drive the Replica service creates its folder and file share on. There is no way to control this during the Lync installation and it seems fairly random as far as I can tell.
In many instances a Lync server will only have a single disk so this isn’t a big issue, but if you are collocating a Monitoring or Archiving role on a SQL cluster node you can run into some serious problems. Since the drive selection is random, you may find the RtcReplicaRoot folder created on a shared cluster disk. This works fine when that node is active, but as soon as the cluster fails over that drive letter becomes inaccessible and the replica’s topology is out-of-date.
In a scenario where you find the folder on the wrong drive you can move it, but it does require a few manual steps. Much of this is a combination of a Technet forum thread and my own experience, but here is the process which worked for me:
- Stop the Replica service on the node you are changing.
- Open a command prompt (As Administrator) and use this command to move the content:
xcopy <Old Drive>\RtcReplicaRoot <New Drive>\RtcReplicaRoot /O /X /E /T /H /K
- Manually unshare the old folder. It does not show in the Computer Management shares snap-in, so you should check the folder properties directly and unshare from there.
- Take ownership of the old xds-replica folder inside of the old RtcReplicaRoot folder.
- Delete the old RtcReplicaRoot folder.
- Share the new xds-replica folder inside of the new RtcReplicaRoot folder.
- Grant Network Service full control of this share.
- Grant (Local)\RTC Local Config Replicator full control of this share.
- Open Regedit and navigate to HKLM\System\CurrentControlSet\Services\REPLICA
- Modify the drive letter referenced in the ImagePath value to point to the new drive.
- Start the replica service.
- Open the Lync ManagementShell and run:
Invoke-CsManagementStoreReplication -ReplicaFQDN <Server FQDN>
- Restart the Replica service once more and verify your topology status is up-to-date.
Hope this helps. Pretty sure this falls in the unsupported section since this is not documented anywhere.