Category: search

Had an interesting problem the other day where, upon examining the Search Administration service, it was discovered that no content was being indexed. Any existing content in the index had been removed en masse one night.

Neither restarting nor resetting the index, common ways to fix search errors, did anything. Any new indexing attempts would yield errors saying that the content could not be indexed because access was denied. The content access account did not have any issues with it, though an attempt at updating it for the sake of completeness yielded the following error on the Search Administration page:

The search service is currently offline. Visit the Services on Server page in SharePoint Central Administration to verify whether the service is enabled. This might also be because an indexer move is in progress.


Still, the error did not point to anything of use. According to the Search Administration page the search server was healthy and running, with everything showing green checkmarks (the only clue that something was amiss was that there were no searchable items).

An examination of the SharePoint ULS logs showed the following:
mssearch.exe SharePoint Server Search Crawler:Gatherer Service High Failed to encrypt new master key [gthrapp.cxx:4149] search\native\gather\gthrsvc\gthrapp.cxx

mssearch.exe SharePoint Server Search Crawler:Gatherer Service High Failed to write master key to registry [gthrapp.cxx:4094] search\native\gather\gthrsvc\gthrapp.cxx

Unfortunately these seems to have been an unique situation – no one else seems to have had this problem (that I found).

Further investigation into the Windows Event Logs yielded this for the search service service account:
The LoadUserProfile call failed with the following error:
Access is denied.

Finally! A clue! Turns out the profile for the search service account was corrupt. By deleting the corrupt user profile (which showed up as “Backup” on the User Profile management dialog (Computer > Properties > Advanced > User Profiles) and restarting the search service, our search finally was able to reindex our content!

One of our SharePoint servers wasn’t responding the other day. At all. Central Administration and the sites hosted on the server wouldn’t load. You could try to login through Remote Desktop, but that would go as far as getting your login information and stop there. Ditto with the console.

Rebooting the server seemed to help slightly, in that you could actually get some stuff to load within the first 5 minutes before everything ground to a halt again. Browsing through the ULS logs showed that something was accessing content on the server under the search crawl account.

Seems like a “Full” crawl started previously never finished. But how would you stop that search without access to the Search Service Administration page?

Luckily we were able to launch a SharePoint PowerShell window before everything ground to a halt. Via http://www.sharepointdiary.com/2015/05/force-stop-sharepoint-search-crawl-using-powershell.html, the following command will let you stop SharePoint crawls using PowerShell:


Get-SPEnterpriseSearchCrawlContentSource -SearchApplication "Search Service Application" | ForEach-Object {
If($_.CrawlStatus -ne "Idle")
{
Write-Host "Stopping crawl on Content source $($_.Name)..."
$_.StopCrawl()

While ($_.CrawlStatus -ne "Idle")
{
Write-Host "Waiting to crawl to be stopped..." -f DarkYellow
sleep 3
}
write-host "Crawl Stopped Successfully!" -f DarkGreen
}
else
{
write-host "Crawl Status of the Content source '$($_.Name)' is Idle!" -f DarkGreen
}
}


We’re moving on up! Over the past month we’ve been working on upgrading our SharePoint farms to SharePoint Foundation 2010. So far, so good, except for one rather annoying roadblock that’s taken me ’til now to figure out.

We’re using Search Server 2010 Express to power our searches on Foundation (why not just SharePoint Foundation search, you ask? Because it doesn’t support iFilters, such as Adobe’s PDF iFilter). Like Office SharePoint Server 2007, Search Server 2010 features an administration page for managing the system.

The problem we were experiencing was that once we imported in the databases from our existing SharePoint farm, the search administration page was inaccessible to anyone except the System Account. It didn’t matter that the user logged in was a farm administrator.

While there are TechNet discussions regarding this issue, there are no real solutions. Bummer.

After multiple rebuilds of the 2010 farm, we narrowed down the problem to one content database. Testing the database for issues (PowerShell cmdlet Test-SPContentDatabase) yielded no problems. Nor did wading through the “verbose” logs (which by the way, is no fun, as it is indeed verbose). Some further investigation narrowed it down further to one particular site collection. Remove the offending database or site collection and access to the administration page would be restored.

We began by checking the site for permissions issues, some of which did pop up but did not fix the issue. Next we checked for long URLs (remember, SharePoint does not like URLs > 256 characters). None found. After some more experimentation, eureka!
As it turns out, this was a site that was imported from a Microsoft Office SharePoint Server 2007 (MOSS) farm. MOSS included some features not found in the base SharePoint product, including search. Venture onto the Features page of the site collection and you’ll find a button to activate Search features on the site.

Now we go back to the Search Administration page. Viola, we have access again!