Cheat Sheet: Finding the *real Crawl State

Ever had a Crawl seeming stuck Starting, Stopping, Pausing, or even Crawling and thought… hmm, now what? Well, part of the problem is that only part of the Crawl state is shown in either the UI or PowerShell.

Crawls actually have a sub-status as well the status shown in the UI that tells you more specifically the state of this crawl – things like, “Starting, Waiting on a Crawl Component”, “Crawling, Delete Unvisited”, and so on. These Crawl states live in the MSSCrawlHistory table in the Search Admin database and have been translated into *human-speak below (Note: this is the same table that we presented at SPC14).

The SharePoint Crawl is stateful with transitional “ing” states (e.g. starting, completing, stopping, pausing) and corresponding rest states (e.g. started, completed, stopped, paused). In future posts, I’ll deep dive into:

  • How a Crawl moves from state-to-state
  • What to do when you get stuck waiting for a Crawl Component

I hope this helps!

Comments (2)

  1. This goes back to "it's a SharePoint database, treat it as a blackbox", what is the supportability statement for pulling the crawl status from this table? I know making direct modifications to this database is unsupported, but reads are also generally unsupported [unless as directed by PSS].

  2. bspender says:

    Trevor.. good catch and agreed, reads are generally unsupported. Being said, I definitely would not proactively or regularly be diving into this database. However, you could always back it up (the Search Admin DB isn't typically that big even in LARGE environments) and then restore it with another name somewhere else. Once restored (and thus, not being used by Search)… then go nuts 🙂