ITP314 CIO314 PM314 IA314 Wes Preston MCTS Inetium wwwinetiumcom wesidubbscom Wes is a SharePoint consultant and organizes the Minnesota SharePoint User Group 150 attendeesmonth http ID: 251610
Download Presentation The PPT/PDF document "Re-Architecting Search Solutions with Sh..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Re-Architecting Search Solutions with SharePoint’s new Federation Features
ITP314, CIO314, PM314, IA314Slide2
Wes Preston MCTS
Inetium
www.inetium.com
wes@idubbs.com
Wes is a SharePoint consultant and organizes
the Minnesota SharePoint User Group (~150 attendees/month
)
http
://www.idubbs.com/blogSlide3
Abstract
Microsoft introduced federated search functionality as part of Search Server 2008 and as an updated feature set for MOSS. Learn why these features change design strategies for SharePoint topologies and understand the reasons why you may want to revisit how search is deployed in your environment. Slide4
Agenda
1. What new search features are offered by Microsoft Search Server 2008 and included in the MOSS ‘Infrastructure release’.
2. What is Federated Search and how does it fit in with other SharePoint Search solutions and topologies.
3. The advantages of new search topology designs over current topologies. Slide5
What’s New
Products and Updates
MOSS update
Search Server 2008
Search Server Express 2008
Functionality
Federated Search
New Administration and ReportingSlide6
Federated Search
Wikipedia:
Federated
search
is the simultaneous search of multiple online
databasesSlide7
Search is HUGE – Why…
Findability
is a critical part of the user experience.
Product offerings from Microsoft continue to improve because of search’s importance in the workplace
There
is a LOT that can be configured out of the box, even more that can be customizedSlide8
Search is HUGE – How…
Content
sources
Scopes
Crawled and Managed Properties
Audiences
Best Bets
Thesaurus and Noise files
Search pages, Results pages, advanced search pages
XML configured search results
SSPs
Crawl
schedules
More…
And now -
FederationSlide9
Best Practice #1
With
a WSS only farm, install Search Server Express to allow for cross site
searching
Why?
With WSS only, users can search the existing site and all sub webs –
SSE goes
across site collections.
SSE
adds enterprise search
functionality: Scopes, best bets, etc…
Allow for broad search across site collections
Better administration and control
No additional software/licensing cost Slide10
Best Practice #1
Trade-offs:
Additional effort to build and maintain multiple farms
There will likely be more search results for each searched topic
Additional thoughts:
There are a number of ways to implement – find the one that is right for your particular needs to be successful
Integrate into WSS. Replace the WSS search functionality with SSE functionality.
Add SSE to the environment as a stand-alone search offering with WSS as just one of a number of content sources.
Become a federated source for other searchesSlide11
Best Practices #2
Don’t crawl across the
WAN (with a ‘smal
l’ pipe)
.
Why?
Reduces the load on the WAN pipe/bandwidth
Crawls may be affecting the performance of other applications
Faster crawls
Allows for increased frequency of search and query updates
Trade-offs:
Additional effort to build and maintain multiple farms
Lose the ability to merge results between core and federated result sets.Slide12
Best Practice #2
Additional thoughts
If you can mitigate the limitations of crawling across the WAN, it may still be worthwhile
Not
crawling
too much or too often
As
MS does with their farms today, you can tweak the content crawling schedules and
frequencies
If you’ve got a WAN that’s fast enough to maintain crawls and searches while not negatively impacting other WAN usage, you may be ok to continue down the traditional route. Be sure to plan for growth.
Be
sure to monitor both full crawls and incremental crawls. Slide13
Best Practice #3
Dedicate search servers to business-
specific content sources when
appropriate
Why
?
To accommodate large volumes
of data, constant changes,
and a
need for up to date results
Crawls can take a lot of time. Isolating a content source allows the indexer to focus on the one solution. There might not be a lot of changes for each incremental crawl, but they can be updated and propagated more quickly.
Faster
crawls
Allows for increased frequency of search and query updatesSlide14
Best Practice #3
Trade-offs:
Additional effort to build and maintain multiple farms
Lose the ability to merge results between core and federated result sets.
Additional thoughts:
Maybe this is more of a specific use-case solution than it is a best practice, but I want to get across that there will and can be requirements for extreme configurations that SharePoint can meet.
This is one of the tougher best practices to
nail down specifics
on because it goes
hand-in-hand with taxonomy
planning - aligning
with business data and usage. Slide15
Best Practice #3
Additional
thoughts:
While results from the isolated content source won’t be integrated into a merged result set, it can still be exposed via federation and then drilled down into via the focused search Slide16
Best Practice #4
Governance
: Train and inform users about
search functionality and changes.
Why?
Users are more productive
Because this keeps your users and stakeholders happy.
Trade-offs:
Effort to create and distribute the information to usersSlide17
Best Practice #4
Additional thoughts:
The effort to create and distribute information preemptively should be a
significantly
less
than the time required to respond to the
questions and issues that
will
arise if the information
is
not shared.
There should already be one or more methods in place for news and training
Internal training and user group sites
SharePoint Portal Training kitSlide18
Worst Practices
Don’t index the same content from more than one Search server - avoid cross-over search and multiple results
Indexing the same content more than once eats up processor time, SQL access bandwidth, LAN bandwidth, and storage space.
Don’t
use too many federated search results web parts and/or
sources
SharePoint 2007 Best Practices book recommends no more than 10 Federated web parts per page… Slide19
Worst Practices
Don’t
over isolate – don’t use separate search servers for content sources if they are not needed (e.g. – one server for each file share, etc…)
Don’t crawl so much data that the crawler can’t finish befor
e it’s scheduled to start the crawl againSlide20
References
Federated
Search overview
http://blogs.technet.com/tothesharepoint/archive/2008/07/18/3090988.aspx
Plan for global enterprise search
http://technet.microsoft.com/en-us/library/cc262205.aspx
Best Practices for Search in Office SharePoint Server
http://technet.microsoft.com/en-us/library/cc850696.aspx
Plan the end-user s
earch experience
http://
technet.microsoft.com/en-us/library/bb905371.aspx
Slide21
New Book!
Microsoft Search
SharePoint 2007 and Search Server 2008Slide22
Thank you for attending!
Please be sure to fill out your session evaluation!