What is Central Management Store (CMS)?
- Central Management Store (CMS) is a repository to store management data in the form of topology, configurations and policies.
- The access to the repository is provided through and limited to a Microsoft Lync Server Dynamic Link Library (DLL) called Microsoft.Rtc.Management.Core.dll. The DLL also enforces validations and scope resolutions etc. All consumers of the repository and its data, including service components and Lync Server Management Shell, uses this dll to interact with the CMS store.
- CMS implements and checks many rules for dependencies and inter-dependencies between components and server roles. In this way we make sure that the topology is valid and does not contain any un-supported configurations.
- CMS includes the key functionality of validating any information being written to it before it commits to the database.
- CMS operates in a single master/multiple replica system.
- In every Lync Server deployment there is only a single master CMS and all servers running Lync Server have a local replica of CMS. All updates to information in CMS takes place at the master.
- It is recommended to install CMS on an Enterprise Edition (EE) pool so that it benefits from the high availability built into the Enterprise Edition.
- Each Front-End in the pool will have the replica xds database in a local SQL Express instance called RTCLOCAL.
- Mirroring the front-end servers in an Enterprise Edition pool the Standard Edition pool will also create a replica xds database located in the SQL Express instance called RTCLOCAL
The location of the master is found by looking up a Service Connection Point (SCP) for the master CMS. The SCP is an object in Active Directory created under the path of the following Distinguish Name (DN), CN=Topology Settings, CN=RTC Service,DC=<domain>, of type msRTCSIP-GlobalTopologySetting. This object contains the msRTCSIP-BackEndServer attribute, which specifies the FQDN of the master and the instance name of the SQL Instance.
Move-CsManagementServer has to be used to move CMS and it will also update the SCP to point to the new location.
CMS is implemented using three Windows services:
- Lync Server Master Replicator Agent (MASTER)
- Lync Server File Transfer Agent (FTA)
- Lync Server Replica Replicator Agent (REPLICA).
All three services run on the CMS master; however, only REPLICA runs on the replica .
CMS stores three types of information: Topology, Policy and Configuration and these three types of information can be stored in four different scope levels: Global, Site, Service and Tag.
How does CMS replicate?
The CMS master uses a directory structure shared with other Lync Server components in network share defined in the topology document. The name of the top level directory is the Service Id of the CMS master. The tree structure is the following: <Lync Server FileStore>\<CMS Service Id>\CMSFileStore\xds-master, where <Lync Server FileStore> is the name of the directory selected to be the FileStore used by the CentralMgmt service in the topology document and CMS Service Id is the Service Id of the CentralMgmt service in the topology document . The directory, xds-master, contains two sub-directories replicas and working. The replicas directory contains a sub-directory for each of the replicas. Each sub-directory is named after the server’s FQDN. Within each replica directory are two sub-directories: from-replica and to-replica.
Each replica uses a directory structure in the file share, xds-replica (\\<replica>\xds-replica), to synchronize with the CMS master, where <replica> is the FQDN of the replica. The xds-replica contains three sub-directories: from-master, to-master and working.
Each 60 seconds a task is run to determine if a change has been made to the CMS master and needs to be replicated. The unit of replication is the changed XML document, i.e. if a dial plan with global scope has been added, the full XML document containing dial plans with global scope will be replicated. All changes made since the last time the task was run are batched together into a data package – data.zip.
The size of the data package is small, typically less than 100 Kb, which makes for fast replication across the network without any substantial impact to the bandwidth.
The MASTER generates the data package containing new changes to CMS and stores a copy in each to-replica directory for every replica.
The data package must be copied to all replicas. All Lync servers, except the Edge Server, uses the Windows file copy SMB[4] protocol mechanism to push the data package from the CMS master to the replica.
For Edge servers the file copy is performed over an HTTPS channel. The Edge Server runs a Web Service (https://<edgeserverfqdn>:Port/ReplicationWebService) on the port specified for the ManagementServices in the topology document. The default port is 4443
Get-CsManagementStoreReplicationStatus –CentralManagementStoreStatus –Gives the status of CMS replication.
It is the responsibility of the FTA service running on the CMS master to copy the data packages from the master to the replicas. The FTA service has change notifications on all the to-replica directories. It is alerted when the MASTER service places data packages in those directories and starts the file copy process to the replicas.
On a replica the REPLICA service has change notification on the from-master directory. It gets alerted when the FTA service has copied the data package to the replica. It then extracts the data package and applies the changes to the local CMS replica. After applying the CMS changes the REPLICA generates a status package – status.zip.
The status package contains information for the CMS master about the status of the application of the CMS changes.
The REPLICA service will place the status package in the to-master directory. The FTA service running on the CMS Master has change notifications on the to-master directory on all replicas (except on Edge Servers). It is alerted about the new status package. On Edge Servers the FTA regularly polls the to-master directory to see if a status.zip package is placed there. Then polling frequency is increased when the FTA is expecting a status.zip package, i.e. after it has just transferred a data.zip package to the Edge Server. It then copies the status package from the replica to the from-replicadirectory on the CMS Master for the given replica. The MASTER has change notifications on all from-replica directories. It will process the status package and update the CMS Master. When a Lync Server starts up the REPLICA generates a status.zip package to report the current status to the CMS Master.
Reference:
what-is-central-management-store-cms?
Happy Learning….!!!
Former Microsoft Premier Unified Communication Engineer
Anoop Karikuzhiyil Babu
[…] Central Management Store explained […]