Ever had this happen to you? No, probably you haven't, but then again…have you been a good Admin and tested your Search Backup and Restores? No, didn't think so. So if that fateful moment ever happens, here's what can cause it and what you have to do to clear this status code.
The issue arose when I was trying to backup and (unsuccessfully), restore using the Central Administration UI. This I am afraid is a futile approach. Things really only work when you use Windows PowerShell for backup and restore and I highly suggest you keep to that.
So what happened? Well, somewhere in the process of restoring after I FULLY deleted the search service application, the status got corrupted. The restore DID work successfully, but I was left with a status of "Paused for:Backup/restore" on the main admin page.
Looking up the code for that page, their is a web part called SearchApplicationSystemStatus. It interrogates the search service application object and then makes a call to a method called GetStatusString. GetStatusString runs the IsPaused method on the SearchServiceApplication which then makes call to the stored procedure called "dbo.proc_MSS_GetPauseCrawlsReasons". This looks up some data in the search admin database table called "MSSStatusChange". This table has some records in it (that you should not delete), but have a status code on them. If the status is anything but zero, your search will be in some state other than "Running". When this happens, you can pretty much guarantee that some items are going to effectively be OFF. This includes things like no Crawling, no searching, no index replication…etc.
Of course, I needed to re-crawl my content, after trying to start the crawls, they just stayed in "Starting" state.
So how to you fix this? I suppose an easy, yet long and wasteful approach would be to attempt to do a backup and then a restore. But I hate waste. So I changed the status codes to zero. What happened? Didn't work…crap. Then I did a restart on the "SharePoint Search Host Controller" just to re-initailize things. Didn't work.
So, one last ditch effort, I manually paused the server (via the quick launch on the search admin page), then resumed it. This kicked the crawl component back into action! Sweet! Solved!