Caroline Sosebee is a Software Engineer at ThreeWill. She has 30+ years of software development experience and a broad scope of general IT knowledge. At ThreeWill she has a proven track record of quality consultative and software development skills, focusing on the design and implementation of SharePoint solutions, both on-premises and in the Microsoft 365 cloud.
There are times when SharePoint Search can get out of whack and you need to go in and get it cleaned up and running again. This manifested itself at one our customers recently and I thought I’d document the steps I needed to take so that I would remember them for the next time and maybe help someone else as well.
The error being returned in the UI was the usual ubiquitous message that simply said ‘Sorry, something went wrong.’ and ‘Search has encountered a problem …’ – very, very helpful messages.
The error being thrown in Event Viewer and in the ULS logs was as follows:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (09fe67b2-d3d8-4d45-a87a-bda7d45a9ad0). Reason: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by XXX\xxxxx, in the OWSTIMER (17324) process, on machine XX-XXXX. View the tracing log for more information about the conflict. Technical Support Details: Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by XXX\xxxxx, in the OWSTIMER (17324) process, on machine XX-XXXX. View the tracing log for more information about the conflict. at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize() at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)
In simplistic terms, this is basically saying that the SharePoint search index and the local configuration cache on the server are out of sync.
I then went into the Search Service Application within Central Administration and I saw that there was a warning sign under Index Partition.
So there was definitely something wrong with the search index. I found that this can typically be corrected by doing two things – clearing the cache and resetting the search index. Here are the steps necessary to complete both of these.
Clearing the Configuration Cache
The first step is to stop the timer service. This is most easily done via command prompt (run as administrator) and running this command:
net stop SPTimerV4
Once done, open Windows Explorer and navigate to the following directory:
In this folder, you’ll see several GUID folders. Open the one that has the most recent Date Modified value.
Select all the files in this folder with the exception of the cache.ini file and delete them. If this makes you uncomfortable, backup the entire directory to a temp folder before doing this.
Edit the cache.ini file in your favorite text editor and reset the random number found there to 1. Save and close the file.
Go back to the command prompt and run this command to restart the timer service:
net start SPTimerV4
Soon you should begin to see .xml files begin to repopulate in this directory. The cache is now refreshed so that just leaves the search index to reset.
Resetting the Search Index
To reset the search index, go into Central Administration / Application Management / Manage service applications.
Scroll down the list until you find Search Service Application and click on it to open.
On the left hand side, click the Content Sources link. You should see a screen like the one below. If any of the sources are set for Continuous Crawl, turn this off by right clicking on that content source and selecting ‘Disable Continuous Crawl‘. After doing this, it will immediately kick off an incremental crawl which you will also need to stop. Right click again and select ‘Stop Crawl‘ to cancel it.
Do this for each of the content sources until they all show as idle.
Once all the crawls are stopped, click on the Index Reset link found on the left, a few entries below the Content Sources link.
In the dialog, make sure the Deactivate search alerts during reset checkbox is checked and then click Reset Now.
Click Ok to confirm and start the reset. This can take a few minutes to complete so be patient.
Once complete, a full crawl will need to be started on all the content sources. Right-click each source and select Start Full Crawl. To verify the crawl started successfully, peruse the crawl logs for successful items.
Once the full crawls have completed you should set any content sources that were initially set to continuously crawl back to this.
To do this click on the Content Sources link again then click on the name of the Content Source (e.g. ‘Local SharePoint sites’) to open the Edit Content Source screen. Scroll down to the Crawl Schedules section and select Enable Continuous Crawls, then click Ok.
Your search should now be all set until the next blip knocks it out again (you know it will!).
Here are some references to a few sites that helped me get this all sorted out.