The server is unavailable and could not be accessed. The server is probably disconnected from the network

All of a sudden my FAST search crawler is returning the following error on every item:
The server is unavailable and could not be accessed. The server is probably disconnected from the network

I already had DisableLoopbackCheck enabled so that wasn't it.
In any case, I removed the DisableLoopbackCheck and decided to try BackConnectionHostNames instead (ie: the safer method). This also didn't help
I tried adding in DisableStrictNameChecking. This also didn't help.
Hours of searching, I was about to give up, then I thought I'd check the hosts file. At that point, I remembered that I added an entry there when I had previously done some maintenance on that server. After I removed that errant entry, my crawler now works.

Crawling root web of a site collection

I was recently trying to troubleshoot a search problem with my application. It turned out that there was a list at the root web of a site collection that was not being indexed by search.

$ssa = Get-SPEnterpriseSearchServiceApplication | Where-Object {$_.Name -eq "FAST Search Query Service Application"}

$logViewer = New-Object Microsoft.Office.Server.Search.Administration.LogViewer($ssa)

$urlProperty = [Microsoft.Office.Server.Search.Administration.CrawlLogFilterProperty]::Url

$stringOperator = [Microsoft.Office.Server.Search.Administration.StringFilterOperator]::Contains

$crawlLogFilters = New-Object Microsoft.Office.Server.Search.Administration.CrawlLogFilters

$searchUrl = 'my URL'

$crawlLogFilters.AddFilter($urlProperty, $stringOperator, $searchUrl)

$i=0

$urls = $logViewer.GetCurrentCrawlLogData($crawlLogFilters, ([ref] $i))

$urls

Then I checked with a colleague and it turns out that all I needed to check was Site Actions->Site Settings->Search and offline availability. The "Allow this site to appear in search results" was set to No. 

Trying to configure FAST search and SharePoint Search to work on the same web application

I have been trying to run FAST search for my content and standard SharePoint Search for people search. I know FAST can do people search, but a third party application is forcing my hand.
I believe I have run into a wall as it appears that the OOTB search web parts do not allow you to pick one search over the other and the Configure Service Application Associations only lets you pick down to the granularity of the service application.
Incidentally, if I do not have FAST Search Query Service Application set as default in my Configure Service Application Associations, my FAST Search Center will return an error "The search request was unable to connect to the Search Service"

Oh well, time to give up and move on.

Access is denied when crawling despite account having access - using basic authentication

I had just set up a content source and ran a full crawl of one of my sites. However, this is what I got in the crawl log:

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

I doublechecked that my Default Content Access Account indeed has rights to the entire site by logging in from the server as that account and browsing around. I also had DisableLoopbackCheck set (don't worry, this is not a production machine).

So, I looked at the IIS logs to see what is going on. However, there were no access attempts recorded. Given that the machine is accessible I concluded that this was an authentication issue.

Then I came across this Crawl Rule configuration. If you go into Crawl Rules under your search service application's management screen you can set Crawl Configuration to "Include all items in this path". Then, the Specify Authentication section will become available. Pick "Specify a different content access account" and you can specify different login credentials, but can also uncheck "Do not allow Basic Authentication" (which was my problem).

(Oh, and if you go back to reading the error message, it does suggest creating a crawl rule).

Missing FAST Administration Links

I just upgraded some of my sites to SP1 + June CU and the Administration Links for FAST disappeared. Very simple fix described here: Updating SharePoint Server 2010 from RTM to December or later Cumulative Update disables FAST Search links in site collection administration (KB2521577)

Unable to install Hotfix for Microsoft Windows (KB976462)

While installing FAST Search for SharePoint, I came across this error:
Error: The tool was unable to install Hotfix for Microsoft Windows (KB976462). If Hotfix for Microsoft Windows (KB976462) is already installed you may need to uninstall it and run prerequisite installer again.

It turns out all I have to do is run the installer again since I was running Windows 2008 R2 SP1 which already has the necessary fixes.

Reference: KB2581903

Sluggish site, multiple authentication prompts - caused by stack overflow in IIS application pool worker process

On one of my servers, users were reporting:

• Site was sluggish
• Sometimes several authentication prompts

I check the site, and here is what I found:

In the ULS log, some messages logged by mssdmn.exe including:

CSTS3Accessor::Init: InitRequest failed for URL http://my-server/clientxyz/Pages/Home.aspx Return error to caller, hr=80041204  [sts3acc.cxx:546]  d:\office\source\search\native\gather\protocols\sts3\sts3acc.cxx

In the System log, regular Warning events logged by WAS, ID 5011 with the message:

A process serving application pool 'SharePoint - [my-server]80' suffered a fatal communication error with the Windows Process Activation Service. The process id was '12028'. The data field contains the error number.

In the Application log, regular Information events logged by Windows Error Reporting, ID 1001 with the message:

Fault bucket , type 0

Event Name: CLR20r3

Response: Not available

Cab Id: 0

Problem signature:

P1: w3wp.exe

P2: 7.5.7601.17514

P3: 4ce7afa2

P4: Microsoft.SharePoint

P5: 14.0.0.0

P6: 4bad8a7a

P7: 5cc9

P8: 0

P9: System.StackOverflowException

P10: 

Attached files:

These files may be available here:

C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_w3wp.exe_69fc9436e8b5896ded626b3ecf45dce746b517_3ed230ba

Analysis symbol: 

Rechecking for solution: 0

Report Id: 245f9c35-aaa0-11e0-96d0-f4ef7acc1a53

Report Status: 4

These all happened every 15 min - coincidentally the frequency of my incremental crawls

What can I conclude from this evidence? The W3WP is crashing. This would explain the users' various reports of sluggish behaviour and repeated authentication prompts. Now to figure out why the application pool process is crashing.

Some searching and I find this TechNet article Event ID 5011 - IIS Application Pool Availability under Troubleshoot Windows Server 2008 R2. So, I go ahead and download and install Debug Diagnostics x64. So far so good, but for some reason it runs only in Analyze Only mode. The documentation and help screens don't match the application. So, I thought I'd try the 32-bit one. This one matched the documentation, but is unable to attach to my w3wp.exe processes. Searching some more, I find that Debug Diagnostics is not supported on Windows 2008 R2 (major WTF moment!) and to follow How To: Collect a Crash dump of an IIS worker process on IIS 7.0 (and above) instead. So, I am now looking for WERCON. Well, of course this doesn't exist either, but I can read the .wer file with Notepad and this didn't give me much more information than the Application Log.

Frustrated, I give up on the diagnostics and try to do a little more experimenting. Is my FAST search crawler overloading the application pool? I create a Crawler Impact Rule to limit the crawler to one document request at a time. Still, this did not help.

Even more frustrated, I decide to see how much of an impact the crawl has. I go back to the ULS log and look at the URLs and try them out in a browser. Jackpot! The very first address I tried crashed the worker process. I try it a few more times and each time I got the same crash. 

Curious, I did more digging. The site was created at roughly the same time the WAS warning messages started showing up in the System log.

So, it turns out that one of my sites was causing the W3WP to crash and whenever the search crawler runs, it tries to crawl that site causing the crash. To workaround the problem, I added a new Crawl Rule to exclude the culprit site. This appears to have worked.

Host name validation failed when configuring FAST Search Server 2010 for SharePoint

This was extremely frustrating while trying to figure it out. Now that I have it is pretty obvious. I was configuring a FAST Search Server 2010 for SharePoint. In the Configuration Wizard at the Server settings screen, it asks for a Server name. The documentation says that this is the FQDN of the server. All my servers have their own name but also have an alias pointing to them. Of course, I always refer to these servers via their alias. So when it asked me for the server name, I naturally entered the alias. The wizard rejects this with a dialog box "Host name validation failed - Please provide a valid server name". I checked firewall settings, event logs and found nothing. It finally dawned on me to actually use the FQDN (easiest way to confirm this is to right click My Computer and select Properties) and it worked.

The strange thing is that if the wizard is able to determine an incorrect FQDN, then why couldn't it just set that value?