Event ID 2424
Recently I've seen a new error in our SharePoint server's application log event viewer occur every 5 minutes (non-essential fields removed):
Event Type: Error
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2424
Description: The update cannot be started because the content sources cannot be accessed. Fix the errors and try the update again.
Context: Application 'Search', Catalog 'index file on the search server Search'
After some Googling I found that SharePoint Services Search error with Event ID 2424 is not all that uncommon. Many "resolutions" are provided; one in particular seemed quite prevalent: Change the SharePoint Services Search Service Settings for the Service Account to use the same account as the Content Access Account. I agree. That last sentence is not exactly easy to follow. In easy-to-follow terms:
- Log into Central Administration > Operations > Services on Server > click on Windows SharePoint Services Help Search.
You should now be in Configure Windows SharePoint Services Search Service Settings on server XXXXXX.
- Update the "Service Account" to be the same account as the "Content Access Account".
- Scroll to the bottom of the page and click OK. You can see just above the OK button the Indexing Schedule; by default, this is set to every 5 minutes which is why the application event log had an Event ID 2424 every 5 minutes.
- I haven't taken the time to investigate whether you should just reset IIS or reboot the server once you've updated that account. In my case, I just rebooted the server.
As soon as I rebooted the server, the SharePoint Services Search error with Event ID 2424 disappeared.
I noticed that Event ID 2424 began around the time I installed the following WSS/MOSS security patches which came out prior to the SharePoint SP1 patch:
I'm going to make the assumption that this error will occur as soon as you install the SharePoint SP1 patch as well.
Common factors contributing to Event ID 2424:
- The SharePoint environment uses multiple domain service accounts to manage SharePoint services.
- Kerberos authentication is being used.
- The WSS/MOSS updates previously mentioned have been applied and/or SharePoint SP1 has been applied.
I wasn't completely satisfied with the above resolution since it required a change in our role-based architecture of our service accounts. After some pondering, I came up with the theory that the permissions on the Search Database (and possibly registry permissions) as defined in the Search Service Settings are modified for the "Service Account" when changing the user. If that is the case, then updating the "Service Account" to the original account should reset the permissions on the database (and registry settings if needed).
Once I was satisfied that Event ID 2424 was no longer prevalent after 3-4 days of usage using my original resolution of using the same account for the "Service Account" as the "Content Access Account", I changed the "Service Account" back to the original account and rebooted the server. Again, I waited a few days to see if Event ID 2424 was raised and low-and-behold it did not!
Somewhere along the line, the WSS/MOSS and/or SharePoint SP1 update(s) are modifying existing permissions… Shame on the updates.
I've read other posts whose resolution is to manually update the permissions on the database for the account(s) in question. Although their resolution may work, I feel it is safer and a better best-practice to allow SharePoint to update the permissions whenever possible.