Corey Roth [MVP]

I was working on an Enterprise Search deployment the other day and I encountered this lovely error.  I found the answer buried in some forum posts, but I wanted to tell you what side effects I found when implementing the solution (and I wanted to make sure I could find the answer again someday when I forget it).  In my case I configured my Content Source to crawl a remote SharePoint farm (although I don't think being on a remote farm has anything to do with it).  When I started the crawl, I saw the following error in my crawl log.

HRESULT E_FAIL has been returned from a call to a COM component

The reason this error occurs is because, I did not have impersonation enabled in my web.config.  I needed a line that looked something like this.

However, before you are doing that, you need to know that this really changes the way security works on the site.  When impersonation is enabled, it means the Application Pool account will no longer be used to execute ASP.NET page requests.  It also means that if you are using Integrated Security with your connection strings, that you will most likely end up with an error message such as the following.

Login failed for user 'NT AUTHORITY\NETWORK SERVICE'

Additionally if you are using the SqlDataSource, it is most likely mapped to the SpSqlDataSource (unless you removed the tag mapping) and will get a message like the following.

This control does not allow connection strings with the following keywords: ‘Integrated Security’, ‘Trusted_Connection’.

I talked about the above message in the past.  On a related note, I have discovered (assuming Impersonation is off), that you can enable Integrated Security with the SPSqlDataSource control by setting the AllowIntegratedSecurity property to true.

So what is the bottom line?  Well, from my personal attempts as well as from what I have read in forums, it is not possible to have Impersonation enabled as well as use Integrated Security with your connection strings.  In theory, I do believe it could be possible if you were to give all of your SharePoint users the same permissions as your original application account on your SQL Server.  What I mean by that is give DOMAIN\Domain Users permission directly on the database.  I don't really like that idea though.  This, unfortunately, left me to breaking a best practice (come on not like SharePoint hasn't made you do that before) and use an internal SQL account for authentication. 

I am out of ideas on this one, so currently this seems to be my only answer.  Once, I changed my connection string and turned impersonation off, I recrawled and everything works great.