I decided to write a “Simple Lync CMS Explanation” article, the difference with this article is that I decided to use easy words not big words as much as I can, to make it easier for Engineers with little SQL experience to understand Lync Database and how does it work, replicate…etc.
So less words and more diagrams to make it understandable, instead of 5 pages of words
What is CMS?
Lync Central Management store (CMS), is a Microsoft SQL database (will be under the name xds in the SQL server) that is used by Lync to store the following data:
- Topology (contain all data and information created by the Topology Builder)
- Configuration (contain all Lync’s different settings e.g. Certificates, dial-in conferencing number)
- Policies (contain the different Lync Policy e.g. dial plans, client policies, meeting policies)
Those kind of data are stored as XML documents in the database, and CMS services replicate those data to the required servers.
In previous versions as in OCS and OCS 2007 R2, those kind of data were stored in the Active directory, Windows Management Instrumentation (WMI) and also SQL database, if you had worked with OCS you will remember that you needed to extend the Active Directory Schema to add a new features or functions and wait for replication across your AD infrastructure to complete, with Lync CMS it became way much easier as all data are stored in one location.
NOTE: Lync still save some user object information in Active directory to maintain “Backward Compatibility” with OCS.
Data stored in CMS can be stored with four different scope levels:
For each of those scope, there will be only one xml document, so if you have in your Lync deployment a site Dial plan in addition to the Global dial plan, there will be two XML document in your CMS, one for the Global dial plan and one for the site dial plan.
If you have good experience with SQL, you can check the “Document” table in the xds database and you will notice that each xml document end with a “scope” and only one file exist by scope
How to access CMS?
The answer for this question is “You cannot”, access to the CMS is limited by only a .dll file (programming library) called “Microsoft.Rtc.Management.Core”, the following Lync server tool are using this file:
- Lync Control Panel
- Lync Topology Building
- Lync Management Shell
So to modify data in CMS, you must use one of those Lync Management tools.
NOTE: this .dll file has too many validation rules to check if what you trying to do is supported by Lync core design, then when it find that it is valid, it writes the new data to the CMS.
CMS Directory Structure
Before explaining how does the CMS replication works, I will explain the structure of the CMS directory, but first you need to know that CMS operate in a Single master / multiple replica (another word: Copies) system, we will talk more about that later in this article, but this mean that any Lync deployment has ONE and Only ONE master CMS stored in the Lync file store defined in the Lync Topology.
Inside the file store you can find the “Central Mgmt” folder that is used by the Master CMS to replicate data.
The xds-master folder is where all the magic happens, this folder is located in \\Lync fileshare\CentralMgmt folder\CMS FileStore\
xds-master contain two sub folders:
Inside the replicas folder, you can find a folder for each Lync server you have in your deployment, the folder name will be the FQDN of the Lync server, to make things easier, let us say you have a simple Lync deployment that consist of 1 Lync Frontend (lyncfe.lyncdude.local) and 1 Lync Edge server (lyncedg.lyncdude.local), inside the replicas folder you should find two subfolders of those two Lync servers
Inside each of those subfolders, you will find another two subfolders (just try to keep up, I’m putting a big diagram in the end to show you overall view of the structure):
Here, we finished explaining the structure of the xds-master directory in the file share, and below is a diagram that helps you visualize the structure of the xds-master directory
As I mentioned, for each server there is a replicas folder with its name in the \xds-master\replicas\ directory. Each Lync server has a local “xds-replica” folder located under \\Lync server FQDN\xds-replica that it uses to replicate to or from the “xds-master”
If you log into one of the Lync servers, and navigated to C:\ drive, you find a folder called “RTCReplicaRoot” where under it you will find the xds-replica folder
NOTE: IF YOU TRY TO ACCESS THIS FOLDER YOU WILL NEED TO CHANGE THE OWNER OF THE FOLDER WHICH YOU SHOULD NOT DO BECAUSE IT WILL BREAK YOUR LYCN SERVER, I DID THAT ON A LAB
Under the xds-replica you find three subfolders:
How does CMS Replica works
Like I mentioned before, the CMS operate in Single Master / Multiple replicas (copies) system, so one master located on the SQL backend server (called RTC), and each Lync server in the topology have a copy (replica) of this master (called RTCLOCAL).
In case of an Enterprise edition pool deployment you will have a dedicated SQL server as a backend, so it will be like the following diagram, the master (RTC) stored on the SQL server and each Lync frontend will have a copy (RTCLOCAL)
in case of a standard edition pool deployment the master xds and the replica (copy) will be both hosted in the same server using SQL Express server
In case of the Edge server, which is not joined to the domain and located on a DMZ network, it gets the replication using HTTPS
The location of the master CMS is stored in an Active directory object called “msRTCSIP-GlobalTopologySetting” which under its properties you find an attribute named “msRTCSIP-BackEndServer”
This location is called “Service Connection Point” SCP which is created by the topology builder in the first time you published the topology and can be edited using the move-CsManagementServer cmdlet, or checked by using the Get-CsManagementConnection.
The CMS master has three service installed on it:
- Lync Master Replicator Agent
- Lync File Transfer Agent
- Lync Replica Replicator Agent
All those services are running on the CMS Master except for the “Replica Replicator agent which is not, the Replica Replicator agent services runs on other Lync servers in the topology.
Step by Step Replication (more words)
- Each 60 seconds a task run to check if there is any changes made to the CMS master that need to be replicated.
- If changes are found (xml files), they are all packed in a Data.zip file which have size less than 100KB to make the replication fast
- The data.zip is copied to each “to-replica” folder of each server’s replica folder in the xds-master directory
- The FTA service running on the Master monitor all “to-replica” folders and once it sees a data.zip file in them it start the replication process
- On the servers themselves, the Replica replicator is monitoring the “from-master” folder, once it sees a data.zip file in it, it unpack it and apply the changes to the server
- After the changes are applied, a status.zip file is created and placed in the “to-master” folder in the server.
- FTA is monitoring “to-master” folders on all Lync Servers and once it sees status.zip file it pull it to the “from-replica” folder on the CMS-Master
- The Master replicator then unpack the package and update the status CMS-Master
For Edge: Lync edge server uses the replication web services over HTTPS / 4443 port to copy the Data.zip file, the replication web services uses the internal Certificate issued by the internal CA and trusted by the Lync in the replication process.
NOTE: it takes 60 seconds to pull changes from Master + some seconds to apply the changes + 60 seconds to pull from replica + some replication delays maybe, that’s why it takes up to 3 minutes for changes to reflect and be visible by the Lync users