Category Archives: SQL

Solving Event ID 32134

24 Thursday Dec 2015

Posted by in event id, RTC Database, RTCAB, SQL, Uncategorized

≈ 1 Comment

Tags

Whilst working through a patching session I noticed a standard edition front end server throwing Event ID 32134 every 10 minutes.

That’s new to me, so how do we resolve this?

Error Details

Event ID 32134

Event ID 32134
Source: LS User Services
Error

Failed to connect to back-end database. Lync Server will continuously attempt to reconnect to the back-end. While this condition persists, incoming messages will receive error responses.

Back-end Database: rtcab Connection string of:

driver={SQL Server Native Client 11.0};Trusted_Connection=yes;AutoTranslate=no;server=(local)\rtc;database=rtcab;

Cause: Possible issues with back-end database.

Resolution:
Ensure the back-end is functioning correctly.

 Cause

The error message does give a good clue as to where to start looking. The server cant connect to the backend database rtcab on the local server.

My weapon of choice is SQL Management Studio as it will allow me to take a peek at the suspect database.

Connecting to the local server and expanding the databases folder I notice the rtcab database stating that access is set to Restricted User).

SQL Restricted User

Solution

Not sure why this rtcab access has been locked, perhaps part of the update process that didn’t quite finish.

An easy fix, simply right click the database rtcab and select Properties. Navigate to Options.

Scroll down to the State section and change the Restrict Access to MULTI_USER.

Lync Backend Database

Even on a good day, error messages from SQL make me uncomfortable, BUT this particular issue has been comfortably sorted.

 

Advertisement

What are all the Lync Databases for?

28 Thursday Feb 2013

Posted by in CMS, Databases, RTC Database, SQL

≈ Leave a comment

Tried to give a customer a quick verbal re the databases as seen in their SQL backend on the fly…Surprisingly I only missed one 😉
Better chuck that in the blog for quick reference then
Xds – aka the CMS, contains the published Topology
RTC – persistent user data including contact lists, scheduled conferences
Rtcdyn – Presence info
Rtcab – address book data (synced from AD)
Rtcab1 – address book data (synced from AD)
Cpsdyn – Call Park data, dynamic
Rgsdyn – RGS data, dynamic
Rgsconfig – RGS config
LcsLog – IM and Conference data for Archiving
LcsCdr – CDR
QoEMetrics – QOE Data
Lis – Location and information service

Log file placement defined here

The DB names are hardcoded. You can only choose the SQL instance name, and port numbers.

SQL Single Instance – Co-Locating all databases

21 Thursday Feb 2013

Posted by in Lync Monitoring, RTC Database, SQL, SQL Single Instance - Co-Locating all databases

≈ Leave a comment

Today I learnt something new…

Of course a Standard Edition Deployment cannot have co-located Databases on the Front End, if you wanted to add the Monitoring role or other database roles you would need full blown SQL elsewhere.What I learnt was that you can collocate each of the following databases on a single database server:

  • Monitoring database
  • Archiving database
  • Persistent chat database
  • Persistent chat compliance database
  • A back-end database for an Enterprise Edition Front End pool

You can collocate any or all of these databases in a single SQL instance or use a separate SQL instances for each, with the following limitations:

  • Each SQL instance can contain only a single back-end (RTC) database (for an Enterprise Edition Front End pool), single Monitoring database, single Archiving database, single persistent chat database, and single persistent chat compliance database.
  • The database server cannot support more than one Enterprise Edition Front End pool, one server running Archiving, one server running Monitoring, single Persistent Chat database, and single Persistent Chat compliance database, but it can support one of each, regardless of whether the databases use the same instance of SQL Server or separate instances of SQL Server.

WARNINGAlthough collocation of databases is supported, the size of the databases can grow quickly. For example, when you consider collocating the Archiving database with other databases, be aware that if you are archiving the messages of more than a few users, the disk space needed by the Archiving database can grow very large. For this reason, we do not recommend collocating multiple databases, especially the Archiving database, Persistent Chat database, and Persistent Chat compliance database with the back-end database of an Enterprise pool.