While performing a large Sitecore upgrade, we ran across an issue during the step that required us to rebuild the search indexes. It seemed that after a few minutes of working as it should, the index rebuilding process would stop abruptly. Initially, we didn’t even notice that this had happened because the “Rebuilding Indexes” dialog was still up and did not present any error message, so we waited an awfully long time before realizing that nothing was being indexed. However, when we tried again, we did quickly notice that the statistics shown for the number of items crawled suddenly disappeared when the error occurred.


My first instinct was to check the crawling logs, but there were no errors in there. I also changed Log4NET’s configuration for the crawling log for more verbose logging, but couldn’t find any clues. After looking at the standard Sitecore log, however, I realized why the indexing was being terminated abruptly. I noticed the following statement in the logs shortly after we started rebuilding the indexes:

WARN  Sitecore shutting down
WARN  Shutdown message: IIS configuration change

The issue was basically that Sitecore would shut down thinking that a configuration change was made, effectively killing the process that was responsible for indexing before the rebuild was complete.

But wait, I never made any configuration changes during that time!

It turns out that the issue was with IIS. Normally, IIS listens for file changes in the web root (and subfolders) of any application to try and intercept any changes that may require IIS to recompile the application. If that list of file changes becomes a bit much for IIS to handle, it restarts the application. So, because the indexing process was making very fast and frequent changes to files in the web root, IIS couldn’t keep up and would restart Sitecore.

So, if you have the same issue, here is how you can resolve it:

  1. Move the “data” folder out of the Sitecore web root. The “data” folder contains all of the Lucene indexes and files do change frequently in there as the indexes are updated. Also, don’t forget to update Sitecore’s web.config file to point to the newly moved “data” folder.
  2. Move the “temp” folder out of the Sitecore web root. The indexing process often uses the temp folder to temporarily extract and crawl assets (such as PDF files and images). Because that also causes frequent changes in files, it should be moved out of the web root and Sitecore’s configuration should be changed accordingly.
  3. OPTIONAL: Apply Microsoft’s hotfix for this issue in IIS. See https://support.microsoft.com/en-us/kb/3052480 for more information. If you follow steps 1 and 2 above, you shouldn’t need to do this, but I thought I would mention it, just in case.

Happy index rebuilding!