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.