Whole farm is down because timer jobs are not running

re: Whole farm is down because timer jobs are not running

Nick chapman — Thu, 26 Mar 2009 14:50:48 GMT

I have had a problem with my timer jobs ever since i have moved the config database onto a new sql2005 server, the timer jobs link errors and looks like its still looking for my old sql server as i get the following error message :-

Unable to connect to database. Check database connection information and make sure the database server is running.

If anyonce could offer any advise it would be greatly appreciated. Regards

Nick

re: Whole farm is down because timer jobs are not running

Sp Guy — Wed, 22 Oct 2008 14:43:32 GMT

The web is filled with lots of tricks on how to get into the databases, what files and fields can be hacked, and cool tricks that MS does not support. Although thses are really greate and can get you out of a bind, it is the I'll do it myself endgame. If going down this path does not fix the problem, your on your own to figure out a fix since you will not be supported by ms. Creating a new content databse takes no more than a few minutes (maybe even less time thatn all the cool hack steps), and you know you will not be haunted later by some setting that was burried so deep in the database you would never have found it.

I suggest tricks be used when all supported methods have failed and you are totally without hope.

Links (10/12/2008) « Steve Pietrek - Everything SharePoint

Links (10/12/2008) « Steve Pietrek - Everything SharePoint — Mon, 13 Oct 2008 00:04:26 GMT

Pingback from Links (10/12/2008) « Steve Pietrek - Everything SharePoint

re: Whole farm is down because timer jobs are not running

Anthony Poole — Fri, 10 Oct 2008 14:39:00 GMT

Hi Shane,

Thanks for the post. Last thing I heard, Microsoft did not officially support moving the configuration database - period.

However I've become very familiar with the procedure around moving and restoring config databases over the past year. It's really not that big of a deal.

Firstly, I always use SQL2005 aliases. That way you can freely move all your databases without having to change anything (well almost - see below) in SharePoint. You just change the database server in the alias, and hew presto you're redirected to the new SQL box.

Secondly, if you either move or restore the config database, you must ALWAYS clear the SharePoint cache on all servers in the farm. Otherwise chances are your timer service will always refuse to play ball.

This is the procedure you describe above, and the best practice I've developed is:

1) Stop the timer service on all servers in the farm

2) On all servers in the farm, delete all the xml files in C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\<guid>\.

[NB: If you've done repeated deployments on the same farm/server, you may have several GUIDs in that folder. To establish which is the current one in use, check the id string in this reg key: HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB]

Do NOT delete the cache.ini file!!!!!

3) Open the cache.ini file in that folder, and replace the contents with the number 1, and save. Repeat on all servers in the farm.

4) Restart the timer service on all servers.

I've written a nice little script which takes care of all of this, let me know if you want a copy. sharepoint@antpoole.com

Regards,

Anthony

re: Whole farm is down because timer jobs are not running

Paul Liebrand — Thu, 09 Oct 2008 20:20:30 GMT

I want to clarify that the "sync" operation of STSADM actually has zero destructive switches. There is a switch called "-deleteolddatabases" but it is not what the name implies. This switch simply purges the sync tables which will force SharePoint to repopulate them the next time the sync job runs.

Just bad naming on Microsoft's part.