Lync Server 2010 locally uses the following SQL databases:
On every Lync server SQL express gets installed. Default Instance name for SQL installed on FE & other roles is always SERVERNAME\RTCLOCAL and SERVERNAME\LYNCLOCAL
SERVERNAME\RTCLOCAL - It contains the read only copy of the XDS database and RTC and RTCDYN databases
SERVERNAME\LYNCLOCAL - It contains the LYSS database
LYSS - (Lync Storage Service). On every front end server under the LYNCLOCAL instance LYSS database is located.
It is a replacement for MSMQ which was used in previous version of Lync. It temporarily holds the data and delete them once the data has been written to backend SQL server. It is also used for Archiving integration and Unified Contact Center.
NOTE: Only in the standard edition there will be one more instance SERVERNAME\RTC in Enterprise edition this RTC instance is in the backend SQL server
Below shown databases are in the backend SQL
1) Central Management Store (CMS) i.e. the XDS database. NOTE - CMS will be only one writeable copy in entire forest, rest all will be read only on each servers.
Changes are replicated to all Lync server roles using the Windows file copy SMB protocol on port 445. Changes are replicated to the Edge role via HTTPS on port 4443.
2) User/Pool Configuration Store
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 alternatives 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.
3) Application Store
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
4) 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)
5) Location Store
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.
6) MGC – Microsoft Group Chat / Persistent Chat Database
7) MGC Comp – Microsoft Group Chat Compliance
> In lync 2013 if there is a pool pairing done, Is failover and failback are automatic or manual ? or can it be automated ? It is manual.
> If we are doing SQL BE mirroring or clustering and one of the SQL server fails then other will take care of it. Is it automated or manual ? If we deploy witness i.e. SQL express edition
then it will be automated failover else admin have to do it manually.
Most of the work for the pool failover involves failing over the Central Management Store, if it is required. This is important because the Central Management store must be
functional when the pool’s users are failed over.
> Is SQL mirroring or clustering required for pool pairing ? No, there is no dependency for pool pairing with SQL mirroring, because in STD edition of Lync there is no SQL BE but
still pool paring can be done
Pool pairing is done to achieve pool level high availability.
SQL mirroring or clustering is done achieve SQL high availability.
No comments:
Post a Comment