A previous post indicated about using search to aggregate data. Whilst an acceptable approach (though with some limitations?) another is to go down the route of providing a custom Data Source

Todd Baginski & Andrew Connell have presented and posted information on how to do this - the Content Monster Web Part. don't be put off by the name (those who have seen Todd present can appreciate the left field naming!)

The article has been posted on MSDN and the slide desk from TechEd also

Working on a new intranet site for a client I was puzzled when only the homepage of the root site collection would appear in search results. We have site collections on managed paths below the root site and those weren't showing either. Crawls were running but the crawl log showed "Some parts of this document cannot be accessed". I checked the sharepoint logs and the windows event log, then googled away as usual but there weren't really any further clues, everything seemed to be as it should be.

I tried a reset all content on the search index and this made no difference, next up I tried a new content source as I had I noticed some blogs and forums had mentioned an error meessage saying

The start address http://intranet/sites/sitename is not valid for this content source type.

So I tried creating a content source of SharePoint Sites pointing at the site collections on managed paths, these also gave this message - Ah!, progress I thought as it gave another clue. But alas, no further clues were to be found. In the absence of any further hits on google revealing an insight that would solve it. I tried a restart on the Search Service and the Timer service followed by a full crawl. And straight away the crawl log started to give me more than just one hit on the new location, by the end of the crawl there were all the results I had been expecting first time round.

The only thing I can think confused it was that we recreated the site collections several times during deployment and that caused it to get confused.

I hope that little gem helps you out of a spot if search isn't bringing back the results you're expecting.

I'm part way through the great book on Search Server 2008. Even using Sharepoint and Search every day, it's still interesting to find the things you don't know (or have forgotten ) about the products.

Some quick notes that I made while reading the book. They are in no particular order, other than I wrote them while reading so probably follow the chapters

If using a separate index server, make it also a Web Front End

The Search Service account will be granted read permissions in the farm and should not be part of the administrators

WSS Search (for searching Help) should be configured to crawl off peak. It only indexes the Help and runs a full crawl each time ?

Look carefully ate crawl impact rules for external sites and check the order of the rules

Schedule any full crawls to run after any daily backup jobs

Manage 'web site' content sources with custom properties and check the hop number (to avoid crawling the net) or set to 'this site only'

You can index Forms Based Authenticated sites using crawl rules and form credentials- point to the login page to crawl

Basic authentication is sent in clear text so implement SSL. You will need to specify the certificate?

You can specify a cookie

Ignore SSL warnings overcomes any self signed certificates

You can configure the Shared Services recently configured crawls web parts to suit your requirements

Search Scope can implement a custom property

Search result removal clears items from the index immediately and prevents explicit results being displayed

Search needs monitoring and management !!!!!!

Index will only do 16mb of a file

.one and .vsd files are not crawled by default and need additional iFilters

Beware of choosing stop / start services from Central Admin - this will clear the index and require a new full crawl