OCS Database move – Front End server doesn’t start anymore

This is just one of the issues which occured at one of my clients. I built a complete new OCS 2007 R2  Enterprise Edition consolidated pool, completed with an consolidated edge server, mediation server, monitoring and archiving server. As resources were not completely available at time of installation, it was decided to install the back-end database on a temporary SQL 2008 instance.

When I returned to the client a few weeks later, I was able to move the databases to a more permanent SQL instance. Good news, you would say! Well, it was a pain in the ass to get it done, but eventually, I found a solution/workarround.

All of the servers were updated to CU6. Moving the monitoring, archiving and reporting databases were not a problem. The procedure for this was simple: stop the corresponding services, move the databases, re-run the activation wizard for Monitoring and Archiving servers and start their services. For Reporting, change the database in the Reporting server Management, and restart the service.

However, while following this technet article, moving the RTC databases was more of a problem. When you follow the procedure, on the last mile (starting the front-end service), the front-end service won’t start anymore. It was stuck at the status of  “starting”. A reboot was required (or force a stop of the executable from the service), but after that reboot, still a no-go. All services will start, except for the front-end service.

When digging in a bit, the event viewer on this front-end showed a bunch of error messages, starting with an event stating that “the database version is different from the front-end service”.

Hey, we’ve noticed these kind of errors before, with CU6, when you didn’t apply the database upgrade! My next step was obvious; I’ve started the database update again. Make sure the MSI installer runs the necessary scripts to “upgrade” the database. When it has been installed from the same server before, this might be an issue (not being able to run the upgrade) – just make sure you’ll see the command-prompt running some scripts.
Now this script shouldn’t update anything – the database has been “updated” earlier, when applying the CU6 updates  – but apparantly the database version number is changed or located somewhere else during the database move. With re-running this “upgrade” with its update scripts, the version number should be restored again.

When the DBupgrade has been completed succesfully, continue with starting the services again (beginning with the front-end service) and voila; you’ll be happy to see them “started” !!

Front End Services started