Applies to: SharePoint Server 2013, SharePoint Server 2016, SharePoint Server 2019
Here is the script you can use to reset the configuration cache. The article also describes how you can perform it manually. It also points out some issues you may encounter when running this or other scripts available on the web.
You cat test the script by running one of the following:
-------------------------- EXAMPLE 1 --------------------------
SharepointConfigCacheReset.ps1 -TestOnly
-------------------------- EXAMPLE 2 --------------------------
SharepointConfigCacheReset.ps1 -TestOnly -ServerByServer
-------------------------- EXAMPLE 3 --------------------------
SharepointConfigCacheReset.ps1 -TestOnly -ServerList Sever1,Server2
-------------------------- EXAMPLE 4 --------------------------
SharepointConfigCacheReset.ps1 -TestOnly -ServerList "Sever1","Server2" -ServerByServerI actually recommend running it on one server at a time to avoid potential issues mentioned in the last section. In the screenshots in this post I am using the -TestOnly switch. Without the switch the script will do the actual reset.
If you want to do clear the cache manually you can skip to the step 4.
Step 1 – Import the sharepoint powershell snapin if needed
This step will not show up in the script output if the snapin is already imported.
Step 2 – Get the basic Information about the farm
The script will pull the configuration database name, Guid and it will list all the farm servers.
Step 3 – Check the remote WMI connection to the remote servers
The script is connecting to WMI on the remote servers. In the background it checks for SPTimerV4 service to see if it there is any response.
Step 4- Check if the config cache folder can be found on the sharepoint servers
In order to clean up the cache you need to locate the correct cache folder in the following folder.
C:\Programdata\Microsoft\Sharepoint\Config\
If you want to open this folder manually. You may have to start by opening C:\ and clicking through all the folders in order to gain access to it. There may be several folders inside as in the screenshot above. The correct folder is the one which has been currently modified. You can also identify the correct folder by checking the configuration database GUID.
Note that the folder name is equal to the config DB GUID in step 2 – the script checks if the folder with this name exists on all servers.
Step 5 – Stop the timer service
Here the script is stopping the timer service on all specified servers. If -TestOnly switch is used it only tells you that the service would be stopped at this point and instead it just checks the status.
Step 6 – Delete the XML files in the config cache folder
The script checks how many xml files there are in the chache folder and then it removes them. Once they are removed it checks again how many xml files are in the folder. It also displays the oldest file date just for your information.
With the -TestOnly switch it does not really delete the files.
When you run it “for real”, the second check returns zero xml files so you will see if it really deleted the files.
Step 7 – Set the content of cache.ini file to 1
If you do the actual reset the second check of the cache.ini file will return “1”. You can do the same manually by opening the cache.ini file in notepad and overwriting the current number to 1.
Step 8 – Start the timer service
Step 9 – Check the xml count and cache.ini content after the reset
Here the scipt might throw some errors because the servers will be busy with creating new xml files and frequently rewriting the cache.ini files. It is just a check so it is not a problem. You can wait a bit and run the script again with the -TestOnly switch to check the config.ini and xml files again.
Recently I updated the script to wait until it can get the cache.ini folder. But it still might throw errors when getting the number of XML files. I found out it can take quite a long time depending on the environment.
Potential Issues
Central Administration Page
After cleaning up the configuration cache on servers running the central administration, you might experience temporary side effects when you open the central admin page, for example web applications might be missing in central administration but also other weird things…just give the servers some time to load the configuration from he database and then reopen the CA, the issues will gradually go away.
Performance
If you stop the timer service on all the servers at the same time, then clean up the cache on all of them and then start the timer service on all of them, all these servers will start loading the configuration from the database at the same time which might have impact on the performance until the configuration is loaded. Therefore you should consider doing it one server at a time by using -ServerByServer switch which will finish all the steps on one server and then moves on to another server…
Search Service Application
If you have issues with SSA, resetting configuration cache might help you but also might make it worse. We had issues with one of two SSAs – crawls were not working. After the reset, both SSAs had the same issue and we had to remove all the search components and then add them back again to fix the SSA.