locked
After SharePoitn configuration cache reset, cache.ini file is not updating RRS feed

  • Question

  • I reset SharePoint configuration cache under C:\ProgramData\Microsoft\SharePoint\Config\ according to number of articles available online.

    but now, xmls files are still creating in the folder and cache.ini file does not seems to be updating. it is showing last modified date as yesterday.

    i am not able to start / stop sharepoint service due to this. Need help troubleshooting..

    Thanks,

    Abhilash

    Thursday, August 30, 2012 1:30 AM

Answers

  • Abhilash, What was your resolution to this issue? Our team ran into the same issue and was thoroughly frustrated that every search on Configuration Cache would result in your unanswered question and directions on how to reset the cache which you obviously already did. We had to remove each server from the farm and join them back to the farm for this issue to resolve. Narrative below....

    Situation: We have 5 SharePoint 2010 servers, 2 Application and 3 WFE, and were having issues updating some Farm Solutions through known healthy WSP files. The deployment would start but never complete, the one-time timer jobs would never remove themselves from the queue. After establishing that this was a consistent behavior, we looked at the configuration cache knowing that the systems were out of sync.

    We performed the steps that everybody has posted and reposted about resetting the configuration cache, which appeared to work properly but the WSP issue would remain.

    When I say that the configuration cache reset appeared to work properly, I mean that we would stop the SPTimerv4 service on all servers, delete all the XML files, reset cache.ini to 1, and then start the SPTimerv4 service. After starting the service, the XML files would repopulate in the Farm Configuration folder. So that appears correct.

    However, I noticed that two of the servers (one WFE and one App server) would have 2064 items in the folder and the other three servers would have 1032 items. On opening the Cache.ini file on the three servers, we found that it still read "1" rather than ever increasing. Furthermore, the modified timestamp never changed.

    We tried to completely shut down all SharePoint Services (IISReset Stop, Stop SPTimerV4, Stop SPAdminV4, Stop OSearch14, Stop SPTraceV4) on all servers, reset the configuration cache, and then restart everything one server at a time. The result of this was that 4 servers now had 1032 items and a never updating cache.ini file. One server had 2064 items with an updating cache.ini file and this was one of the WFE servers.

    So this meant that both Application Servers which both hosted Central Administration were out of sync from the farm, and the one server that appeared to be in sync ran none of the important farm services.

    Enough Situation...

    Resolution: We knew that the only resolution to this issue would be to run the SharePoint Configuration Wizard, but we were not convinced that just rerunning is on all the servers would fix the farm so we went one step further. Starting with one of the Application Servers, we ran the Configuration Wizard and removed the server from the farm. This took a while to run but completed successfully on the second attempt. We rejoined the farm and everything was healthy, cache.ini file updating with 2024 items in the Farm Configuration folder. Then we performed the same remove server/add server steps on each of the WFE servers. Cache.ini updating properly, with roughly the same number of items in the Farm Configuration folder (plus/minus 12 items, note that these numbers don't need to be the same). Did the same on the other application server by removing it from the farm and adding it back and this one was updating properly.

    And then on to the WSP deployment, with all the servers back in sync we proceeded with our original task. One of the WSP deployments were hung on one of the servers. To clear out the processing we stopped SPAdminV4 on the server, ran “stsadm –o execadmsvcjobs” which forced the processing of that hung job. From that point on we had no more problems with the WSP deployment. To clear that processing on the whole farm, the execadmsvcjobs command should be run on all servers in the farm.

    • Proposed as answer by Kevin E. Carbray Monday, November 26, 2012 2:35 PM
    • Unproposed as answer by Kevin E. Carbray Monday, November 26, 2012 2:35 PM
    • Marked as answer by Abhilash.S Tuesday, November 27, 2012 5:40 AM
    Monday, November 26, 2012 2:31 PM

All replies

  • Hi,

    Did you check this?

    http://spcachecleaner.codeplex.com/

    http://underthehood.ironworks.com/2010/07/error-message-when-you-try-to-start-user-profile-synchronization-in-sharepoint-2010-an-update-confli.html

    Let us know your result


    Cheers, Hemendra-MCTS "Yesterday is just a memory,Tomorrow we may never see"

    Thursday, August 30, 2012 6:25 AM
  • Thanks for the reply.

    Yes, i followed same steps.

    issue is after resetting cache.ini value to 1 and start timer service, it is not updating the cache.ini to the old value.

    But i can see XMLs are being re-created.

    Thanks,
    Abhilash

    Thursday, August 30, 2012 7:18 AM
  • It is not updating. Showing last modified date of yesterday.

    Thanks,
    Abhilash

    Friday, August 31, 2012 5:18 AM
  • Hi,

    You may refer to the articles.

    SharePoint 2010 how to clear Config Cache.ini

    http://lindachapman.blogspot.com/2011/07/sharepoint-2010-how-to-clear-cacheini.html

    SharePoint 2010 – Clearing the Configuration Cache

    http://blogs.msdn.com/b/jamesway/archive/2011/05/23/sharepoint-2010-clearing-the-configuration-cache.aspx

    Ivan-Liu

    TechNet Community Support

    • Marked as answer by Qiao Wei Friday, September 7, 2012 10:44 AM
    • Unmarked as answer by Abhilash.S Tuesday, November 27, 2012 5:37 AM
    Monday, September 3, 2012 9:24 AM
  • Abhilash, What was your resolution to this issue? Our team ran into the same issue and was thoroughly frustrated that every search on Configuration Cache would result in your unanswered question and directions on how to reset the cache which you obviously already did. We had to remove each server from the farm and join them back to the farm for this issue to resolve. Narrative below....

    Situation: We have 5 SharePoint 2010 servers, 2 Application and 3 WFE, and were having issues updating some Farm Solutions through known healthy WSP files. The deployment would start but never complete, the one-time timer jobs would never remove themselves from the queue. After establishing that this was a consistent behavior, we looked at the configuration cache knowing that the systems were out of sync.

    We performed the steps that everybody has posted and reposted about resetting the configuration cache, which appeared to work properly but the WSP issue would remain.

    When I say that the configuration cache reset appeared to work properly, I mean that we would stop the SPTimerv4 service on all servers, delete all the XML files, reset cache.ini to 1, and then start the SPTimerv4 service. After starting the service, the XML files would repopulate in the Farm Configuration folder. So that appears correct.

    However, I noticed that two of the servers (one WFE and one App server) would have 2064 items in the folder and the other three servers would have 1032 items. On opening the Cache.ini file on the three servers, we found that it still read "1" rather than ever increasing. Furthermore, the modified timestamp never changed.

    We tried to completely shut down all SharePoint Services (IISReset Stop, Stop SPTimerV4, Stop SPAdminV4, Stop OSearch14, Stop SPTraceV4) on all servers, reset the configuration cache, and then restart everything one server at a time. The result of this was that 4 servers now had 1032 items and a never updating cache.ini file. One server had 2064 items with an updating cache.ini file and this was one of the WFE servers.

    So this meant that both Application Servers which both hosted Central Administration were out of sync from the farm, and the one server that appeared to be in sync ran none of the important farm services.

    Enough Situation...

    Resolution: We knew that the only resolution to this issue would be to run the SharePoint Configuration Wizard, but we were not convinced that just rerunning is on all the servers would fix the farm so we went one step further. Starting with one of the Application Servers, we ran the Configuration Wizard and removed the server from the farm. This took a while to run but completed successfully on the second attempt. We rejoined the farm and everything was healthy, cache.ini file updating with 2024 items in the Farm Configuration folder. Then we performed the same remove server/add server steps on each of the WFE servers. Cache.ini updating properly, with roughly the same number of items in the Farm Configuration folder (plus/minus 12 items, note that these numbers don't need to be the same). Did the same on the other application server by removing it from the farm and adding it back and this one was updating properly.

    And then on to the WSP deployment, with all the servers back in sync we proceeded with our original task. One of the WSP deployments were hung on one of the servers. To clear out the processing we stopped SPAdminV4 on the server, ran “stsadm –o execadmsvcjobs” which forced the processing of that hung job. From that point on we had no more problems with the WSP deployment. To clear that processing on the whole farm, the execadmsvcjobs command should be run on all servers in the farm.

    • Proposed as answer by Kevin E. Carbray Monday, November 26, 2012 2:35 PM
    • Unproposed as answer by Kevin E. Carbray Monday, November 26, 2012 2:35 PM
    • Marked as answer by Abhilash.S Tuesday, November 27, 2012 5:40 AM
    Monday, November 26, 2012 2:31 PM
  • Hi Kevin,

    For us it turned out to be issue with Powerpivot service. It was not unintalled properly.

    But, yes running sharepoint wizard again might help resolving this issue.

    Thanks for your reply.

    Abhilash

    Tuesday, November 27, 2012 5:39 AM