SharePoint 2013 Search Crawl Timeout Issue

​Implementing SharePoint 2013 in a secure zone as an extranet application might be challenging, if you are deploying your farm in a zone with many restrictions.

Recently, I deployed a large SharePoint 2013 farm in a DMZ zone for a regulated portal. Regulated data in my case meant the following restrictive rules in the network and on the servers in the farm:

Configuring SharePoint in this environment was not a straight forward exercise. After disabling some GPO policies to allow the creation of the IIS web applications, we had to map out the communication between all the servers so the firewall ports are open, allowing each server in the farm to talk to each other.

To get a better understanding of the ports required in your farm, you can follow this TechNet article. It explains the details of each port and its use.

Configuration SharePoint was successful; everything worked, the portals are up and running, content is being populated, User Profile Service Synchronization is working, and the Search Service Application is up and running.

However, I was faced with a very challenging issue when crawling content. Crawling the SharePoint content source always returned a "timeout" error in the logs. Resolving this issue took a lot log monitoring, custom code to monitor the traffic, and long nights.

This means that the search crawl is sending an HTTP request to your portal, but it is not receiving an answer back. The authentication is fine, security is OK, but there is no HTTP trip back to the crawl server.

There are my suggestions to a Search Crawl Timeout issue; one of the following suggestions might resolve your issue:

1. Make sure you disable the loopback on the crawler server. In my case, this did not help at all.
2. CRL Check: Most DLL assemblies are digitally signed.  Each time signed assemblies are loaded, default system behaviour is to check with the owner of the root certificate that the cert with which the assembly was signed is still valid. SharePoint 2013 search checks few certificates, like crl.microsoft.com or *.akamaitechnologies.com. To resolve this issue, open the outbound internet connection . If this is not doable, then install the crl.microsoft.com certificate on the server, or add an entry to local server host file like this: 127.0.0.1 crl.microsoft.com. This way certificate checks does not need to validate the certificate over the internet;
3. Add exceptions on the firewall to allow traffic for the certificates; or
4. Open Internet; or
5. Revisit the firewall rules.

I suggest to first looking into the firewall rules again. 9 out of 1, it is the firewall that is doing funny things to block traffic between the servers. In my case, the security team were using Cisco Smart Care firewall, which is an advanced firewall and it does not only look at the ports' rules. You will have to create exception for applications, because it detects SharePoint and it automatically blocks it if SharePoint as an app is not listed as one of the trusted apps.