Re-Architecting Search Solutions with SharePoint’s new Federation Features

1. Re-Architecting Search Solutions with SharePoint’s new Federation Features ITP314, CIO314, PM314, IA314

2. 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/blog

3. 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.

4. 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.

5. What’s New • Products and Updates • MOSS update • Search Server 2008 • Search Server Express 2008 • Functionality • Federated Search • New Administration and Reporting

6. Federated Search • Wikipedia: Federated search is the simultaneous search of multiple online databases

7. 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 customized

8. 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 - Federation

9. 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

10. 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 searches

11. Best Practices #2 • Don’t crawl across the WAN (with a ‘small’ 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.

12. 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.

13. 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 updates

14. 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.

15. 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

16. 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 users

17. 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 kit

18. 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…

19. 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 before it’s scheduled to start the crawl again

20. References • Federated Search overview http://blogs.technet.com/tothesharepoint/archive/2008/07/18/3090988.aspx • Plan for global enterprise searchhttp://technet.microsoft.com/en-us/library/cc262205.aspx • Best Practices for Search in Office SharePoint Serverhttp://technet.microsoft.com/en-us/library/cc850696.aspx • Plan the end-user search experiencehttp://technet.microsoft.com/en-us/library/bb905371.aspx

21. New Book! • Microsoft SearchSharePoint 2007 and Search Server 2008

22. Thank you for attending! Please be sure to fill out your session evaluation!