Thủ thuật Sharepoint 2010 part 55 pptx

Confi guring and Managing Enterprise Search WHAT’S IN THIS CHAPTER? SharePoint Foundation Search  SharePoint Server and Search Server  FAST Search  All the bells and whistles of Search  Who doesn’t need Search these days? In the early days of the Internet search engines were either unknown or considered weird things that the geeks (like the authors of this book) would use to fi nd those cool nuggets of information on the Internet. You know the ones, like how to build your own BBS using 286s or what was the code for invincibility in Doom. Fast forward to today and now everyone and their dog uses search to explore the Internet. And it works great for fi nding anything and everything you can imagine. It even works just as well to fi nd those Doom codes. Unfortunately, Internet search engines cannot reach inside your corporate network. And even if you buy one of those “Internet search devices” and put it inside your network they generally don’t do a very good job of indexing (cataloging) your corporate data. That’s because the online search engines are optimized for following the billions and billions of links on the Internet and determining relevancy that way. Your intranet doesn’t have the same type of linking, so the results fall short. The challenge is your users want to search, they even expect it. They don’t want to dig through a fi le share to fi nd their spreadsheet. Think about it; what is one of the most popular features in Outlook 2007 and 2010? The instant search capabilities of e-mail. Once again, people don’t want to categorize and organize e-mail; they want to have a big pile that search can deal with. If only there was a way to effectively provide search results from the intranet. Enter SharePoint 2010 in all of its Search glory (hear the trumpets?). For a lot of companies evaluating SharePoint, Search is one of the most compelling reasons to invest in the platform. 14 372  CHAPTER 14 coNfigUriNg aNd maNagiNg eNterPrise search SharePoint Search not only does a fabulous job of indexing your SharePoint installation, but can reach out and index the rest of your enterprise. File shares, Exchange public folders, other web sites, line of business data, even Lotus Notes databases can all be added to your SharePoint index by the index servers. Servers? Yes, that’s right; SharePoint 2010 has made some major architectural changes, including supporting multiple index partitions and even using multiple index servers to populate them. All of these changes extend SharePoint Server Search’s upper limit to 100 million items. And if you want to go beyond that you should look at one of the new SKUs introduced, FAST Search. With FAST, having 1 billion items in the index becomes a real possibility. A fancy new architecture and some new SKUs wasn’t enough for the Search team. They have also invested quite heavily in updates to the user experience. Things like wild card searches, support for Boolean operators, and a refi nement panel are all now available. You will also see a new Search- specifi c master page that provides more screen real estate, and AJAX support for rendering Web Parts — and extensible Web Parts this time around. When you fi rst begin to administer Search, it will seem very familiar as the Search administration pages that were introduced with MOSS 2007 at the infrastructure update have been retained in SharePoint 2010. But don’t overlook this chapter, as there is gold in them thar hills. Several small nuggets have been added to give the administrator more control. Features like setting content prior- ity, search of case sensitive locations, and a whole list of new reporting options will excite even the most jaded administrator. Also, watch for some changes: protocol handlers are out, BCS connectors are in, and introducing claims to the farm. This chapter will help you unlock all of the power of this favorite feature of both administrators and users. THE DIFFERENT VERSIONS OF SEARCH In Chapter 3 you learned that there are a lot of different SKUs for SharePoint. This chapter looks at the way Search functions in three key product sets: SharePoint Foundation Search  SharePoint Server and SharePoint Search Server  FAST Search Server 2010 for SharePoint and FAST Search Server 2010 for Internet Sites  FAST Search Server 2010 for Internet Business is not covered in this book. While it shares a similar name, it is a standalone product that has nothing to do with SharePoint. SHAREPOINT FOUNDATION SEARCH SharePoint Foundation continues the proud heritage of Windows SharePoint Services as an environ- ment that is easy to deploy, confi gure, and use. Once deployed, it gives users convenient access to the key features they need to start collaborating. Search is no exception to this. Foundation Search will SharePoint Foundation Search  373 index all of your SharePoint content and provide basic search results with very little effort. And once you enable the indexing, the administration and UI have no settings to configure — they just work. But don’t gloss over this section; there’s some important info here to help you get the most out of Foundation Search. Setting Up Foundation Search Foundation Search does need a little nudge from you, the SharePoint administrator, before it goes into auto-pilot mode for the next couple of years. You need to start the service and ensure that all of your content databases know to use the service you start. Follow these instructions to get things going: 1. Open Central Administration. 2. Under System Settings, click Manage services on server. 3. At the bottom of the list click Start (to the right of SharePoint Foundation Search). 4. Choose the proper service account; if you are doing a least privileged install, then you should create a new managed account for Search. 5. For Content Access Account, enter a username and password as shown in Figure 14-1. Keep in mind: This should be a unique, dedicated only for Search account.  Always enter accounts in the form domain\username.  FIGURE 141 6. Make any changes to the Search Database screen that you need. For most options, the defaults will work well. Figure 14-2 shows an example. 7. If applicable, specify a Failover Server. 8. For Indexing Schedule, you need to choose the proper schedule for your needs. You will need to balance the need for more frequent index updates with the performance capacity of your server(s). If you are unsure, start with the default of once an hour and then adjust from there based on user feedback and system performance. Figure 14-3 shows a default schedule. 374  CHAPTER 14 coNfigUriNg aNd maNagiNg eNterPrise search FIGURE 142 FIGURE 143 9. Scroll to the bottom of the page and click Start. After a minute or two of processing you will be taken back to the Services on Server page and the status for SharePoint Foundation Search will be started. (You may see the name of the service updated to SharePoint Foundation Help Search.) Now, with Foundation Search running, you need to ensure that all of your content databases are assigned an indexer. The indexer will be the server on which you just started the Search service. 1. From Central Administration, go to Application Management. 2. Under the Databases section, click Manage content databases. 3. Click the name of your content database. 4. Scroll down the page to Search Server and select your index server from the drop-down. 5. Click OK. If you have multiple content databases you will need to repeat these steps for each of them. With the Search Server value updated, the next time the indexer runs based on the schedule you defined earlier, the selected content database will be indexed. If, like your impatient authors, you do not want to wait, you are in luck. You can use the stsadm.exe command shown here to start a full crawl immediately: Stsadm.exe -o spservice -action FullCrawlStart SharePoint Foundation Search  375 With Foundation it is possible to have multiple index servers by simply start- ing the service on multiple servers. If you do this, you can then distribute the load by content database. And as long as you have your site collections spread across multiple databases, you have a solution that has distributed the load of indexing. Keep in mind, though, that this is not making your indexing high availability. If one index server goes down, then the other server will not pick up and respond to requests in its place. You would fi rst have to set all of the content databases to be indexed by the surviving index server and then run another crawl. Remember that you have to be in the SharePoint Root folder and then \bin to run the command. Or you can take the easier way and open the SharePoint 2010 Management Shell, since stsadm.exe is already in the path. The message “Operation completed successfully.” will return quickly. This does not mean the index is done, just that it is started. If you want to know when it is complete, you can monitor Event Viewer on the server. You will see an Event 85: “A master merge has completed for catalog Search.” Now you have search results. Search Results Take a look at Figure 14-4 for an example of Foundation Search results. FIGURE 144 376  CHAPTER 14 coNfigUriNg aNd maNagiNg eNterPrise search Here you can see the simplicity at work again. No tabs to navigate search result pages, no refinement panel to drill down based on metadata, no federated results, no advanced search options. Just good old-fashioned SharePoint content search results. To understand exactly where those results come from, Figure 14-5 shows an example hierarchy. Web 1 Web 1a Accounting.doc Site Collection 1 Http://docs Web 2 Accounting.doc Site Collection 2 Http://docs/ sites/archive Web 3 Accounting.doc Site Collection 3 Http://docs/ sites/storage Web 4 Accounting.doc FIGURE 145 If you run a search for Accounting.doc from each of the locations shown in Figure 14-2, you will see the following results: Site Collection 1  — You will get results from all four sites: Web 1 a, Web 2, Web 3, and Web 4. Web 1  — You see the results only from Web 1 a. Web 1 a  — You see the results only from Web 1 a. Web 2  — You see the results only from Web 2. Site Collection 2  — You see the results only for Web 3. Web 3  — You see the results only from Web 3. Site Collection 3  — You see the results only for Web 4. Web 4  — You see the results only from Web 4. From the root web at the root site collection, Search will return results from the entire web applica- tion. This is the only location that will return all results. Searching from any of the other locations will return results only from that spot in the site collection and down the tree, as shown when you are on Web 1 and you see results for Web 1 a but not Web 2. Web 1 and Web 2 are in the same site collection but they are in different branches. Why does that root site collection get these magical powers? In fact, it isn’t magic, just fun with query strings. Go to the root site collection and search for test. Then look at the URL http:// docs/_layouts/searchresults.aspx?k=test&u=http%3A%2F%2Fdocs . If you break that down starting from the ?, you can see there are two parameters. The K=test parameter means “do a search for the keyword test.” The & means there is another query string coming. The u=http%3A%2F%2Fdocs parameter translates to “return search results for URLs that start with http://docs.” Because every web in the web application starts with http://docs, you got results from the whole web application. SharePoint Foundation Search  377 Just for fun, what happens if you manually remove the u=http%3A%2F%2Fdocs from the URL and press Enter? You get results from the entire farm. Very inter- esting; maybe you should add that to your secret SharePoint hacker notes. Remember that the search results you see, even if you are manipulating the query strings, will only be items to which you have permissions. SECURITY TRIMMING SharePoint will only show you search results for content you have access to, and for which SharePoint understands the security. This is called security trimming. For example, when you index your Windows fi le share, SharePoint can match your AD permissions on the share to the AD account you are logged into SharePoint with and trim your search results. But if you set up SharePoint to index an exter- nal source, maybe using a cookie or a secret anonymous back door, SharePoint doesn’t understand these permissions. It will then show you all of the results for that source. If you need to have security trimming for these external repositories, you should look into developing a custom security trimmer. That is another one of those “developer” topics that is outside the scope of this book. User Interface Features A couple of user features are worth noting. Wildcard and Boolean searches work with Foundation and are covered in greater detail later in the chapter in the “SharePoint Server and Search Server” section. This means you can do searches like share* or something fancy like “Human Resources” AND policy. This former does a search for anything that begins with share. The latter will search for anything that has the words Human and Resources together and has the word policy in it. Foundation will automatically create contextual scopes for you. A contextual scope can help you narrow down your search results. It enables you to do a search of This Site or This List. To access the contextual scope for This List, navigate to the list and then do your search from the Search box at the top of the page. It will default to searching your current list. You can then click the drop- down menu to select This Site. Interestingly enough, if you look at the URL when you search This List, you will see the same u=<your URL location>, once again opening the door for some search results manipulation if necessary. Site Search Administration If you look for Search settings from the Site Settings page, you will not fi nd much. The only search- related option is Search and offl ine availability. This setting allows you to control whether the current web is included in search results and how to handle any ASPX pages you may be using. 378  CHAPTER 14 coNfigUriNg aNd maNagiNg eNterPrise search That’s it; you are done with your tour of Foundation site search administration. Clearly, there are a lot of positives here; but keep reading. The next section covers SharePoint Server Search and Search Server. As you drool over those features, don’t forget that the Express version of Search Server is free, and you can bolt it right on top of Foundation with ease. Wow — a free solution and a more awesome Search. SHAREPOINT SERVER AND SEARCH SERVER This section covers the following products: SharePoint Server 2010 Standard  SharePoint Server 2010 Enterprise  SharePoint Server 2010 for Internet Sites Standard  SharePoint Server 2010 for Internet Sites Enterprise  Search Server 2010 Express  Search Server 2010  This is the money section of the chapter. Most readers probably have one of the aforementioned products or are bugging their bosses to get one. Foundation Search is great for getting started, but it lacks the level of control you may be hoping for. FAST Search is amazing, but its price tag can be a tough hurdle to overcome in smaller environments — so that leaves you here, in a very nice and com- fortable place. Search Server versus SharePoint Server A very common question that first pops up in this conversation is “If I have SharePoint Server what do I get by adding Search Server?” The answer is simple: nothing at all. Search Server is only a subset of the functionality available in SharePoint Server and cannot be installed on an existing SharePoint Server installation. An example of a key difference is that SharePoint Server can index Active Directory information about your users after you configure and do a profile import, which is covered in Chapter 17. While Search Server can index SharePoint sites, it does not have a mechanism for doing the profile import from Active Directory, so it is unable to index user information. We will note similar limitations on Search Server throughout the chapter; otherwise, assume Search Server can perform the covered feature. The follow-up question is “What is the difference between Search Server and Search Server Express (SSX)?” Again the answer is simple: scale. SSX can only be deployed on one server in the farm. You cannot add more servers to make Search high availability. Search Server can be scaled in the same fashion as SharePoint Server, providing high availability for search and the capability to scale to some- where in the ballpark of 100 million items. Yikes! Of course, that power comes at a price. Express is free, whereas regular Search Server is not. . awesome Search. SHAREPOINT SERVER AND SEARCH SERVER This section covers the following products: SharePoint Server 2010 Standard  SharePoint Server 2010 Enterprise  SharePoint Server 2010 for Internet. for SharePoint. This chapter looks at the way Search functions in three key product sets: SharePoint Foundation Search  SharePoint Server and SharePoint Search Server  FAST Search Server 2010. standalone product that has nothing to do with SharePoint. SHAREPOINT FOUNDATION SEARCH SharePoint Foundation continues the proud heritage of Windows SharePoint Services as an environ- ment that