locked
WSS 3.0 Search not returning any results RRS feed

  • Question

  • Greetings,

    I have a WSS 3.0 site that is not returning any search results.  I have checked and double-checked the settings but am not getting anywhere.  Can someone please tell me what I am missing??

    The service is running (checked in Admin Tools > Services and in WSS Central Admin).
    Search is working in that I get a "No Results" message not a Search is not enabled-type message.
    I have tried other fixes to no avail.
    My Service Accounts and Content Access accounts are domain accounts (non-admin).
    They have reader access to the content database and owner access to the search database.
    I have stopped and restarted Search Service to create a new Search database (that completes successfully)
    I am using Windows Authentication, not Basic or Forms
    The Search service has "Full Reader" access in the Web Application Policy
    The Search Server for my Content Database is correctly set.
    The lists and other elements are set to allow their contents to show in searches.
    I have indexed my primary search fields.
    My Search database has data in it.

    They only error that I am receiving is the 2424 error in the Windows Application Log - the only fix I can find for that is to have a domain user account for the service and I already had that.
    My Sharepoint logs are not showing any errors and yet...

    No searches return results, for any scope.
    I also don't have an All Sites scope, but I am not sure if this is normal or abnormal as I am using WSS 3.0 with the vanilla search.

    Any help would be most appreciated!!!

    Thursday, July 9, 2009 11:23 PM

Answers

  • Using no host header I created a new web app and site collection and search works fine for this collection. 
    I then created a new web app and site collection with a host header and search works fine for this collection as well.

    So, I don't know if the loopback bug fix only works on the new web apps but not the existing ones, but I doubt it.

    I have no problem with the idea that it is a permissions issue, but several times I have reviewed all of the permissions I am aware of (and I have used the document you linked to) and they are as specified in the documentation.  So, if it is a permissions issue, it is buried.

    I have run out of time to work on this further so we have decided to blow away the current collection and start fresh.

    Thank you for all of your help!
    • Marked as answer by are4664 Monday, July 20, 2009 4:06 PM
    • Unmarked as answer by are4664 Monday, July 20, 2009 4:07 PM
    • Marked as answer by are4664 Friday, September 11, 2009 5:50 PM
    Monday, July 20, 2009 4:05 PM

All replies

  • What kind of documents are you searching on? Are you searching for a particular word?
    certdev.com
    Friday, July 10, 2009 2:22 AM
  • Could you please clarify whether the error 2424 was fixed?

    The error 2424 was related with Windows SharePoint Services 3 Search, if the error was still existed, we need to resolve the issue to let the search work.

     

    If not, please make sure

    1.    In SQL Server Management Studio > Security > Logins >[Search Service Account]

    2.    Right click Properties>Server Roles tab.

    3.    Check following options:

    1)    Server Roles: ”dbcreator” and security admin”

    2)    User Mappings Tab, “dbowner” of SharePoint search databases

     

    After double confirm the settings, please manually start a full crawl by using the command:

    Ran stsadm -o spsearch -action fullcrawl start

    See Spsearch: Stsadm operation (Windows SharePoint Services) (http://technet.microsoft.com/en-us/library/cc288507.aspx) for more information.

     

    If no result returned after some time, please let me know more information for further research:

    1.    please follow the steps to gather the SPSReport logs:

    1)    Download the SPSReport tool from http://spsreport.codeplex.com/

    2)    Run the SPSReport.exe.

    3)    Choose option 3 (Full).

    4)    On your system a CAB file will be generated in the %systemroot%\SPSReports\Portal\rpt\Cab directory called %COMPUTERNAME%_SPSReports.CAB.

    5)    The CAB file will contain the reports generated by the SPS Reporting Tool.

    6)    Send the cab file to the workspace.

    Notice:

    The reporting tool DOES NOT make any registry changes or modifications to the operating system.
    Average completion times for the SPS Reporting Tool are in the range of 5 to 15 minutes.
    It is required that the currently logged on user have Administrative rights in order to allow for proper operations of the SPS Reporting Tool.

    2.    Backup Windows SharePoint Search database in SQL Server Management Studio and upload to the workspace.

     

    Workspace URL: (https://sftus.one.microsoft.com/ChooseTransfer.aspx?key=a4754242-50c5-4f81-9029-7e2cd51db010)

    Workspace Password: V0g$dp#kaylZ*7

     

    Let me know the result if possible.

    -lambert


    Sincerely,
    Lambert Qin | Microsoft TechNet Managed Forum Support
    Posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, July 10, 2009 2:48 AM
  • FYI, I am running a 64 bit version of Windows Server 2008 SP2. 

    I added the Server roles to the search accounts in SQLServer (the technet article for 2424 mentions the dbowner user mapping but not the server roles if I remember correctly.)  Still, that did not resolve the issue.

    I tried to run the stsadm command but receive an Access Denied error message.  I am running as a Domain Admin though.  I may have an error message in the event logs about not being able to create a database connection so I tried using the account credentials but that did not work.

    I then downloaded the SPSReports tool.  It seems to hang at gathering file version information from the SharePoint bin folder and does nto create a cab file.  It throws an error on the line just before the hang at gathering office server registry information.  I assumed this would be okay though as I don't have MOSS installed, just WSS. I have uploaded what files it did create to the workspace listed above. 

    2 files would not upload because they were 0 bytes; hotfixtimeline and officeserverreg

    BTW, as a workaround to not being able to run the stscmd, I stopped and started the Search Service through Central Admin.  My understanding is that it would create a new database and perform a full crawl.  The database is growing and has CrawlHistory in it but search is still not returning any results.

    Finally, Should I have an All Sites scope for search with WSS?  I don't.

    Thank you for your help!!
    Wednesday, July 15, 2009 11:24 PM
  • Hi,

     

    Thanks for your cooperation.

     

    I restored the search database, and found the search service was working normally.

     

    The Central Administration site located in Port 10000 was successfully crawled.

    You could check MSSCrawlHostList for more information.

     

    You could see there is an error logged in the MSSCrawlHostList table and I check the error using the following SQL Command:

     

    Select msscrawlurllog.lasttouchstart as Time, msscrawlurllog.displayurl as URL, msscrawlurllog.errorid as Error, msscrawlerrorlist.errormsg as Description
    From msscrawlurllog Join msscrawlerrorlist On msscrawlurllog.errorid = msscrawlerrorlist.errorid
    Order by msscrawlurllog.lasttouchstart

     

    I found that the root cause is “Access Denied”.

     

    Please check the Content Access account permissions in Windows SharePoint Services Search Service.

    Here are the requirement of the Content Access account for your reference:

    • Must be a domain user account.
    • Must not be a member of the Farm Administrators group.
    • Access to read from the configuration database and the SharePoint_Admin Content database.
    • Membership in the db_owner role for the Windows SharePoint Services Search database.
    • Added to the Web application Full Read policy for the farm

     

    See Plan for administrative and service accounts (Windows SharePoint Services) (http://technet.microsoft.com/en-us/library/cc288210.aspx) for more information.

     

    I also noticed you used Host Header in the web application, if you are sure the permission was correct, please try to using Method 2 of the KB896861 (http://support.microsoft.com/kb/896861) in case this is a Loopback issue.

     

    Furthermore, you need to have local administrator and farm administrator permission to run the stsadm command and SPSReport tool.

    Although you mentioned  are a Domain Admin, I suggest you to check the permissions with your AD administrator for troubleshooting the permission issue.

     

    Hope the information can be helpful.

    -lambert


    Sincerely,
    Lambert Qin | Microsoft TechNet Managed Forum Support
    Posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, July 16, 2009 7:14 AM
  • Thank you for the suggestions.  I checked all the settings and they are as listed above.  I have made the change to the registry for the loopback issue and am waiting to reboot the server to check that.

    For the permissions thing, I am a Domain Admin, this account is part of the local admin account on the machine and it is part of the farm admin group for SharePoint.  This account is also part of the WSS_ADMIN_WPG group on the local machine.  Is there someplace else I should look for permissions?  As far as I can tell I have all the permissions that are needed. 
    Is it possible to find out exactly what resource is denying access?

    Finally, I am not seeing an All Sites scope for search options.  I have This List, This Library and This Site.  Is that because I am using the standard search with WSS or is there something I am missing to get the All Sites search?
    Thursday, July 16, 2009 9:04 PM
  • Alas, the loopback did not correct the issue.  I am still not returning search results.  Any other ideas?  Any help would be appreciated.  Does this have anything to do with running on Windows Server 2008 SP2, 64bit?
    Does it have anything to do with User Access Control options in Local Security Policies?

    After trying a few trial searches I found this error in the urllog table... A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.)
     
    One last question, is this issue likely to go away if I install Search Server Express?
    • Edited by are4664 Thursday, July 16, 2009 10:50 PM
    Thursday, July 16, 2009 9:54 PM
  • Hi,

     

    The search feature in WSS 3.0 only allow you to search the content within the site collection, so you could not get the All Sites Scope.

     

    The issue is not related with your Operation System in my option and Local Security Policies in my option.

     

     

    The “Access Denied” Permission was caused by the Content Access account in Central Administration > Operations > Services on Server > Windows SharePoint Services Search Service Settings.

    Here are the required permissions Content Access account for your reference:

    • Must be a domain user account.
    • Must not be a member of the Farm Administrators group.
    • Access to read from the configuration database and the SharePoint_Admin Content database.
    • Membership in the db_owner role for the Windows SharePoint Services Search database.
    • Added to the Web application Full Read policy for the farm

    See Plan for administrative and service accounts (Windows SharePoint Services) (http://technet.microsoft.com/en-us/library/cc288210.aspx) for more information.

     

    After checked the permissions, could you please try to create a site collection in a new web application and verify whether the issue is in the new site?

    Please notice that do not assign host header to the new web application.

     

    If possible, could you please capture another SPSReport log and upload the latest search database.

    Or you could check the database and let me know the result based on my previous reply.

     

    For the “transport-level error”, it could be caused by SQL Server was under heavy load, I think we could pending the error temporarily until occurred more frequent.

     

    Search Server Express provide more search feature than WSS 3.0 does. It may not resolve your issue, but it provide more powerful way to manage and monitor the search status.

    If you customize search scope and index resource outside the SharePoint sites, I suggest you to investigate the product.

     

    Hope the information can be helpful.

    -lambert


    Sincerely,
    Lambert Qin | Microsoft TechNet Managed Forum Support
    Posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, July 17, 2009 3:12 AM
  • Using no host header I created a new web app and site collection and search works fine for this collection. 
    I then created a new web app and site collection with a host header and search works fine for this collection as well.

    So, I don't know if the loopback bug fix only works on the new web apps but not the existing ones, but I doubt it.

    I have no problem with the idea that it is a permissions issue, but several times I have reviewed all of the permissions I am aware of (and I have used the document you linked to) and they are as specified in the documentation.  So, if it is a permissions issue, it is buried.

    I have run out of time to work on this further so we have decided to blow away the current collection and start fresh.

    Thank you for all of your help!
    • Marked as answer by are4664 Monday, July 20, 2009 4:06 PM
    • Unmarked as answer by are4664 Monday, July 20, 2009 4:07 PM
    • Marked as answer by are4664 Friday, September 11, 2009 5:50 PM
    Monday, July 20, 2009 4:05 PM