Wednesday, March 18, 2009

No results matching your search were found

A search on "All sites" returns results, but when you select the "This site: xxx" no results are returned:






Match your default zone url in Alternate Access Mappings with the url used in the Content source, then you will fix this issue.

A clarification: This issue concerned a MOSS server, not a WSS installation.

47 comments:

Darren said...

Where would I find the "Content Source"?

Lise said...

Hi Darren!

First I need to ask you if you are running on a MOSS or WSS?
Cause this issue concerns when you run MOSS. In a WSS installation you dont have Content Sources.
It belongs to the SSP section! If you run a MOSS server, then enter the Shared Services section and click on "Search settings", then you will find "Content source" there.
Best regards, Lise

Darren said...

Hello Lise. Thanks for the quick response.

We are running on WSS. I'm completely new to this whole thing after our sharepoint person left the company. The search is working on 1 of our 3 web applications. The two not working come up with the message in your original post.

I've made sure they are all pointing to the corect search server and I've stopped and started the search service with no luck.

Any suggestions would be greatly appreciated.

Thanks.

Darren

Lise said...

Actually, this sounds like an AAM issue. Have you checked that all headers are listed in your AAM, Alternate Access Mappings? You find a link to that under "Operations" in Central Administration.
Another thing to check:
- Click on "application management" in CA, click on "Content databases" and then select the web app that does not return any results (up in the right corner, a yellow select box, select the web app) and click on the database name link, select "Index server" and select your WSS server.
Good luck!

Darren said...

I had checked they were all listed in AAM.

There is no "Index Server" field when I'm in managing the Content Database Settings. There are 4 sections.

1.Datatbase Information section and the only changeable field is to select "Ready" or "offline."

2.Database Capacity section which has 2 fields one for warning events and the other for maximum sites.

3.Search Server section where I have the WSS search server listed.

4.Remove Content Database section where there is a "Remove Content Database" Checkbox.

Lise said...

Hi Darren,
You seem to have the content database settings correct. More things to check:
- Have you looked into the Event Viewer on your server?
- Maybe it has to do with permissions?
- Check your application pools on your web apps so that they run under correct domain accounts.

Darren said...

The event viewer has numerous warnings. They are all the same. "The start address (web app) cannot be crawled."
"access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content."

I checked the app pools and they are all set to run under the same account.

I searched the event log error and found this: http://dotnet.org.za/zlatan/archive/2008/11/19/access-is-denied-check-that-the-default-content-access-account-has-access-to-this-content-or-add-a-crawl-rule-to-crawl-this-content.aspx
I'm thinking of giving it a try. Any thoughts?

Lise said...

Hi Darren!
Yes, like I said in my former comment, it sounds like a permission issue and the Event Viewer is quite helpful sometimes :)
Good luck, hope you are able to solve the issue!
Best regards
/Lise

Lise said...

An addition to my comment:

I have had this error message as you can read here, http://miss-sharepoint.blogspot.com/2009/02/search-and-basic-authentication.html. But that had to do with the crawler not being able to access the content sources since I had Basic Authentication turned on. Do you have Win Auth or Basic? And make sure you are able to access all your web apps URL-s from your server.
This error message could concern those issues and not permissions!

Darren said...

Hello Lise

I added that DWord Value to the registry and the search is working again. Thank you very much for all your help!

Darren

Lise said...

Thank you Darren!

Anonymous said...

Hi,
I am getting same error, what you mentioned in image “No results matching your search were found”. I followed your points. I set my URL to AAM (SharedServices22 > Search Settings > Content Sources > Edit Content Source.)

I selected my WSS server here also Application Management > Content Databases.

It throwing error Event IDs: 3759, 6398,11,8193

I stopped the service “Windows SharePoint Services Search” under Central Administration > Operations > Services on Server and again. When I click “start”, service is not starting. It showing error “WSS_Search_server1 on server1\OfficeServers contains user-defined schema. Databases must be empty before they can be used. Delete all of the tables, stored procedures and other objects or use a different database.”

What I do? Please help me

Thanks in advance, velmurugan

Lise said...

Hi!
That error that you get when you try to start the Windows Search Service means that you must RENAME the search database on that page, because it wants to create a new database for the WSS search. So just add like _new or something after the database name that it suggests (or whatever name you want, I try to be clear with all database names so that you can tell what they belong to on the SQL server). Then you will be able to start the WSS service again.
/Lise

Anonymous said...

Hi Lise,

Thanks for your response

I renamed my database (WSS_Search_server1 to WSS_Search_server1_new) and added under (Central Administration > Operations > Services on Server > Windows SharePoint Services Search) page in Search database area, after that I started service "Windows SharePoint Services Search”. The service is started.

But the Search is not working; I am getting below the Event ids: 6482, 7076, and 6398

Please help me

Thanks in advance,Velmurugan

Oliver Pergler said...

This did it.
http://yagyashree.wordpress.com/2009/06/05/wss-3-0-when-trying-to-search-on-sharepoint-site-getting-message-no-results-matching-your-search-were-found/

Looks like a MS bug caused by a security patch.

Alexei said...

Great, this worked! Thanks very much

Wai Thing said...

Hi Lise,

Recently, I set up a Sharepoint server farm (one physical machine). Everything is working fine except for the search function. No matter what keywords I use, there is no search result returned. I there any setting that I missed out during the setup? Please advice. Thank you!

Lise said...

Hi Wai Thing,

Wow there really are a lot of steps that needs to be veryfied in a search setup. You have to give me some more info before troubleshooting.
Check these first:

- AAM Default Zone must be matched to the URL in your Content Sources
- Check all services, are they started
- Check your accounts, do they have the correct access and password
- Schedule your search and perform a full crawl

Those are the first simple steps...

/Lise

Alejandro said...

Hi Lise!

I'm running MOSS 2007 with 2 web front end servers
The general search is working fine, however when I chose Search This Site or This List no results are returned.

By looking at my content sources it has
http://hostname/
sps3://hostname/
http://intranet.domain.name/

I'm not certain how to: "Match your default zone url in Alternate Access Mappings with the url used in the Content source"

I understand my default zone URL should be:
http://hostname/
and the Public URL (As used in my content source):
http://intranet.domain.name/

What I have right now under AAM is
--------------------------
Internal URL:
http://intranet.domain.name
Zone:
Default
Public URL for Zone:
http://hostname/
----------------------------
Internal URL:
http://hostname/
Zone:
Intranet
Public URL for Zone:
http://intranet.domain.name

Yet no results are returned, also i found this entry http://blog.jonathanroussel.com/2009/01/sharepoint-search-using-this-site-or.html
Which suggest switching to this setup


--------------------------
Internal URL:
http://hostname/
Zone:
Default
Public URL for Zone:
http://hostname/
----------------------------
Internal URL:
http://hostname/
Zone:
Intranet
Public URL for Zone:
http://intranet.domain.name

but i get this error when setting up the intranet zone
You must specify the default zone URL for all Web applications. To delete the Alternate URL Collection, remove the public URLs in all other zones, and then remove the default zone URL.

I'm not very experienced with the setup of these things.
any suggestions, comments? I will greatly appreciate it.

Lise said...

Hi Alejandro!
Sorry for late response, been busy!
Yeah I understand that error message, you cannot remove the Default Zone. There MUST be a default zone, and that zone must be accessed by the crawler. Try to surf on that URL on the server, if you get the 404 or any other error then you have the problem there. Make sure your IIS is updated with the same URL as you use for your Default Zone.
So steps:
1) Try to access your URL's defined in the Content Sources
2) If you cannot surf those, make sure you have the header on your IIS site
3) Match your Default zone in AAM to your Content Sources.

Let me know,
Take care
/Lise

Karl said...

I have 2 MOSS 2007 server farms one for production and one for test, the search has stopped working on both. I have tried just about everything from the loop back reg edit..... There are no errors, all service are running and can search content that has already been crawled. In your post you said that AAM need to match content sources.

AMM
server.domain.com

but my content sources search a specific area

server.domain.com/site/folder

do I need to add a AAM for that specific path?

Thanks

Lise said...

Hi Karl,
If you have specific URL's pointed out in your content sources then you must be sure that you are able to surf them from your SP servers as well. Match your AAM and check your headers on the IIS.
Let me know,
/Lise

Karl said...

Yes I can go to the URL's that are listed as content sources. The strange thing is the crawls still run and show that they are successful they just don't pick up any new data.

Lise said...

What are your url's pointing to in your content source? And why aren't the top site listed?
Are you performing a Full Crawl?
Have you checked Event Viewer or Crawl log for errors?
I think I have experienced this once actually. The last step is to reset the content index.

Karl said...

We only want certain content to be searchable.

Yes I have checked all logs and am coming up with nothing, thats what makes this so frustrating, if I could just find something to go on.

Lise said...

Hi Karl,
Just a longshot, but have you checked the search account for permissions and that the password is OK?
Did you perform a Reset of the index? And then do a Full crawl again?
Has there been any new updates installed on the server?

turtlehand said...

Thanks Lise, that did the trick.

Roger Keast said...

Thanks for the help! I'm runnnig Moss2007, and after reading your post I found that my alternate access sites were not correct.

Our site is accessed internally via https://home
Default site was set to https://home.domain.org
Intranet site was set to https://home

I changed https://home.domain.org to the Internet site, and made https://home the Default site, leaving Intranet blank.

Saved and went directly to my site. Search for Folder and Site both worked perfectly now.

Thank you!

Lise said...

Great to hear! =)

Anonymous said...

Hi Lise,

I am facing issue with MOSS 2007,No search results come up for a particular document library, even though i have farm level access.
This happens at top level as well as for the particular site. The search functionality though is owkring fine everywhere else. Is it possible that since the folders in the documents libaray contains only PDF files it does not come up with anything. Any help would be really appreciated. THanks.

Lise said...

Hi Anonymous!
Have you installed iFilter for pdf?
If not, do it right away and run a full crawl after that. Then I am sure you will receive some search results!
Go to adobe.com and download iFilter for your correct server OS and SharePoint version.
Thanks for posting!
/Lise

Sony said...

Hi Lise,

I'm having this same issue with no results, but only for one single subsite when a user selects "This site". They can use search "This site" in every other subsite.

If the user select "All Sites" they get results. If I remove the u="https://...." from the URL they get results.

All of the points you mentioned are all confirmed:

- AAM Default Zone must match to the URL in your Content Sources
- All services are they started
- Accounts have the correct access and password
- A full crawl has been done.

Any suggestions on why this is happening?

Sonia

Lise said...

Hi Sonia!
Sorry for late reply!
Did you say that it only occured on ONE single subsite? You get search results on all other subsites, both on "This site" and "All sites"?
/Lise

Phil said...

I'm having similar issue like Sonia. If I go into most top level sites the "This Site" search works. However there are a few sites in which the "This Site" search returns nothing. One user said it used to work... The ONLY difference I can find is that the offending sites all belong to the same content database. This is MOSS 2007. Help please!

Phil said...

Turned out our search issue was being caused by an orphaned site that belonged to the same database. Once the orpaned site was removed (and after a full crawl) "This Site" search works for all sites.

Lise said...

Hi Phil,
Thanks for sharing!
Take care,
Lise

Jim said...

Hi Lise,

Thank you for this valuable information. This helped me fix a problem. My solution was different and could help someone else:

Ensure that the web application that houses your site is associated with the correct SSP, (the some one that houses your SSP and MySites applications/sites.)

I created a new application for our partner sites in MOSS 2007, which was assigned by default to the first application's Shared Service Provider (SSP) in Central Admin. Then I created the new Shared Service Provider (SSP) with two new applications for the SSP Admin Site and MySites feature.

I forgot to associate the new Partner Web application with the new SSP after I created it... The search worked great in the old intranet application but not in the new partner application... Sounds obvious but a logical error considering my environment and the order of operations.

Hope this helps someone else.

Jim

Sony said...

Hi Lise,

Sorry about my late response; I was out and didn’t have internet access.

Yes this is only happening on one subsite and all other sites results come up with "This site" and "All sites".

Seems I do have an orphaned site like Phil. I ran the databaserepair command in stsadm and it came up with . I know how to remove a content db in Central Admin - not to sure the best way to add it back.

My database is extremely large (120GB) so I'm not sure what I should do. We are by the way working on separating our sites into their own site collections with separate databases preparing for out 2010 upgrade.

Any help would be greatly appreciated.

Thank you,
Sonia

Mister said...

Hi!

I need urgent help because of "search - no results" issue.

We are running WSS 3.0.

I think that we configured everything properly, as event log doesn't show any errors, but still search doesn't return any results.

The only error we have is in sharepoint log and it says "FetchDataFromURL start at(outside if): 1 param: start".

Please help help help! :-)

Lise said...

Thanks Jim and Sonia for sharing your solutions!
Mister, have you solved this? There are so many places to troubleshoot at so please provide some more information if you can.
Check this
- AAM, does it match your content sources url's?
- permissions, what account runs the search service?
- restart the search service and perform a full crawl
- I have not seen your error before, sorry.
Hope you fix it!

Anonymous said...

We have two site collections in Production (using MOSS 2007):

http://server.domain.com/sites/

http://server.domain.com/pwa/

I looked for permissions:

Application Management-->Policy for Web application

For Admin, it has "Full Read, Full Control" permissions.

I checked the AAM and Content Source URL also.

I found something interesting in the crawl log. I see that it is able to crawl some particular subsites under /pwa/ say

/pwa/site091

/pwa/site098

/pwa/site100

But it cannot crawl the subsites /pwa/site097 , /pwa/site099 , ...

Also some errors like:

" There is no Web named "/pwa/site074/meeting/Forms/AllItems.aspx". "

But when I open the URL, the site exists.

Lise said...

Hi Anonymous!
When you say that the crawler could not find the "/pwa/site074/meeting/Forms/AllItems.aspx", is that really a URL in your content source? It should only be
"yourserver/pwa/" if that is a DNS record and in your AAM.
Maybe you need to add some more information. Or maybe you have the same issue as Phil posted here on this blog article:
"Turned out our search issue was being caused by an orphaned site that belonged to the same database. Once the orpaned site was removed (and after a full crawl) "This Site" search works for all sites." By Phil.
Take care,
/Lise

michel said...

Resources like the one you mentioned here will be very useful to me! I will post a link to this page on my blog. I am sure my visitors will find that very useful.

Lise said...

Thanks Michel! Take care,
/Lise

Anonymous said...

Thanks for that valuable piece of information. I had entered https://sitename for my Public URL in the Default zone, but specified the search app to crawl http://sitename. After changing it in AAM (to http://sitename) it worked great and I didn’t even have to do a full crawl. Thanks again!

Miles

cloud hosting india said...

Thanks for taking the time to discuss this, I feel strongly about it and love learning more on this topic. If possible, as you gain knowledge, would you mind updating your blog with extra information? It is extremely helpful for me.

Dave Stuart said...

Wow, that's all it took! I have been having the same issues with Search Server Express 2010 and SharePoint Foundation! Thanks for taking the time to blog this over 2 years ago! Very helpful indeed :-)

Dave