The Pitfalls of Resetting the Config Cache

I see many SharePoint admins resetting the config cache but not knowing what it is or what it does.  This seems to be a go to action for anything wrong with SharePoint along with IISReset, PSConfig, and rebooting the servers.

What is the Config Cache?

The config cache is a copy of your objects table from your configuration database.  The location for the config cache cannot be changed.

Location: C:\ProgramData\Microsoft\SharePoint\Config\<GUID of ConfigDatabase>

We may see multiple folders due to the number of Config Databases(farms) the server has been connected to.

The config cache is updated and mostly used by OWSTimer.  If the config cache has incorrect formatted XML, the OWSTimer will fail to initialize(also will fail if it doesn’t complete the rebuild).

Cache.INI

The folder will contain many XML files and one cache.ini.  The cache.ini controls the version of the config cache.  This integer value controls the version of the config cache.

Setting it to 1 will make the entire cache to rebuild.

Config Database location:

<GUID>.XML

The files are objects from the object table.  The file name is the GUID.  Inside you can see the version number and other information about object.  Each time an object is updated the cache.ini will be updated.

When to reset?

Resetting the config cache will not fix most things.  Update conflicts happen when the refresh does not happen manually.  The object is newer in the ConfigDB than on that server’s config cache.

 

Log Name:      Application

Source:        Microsoft-SharePoint Products-SharePoint Foundation

Date:          12/20/2017 8:46:23 AM

Event ID:      6398

Task Category: Timer

Level:         Critical

Keywords:

User:          domain\farmaccount

Computer:      SharePointServer

Description:

The Execute method of job definition Microsoft.SharePoint.Diagnostics.SPDiagnosticsMetricsProvider (ID 0a77ce6a-69d3-47d4-86ae-56c772fd498d) threw an exception. More information is included below.

An update conflict has occurred, and you must re-try this action. The object SPWebService was updated by domain\farmaccount, in the OWSTIMER (9920) process, on machine SharePointServer.  View the tracing log for more information about the conflict.

 

It doesn’t hurt anything, right?

There are some possible negative effects when trying to reset the configuration cache.  Resetting the config cache on large farms will cause performance issues and/or take down your farm.  I’m talking more about those fancy scripts on the web that try to rebuild the cache across the entire farm in parallel.  Just do it manually, one server at a time.  This can cause SQL to lock the objects table and may fail to rebuild the config cache or take days to rebuild.

Config Cache while rebuilding

The config cache is done rebuilding after the cache.ini is no longer locked by OWSTimer.exe and has a value other than 1.

After the build is done, you’ll see numerous XML files and the cache.ini should be showing the version of the config cache.

Bottom line…

The issue we are trying to fix is unlikely to be fixed by resetting the config cache.  ULS logs are always the best place to look before taking action that may not be needed.   Manual reset, one server at a time is the way to do it if you’re looking to reset it.

Comments

• Anonymous
  December 21, 2017
  Excellent.
• Anonymous
  December 21, 2017
  Suberb!