MOSS 2007 - This Site and This List Scopes Not Working RRS feed

  • Question


    I am using the production version of MOSS 2007 Enterprise.  Selecting the search scope "This Site" or "This List" and specifying information that demonstrably exists in either of these scopes does not appear in the search results.  Indeed, searches in these scopes always return nothing.


    "All Sites" searches appear to work nicely.


    Any thoughts on how to correct this problem?





    Thursday, August 9, 2007 10:17 PM


  • Sorry this is not my area of expertise so I didnt have a solution or handle on what the problem can be. The one thing that I found is did you guys change the Url of the Default zone for the site? If yes did you do a recrawl after that.


    I will try recrawling in both ValdBath's scenario and SharePoint_d scenario and see if this works for you.


    Typicaly you dont require a recrawl if you are not changing the default zone url while doing the access mapping.



    Monday, August 27, 2007 10:44 PM

All replies

  • I'm having the same issue with the same software.  Results within a subsite return perfectly when searching through the "All Sites" scope, but the "This Site" or "This List" scope return nothing.

    It seems like these should both be searching the same crawler data, so this is sort of baffling.
    Wednesday, August 15, 2007 5:52 PM
  • When you search for a keyword in This Site scope you are taken to osssearchresults.aspx. Look at the query string parameter u. "u" parameter has a url value. Is that a valid url value. Can you go to that url(after appropriately decoding it).


    Most common problem that I have seen is that the alternate access mapping isnt correctly  configured.


    If you determine you do not need alternate access mapping or it is correctly configured then

    Another thing to test is since your All Sites scope is working you can issue the same query against that scope with additional site:http://yoursiteurl


    Does this get you results. If not then you should make sure you are actually crawling this site and the content that you are looking for is actuall crawled.


    Hope this helps in figuring out your problem

    Friday, August 17, 2007 5:39 PM

    I believe the alternate access mapping I have set up is working correctly.  The URL translation appears to work in all other cases.  Perhaps you could point me to a definitive source of information on this or describe in what way mappings have been set up incorrectly so that I can confirm the configuration is correct.


    The site: refinement does not appear to work in the All Sites scope.  It returns nothing.


    I have executed the same query against the All Sites scope without the site: refinement and received the references I would expect to get from the site in question, indicating that the site is being crawled and indexed.  This would imply a problem with extraction, not the crawling engine.

    Friday, August 17, 2007 6:00 PM
  • If you do the site: refinement on All Sites scope with correctly access mapped url does that work?


    In the mean time I will try and find how to setup access mapping correctly



    Friday, August 17, 2007 6:29 PM

    To the best of my knowledge, my access mappings are correct.  Here are the tests I have tried:


    From a client, accessing MOSS using a mapped URL

    All Sites - finds data

    All Sites with sites: discriminator (with mapped URL) - no results

    All Sites with sites: discriminator (with server name URL) - no results

    This Site - no results


    From the server, accessing MOSS using the raw URL

    All Sites - finds data

    All Sites with sites: discriminator (with server name URL) - no results

    This Site - no results


    I should note that any search with This Site scope uses a different search result page than the All Sites search.  Since both return no results I am not sure if this is significant.

    Friday, August 17, 2007 7:01 PM
  • I'm experiencing essentially the same problem.

    I can get the default scope with no 'u=" parameter to work properly, but the site: refinement, as you put it, does make the search not work.

    In my case however, using the correct internal URL does work. i.e. a search that specified u=(URLEncoded internal URL) does return results.


    The added wrinkle in my case is the external URL is an extended application not just an alternate access mapping. i.e. I had to extend another application pointing to the same content database but with a different port number (port 80) for external users versus internal users, and when the URL to the external app is used, and my search string includes the u=(URLEncoded external URL) parameter, I get no results. As far as I can tell everything looks fine in terms of the alternate access mappings, but essentially searches don't work when the site is accessed from the external URL.


    Any suggestions?

    Monday, August 27, 2007 2:59 PM
  • Sorry this is not my area of expertise so I didnt have a solution or handle on what the problem can be. The one thing that I found is did you guys change the Url of the Default zone for the site? If yes did you do a recrawl after that.


    I will try recrawling in both ValdBath's scenario and SharePoint_d scenario and see if this works for you.


    Typicaly you dont require a recrawl if you are not changing the default zone url while doing the access mapping.



    Monday, August 27, 2007 10:44 PM
  • My default URL is set to the server name running MOSS 2007.  I have run multiple full recrawls since installation with no luck.

    Monday, August 27, 2007 10:50 PM
  • This post gave me an idea, I checked the index server, and sure enough, it couldn't access the default zone of the site. I changed the default zone URL to something that the index server could access, recrawled, and a few hours later all the content was searchable!
    Wednesday, August 29, 2007 1:17 AM

    I am glad this worked for you.  Unfortunately, I do not have such luck.


    My logs show that the default URL is fully accessible to the crawler (it is the raw server URL).  I have verified my DNS settings are set up properly and I have tried searching using all the alternate mappings.  All Sites returns results properly, This Site and This List do not.

    Wednesday, August 29, 2007 1:55 PM

    We are having the same problem, however it is only happening in production NOT staging.  Our production servers are load balanced (except the indexing server) but our staging servers are not.


    The other odd thing is that one of our front end servers (not both) receives this publishing error when the This Site or This List fails:


    Source: Office Sharepoint Server

    Category: Publishing

    Event ID: 5165


    Console Configuration File Error: File Not Found: The system cannot find the file specified. (Exception HRESULT: 0x80070002)



    Thursday, August 30, 2007 10:19 PM

    Our production system is a small farm: one web server and one database server.  No load balancing, no index server.  We do not receive the error you report.  The query simply returns no results.
    Thursday, August 30, 2007 10:31 PM
  • VladBath:

    Perhaps the issue is that your search service account cannot access content on the site collection / application that is returning no results.

    When you look at the crawl logs from the SSP's search settings / Crawl log link, do you see the appropriate number of items successfully crawled next to the URL for the problematic site coll / app? How many errors? If you look at the errors for the site collection, what do they say?

    Friday, August 31, 2007 3:40 PM
  • Thank you for responding.


    The problem isn't that the information is missing, just not available in certain scopes, namely, the built-in "This Site' and "This List" scopes.  When I search for the information using "All Scopes", the information is discovered.


    The crawl logs show that all items are located.  There are no errors.


    Friday, August 31, 2007 4:07 PM
  • Hi,


    Same problem here; All Sites and custom scopes that we've defined ourselves work correctly but not the Contextual Scope (This Site, This List).


    In order for these scopes (This Site, This List) to be working, would it make sense to link the Content Database of the Web Application to a Windows Search Service? I see this option in Central Admin - Application Management - Web Application - Content Database? If it's the case, what's the impact on the MOSS Search (Office Search service)?


    We having this problem in multiple configuration of MOSS (single server, small farm, etc.).


    Thanks and regards,


    Thursday, October 4, 2007 12:34 AM
  • Sadly no that shouldn't matter.  All websites need a content database (even Central Administration)


    We actually filed a support ticket with Microsoft and they have been no help at all.  It's VERY frustrating.  We actually compared the Google appliance to the Sharepoint search engine and and a major reason Sharepoint won was the contextual scope search was better.   With it non-functional I now have egg on my face for not selecting Google.


    Thursday, October 4, 2007 4:53 AM
  • This is extremely disheartening.  I attended a sales seminar by Mondosoft, who are the purveyors of Ontolica search.  During the course of the seminar I had an opportunity to test  the This Site and This List scopes using SharePoint's built-in feature set.  They appeared to work.  This leads me to believe that there is something amiss in my basic configuration, but I cannot be sure.  Maybe I will put in a trouble ticket with Microsoft as well and see if I get any farther.  I just hate wasting money to debug someone else's product.


    Take care,




    Thursday, October 4, 2007 7:55 PM
  • Has anyone found a resolution to this yet? I too am experiencing the same issues (contextual scopes do not work when All Sites and custom built scopes work fine).


    Monday, October 29, 2007 10:41 PM

    I have not found any resolution, sorry.  It would seem quite a few people are experiencing this problem.  Perhaps someone from Microsoft could take a look?  I am happy to help them investigate if they like.



    Monday, October 29, 2007 11:07 PM
  • I just looked at the article.  I do not think it is relevant to my situation as I am using only one site collection.  There would be no logic in pointing to myself.


    Thank you for the pointer though.




    Thursday, November 8, 2007 4:36 PM
  • Our company did report this issue to Microsoft and I instructed them to read this thread.


    They are stumped.  We finally tried one last thing.  I created a second shared service provider, setup another indexing service, then another 'My Site' and portal web application side-by-side on the same production hardware.  Lo and behold the problem disappeared.


    So it appears that my default SSP is corrupt.  So, Microsoft has now recommended that I duplicate all of my BDC, search et cetera settings from the default SSP on the new one I created, then reassociate (move) my portals from the default to the new one, then make the new one the default.  SIGH


    I know it will work but it is going to be a royal pain in the butt.  It will take on of our team roughly 2 days to duplicate all of the customization.

    Thursday, November 8, 2007 8:09 PM
  • Thank you for the information.  I am very sorry to hear of the effort required.  Unfortunately I have no further information on the issue from any other source.


    Take care,




    Thursday, November 8, 2007 8:42 PM
  • I had seen this problem before and was able to fix it, not sure if it would help in your case but you can give it a try.


    If your default url and the url used in the content source are different, then you'd run into this issue.


    For eg: if your default URL is http://servername and you have an addtional URL for the same web app in the alternate access mappings, say http://sharepoint and if you use http://sharepoint in your content source, the crawl works fine without any errors but it shows the behavior you are seeing now.


    In my case, my customer was using http://servername as default url and http://something.com as internet URL, which was actually another site extended and mapped to the original one. They decided to use internet url in the content source and that started the problem, because it was not the default url.


    If this is really how you have configured your environment then make sure the default url that you see in alternate access mappings is being used in content source.


    You can even try adding the servername mappings in the SSP search condifuration, that helps too





    Wednesday, November 14, 2007 8:24 PM



    Thank you for your suggestion.  Unfortunately, my default URL in my AAM is the same as the craw URL in my content source.  My problem lies elsewhere.


    Take care,



    Wednesday, November 14, 2007 8:47 PM
  • I have an ugly work-around.  It doesn't actually solve the problem, but it avoids it.


    When I search using This Site and This List, the search page is:




    In other words, the OSSSearchResults.aspx page.  Based on the name I presume this runs a query against the MOSS search mechanism.


    It returns no results.


    On the other hand, if I use the WSS search page, the search works:




    Use the SearchResults.aspx page and all is well.


    I would still like to see this fixed in the MOSS Search mechanism but I can at least create a tool to call a viable search page now.

    Wednesday, December 5, 2007 12:42 AM
  • This issue has stumped me for 2 months. I have created new SSPs, re-indexed, etc. Crawls are working perfectly but the osssearchresults.aspx was coming up with nothing for contextual searches (This Site: & This ListSmile. After getting no results, I replaced osssearchresults.aspx with searchresults.aspx in the url and the query worked fine as VladBath stated above.

    My only solution was to rename osssearchresults.aspx to osssearchresults.aspx.old (backup) and copy searchresults.aspx as osssearchresults.aspx. These files are located in the layouts directory. My searches are now working fine.

    MS needs to resolve this issue or at least acknowledge it!!!!

    Monday, December 31, 2007 7:19 PM
  • Edros,


    I am glad my investigation was helpful to you.  At least there is a work-around.


    Take care,




    Monday, December 31, 2007 8:08 PM
  • I have spent some quality time with this issue today also.  Two different clients had the problem today (4 in total over the last 3 months).  The 2 previous clients we created a new SSP and all was fixed.  Easy solution if you aren't in production yet.  The 2 today were not thrilled about creating a new SSP.


    Long story short this problem is an Alternate Access Mapping problem (AAM) vs. content source problem.  Once I setup the default URL and the content source to be the EXACT same url and did a full crawl all was fixed.  In both cases their default URL was http://sharepoint.company.com and their content source was http://sharepoint


    Shane - SharePoint Consulting

    • Proposed as answer by AveryD Thursday, August 7, 2008 3:58 PM
    Friday, February 8, 2008 6:00 PM
  • It would appear there are at least two variants of this issue.  The one you described is addressed using an AAM and crawl solution.


    I have verified several times that my default AAM mapping and crawl sources are exactly identical and run full crawls on several occasions.  This does not fix my variant of the issue.  The only satisfactory solution I have had to date is coping the search page called for This Site and This List from the WSS search page, essentially substituting MOSS search with WSS search for these scopes.


    Take care,



    Friday, February 8, 2008 6:56 PM
  • Hi Vladbathc,

    I had a similar issue and found the solution, so I want share with you. Since I found the solution in Alternate Access Mapping (AAM) area, this information might be in that perspective.


    Situation:  1 MOSS server and 1 SQL server

    • Actual Web Application name and url: Intranet 1234, http://intranet:1234
    • I extended it with http://intranet   (port 80), and make it default zone.  So in Web Application list, it shows (changed) as below
      Intranet 1234, http://intranet
    • From this point, Seach does not work for "This Site" and "This List"
    • Solution: make http://intranet:1234 back to "Default" zone. then it works now.
    • (not really necessary) you may also re-crawl with the default zone url.

    Wish you good luck.



    Thursday, February 21, 2008 5:33 PM
  • Byungchul,


    Thank you for your insight.  Unfortunately this does not map to my situation.  I created the application on port 80 initially and at no time was it on any other port.  It has always been mapped to my default zone.  But you did give me another idea, which I will try.  I will let you know how it turns out.






    Thursday, February 21, 2008 5:40 PM
  • Hi Vlad


    Our team has been suffering with this since last July.  I've posted on this thread previously.  We submitted a support ticket and have been working on this with Microsoft since then.  In fact, in early January 2008 Microsoft Support finally replicated the issue with a copy of our SSP database.  They have been unable to find the root cause, however there is good news, one of our team has found a workaround we are in the process of testing.


    If involves restored the SSP using a non-intuitive workflow.  We've fixed the issue on our staging and implemented on production this week.  Once we have 100% confirmed it's working I'll send the steps to fix it.



    Thursday, February 21, 2008 5:47 PM
  • Did you find a work around for this?  I am having the same issue.  The funny thing is it only happens in our distributed environment.    All of our stand alone environments This Site is working fine.

    Wednesday, February 27, 2008 3:51 PM
  • Emily,


    I posted a work-around on 4 December 2007 in this thread.  It involves copying and renaming the search results page to a version that works.


    I have not found a proper solution but at least the work-around does the job.


    Take care,




    Wednesday, February 27, 2008 3:58 PM

    there is a simpler fix, go to the site settings of the site that the list searchs are not working on.  Then Site Features. Enable

    Office SharePoint Server Standard Site features.


    Try your search and it should work.

    Friday, March 28, 2008 2:13 AM
  •  Kevin41 wrote:


    there is a simpler fix, go to the site settings of the site that the list searchs are not working on.  Then Site Features. Enable

    Office SharePoint Server Standard Site features.


    Try your search and it should work.


    OMG.  I had Microsoft on the phone to solve this, didn't you think we had already been through all this?

    Friday, March 28, 2008 6:01 PM
  • Ted and Vlad:

    Have you tried snapshotting this environment to a VM environment, and then deleting the SSP and re-creating it? I have run into this issue a few times - actually its a few different issues with the same symptoms.

    As Vlad mentions I have also found that using the alternate search page sometimes fixes it (really it's a hack / workaround, not a true fix), sometimes its an AAM only issue (easiest to fix). Other times it appears to be an SSP corruption issue. In the latter case, even though it was a lot of work, I recreated the SSP. Hopefully you separated out your My Sites and can just restore that, but clearly SSP re-creation can be a lot of work, but it sometimes fixes this problem.
    Sunday, April 20, 2008 8:48 PM
  • SharePoint_d,


    No, I have not tried to rebuild the SSP.  The work-around works adequately for our purposes, though it would be nice if a future release did prevent it from happening at all.






    Sunday, April 20, 2008 8:54 PM
  • I worked with Microsoft Support for six months to solve this.  Yes we've tried everything suggested here including this idea over a year ago.  Their hasn't been a single idea in this thread that we hadn't tried.


    The final fix was to backup the SSP and restore it twice!  That is correct.  The first time we restored it we made the 'My Site' web application and the 'SSP Administration' web application the same one.  We then deleted the SSP (without deleting the databases) and restored it a second time only on the second pass we reassigned the SSP Administration and connected 'My Sites' to our previous 'My Sites' web application.  That fixed it.


    We haven't seen the error for 3 months now since we did.  By the way, Microsoft supported repeated our error inhouse and repeated our fix inhouse so they have endorsed it without knowing the root cause.

    Monday, April 21, 2008 4:00 PM
  • Hey Sharat,


             Your suggestion worked like a charm. I had the same problem, global search worked fine but not "This site" and "This List" search. I have changed my default alternate access mapping and used the same URL that I have used in Content Source and my search started working.


              Thanks once again Sharat.



    Thursday, May 1, 2008 9:53 PM

    I was having the same issue. I went through a lot of threads and these are the things that solved it for me:


    Made sure all my Alternate Address mappings (Http;//hostname.domain.com and https://hostname.domain.com) were listed including http://servername (the netbios name). Then in the content databases I made sure the default search server was selected.  Application Management -->Content Databases


    Then I reset all searched content, restarted the Office Sharepoing Search service, and ran a full crawl. That fixed it. Not sure which combination made it all work but it did.

    Thursday, May 8, 2008 8:09 PM
  • I had the same problem with the OSSSearchResults.aspx page not showing data. I went through all of the workarounds on this post but had no luck. I found this blog entry and it fixed the issue the first time:



    Hope this helps someone like it did my group.

    Friday, May 16, 2008 2:48 PM
  • This post above might help some people - I think a lot of the situations in which search doesn't work is when there are extended apps with internal and external zones, and the search indexer can't crawl the indicated zone because of the security settings / authentication issues.
    Friday, May 16, 2008 4:26 PM

    Thank you for this post.  This is exactly what my problem was and by switching the default and the internet alternate access mappings the This Site search starting working immediatly.  Thanks again.


    Wednesday, June 11, 2008 6:08 PM
  • Exactly the same here.


    Being new to MOSS, we initially created our web apps using the http://server: port convention, didn't use host headers, and started with port 6000. E.g. Central admin is moss:6000, ssp1 is moss:6001, my sites is moss:6002, and teams is moss:6003. Well, we quickly realized that we wanted friendly urls for my sites and the teams site collection.
    So, after extending our moss:6002 (my sites) and moss:6003 (teams) web applications and creating the "friendly" urls/host headers on port 80 to accomplish this, I didn't like that search results were still coming back using the http://server: port url and not the friendly url in our custom search with tabs page. So, I added the friendly urls in the search content source setup, removed the old server: port urls, recrawled, and all was well...at least when using my custom search page. I didn't think to go back and check if the built-in This Site searching was still working.
    From reading this thread, it sounded like the content source urls for SharePoint site crawling needed to match the url in the default zone in the Alternative Access Mappings settings. On our moss server, however, the default AAM was still http://server: port and the Intranet zone url was the friendly (i.e. http://teams). This morning I switched them, so the friendly urls are all now the default zone urls.
    Searching using This Site, This List, etc., now returns expected results, and the custom search page (All Sites, People, etc) works as well.
    Wednesday, June 18, 2008 1:56 PM
  • Hi Vlad,


      Our SharePoint portal also having the same problem, and I try to look for the solution to fix it, this is why I reach this TechNet thread. I have try all the solutions that posted in this thread but the problem still not solve.

      I even add a new server to the SharePoint farm and run the Office SharePoint Server Search (index and query) on the new server and change the indexer of the current SSP to the newly setup index server, after the full crawl, the result is still same.

      Finally, I change the AAM of Default zone of our portal site back to the original (http://servername/), because it was changed to a more friendly URL (http://sitename.domain.name), and I add a new mapping under "intranet" zone for the friendly URL and also add one more "Custom" zone with (http://servername.domain.name) for this site .

      After that, I edit the SSP search setting (Shared Services Administration: SharedServices1 > Search Settings > Content Sources > Edit Content Source) to add all the sites name to the "Start Addresses"


    http://servername:29845/   (this is my SSP Administration Site)
    sps3://servername/     (This is where Mysite hosted)


    make sure you have "Reset all crawled content" before you run the Full Crawl of the "Local Office SharePoint Server sites" to avoid all the errors and warnings in the crawl log, because the "Start Addresses" has been changed.

    After I did the above mention activities, I found that the search of the This Site and This List Scopes are start working again.

    Seem like OSSSearchResult.aspx only working properly, if all the AAM zones and sites within that SSP had been added to the "Start Addresses" and being crawled by the search server.


    PS: I have tried to access our portal site with the friendly URL, servername, and servername.domain.name and perform the search test with This Site and This List Scopes, and all are working properly now. Hope this solution help all others who are facing the same problem.




    Thursday, July 3, 2008 7:15 AM
  • Caution- Wall of Text - Sorry



    After reading all the posts above and none of them completely applying, I finally got my stuff to work for my client. I was experience the exact symptoms listed above: The custom content scopes worked great but the contextual search scopes ("This Site", "This List") returned no results.


    So I investigated a little about how the index and query service work to determine if I am on this site. I was able to pull information from almost all the posts above then it started to make sense on how it appears to work. My issue actual was because of Server Name mappings in the indexer.....


    But let me start form the beggining. When the indexer crawls the content it puts the entry of all files in the index. This would look like (simplified for explanation purposes) http://sitename.company.com/site/document1.doc. This works really well and everything is great.


    When you query "This Site" (for example you are on the http://sitename.company.com/Site/default.aspx page when you do this). The Query service looks in the index for any items that match the site based on your url (http://sitename.company.com/site ). This is shown byt th "u=" parameter in the address. It returns matching results.


    Ok now to my scenario. We have an F5 appliance in place that is load balancing a terminating the SSL. So user access sharepoint by typing HTTPS://.... and then the F5 hands off the request to Sharepoint as HTTP://... So sharepoint requests only come in through HTTP://sitename.company.com (as far as Sharpeoint and IIS can see, they never see the HTTPS). This means that in Alternate Access Mappings there are only HTTP://... Mappings and no HTTPS://.


    Now you say, but I don’t want the search links to show up as http://sitename.company.com/site since when the user clicks on it, they will be notified that they are clicking a HTTP link while currently in HTTPS (going from SSL to non SSL site). So the solution is to put the Server Name Mapping in search so that HTTP://sitename.company.com/site shows up as https://sitename.company.com/site .


    That is great. Reset search content and recrawl (you should do this whenever the “references” to the indexed content changes, like server names, url, protocol, etc.) so that the indexes are clear of any old items. Of course now when it finds the document used as an example above it enters it in the index as https://sitename.company.com/site . This works fine.


    Here is the issue. The query portion appends “u=” and the header information that it pulls from the request (remember the request, at SharePoint, is HTTP://...) and looks like u=http://sitename.company.com/site. It checks the index to find site names that match and of course, none do!!!! They are all https://sitename.complany.comn/site, thus a different site from Sharepoints perspective.


    So you have a couple of options, don’t terminate the SSL certificate prior to the SharePoint server, or don’t use the Server Name Mapping feature. This may also hold true in any case that the Server Name Mapping does not match the URL of the site that you are searching from (although I have not tested further on this thought).


    My Fix: Remove the Server Name Mapping and reset the index. Recrawl the site. The user will be prompted whenever they click on a item that they are switching the security zone, but they can click the “don’t show this again” box. We have in place redirection so that it forces any http requests to be changed to https, this allows for the SSL encryption to work as expected.


    This is not the ideal solution, but I don’t have control at a client site over the F5 appliance, or the purchase of SSL certificates (one on the F5 versus two for SharePoint [Two web server, would need a cert on each].

    Maybe this post will trigger some other solution that someone has that may be a better fit.




    Thursday, July 10, 2008 5:42 PM
  • What would be an example of incorrect vs. correctly configured AAMs?
    Bill English
    Wednesday, August 6, 2008 3:51 AM
  • Thank you so much for your post. The way you have described what is happening is very helpful and makes sense. Our environment is somewhat similar to yours except We have an Internet facing site that uses forms authentication and https. The users that acccess the Internet facing site do not have access to the internal url so when this shows up in the search results we are letting our Internet users see the internal URL which is a seccurity risk and of course it won't work because they do not have access. Our site is crawled however with the internal server name http://servername:port. To avoid our search results revealing the internal server name to the Internet users, we have a server name mapping that converts the internal server name to the https name. Of course, as you mention, the problem is now that the contextual "This List" and "This Site" search result page shows 0 matches. Because showing our internal server name in the search results is not an option, can you think of anything else we can do to get the contextual scopes to work?
    Friday, August 15, 2008 11:20 PM
  • Hi All,

    Thanks all for sharing your experiences. Our MOSS 2007 has 1 server and 1 database machine. Currently, our “This Site:” and “This List:” scope doesn’t return any result. When we search using “All Site:” it returns only .aspx pages.

    “Crawl log” has only .aspx pages entries.  

    Any suggestions?

    Wednesday, August 20, 2008 3:14 PM
  • Hi All,

    Thanks everyone for sharing there circumstance, and resolution. 

    Quick Summary:

        1. Validate SSP Configuration is good standing
        2. Validate AAM Configuration
        3. Validate the Zone Authentication for your Default Zone (preferrable: use NTLM authentication)
        4. Validate Crawling is actually been done successfully (Peek inside the Sql DB for your WSS search server)
        5. If all fails, and you don't have a lot of time in your hand; I recommend trying Vlad approach. (rename osssearch.aspx)

    MalikFarhan, unlike WSS search crawling function, the MOSS counterpart will respond to query eventhough the crawling has not been completed; however, running a query against the indexer at the start of the crawling will mostly generate the result you are getting and that will stay the same until the crawling has been completed and the indexer has fully index all of the crawl items.

    Wednesday, September 24, 2008 8:31 AM
  • I am having similar issues.  
    Here is my environment.   We have 5 WFE's.   3 are dedicated for User Traffic.   Then we have our SSP setup also as a WFE to crawl itself.    SSP is not using SSL but WFE servers are.  

    I have deleted the My Site Web application and recreated it. This Site search works. But I added a server name mapping and it broke again. This is what I have done:

    Deleted My Site Web App.

    Created New Web app

    Restored Mysites back.

    Added alternate access mappings

    http://mysite.com - default

    https://mysite.com - intranet

    Ran full crawl

    This Site, All Site, People and (Custom All My Site Search for documents only) returned results.

    But when doing a people search the results page showed a url of https://mysite.com:80/Person.aspx......

    And when clicking on it the page returned an error that Page cannot.

    When I added a server name mapping:

    Address in Index - http://mysite.com

    Address in Search - https://mysite.com

    Fixed that error but caused This Site to break.

    Now I am stumped. I tried to change

    Personal Site Provider which showed this: http://mysite.portal.keane.com:80/ on this page http://SSP/admin/_layouts/PersonalSites.aspx to http://mysite.portal.keane.com/ and it just keeps changing it back.

    I can't figure out how to get the :80 removed. Any suggestions?

    Thursday, September 25, 2008 1:47 AM
  • Hi,

    we had the same problem ,and from MS support this working solution

    1.       Go to your search center and search for someone, just to get to the people results page.

    2.       Edit the page and modify the People Search Core Results web-part.

    3.       Click on the XSL Editor button to get to the XSL style sheet applied to the resultset.

    The URL for each result is under the following section:


    <!-- This template is called for each result -->

    <xsl:template match="All_Results/Result">

    <xsl:variable name="id" select="id"/>


    Replace the <xsl:variable name ="url" select ="url"/> line with:



    <xsl:variable name ="temp" select ="url"/> <!-- We put the url value from the resultset in temp variable -->

                <xsl:variable name="url"> <!-- This will be the value used in the xsl from now on in this section as $url -->


                            <xsl:when test="contains($temp,':80')">  <!--We check temp variable  for the occurrences of string :80-->

                            <xsl:value-of select ="concat(substring-before($temp,':80'),substring-after($temp,':80'))"/>

                                        <!--We remove from temp variable the occurrences of string :80-->



                            <xsl:value-of select ="$temp"/> <!--If we did not find the :80 we will retain the default value (url) as defined above-->






    From now on, wherever we will use $url we will have the translated version of the url returned in the resultset

    Saturday, November 8, 2008 9:18 AM
  • I actually fixed this by making all my web apps on the Index server using default access mappings of https.   Then I set my content source to crawl https.   This fixed This Site and People Search.    
    Wednesday, December 17, 2008 7:13 PM
  • Emily:

    Would you able to layout the steps that you took, I am having this issue too and would like resolve it. I have been through all the other steps and they don't seem to be working in my case. I'm just having a hard time understanding what it is that you did and would appreciate your help

    Thanks :D
    Tuesday, February 3, 2009 8:59 PM
  • Thanks for all the posts here. I am summarizing our journey to resolve many issues revolving around making our SSL portal work and integrate with Exchange and LiveCom. In the course of this process our portal search broke multiple times, which was very frustrating.

    1. To have search work properly and to link SharePoint content seemlessly to Outlook:
        - Search content sources had to be defined with https and sps3s
        - Web applications had to be set to 'Require SSL'

    2. To have the contextual search scopes issue resolved discussed in this thread:
        - Delete Internet Zone for Alternate Access Mappings as https://portal.company.com
        - Changed Default Zone to https://portal.company.com from http://portal.company.com
        We didn't have to recrawl, changing the AAM worked immediately!
    Thursday, February 12, 2009 11:06 PM
  • This is the steps I had taken as well.      So the crawler was crawling https and search results were displaying as https.     This fixed our issue.
    Friday, February 20, 2009 6:55 PM
  • We were having the same issue. We have two separate farms. On one farm, everything works perfectly. After lots of frustration, I found that SearchResults.aspx worked but OSSSearchResults.aspx did not. That does not make a whole lot of sense. So I decided to compare OSSSearchResults.aspx between the two farms. They were different. In fact, they were the only files in the layouts directory that were different. So I simply made a backup of the one in the farm that was not working and then replaced it with the one from the other farm that was working. Now all works well. Go figure. In our case, the issue may have been that someone in our team attempted to "customize" the OSSSearchResults.aspx page without telling anyone, but then again it could have been caused by an update. Both farms have the same updates, but who knows.


    Tuesday, February 9, 2010 6:39 PM
  • Thanks Shane.  Your suggestions fixed my problem. 
    Wednesday, June 23, 2010 2:28 PM
  • I faced this issue with Sharepoint server 2010. I re-setted the index and did a full crawl. I also included the alternate urls in the content sources list. Not sure which from these actions helped, but it works now.

    Ravie, CZ

    Monday, October 11, 2010 10:34 AM
  • FYI.  I am running a SP 07 farm, Server 08 and SQL 08, and our contextual search was working fine since March, 2009 until last week, even though our AAMs are not well configured.  We applied the std MS WindowsUpdate, and since that was the only change we made, I think that must be what broke it.  I am going back through this thread and hope to find an appropriate fix.  I'll post an update if I find anything that works. 


    Monday, October 18, 2010 9:18 PM
  • We're having the same issue with SharePoint 2010.

    We've experimented with different AAMs, content sources, even tried different combinations of the Query String (&u=list) with no luck. (The search obviously returns results from the list with the All Sites scope).

    Currently, the default AAM is non-SSL and the Intranet zone is SSL. Other internal AAMs (e.g. FQDN) map to the default AAM. Search is using the default AAM. (We also tried the HTTP FQDN without luck).

    Any assistance/advice appreciated.

    Friday, November 19, 2010 4:33 AM
  • My colleague solved this issue by deleting and recreating the Enterprise Search Service Application.

    He attempted to reset index, recrawl full and remove all custom settings but with no luck.

    Tuesday, December 14, 2010 11:35 PM
  • Note that the AAM default configuration is also necessary for workflow Open Items links to work properly.

    See here:


    Monday, July 2, 2012 11:28 PM