OCS 2007 R2 Cumulative Update 6 and Stored Procedure Mismatches
Something not mentioned in the release notes of Cumulative Update (CU6) is that there is a dependency on running the new OCS2009-DBUpgrade.msi before any server updates. If you try to run the ServerUpdateInstaller.exe and apply the server updates without first running the database package you may see an error like this:
Event ID: 30968
Source: Live Communications User Services
Details: The component Live Communications User Services reported a critical error: code C3EE78F8 (Enterprise Edition Server successfully registered with the back-end, but a stored procedure version mismatch was detected. The service will not start until this problem is resolved. Cause: The database schema and the Enterprise Edition Server were updated by different installation packages. Resolution: Ensure both the Enterprise Edition Server and back-end were installed or modified by the same installation package. The service has to stop.
Obviously the error verbiage is a bit outdated with references to LCS, but the error is correct – there is a mismatch between the stored procedure versions which makes the Front-End service to fail to start.
To avoid the issue be sure to apply the latest OCS2009-DBUpgrade.msi package before updating any Front-End servers.
Thanks for following up on this Tom. Any prescriptive guidance for those who didn’t install the DB upgrade first, and are getting the mismatch error?
Uninstall the update and re-install in the right order?
Thanks,
Hey Curtis, I’m not 100% on the fix if you’ve already installed. I was actually unable to uninstall the FE updates – got prompted for source media and after inserting it would throw an error. We reverted with a VM snapshot. I did hear you can extract the DB upgrade package and run the .wsf database script manually as a workaround. If you do try it out let me know if that works please.
Hi Tom,
is there any hints how to run the DB update scripts manually by hand?
There are 3 .WSF files, I am not sure if it is enough to run:
“csript dbqfeupdate.wsh”
with the correct parameters required, coming from the source of dbqfeupdate.wsh:
This script applies this QFE to the OCS Database on a target SQL server by updating all of the stored procedures.
It can only be run against a Office Communications Server 2007 R2 database.
It can be run while the service is running. (Nothing needs to be stopped before applying this patch.)
This script can’t be undone.
Usage: cscript.exe %1 [/sqlserver:value] [/role:SE|EE] [/poolname:value] [/verbose] Options: poolname : The EE pool name to update. Required if /Role:EE specified. Not allowed if /Role:SE specified. sqlserver : The SQL server instance to install this QFE on. e.g. \\server1\rtc for the SQL instance named ‘rtc’ on the machine named server1.
Has anyone resolved this issue if you have already installed the other updates before the DB update? My wonderful server team applied this patch before contacting me and now the front ends will not start.
Had the same issue after install this in the wrong order even though on the MS site it listed the last step as the DB upgrade.
To fix it find the update 983472 and uninstall it from add\remove programs, reboot, run the db tool, then run the CU6 installer and reboot…
Not nice. Again Microsoft made a crappy update that doesn’t check for essential prerequisites. One would expect that a cumulative update exe file will check for prerequisites. For me the uninstall of 983472 failed
so now I’m stuck.
I don’t have a snapshot to revert to and I can’t uninstall update 983472. I am stuck. Looks like I’ll need to reinstall…
I was able to get this resolved. When I attempted to run the OCS2009-DBUpgrade.msi package it would fail. I disabled UAC, rebooted and the update installed just fine. After another reboot still no go on the Front End service. Then installed the hotfix for KB967831: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=967831&kbln=en-us. After another reboot my issue was resolved! Whew!
Hey Tom. Quick question: Do you know a good way to pre-set Access Levels for users migrated to OCS from LCS 2005? After migrating users, we are finding that their previous contacts are moved over, but are not given the correct “Access Level” to view their status. The end result is every user having to manually set Access Levels for all old contacts to “Company”. Is there an easier way to automate this, either server-side or via GPO’s?
i am stuck also. installed all the KB 968802 before 967831 i can’t uninstall all the patches so not sure how to fix it..
Hi Tom,
I did write an post in my website about how to apply the Cumulative Update for ocs database manually by script.
Here you can see how apply this. http://rafael-lavecchia.blogspot.com/ http://uclavecchia.wordpress.com
Tks
Rafael Lavecchia
I followed Brians initial steps to disable UAC, reboot, install the DB update, reboot, and all ok now (thanks Brian!!). Very annoying MS provides a neat tool to do all updates in one go but leaves out a pre-req DB update! Knew it was too good to be true
I also find it interesting that the MS article says “To install the database update for Office Communications Server 2007 R2 Enterprise Edition, type the following command: OCS2009-DBUpgrade.msi POOLNAME=PoolnameWhere Poolname is the Enterprise Edition Pool name” Considering you there are two enterprise pools, usually one for directors and one for other front end servers, which one should the update be applied to?