Thursday, October 11, 2012

SharePoint 2010 SP1 changes the account used for indexing content. Not.

After updating SharePoint 2010 from RTM state (14.0.4763.1000) to Service Pack 1 (SP1, 14.0.6029.1000) a content source of the Search Service Application (SSA) suddently stopped indexing content.

The content source in question was of type CustomRepository and used a custom indexing connector to access an external system. It downloaded data via web service. And this suddenly seemed to fail.

What was going on?

Somebody cannot access something

A look into the ULS log revealed errors which happened every time the connector tried to access the web service. The crawl history showed a single top level error and the crawl log had the following entry:

"Error while crawling LOB contents. ( Credentials were not found for the current user within the target application '...'. please set the credentials for the current user. )"
The error message pointed into one direction: the Secure Store. All credentials for accessing the external web service were saved in the secure store. And one account was allowed to get these credentials. The message was suggesting that another account than the allowed one was trying to get the credentials.

But what is the "current" user? Shouldn't the user be the Default Content Access Account of the SSA as configured in the Crawl Rules?

Identity crisis

After looking into the task manager I decided to give credential access to one account: the account mssdmn.exe runs under, which is the account of the SharePoint Server Search 14 service.

And it seemed like

  • before updating to SP1 the Default Content Access Account (as configured in the Crawl Rules) was used to access the secure store credentials
  • after updating to SP1 this account apparently changed to the account of the SharePoint Server Search 14 service.

So the solution was simple, yet mysterious: I changed the account allowed to access the web service credentials. And it worked.

But stop!

Resolution? Confusion.

After a few days I deleted the content source previously affected and added it again. And the indexing stopped again. Same error as before: "Credentials were not found for the current user within the target application '...'. please set the credentials for the current user." What was going on this time?

The account used by Search to access the secure store credentials changed again. To what was set prior to installing SP1: the Default Content Access Account of the SSA. As one would expect.

Strange.

2 comments:

  1. Hi Heinrich,
    I have a custom indexing connector in SharePoint 2013 and I am accessing the Secure Store Service programmatically within the connector code to retrieve credentials to connect to the external system.
    However, when I access the secure store, it does not use the Default Content Access Account, but the mssdmn.exe account (in my case Network Service) and throws the SecureStoreCredentialsNotFoundException. I would expect it to use the default content access credentials even within the connector code. Am i right?

    Thanks,
    Nandini

    ReplyDelete
    Replies
    1. Hi Nandini,

      you are right, it should use the content access account. Be sure that you have no crawl rules specifying a different account than the default one. If not, it would be interesting to hear if your situation is also just temporary and goes away at some time. This would suggest a SharePoint quirk.

      Regards
      Heinrich

      Delete