We just created a new Search Service Application and manually triggered the Full Crawl for a Web Application we want to crawl. The crawl completed under 2 minutes with 0 searchable items. The default SSA by SharePoint gets the same result as well hence we created a new one, hoping it'll resolve the issue.

Error Messages

In Central Admin, the crawl log recorded 1 error

  1. http://targetCrawlSite SharePoint failed to process this item. (Error from SharePoint site: Cannot complete this action. Please try again.)

In ULS Logs, I found 3 entries.

  1. Couldn't retrieve server (http://targetCrawlSite) policy [sts3util.cxx]
  2. STS3::StoredCachedError:Object initialization failed. Message: "Error from SharePoint site: Cannot complete this action. Please try again."
  3. The start address (http://targetCrawlSite) cannot be crawled. Context:Application 'My_SSA_Name', Catalog: 'Portal_Content' Details: SharePoint failed to process this item.

In Event Viewer, I found 2 entries.

  1. Content plugin can not be initialized - list of CSS addresses is not set
  2. The start address (http://targetCrawlSite) cannot be crawled. Context: Application ' My_SSA_Name', Catalog 'Portal_Content' Details: SharePoint failed to process this item.


What weird is that when I tried changing the crawl address to other web app (in the same farm). It finished with 40+ searchable items which is acceptable since it is just a very small web app anyway. The point here is that it was able to find items from that web application.

Other things I checked

  1. Crawl Account has 'Full Read' permission on both Web Application
  2. Crawl Account is in Local Admin group
  3. Crawl address specified is the 'Default' zone address
  4. SharePoint search related services both in Central Admin and server are in running state
  5. The main web app is using Windows authentication while the small web app uses Claims Based Authentication

Possible Cause (Difference between 2 web apps)

Alternate Access Mapping - main has 3 default zones while small web app has 1 default zone

Authentication Provider - main is using Windows(NTLM) while small web app uses Claims(NTLM)

Any thoughts would be highly appreciated.

  • Have you tried to open the web application from the crawling server using the search account? I am not sure what is the topology you use (ie do you crawl the FE or you have WebApp as well on crawl servers) Mar 11, 2019 at 9:01
  • Hello @MarekSarad, we only have single server that hosts Web Apps, Search, etc.. Yes, I also tried using the search account to browse the web application sites and I can view its contents just fine. I really wonder why it can't crawl. I am not seeing any login failed in the database logs too.
    – mjnp
    Mar 11, 2019 at 23:21
  • If it’s a single server and you’re not crawling the hostname of the server, you could be encountering a loop back issue. Have you disabled the loop back check for ntlm (or whitelisted the correct hostnames)?
    – Greg W
    Mar 12, 2019 at 8:54
  • Hi @GregW, I've checked the registry and it appears that loop back check is already disabled. (I didn't know at first because I became an interim administrator when my colleague left the company). I would probably request our security team to check for the white listed host names.
    – mjnp
    Mar 12, 2019 at 23:29
  • It’s one or the other. If the loop back check is disabled, then whitelisting via backconnectionhostnames is irrelevant. (It was just a suggestion)
    – Greg W
    Mar 12, 2019 at 23:39

1 Answer 1


Do you have a top level Site Collection? Something like this:

http://targetCrawlSite               <-- top level site collection

or only this? (no top level site collection)

  • Yes we have top level site collection.
    – mjnp
    Mar 11, 2019 at 1:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.