- 1 Summary
- 2 General
- 3 Types and Uses of Databases in Lync 2013
- 4 Replication and file sharing for CMS replication
Databases and Replication are the dorsal spine of every Lync deployment since Lync server 2010. They allow a Lync environment to have only one configuration tools set (Topology Builder and Control Panel). They are used to share the information between the server, the pool and the sites, without them nothing can work on your Lync environment, but there isn’t a lot of information about it on the Web. Here is a dive into those processes that make Lync so efficient.
The Central Management Store (CMS) stores a copy of the entire Lync topology for your deployment. Every server has a copy of the CMS (the replicas), but the replication system can have only one master. The CMS replication process uses a local file share on each server to copy updates between servers. Each Lync server downloads a copy of the CMS from this master at regular intervals. This process of transferring information updates from master to replica is called replication. The replication process consists of copying information between directories from the master to the replicas, applying the changes received to the replica and report status back to the master. By default, the first Lync server you deploy is designated the master CMS. However, there may be cases where you have to move the master CMS to another server. This can be done relatively easily, assuming you follow the documentation properly.
The CMS master uses a directory structure shared with other Lync Server components in network share defined in the topology document. The share is called \\servername\xds-replica. Every server has this share, including the CMS master. The share is typically located in the root of the C: drive in the folder C:\RtcReplicaR
oot\xds-replica. If you installed Lync on another drive, this folder will be in the root of that drive.
Types and Uses of Databases in Lync 2013
There is different database that are used on Lync 2013 environment, some of them need to be shared across the Lync environment like the CMS, some of them are unique for each pool like the pool configuration.
Central Management Store (CMS)
The CMS store is used by the Central Management Service to maintain a current Lync Server 2013 Topology for the entire Lync deployment (Topology, Policies, Voice Routes, etc…). Here is what you need to know about the CMS:
- The database used for this purpose is called “Xds”; it maintains the Lync configuration as published by the Topology Builder.
- There is only one master copy of CMS database which is automatically installed on the first instance of a Standard or Enterprise Edition Lync pool. For Enterprise Edition pools this first instance will reside on the SQL back-end database for the pool.
- Every subsequent Lync server in the topology gets a read-only copy of it. A topology change on the master is replicated to each read-only copy on each Lync server. This is a key element to Lync Server’s survivability feature set – if the network connection between a Lync Edge server goes down for example, the Edge server still knows about the topology and can keep functioning.
The way to modify information in CMS is by using one of the tools: Topology Builder, Lync Server Management Shell and Lync Server Control Panel. Changes are replicated to all Lync server roles except the Lync Edge using the Windows file copy SMB protocol on port 445. Changes are replicated to the Edge role via HTTPS on port 4443. The Windows service “Lync server replica replicator agent” is responsible for receiving the snapshot and uploading the local copies of the databases. It then sends a status update to the Master Replicator (also a windows service) running on the CMS.
Pool Configuration Store
The pool back-end database is the heart of Lync functionality. The Registrar, User Services, and the Address Book use this database for registration, routing, presence information & conferences, replicating user information, in-band provisioning, and address book functionality. This is commonly referred to the Lync “back-end” database, and one exists for each Lync pool. The following 3 important databases are used for the core feature set of Lync:
- Rtc: stores persistent user data such as user contact lists, scheduled conferences, and access control lists.
- Rtcdyn: stores dynamic Lync user data such as presence information.
- Rtcab & Rtcab1: stores the raw Lync address book information (i.e. that is pulled from AD). The Lync Address Book server alternates use of these databases: one of them is used to service address book queries while the other is being updated. Once the updates are done, they switch roles. Theses databases contain a table called AbAttribute which specifies which AD fields will be used in the Lync Address Book (database and ultimately the Lync address book files). If you are having permission issues with either of these databases, see Access to the Lync Server Address Book Databases.
Lync server uses the following databases for the Call Park and Response Group applications:
- Cpsdyn: stores dynamic system information for the Call Park application
- Rgsdyn: stores dynamic runtime operational information for the Call Park application
- Rgsconfig: stores persistent configuration data for the Response Group application
Archiving and Monitoring Store
This store is used by the Lync Archiving Server Role and the Monitoring Server Role. There are 3 separate databases used:
- LcsLog: stores Instant Messaging and Conferencing data for archiving purposes (used by the Archiving Role).
- LcsCdr: stores the Call Details Records (used by the Monitoring Role)
- QoEMetrics: stores the Quality of Experience data (used by the Monitoring Role)
Lync server uses this database (named “lis”) to hold a network ‘wiremap’ that maps network elements (e.g. subnet, WAP’s, routers) to real civic addresses to provide the new Location and Emergency Services Support (E9-1-1) features.
All of the individual SQL databases used for each Lync purpose is listed here: SQL Server Data and Log File Placement.
Replication and file sharing for CMS replication
The file share that will be used for replication have to be set up in the topology. The content of this file share evolve depends of the server and service that are running on your Lync environment.The root of the file share contains three primary folder used to store shared data from:
- Server Application
- Central Management configuration
- Various Web Services in Lync.
These folder names are encapsulated in digits which denote the Site and Pool instance that each folder belongs to. The folder naming convention is –.
The ApplicationServerfolder contains data utilized by Lync applications like Call Park, Response Groups, and Call Admission Control. Within the child “AppServerFiles” folder the following three sub folders will exist be default.
- The CPS folder is used by the Call Park Service.
- The Rgs folder is used by the Response Group Service to store common data like Music On Hold audio files (.wav) configured on a Hunt Group. The “Rgs\Instances” and “Rgs\Queues” folders should contain a sub folder for each response group that is defined in the topology, but with nonsensical names reflecting a GUID associated to each one. There may also exist an “Rgs\Temp” folder which seems to store the originally uploaded music file.
- The PDP folder name stands for Policy Decision Point and is used by Call Admission Control (CAC) to distribute policies defining some of the CAC rules.
The CentralMgmt folder is used by the Central Management Server to temporarily store replication data sent to and from other active replication partners defined in the topology in the form of data.zip files containing XML data. 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 direction are two sub-directories: from-replica and to-replica.
Each replica uses a directory structure in the file share, xds-replica (\\\xds-replica), to synchronize with the CMS master, where is the FQDN of the replica. The xds-replica contains three sub-directories: from-master, to-master and working
The MASTER generates the data package containing new changes to CMS and stores a copy in each to-replica directory for every replica. 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 File Transfer Agent (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. The MASTER has change notifications on all from-replica directories. It will process the status package and update the CMS Master.