Site Usage Stats and Timer Service Fail to Initialise

I’ve spent some time trying to resolve an issue where the Site Usage statistics were not updating for a MOSS site, even though the log files were being successfully written to the file system as expected and wanted to share how I resolved the problem.

Looking through the diagnostic logs (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS) I noticed the following errors:

SPTimerStore.InitializeTimer: SPConfigurationDatabase.RefreshCache returned SPConstants.InvalidRowVersion with an event id of 75eb.

and

The timer service could not initialize its configuration, please check the configuration database.  Will retry later with an event id of 5utx.

Both errors were for the OWSTIMER process.

I then looked at the Timer Job Status page from the Operations tab of Central Administration, where the Office SharePoint Usage Analytics Processing job’s status was set to aborted.

The answer is pretty self explanatory once you find it, the configuration cache had somehow become corrupt and required resetting.  I had changed a content database with a newer version and I think this has somehow caused the configuration cache to become out of sync.  I have done this before and not come across this issue, so I’m not completely sure how this happened, but I do know how to resolve it.

Resetting the cache is fairly easy and involves the following steps:

  • Stop the Windows SharePoint Services Timer service on ALL servers in the farm.
  • On the server configured for Indexing, browse to %ALLUSERSPROFILE%\Application Data\Microsoft\SharePoint\Config.
  • Open the Registry editor and navigate to the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB.
  • Take a note of the Guid value for the Id item.
  • In my case this folder was empty, so I needed to re-create the cache folder giving it the title matching the Guid value retrieved from the Registry.
  • If the folder already exists, all you need to do is delete all xml files, leaving one file called cache.ini which requires its content to be edited and set to the value 1
  • You can now re-start the Windows SharePoint Services Timer service on the current server.  You should see xml files appear in the folder shortly after the service starts.
  • Repeat all the steps above for all other servers in your farm, starting with any other index servers before moving onto the remaining WFE and application servers.

One last thing you may need to do is re-start the Windows SharePoint Services Tracing service on all servers in the farm.  If you don’t do this you will more than likely start seeing Tracing Service Lost Trace Events errors in the log files.

One comment

  1. AlanG says:

    Is that *the* Stuart Roberts? Hows it going?

Leave a Reply

Your email address will not be published. Required fields are marked *

Solve the maths problem shown below before posting: *

Follow

Get every new post delivered to your Inbox

Join other followers: