SharePoint 2010 & 2007 – Clearing the Configuration Cache

There were many common issues that could occur in WSS v3 and MOSS that would require you to clear the configuration cache on your servers. While less common, these issues can still turn up occasionally on SharePoint Server 2010 (And Foundation). While the resolution for these issues might be the same, the steps are a bit different. The main thing to note is that the Configuration Cache is located in a different directory on Windows Server 2008 then it was in Windows Server 2003.

The new path for the Configuration Cache under Windows Server 2008 is: %SystemDrive%\ProgramData\Microsoft\SharePoint\Config\<GUID> The overall steps remain largely the same:

Stop the Timer service. To do this, follow these steps:

Click Start, point to Administrative Tools, and then click Services.
Right-click SharePoint 2010 Timer, and then click Stop.
Minimise the Services console. 

On the computer that is running Microsoft SharePoint Server 2010 and on which the Central Administration site is hosted, click Start, click Run, type explorer, and then press ENTER.
In Windows Explorer, locate and then double-click the following folder:
%SystemDrive%\ProgramData\Microsoft\SharePoint\Config\GUID

Note: The %SystemDrive% system variable specifies the letter of the drive on which Windows is installed. By default, Windows is installed on drive C.
The GUID placeholder specifies the GUID folder. There may be more than one of these.
The ProgramData folder may be hidden. To view the hidden folder, follow these steps:
On the Tools menu, click Folder Options.
Click the View tab.
In the Advanced settings list, click Show hidden files and folders under Hidden files and folders, and then click OK.
You can also simply type this directly in the path if you do not want to show hidden files and folders. 

Back up the Cache.ini file. (Make a copy of it. DO NOT DELETE THIS FILE, Only the XML files in the next step)
Delete all the XML configuration files in the GUID folder (DO NOTE DELETE THE FOLDER). Do this so that you can verify that the GUID folders content is replaced by new XML configuration files when the cache is rebuilt.

Note: When you empty the configuration cache in the GUID folder, make sure that you do NOT delete the GUID folder and the Cache.ini file that is located in the GUID folder.
Double-click the Cache.ini file.
On the Edit menu, click Select All.
On the Edit menu, click Delete.
Type 1, and then click Save on the File menu. (Basically when you are done, the only text in the config.ini file should be the number 1)
On the File menu, click Exit.

Start the Timer service. To do this, follow these steps:

Click Start, point to Administrative Tools, and then click Services.
Right-click SharePoint 2010 Timer, and then click Start.
Close the Services console.

Note: The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.

Check in the GUID folder to make sure that the xml files are repopulating. This may take a bit of time.

For the original steps for clearing out the configuration cache in SharePoint 2007, there are many articles that cover the steps, one of them is the following: http://support.microsoft.com/kb/939308

Prompt Users login again and again - [DMZ Servers - Firewall]

Problem: Even though you type in correct username and password, it will prompt the login box again and again. 

Many organizations have DMZ environment to serve External Clients and Vendors. The SharePoint environment is the key to make easy access websites and share. Many cases, internal users also will be having access to these DMZ SharePoint Sites.

Firewall plays the security role to allow authentication between Internal Users and DMZ SharePoint sites. When Firewall is busy or down, it will not authenticated and will not allow Internal Users to access the DMZ SharePoint sites. It behaves the same as like your account was locked.


The Solution is make sure the Firewall is up and running and also make sure, in IIS Manager >> Application Pools, SecurityTokenServiceApplicationPool is started. Also make sure the Account used to run the App Pool is not locked.

If you still see issues, recycle the SecurityTokenServiceApplicationPool

This should fix the issue of Users login Failure or prompt the login box again and again.

There are only few scenarios where users will be unable to login into the site.

1. When User's Account was locked.
2. When Firewall blocks the Authentication request from User.
3. When AD does not respond to authenticate the User Account.