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:

  1. Stop the Replica service on the node you are changing.
  2. 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
  3. 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.
  4. Take ownership of the old xds-replica folder inside of the old RtcReplicaRoot folder.
  5. Delete the old RtcReplicaRoot folder.
  6. Share the new xds-replica folder inside of the new RtcReplicaRoot folder.
  7. Grant Network Service full control of this share.
  8. Grant (Local)\RTC Local Config Replicator full control of this share.
  9. Open Regedit and navigate to HKLM\System\CurrentControlSet\Services\REPLICA
  10. Modify the drive letter referenced in the ImagePath value to point to the new drive.
  11. Start the replica service.
  12. Open the Lync ManagementShell and run:
    Invoke-CsManagementStoreReplication -ReplicaFQDN <Server FQDN>
  13. 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.

Moving the Lync Central Management Store

As companies move from piloting Lync to a full-blown implementation you’ll likely end up in a scenario where you need to move the Central Management Store (CMS) from a proof-of-concept pool to a production-worthy one.

This is hopefully a no-brainer, but first you should back up the CMS. Keep in mind that in order to restore the CMS you also need the LIS database, so export both of these.

Export-CsConfiguration –FileName
Export-CsLisConfiguration –FileName

Next, you need to install an empty database to house the new CMS. I typically use the –UseDefaultSQLPaths parameter to control where these databases are installed on the file system. You can also use the -DatabasePaths parameter for more control.

Install-CsDatabase –CentralManagementStore –UseDefaultSQLPaths –SQLServerFQDN <SQL Server FQDN>

Next, enable this topology change:


Verify all of your replicas are up to date before actually moving the CMS. When ready, log on to a Front-End server for the target pool hosting the CMS (Technet says the source, but this is incorrect. I’ve added a comment there as well). You’ll need to open the Lync Management Shell with elevated privileges (Right-click, Run as Administrator) or the next step will fail.


You’ll be prompted to confirm the source and destination. Press Y to accept the move and hopefully it succeeds!

I had to restart both the Master Replica Service and File-Transfer Agent service on the Front-End I used to move the CMS to clear up errors in the event log that it could not connect to the back-end database. Once done, very your replica status is all up to date again.

After the move you need to clean up a few things. You’ll want to launch the setup wizard and run the “Install or Update Lync Server System” step for any Front-End server which was part of the old pool, and for any Front-End server which is part of the new pool. This step adds or removes the required services for a Front-End to serve as a CMS master replica.