Datasheet

24
|
CHAPTER 1 SharePoint Foundation 2010 under the hood
Search has some strengths and weaknesses that you should know about before you install
SharePoint:
Search doesn’t have much of an administrative surface. The GUI settings are limited to
•u
what service accounts are used, the search database name, and how often the site collec-
tions will be indexed. Indexing is primarily incremental, but even that can strain resources
if you do it too often. What little management you can do with Search is through the
SharePoint command-line tool STSADM or PowerShell. See Chapter 14, “STSADM and
PowerShell,” for more details.
Search can search only site collections (or more precisely content databases). It cannot
•u
search file shares, email servers, or other locations. If you want to search content outside
site collections, consider shelling out the money for SharePoint Server 2010 (which, for the
added cost, can search multiple external sources or even multiple SharePoint server farms),
Microsoft Search Server 2010, or installing Search Server 2010 Express.
Search uses a top-down approach. When you conduct a search query on a site, it will search
•u
that site and all subsites under it. If you conduct a search query on a site at the top of a site
collection (the first site created in a site collection), it will search the data contained in its
search database and index files for that site and then systematically check all other subsites
below it. However, if you are already on a subsite and start to search, it will search from
there and work its way down the subsites below it, ignoring the sites above it in the collec-
tion. In other words, Search always searches down and never up. Unless you absolutely
know which subsite has the data you are looking for, you should always perform searches
from the top level of a site collection.
Search is security filtered and searches along a path. Therefore, it generally only returns
•u
search queries per site collection. That means if you are looking for a document and you
have several site collections, you need to know what site collection it’s in or search each site
collection until you find it. Site collections are considered a hard-search boundary because
of two things. Site collections are usually at the top of a path, like http://server/sites/
sitecollection1. Everything within and under the sitecollection1’s top-level site would
be included in a search. Then those results are further filtered by the querying user’s per-
missions. Normally a user is a member of one site collection but not the other. This usually
works fine for most users, but if you are, say, the owner of more than one site collection in a
path, check the URL of your search results to be sure they are from the correct collection.
Search does whole-word, exact-match queries. If there are multiple words in a query, AND
•u
is implied between the words (orange juice is considered orange AND juice and would
return only results that contain both values). Punctuation is ignored, as is the word and.
However, strangely, the word or is neither ignored nor recognized as part of the query logic
and is treated like part of the query text itself.
Unfortunately, Search for SharePoint Foundation doesn’t accept wildcards or Boolean
•u
logic, but it does allow for keyword exclusions or additions by using the plus (+) or minus
(–) signs. Search will also support property filtering. Property filtering means that search
can recognize some field names and properties, such as file type, content type (used for
libraries particularly), author, title, or subject. To filter in the search field by property, the
syntax is property:query; for example, filetype:txt will result in all text files in the site
collection. Searches are scoped in a way (but not as well as the previous version). Search
626382c01.indd 24 1/27/11 10:47:24 AM