Central Management Store

The preceding section referenced the Central Management Store. To understand the responsibility of the CMS, it is important to understand how prior versions of the product operated such that server and service configuration was stored within Active Directory. Live Communications Server and Office Communications Server both stored configuration information within the System partition of the forest root domain. In many cases, this was acceptable, but it caused performance problems in scenarios in which a remote office had poor connectivity to a domain controller in the forest root domain.

This was because the System container is not replicated to all domain controllers in the forest, so servers could be required to leverage WAN links to read settings even if a domain controller existed locally.

To mitigate these problems, Office Communications Server 2007 R2 recommended migrating the settings to the Configuration container instead, which is replicated to all domain controllers in the forest. This solved the problem, but organizations had a confusing manual migration path to move settings to the new container and often skipped this step. Furthermore, organizations could not move the settings after installing OCS 2007 R2, so they were stuck in this state with performance problems.

With Lync Server 2010 and 2013, the settings for the deployment have moved from Active Directory to the CMS, which is just an additional SQL database. The CMS must be populated before the first pool is created, and this is done automatically if the first pool is a Standard Edition server. The CMS can be stored on the same SQL server and instance acting as a Back End Server for a pool, and after installation the CMS can be moved to another server at any time.

As indicated earlier, when a server is prepared for a Lync Server installation, the first action it takes is to install a local replica of the CMS. As changes occur in the CMS, these changes are synchronized out to all members of the topology, which removes the need for servers to maintain a constant connection to a centralized configuration store. Servers synchronize the changes regularly and use the information stored locally instead of contacting a central point for settings, which improves performance and stability.