OK, I’ll admit it – this one was hard to figure out.

Background:

SharePoint 2010 Standard server.  Search was returning content, crawlers were filling the index.  No immediate customer impacting issue.

The Issue:

The event viewer had an error occurring every minute – Event ID 6482 which states:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (21e4447f-bac6-4a29-82db-165e074ac5db).

Reason: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by domain\user, in the OWSTIMER (5040) process, on machine (server name).  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 domain\user, in the OWSTIMER (5040) process, on machine (server name).  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)

It turns out there isn’t a lot of information about this specific issue available via your search engine of choice. I was able to find some similar information but that was related purely to the User Provisioning Service.  So I went with the old tried and true:

  • I reset the Index
  • I deleted/recreated the Search Service App

Neither of these worked so I went back to the 2 blog articles I found that were similar the issue I was seeing.  Turns out that this happens when “the contents of the file system cache on the front end servers is newer than the contents of the configuration database”.  This could happen if you’ve recently been through a system upgrade or recovery.

Resolution:

The file system cache on all FE’s (in my case, this was just one server) on which the timer service is running needs to be cleared.

Below is the step by step provided by Microsoft in this KB Article for doing this:

  1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
  2. Navigate to the cache folder
    In Windows Server 2008, the configuration cache is in the following location:
    Drive:\ProgramData\Microsoft\SharePoint\Config
    In Windows Server 2003, the configuration cache is in the following location:
    Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config
    Locate the folder that has the file "Cache.ini"
    (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)
  3. Back up the Cache.ini file.
  4. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
  5. Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  6. Double-click the Cache.ini file.
  7. On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
  8. Start the Windows SharePoint Services Timer service
  9. Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
  10. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.

In my case – it worked like a champ.  I will freely admit that I made 2 distinct copies of the cache … I was paranoid!

 

Sources for this article – you guys saved the day:

Tags: , , , , ,

38 Responses to “SharePoint 2010 Event ID 6482 Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance”

  1. marbs says:

    perfect. Thank you.

  2. JoanmiPou says:

    Awesome!, it works for us!.
    Good post and very good work!
    Thanks you very much.

  3. Colin says:

    Good work. Total life saver! Thanks!

  4. JeffDeVerter says:

    Awesome! Glad it helped.

  5. Kim says:

    Awesome. This worked for me. Thanks!

  6. Vegaz says:

    Great, it works. Thank you

  7. Steve says:

    Helped us out too – thanks!

  8. Kaptain says:

    Freakin Amazing. Fixed me right up.
    Awesome tutorial. Big props Thanks.

  9. Kurt says:

    Worked a charm. thanks!!!!!!

  10. molezoe says:

    it’s fine ,that’s error fixed.think you very much.

  11. Needo says:

    Thanks it worked for me

  12. ajnar says:

    Tried your way but no joy….
    Article below helped me out to get the descriptive text of the error message.

    http://www.zimmergren.net/arch.....-2010.aspx

  13. [...] quite a bit of Google-Fu and 4 of the strongest coffees i could find, I stumbled across this post from Jeff DeVerter. Basically, what I was seeing in Event Viewer was the following error being [...]

  14. [...] quite a bit of Google-Fu and 4 of the strongest coffees i could find, I stumbled across this post from Jeff DeVerter. Basically, what I was seeing in Event Viewer was the following error [...]

  15. Nuria says:

    Worked for me. Thank you!

  16. Daniel says:

    Hi

    I am getting these as well so I will be following those steps later.

    Couple of questions:

    1) what issues have been seen with the farm ( other than filling up my ULS log)
    2) Do we know if SP1 or a CU has fixed this

    Daniel

  17. Frank says:

    Also helpded me – thanks !

  18. Vijay says:

    Thank you very much.. It saved a great trouble for us..!

  19. Mike says:

    Perfect! Here it worked also like a champ!
    Best thanks!

  20. Monir says:

    I just tried, error seems to be gone… good works – thanks –

  21. airliner says:

    You saved my day (and my nerves)! Thank you very much!

  22. Svilen Ivanov says:

    Great! Worked for me. Thanks.

  23. Rajni says:

    This is awesome stuff, i was able to solve the issue….

  24. [...] this point I was stumped so turned to the Internet and found a possible solution on Jeff DeVerter’s blog. Here’s the solution: Share this:TwitterFacebookLike this:LikeBe the first to like this. [...]

  25. Gipper says:

    This worked for me! Thanks!

  26. Greg says:

    So, I had just switched my webapp over from classic to claims and my search/crawl was dead. I did this procedure (THANKS BRO!) and for the first time in 2 days – the crawl is working. WOW. 15 minutes ago I opened a ticket with Microsoft. You saved me from having to talk to Bangalor. Thanks again!

  27. Jennie C. says:

    Worked like a charm. Thanks.

  28. Pratik Modi says:

    its very helpful. you saved my day.
    thanks a lot, man you are great.

  29. PanLoki says:

    Many thanks :) You made a recurring headache go away :)

  30. PanLoki says:

    Many thanks :) You made a recurring headache go away :)

    (This issue started occurring well after I did SP1 and am currently updated to April 2013 CU)

  31. Gary says:

    perfect, thanks!

  32. Jacques says:

    This also works for SharePoint 2013.
    Thanks

  33. Mark Dininio says:

    You sir are awesome! Worked like a charm after restoring my site. My search finally indexes and works! THANKS!

  34. Mark Dininio says:

    You sir are awesome! Worked like a charm after restoring my site. My search finally indexes and works! THANKS!

  35. Nate says:

    Genius!! This worked for SP2013 as well. Second search instance status would not get out of disabled. Hours spent banging my head on this one. Thank you!

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>