The Search application is not available for (all these) sites.

I was at a client site, checking on someone’s work in migrating a SharePoint Search system from one domain to another.

Everything was looking good – the crawl was working, a search returned hits as expected. However when I checked the Advanced Search page, I saw the error:

The Search application is not available for this site.

Oops – that didn’t look good.

Grabbing the message, I plugged it into Google in hope of finding a solution.

Much to my surprise, Google listed 43 sites that matched that error message, and 38 of them linked to the Advanced Search pages of public sites that were having the exact same problem.

Now fortunately the first link in the search results had the answer. So, I had this one fixed pdq.

What amazed me was the other links that directed to public web sites. These included schools, a government department in Qatar, the Connecticut National Guard, the Massachusetts National Guard, as well as other “interesting” sites.

I’m flabbergasted. It would appearthat these sites have undergone a similar exercise where something was changed. Someone had done some cursory testing, and had given the “It’s all good” sign.

And that was it.

Here – have a look for yourself.

Related Posts

The importance of real End User Acceptance testing

Importance of End User Acceptance testing

Here’s a real-life story that shows the importance of End User Acceptance testing and what happens if this is skipped.


Just doing an upgrade

I was a systems analyst in a project for a client once that involved an upgrade for an Enterprise Search application. The application allowed users to locate documents that were scattered across different locations and was one of the important tools that the users relied on to do their job.

The tech guy who was doing the upgrade had worked many, many hours.

The job was not complex, but the server on which the application was installed was also used for other things and so, there were starts and stops as others demanded their own slice of time to do maintenance on other apps running on the system.

Time to test

Finally, Techguy had finished the upgrade. He made sure that all the settings were still correct and that the software was still able to give the logged-in users access only to the documents that they were allowed to see.

Techguy ran the software and checked that there were no errors.

Everything looked fine. The documents were being returned OK.

He did further testing, by physically eyeballing a document in the system, checking the content, and then doing searches on various metadata, as well as content searching. Yep, system worked well.

Techguy even performed Regression Testing, following a scripted Regression Test that he had written. It went through the whole process of creating a document, sending in for review, getting it approved, changing the status of the document, etc.

Everything checked out beautifully. Techguy proudly confirmed that the system was working fine.

Then the errors started

Then the users were allowed back onto the system. Within hours, tickets issues were being lodged. It seemed that the documents that were being returned in a Search were not opening. The user would click on a search result, and get greeted with a page not found error.

Techguy was called back in. He started looking at the system. Everything looked OK. He was told to look harder. After much scratching of head, and flicking back and forth between various screens Techguy looked up sheepishly. “He had forgotten to add one critical setting – the address of the computer that would allow a document to be displayed.

It turns out that all the Search application could talk with most of the computers involved, but when it came to doing the indexing, but when a request was made to open a document from the search results, a different mechanism was used. If the address of another server is not correctly entered, then a big fat nothing happens when a user clicks on a search result.

End User Acceptance testing – Test as a user, not as a techie …

Techguy was just that – a tech guy. When he did the upgrade he was a tech guy, and when he did the testing he was a tech guy. And

When he did the upgrade he was a tech guy, and when he did the testing he was a tech guy. And as a tech guy, he had focused on the technical side. He had made sure that all the main knobs had been turned, he had made sure that the process of indexing was working fine. He had even made sure that the system was returning search results as expected. The one thing that he hadn’t done was to try and open one of the documents that was returned!


Techguy’s oversight raised a very important point.

As well as technical guys doing technical testing, end users are also required to do end-user testing.

Why? Because the end user does stupid things that the technical people never expect…they actually use the system. And, even if there is a Standard Operating Procedure in place, users tend to use systems in ways that the technical guy would never think of.

Recommended Resources 

[Important Disclosure]

Udemy Courses
The Best Software Testing Training You Will Ever Get
Software Testing,QA Testing, Manual Testing,SDLC,Test Plan
An Intro to Software Testing: Ultimate Guide for Testers
Software Testing
Testing In Agile