Access is Denied error for Search Service Application

I have SharePoint 2013 running on Server 2012 R2 Standard.
We have a fairly basic site that consists almost exclusively of document repositories.
I've been trying to configure the Search Service Application to crawl the site for search indexing.
Initially, I followed recommendations found online to create a Default Content Access Account for the Search Service, and gave it permissions to both the SQL databases, as well as full read permissions to the Web Application for the site.

After adding the site as a Content Source, I started a crawl and received the following error:
Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled.

To try and narrow down the permissions issue, I switched the Search Service to use an account with full administrative permissions to the Web Application, and received the same error.

So far, I've tried using an account that has explicit Full Control permissions both on the Web Application and the Site Permissions. As well as Full Control permissions on the Search Service Application itself, same error.
I've tried using the Farm account as well, same error.

I've tried creating a new Application Pool for the Search Service.
I've tried creating a new Search Service Application and Application Proxy.
I've tried using different variations of both the internal and external IP and URL of the site as the Content Source, as well as trying different content source types.

Each time, the crawl fails within 20 seconds with the same error.
The only variation I've seen is if I specify a Crawl Rule, the crawl will run for almost 2 minutes before failing with the same error.

I've tried the recommendation for disabling Loopback Verification in the registry, and for resetting the credentials in the IIS App Pool with no change.

Both the server OS and Sharepoint 2013 are fully updated.
The server is running SQL 2008 R2 for the databases.
The only unusual aspect of the deployment is that the WSS_Content database is configured with encryption at rest using TDE.
I haven't been able to find any information on if this would somehow cause an issue.
Who is Participating?
SINC_dmackAuthor Commented:
We spent three days assisting Microsoft with troubleshooting the issue.
In the end, it appeared there was an issue with the configured farm account.

Get-SPManaged listed a farm account that did not match the farm account configured in Central Administration.
In fact, Get-SPManaged listed an account that didn't even exist.
We were unable to change this by reassigning the farm account in Central Administration, and trying to change it in the Management Shell would fail.
We finally had to use the Shell to forcible delete the farm account setting for this non-existent account before we could apply the correct account.

After this, they also disabled all Offloading settings in the network adapter driver settings.

Now the crawl error was about the repository not responding withing the specified timeout period.
This was fixed by unchecking the Automatically detect settings option in the Internet Options.

The crawl was now running successfully.

Microsoft had no explanation for why Central Administration was wrong about the configured farm account, or why everything except the search service was working properly with this farm account misconfiguration.
Walter CurtisSharePoint AEDCommented:
Give the account you will use for crawling full read access via a user policy for the web app in central administration. That may help.

Good luck...
SINC_dmackAuthor Commented:
Thank you for the recommendation, Walter. However, I've already tried this in my previous troubleshooting with no effect.
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

SINC_dmackAuthor Commented:
We ended up calling Microsoft and opening a $500 case.  They did eventually get the issue resolved.  We'll follow up with details.
Walter CurtisSharePoint AEDCommented:
Glad you resolved the issue.

Have a good one...
SINC_dmackAuthor Commented:
Solution was obtained by working with Microsoft's paid support.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.