I recently got a hardware upgrade and had setup up a new farm in a virtual environment using Hyper-V, after which I ran into the following problem after configuring search and attempting to perform a search.
Scenario: I created a new web application on port 100 with no host headers & then a site collection based on collaboration portal. On one of my client machines, I had a HOSTS file entry named NorthWindWeb that mapped to my Web Front End server. Thus I would access the application as http://northwindweb:100
Later, I uploaded some documents using the browser interface and ran a Full Crawl. The first thing I observed was that my crawling failed. I have written a separate blog post here on how I went about troubleshooting the problem. Anyways, so after fixing the crawl issues, I observed a peculiar behaviour – In the Search Centre of the collaboration portal, if I click on Advanced Search, I’d get back the following error: The Search Application is not available for this site.
My first instincts are to look at the Event logs on the Web Front end. I check the event logs on the web front end because that is where my request is sent to. Nothing in there. As always, the first thing in any troubleshooting is Scoping the problem area. Scoping really helps narrow down on the problem area.
In this case, it had to be some sort of configuration problem since I can get back a page which says “search application is not available for this site”. I always say this – pay attention to the error message. Although many times errors can be misleading, there might still be some clues to begin with when you have nothing to start with.
So let me split the error - “The search application” “is not available” “for this site”. Hmmm.. for this site? Why? So does it work for other sites? I decided to use the default URL with which I created the web application to begin with – which was http://servername:100. I did so because when you create applications with a specific URL, I’d at least expect the system to get it configured properly using the defaults. So in this case I opened a new browser and navigated to http://servername:100, clicked on the search centre and then Advanced Search. Cool! I was able to browse to the page without errors and search worked as expected! Now I figure that there is something wrong with the URL that I am using – which is http://northwindweb:100. What is wrong? I am able to browse perfectly!
So here’s where some domain knowledge can help you move forward. In Office SharePoint Server, the Alternate Access Mappings (AAM) has a huge significance. AAM plays a vital role in accessing content, especially shared services. If you find one URL works and another doesn’t in MOSS apps, think AAM. So my first instinct was – Is the URL that I am using configured in the alternate access mappings configuration for that web application? Turns out that I didn’t have it! Although my HOSTS file entry was routing the traffic to the web front end correctly, the MOSS system doesn’t recognize the incoming URL HOST value. It checks its database and does not find this site/URL information and therefore returns the error. It works with the server name because it created the AAMs when I created the web application.
So I am sure you all know the resolution by now. 🙂
1. Open Central Administration Site.
2. Select the Alternate Access Mapping for that web application.
3. Click on Edit Public URLs link.
4. In the Intranet text box, add the value http://northwindweb:100
5. Click OK and test.