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?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.
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.
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SharePoint

From novice to tech pro — start learning today.