SharePoint Search – No Results after really long crawls–currently blaming and shaming SP1 and CRL checks


I had a customer this week that had:

  • SharePoint 2013 Enterprise
  • Windows Server 2012
  • SQL Server 2012

Prior to applying Service Pack 1, Search was working without a hitch for the most part.  However, shortly after applying service pack 1 (SP1), the customer started reporting that SharePoint Crawls, whether they were full with incremental, or using continuous crawl, would go from taking minutes to run, to running for 18+ hours and yield zero results (no successes, no warnings, no fruit whatsoever).  More frustrating was that initial troubleshooting efforts would not yield any clues in Windows Event Logs or ULS/Diagnostic Logging.

So What

The customer stumbled across a Google article that I didn’t so he gets the win for finding a solution (we were are at the point of considering rebuilding the search service application and that seemed silly).

The problem in this case was identified by Richard Skinner (  The strange and frustrating thing is our previous techniques for dealing with CRL and performance issues (we have had best practices in place for this for ages in our builds and troubleshooting/performance checks) now need another element added AND this particular problem/solution/fix got aggravated by Service Pack 1 (at least, that is clearly what the timing of the problem was).

Most frustrating was there were no other noticeable errors, symptoms or logs and the content access account could browse the content (verified at the console), etc. so this was pretty difficult to detect.


Now What


  1. If you are experiencing slow page or search crawl performance
  2. If your Search Crawls yield zero results or start to post SP1
  3. If you like to squeeze everyone ounce of juice out of your SharePoint page performance


Be sure to:

  1. Check out Richards article:
  2. Read Microsoft’s best practices for Certificate Revocation:


Happy Hunting!