Lync Server 2010 CU3 Database Update Explained

by Jamie Schwinn on September 6, 2011

If you didn’t catch it, there is an important note in the KB Article attached to the Lync Server 2010 Knowledge Base article, KB2493736 regarding a SQL database update that must be performed in addition to the installation of the CU3 software patch. To install the SQL update, the KB article states the following under installation Method 1:

On Standard Edition Server and Enterprise Edition – Front end server once you have installed update for core components, the updated sql files will be dropped on the server. Then, run the following cmdlet to apply the changes:

Install-CsDatabase -Update -ConfiguredDatabases -SqlServerFqdn <EEBE.Fqdn> -UseDefaultSqlPaths

Notes

  • In a Lync Server 2010 Standard Edition environment, run the cmdlet from the Standard Edition server.
  • In a Lync Server 2010 Enterprise Edition environment in which the archiving/monitoring services are collocated with an Enterprise Edition back-end server, run this cmdlet from the Enterprise Edition back-end server.
  • In a Lync Server 2010 Enterprise Edition environment in which the archiving/monitoring services are not collocated with an Enterprise Edition back-end server , run this cmdlet from the Enterprise Edition front-end server.

If the RTCDyn databases are removed after you run the cmdlet without the UseDefaultSqlPaths parameter, run the following cmdlet to restore the RTCDyn databases:

Install-CsDatabase -Update -ConfiguredDatabases -SqlServerFqdn < EEBE.Fqdn > -DatabasePaths <RtcDyn log path>, <RtcDyn data path>

Note The RtcDyn log is located under the path of the rtcdyn.ldf file. The RtcDyn data is located under the path of the rtcdyn.mdf file.

I installed the CU3 update patch on several Front End Pool servers in my lab and rebooted. I was a little confused since, following the reboot, Lync Services started and everything seemed to work OK. I wondered… was the SQL updated required? Would something eventually break? or did the ServerUpdateInstaller.exe run the SQL update automatically? To many questions…

Searching about the issue, the only thing I could find was a reference to a MS Forum post by a Microsoft CSG stating that the database updated was an “absolute requirement”. See Forum post Lync CU3 SQL update questions.

I was not entirely convinced and decided to dig in a little deeper. While comparing a couple Front End pools in varies different states, my colleague discovered that on servers that had been fully patched with CU3 AND had the SQL database update applied, there was an important difference in the back-end pool RTC database. The dbo.DbConfigInt table contained an extra row as shown below:

Before applying the SQL update, the DbVersionUpgrade row does not exist and the table only contains 13 rows. After applying the SQL database upgrade as described in the KB Article, the table has 14 rows and shows DbVersionUpgrade with a value of 1. Also important to note that this is only reflected in the Pool Back-end Database and not in the RTCLOCAL replica.

I have been unable to determine if there are any negative repercussions if the SQL database update is not installed and I have seen several servers running just fine with CU3 installed without the SQL database update. I can also report that installing CU3 via Microsoft Update does not install the database update as servers patched in this manner do not show the DbVersionUpgrade row in the database.

I would encourage anyone applying CU3 to Lync Servers to run the database update as shown in the KB article. You can check to see if the SQL database update was applied by checking for DbVersionUpgrade with a value of 1 in the dbo.DbConfigInt table of the Pool Back-end Database.

If anyone knows of any negative side effects to not running the SQL database update, please share via the comments!

Credit goes to Paul Placanio @ Ronco Communications for finding the new DbVersionUpgrade row in the dbo.DbConfigInt table on servers with the SQL database update applied.

[edit]

I was notified by Tom Pacyk via Twitter that the fix described in KB2560102 may not take effect if the SQL database update is not applied. Thanks Tom!

See Lync Server 2010 Database Updates Explained – Part 2 for more information.

Be Sociable, Share!

{ 7 comments… read them below or add one }

soder September 7, 2011 at 12:42 am

Very useful article, simply you discussed all my concerns regarding the SQL update for Lync!
The Frontends and other services still able to get started properly (you remember, OCS introduced some check at a mid-time CU, when frontends were broken as long as you didnt apply the DB update as well)
There is only 1 question left: that single +1 row is the only sign of the succesful update? The script goes through several databases, and in a complex environment that script had failed multiple times before it could finish completely. I just wanted to make sure it applied all the db changes in a single “atomic” process instead of finishing half of the databases, but not applying to the rest.

Jamie Schwinn September 7, 2011 at 6:57 am

Good point. I’m sure there are plenty of other changes that the update makes to SQL. I have not taken the time to do a comprehensive SQL comparison to identify all of the signs of a successful update. I’ve run it several times at now and the only time it has failed was when I didn’t include the ‘-UseDefaultSQLPaths’ parameter. When this happened, I lost Presence and Lync went into a limited functional state similar to when a registrar fail-over occurs. Running the update without the ‘-UseDefaultSQLPaths’ parameter can cause the RTCDYN table to drop which is the table that holds dynamic information for the pool, like Presence info. After re-running the update command with the ‘-UseDefaultSQLPaths’ parameter, the pool started working correctly again after a few minutes.

soder September 13, 2011 at 2:52 pm

OCS (and even Lync) depends on so many sub-system, if one of them breaks, you are doomed. And they break indeed! Especially if the SQL gets f*cked up. Thatswhy I am completely unsatisfied, that MS lacks of a professinally detailed update-check procedure. Am I supposed to reverse-engineer their multi-megabyte .SQL scripts to find out if the schema update has been run properly, or stopped at mid-way without rolling back properly? Non-sense.

Also the lync documentation does not really clearly specify the difference between the “-SQLinstance” and the “-ForInstance” switch used in the Install-CSdatabase cmdlet, though I believe there must be something significant between them, otherwise MS wouldnt have implemented 2 separate command line switches for the exact same functionality. According to my experience -SQLinstance switch is used ony for the manually-provided database types (opposed to the from-topology-discovered types that use -ForInstance), but guessing such a essential attribute due to the lack of proper documentation is really a dangerous activity.

Divya September 12, 2011 at 2:23 pm

Thanks, Jamie. This was very useful.
I was a little confused with the KB article – it specifically mentioned the back-end upgrade process under method 1. However, we use WSUS in our environment for Lync updates. I didn’t see how the updates would automatically perform the DB upgrade using WSUS. In fact, it did not – thanks to your post on how to verify it :)
I had to run the PowerShell command to get the RTC DB updated.

Paul-Christiaan September 27, 2011 at 12:16 am

Just found out that if you do not update the database when you install CU3, S4 logging on the mediation server does not work. The logs stay empty. If you do the database update with your command, it starts working again!

Leo October 25, 2011 at 10:21 pm

Hi I found a really bad side effect of not doing this update. I just completed a greenfield deployment and got each server to apply all updates through windows update and all seemed to work ok except presence and address books didn’t work. It turns out that the RTC databases had magically disappeared off of the SQL cluster. Running the above command recreated the databases and all is working now.

Tommy Clarke November 4, 2011 at 5:25 am

Great post and good work on your research. Most people would miss this so again.
Great work.

{ 7 trackbacks }

Previous post:

Next post: