Академический Документы
Профессиональный Документы
Культура Документы
ii
Search Overview
Search is perhaps one of the most important aspects of any SharePoint 2013 deployment, which allows users to quickly discover content that is relevant to some need they have. In some instances, a user may know many characteristics of the content they are looking for perhaps theyve seen a specific document before but have forgotten where that document is stored. In other situations, a user may not know content specifics beyond a single keyword. Even in the most well designed and intuitive information architectures, search effectively allows users to spontaneously create a taxonomy of their own that facilitates both the navigation and discovery of relevant information in their SharePoint 2013 deployment. This document includes search planning resources for SharePoint 2013. The following Microsoft TechNet resource centers and blogs are relevant to content in this guide: Enterprise Search Resource Center Enterprise Search Team Blog
Relevance enhancements
Relevance is determined by how well a search result, suggestion or recommendation satisfies the information need and the intent of the person issuing the query. SharePoint 2013 provides relevance improvements in freshness, and in linguistics and document parsing. There are also relevance improvements in the following areas: New ranking models Analysis of content and user interaction Query rules Result sources
Query rules
Without any custom code, you can create query rules to help direct search results to the intent of your users. In a query rule, you specify conditions that will cause the rule to fire. For example, a condition might be that a word in a user's query matches a term in a SharePoint term set, or that a word in a query commonly appears in queries typed on a particular site on your intranet. When a query meets conditions specified in a query rule, the rule specifies actions to improve the relevance of the associated search results. A query rule can specify the following types of actions:
Result sources
In SharePoint Server 2010, federated locations and scopes were both ways to delimit sets of search results. In SharePoint 2013, result sources replace federated locations and scopes. You create and use a result source to specify a location to get search results from, and to specify a protocol for getting those results. In comparison, in SharePoint Server 2010, you specified a location and a protocol by creating a federated location. In SharePoint Server 2010, you could specify the protocol as local SharePoint index, FAST Search Server 2010 for SharePoint index, or OpenSearch. In contrast, for protocol in SharePoint 2013 (which is called the Source Type), you can specify local SharePoint index, remote SharePoint index, OpenSearch, or Microsoft Exchange Server index. If you specify remote SharePoint index as the Source Type, you do not have to supply any custom code to handle authentication as you did in SharePoint Server 2010. With a result source, you can also restrict queries to a subset of content. The pre-defined result sources in SharePoint 2013 show how you can do this by using query transformations. For example, the pre-defined "Local Video Results" result source uses a query transformation to return only video results from the local SharePoint index. In SharePoint Server 2010, this kind of restricted query was called a search scope. You can use a result source in several ways. For example, in a Web part you can display results from a result source, as compared to displaying results from a federated location for the same purpose in a previous release. As another example, you can configure a result block to contain results from a result source. In SharePoint Server 2010, only a Search service application administrator was able to manage and configure federated locations. In contrast, in SharePoint 2013, site collection administrators, site owners, and site designers can also create and configure result sources to meet their specific requirements, rather than having to rely on Search service application administrators.
Changes in crawling
Continuous crawl
In SharePoint 2013, you can configure crawl schedules so that crawls are performed continuously.
Client Application
Custom
Event Store
The crawl component crawls content sources to collect crawled properties and metadata from crawled items. It sends this information to the content processing component. The content processing component transforms the crawled items so that they can be included in the search index. The component also maps crawled properties to managed properties. In addition, the content processing component interacts with the analytics processing component. The analytics processing component analyzes the crawled items and how users interact with their search results. The information is used to improve the search relevance, and to create search reports and recommendations. The index component receives the processed items from the content processing component and writes them to the search index. The component also handles incoming queries, retrieves information from the search index and sends the results back to the query processing component.
Multi-tenant hosting
SharePoint 2013, the search system supports multi-tenant hosting.
Query Capabilities
SharePoint 2013 enables end users to create and run more effective search queries. It also enables users to issue search queries from the desktop in Windows 7. The new query capabilities are: Boolean query syntax for free-text queries and for property queries SharePoint 2013 supports use of the Boolean operators AND, OR, and NOT in search queries. For example, a user can execute a query such as the following: (SharePoint Search OR Live Search) AND (title:Keyword Syntax OR title:Query Syntax) Prefix matching for search keywords and document properties Search queries can use the * character as a wildcard at the end of a text string. For example, the search query "comp*" would find documents that contain "computer" or "component" or "competency". Similarly the query "author:Ad*" would find documents created by "Adam" or "Administrator". Therefore, the query "comp* author:ad*" would find documents that contain "component" and that were created by "Adam", as well as finding documents that contain "computer" and that were created by "Administrator". Suggestions while typing search queries As a user types keywords in the Search box, the Search Center provides suggestions to help complete the query. These suggestions are based on past queries from other users. Suggestions after users run queries Search center also provides suggestions after a query has been run. These suggestions are also based on past queries from other users, and are distinct from the 'did you mean' feature. Connectors for enterprise search in Windows 7 From an Enterprise Search Center, users can easily create a connector for their SharePoint searches in Windows 7. By typing
Terminology
It is important that you have a solid understanding of the terms and definitions used throughout this document. Note that some key terminology has changed since SharePoint 2010.
Index Replica
Managed Property
Properties Database
Relevance
Search Center
10
Search database
(See the logical topology diagrams elsewhere in this document to see the interrelationship between the various search components and search databases.) The search databases contain status and configuration information, not the actual search index itself. (see index for more information) There are four distinct search databases: Search Administration Database Crawl Database Link Database Analytics Reporting Database
Stop Word
Synonym
See Search Center, above. Words in each language can have multiple forms, but essentially mean the same thing. For example, the verb 'To Write' includes forms such as writing, wrote, write, and writes. Similarly, nouns normally include singular and plural versions, such as book and books. The stemming feature in enterprise search can increase recall of relevant documents by mapping one form of a word to its variants. Stop words (sometimes known as noise words) are those words which are very common in the corpus. Querying for them may affect performance by resulting in too many hits, so a cap can be placed on the hits returned to resource consumption. Note that these terms are indexed, unlike some previous search mechanisms. Synonyms are words that mean the same thing as other words. For example, you might consider laptop and notebook to mean the same thing. Administrators can create synonyms for keywords that information workers are likely to search for in their organization. Additionally, synonyms that can be used to improve recall of relevant documents are stored in thesaurus files. An enhanced Best Bet mechanism in FAST Search For SharePoint 2010 that displays rich HTML content obtained from a URL (vs. normal Best Bet display) Streams or words are retrieved from content sources, and those streams are broken down into discrete words for indexing. Word breakers are the components that break down streams into individual words. Streams to be indexed are normally broken down by identifying spaces, punctuation marks, and the particular rules of each language. Also, when a user enters multiple words into a search box, that query is broken into discrete terms by a word breaker.
11
12
13
14
15
16
While SharePoint 2013 includes out of box a number of IFilters, others may be required to truly gain access to content stored within those documents. The amount of processing time associated with crawling one file type versus another may be significant, even if we are talking milliseconds. Ultimately, we are concerned about the aggregate impact. Different file types typically have different index densities. By this we mean that there may be more actual content that will make its way into the index for a small Microsoft Word file than in a large JPEG file. Some file types expose metadata along with their content. For example, a Microsoft Word file may have properties on it that supplement the content contained within the actual file keywords, customer name, and subtitle are a few examples. A web page may expose HTML META tags that are exposed by an IFilter as properties. Dependent on how you choose to respond to these properties, they may end up in the property store, increasing its overall size. SharePoint 2013 may need additional configuration to crawl specific file extensions, even if an existing IFilter could crawl the content.
Does content in one repository need to There may be regulatory or security motivators for doing this. As with be kept separate from another? the similar topic in the end user section, there can be a number of solutions to this problem. If the motivation is to prevent users from seeing content that they should not be able to see, assuming the content is already secured and the crawler can consume the permissions on that content, isolation by way of security trimming should already occur. It is also possible to logically isolate content by creating multiple content sources that target different segments of a repository, or even redefining the default search scope or defining new scopes that at query time, to restrict the query to only a portion of the corpus. If the customer demands the more physical isolation, separate crawl and query applications (along with their required databases) could be setup to ensure that content is truly managed separately. If the demands are even more extreme, it may necessitate production of a separate farm to honor this isolation requirement.
17
18
Crawled Properties
These are the attributes that are discovered and indexed at crawl time, including attributes from content source systems, such as the last modified date for files in file shares, and the column data for items in SharePoint lists and libraries. They also include embedded property values from the property sheets of specific file types, such as Microsoft Office documents.
Managed Properties
Managed Properties. These represent a virtual mapping between one or more crawled properties and the values for each item that are stored in the search index.
Index Schema
The Index Schema is the structure of the data stored in the index. It is defined by the list of managed properties that are available for use in the search index. New in SharePoint 2013: The ability to include crawled property values in the index without assigning them to managed properties. The ability to modify within limits the index schema at a tenant or site collection level.
19
The answer to each of these five questions is, in the end, a list of Managed Properties that defines your Index Schema. These managed properties are what you map your crawled properties to from your data sources. Answering The 5 Questions well improves overall user experience!
20
As a customers volume of searchable content may vary in size from thousands to millions of documents, these use cases help you identify opportunities to introduce or extend the use of search within your customer s portfolio, as well as be catalyst for conversations about search with your customer.
Basic Search
Basic Search relies on out-of-the-box functionality provided by SharePoint 2013 and can be delivered in a short timeframe, with minimal customizations and at a minimal cost. A Basic Search solution delivers query results in relevant order by consolidating information (e.g. structured and unstructured data) from one or more sources into a single searchable index up to 10 million documents. Leveraging a standardized user interface (UI), a Basic Search solution also supports multiple document formats and languages. If desired, a Basic Search solution can also include the following search capabilities: Content can be augmented prior to indexing by adding metadata or by extracting concepts or select text within content. This information can then be used by users as additional search criteria or to refine search results. Users are provided with advance query capabilities (Boolean searching such as Cat AND Dog as well as wildcard searching) that returns results in order of relevance or sortable by customer selected criteria. Search results are supplemented with Refiners, such as Document Type, Author, Company, which enable users to quickly drill down into results. Query Suggestions provide a list of suggestions that appear as queries are typed. Document thumbnails for Word and PowerPoint documents give users a quick view at the first page of documents. PowerPoint documents can be viewed in their entirety directly in search results, preventing users from having to open multiple documents.
Enterprise Search
An Enterprise Search solution, by definition, integrates large volumes of data from a wide variety of heterogeneous data repositories often dissimilar information sources. They also typically leverage employ the most more adva nced Out of the Box capabilities SharePoint 2013 and frequently extends them in order to address the a customers unique enterprise-wide business requirements. For example, some of these advanced capabilities may include real-time content refinement (data mining), extracting named entities and key concepts (entity extraction), customized dictionaries (linguistics), data-driven navigation (refiners), and extending the search to incorporate results from legacy applications (federation), among others. Features like relevance tuning, entity extraction, data for example, by categorizing the document based on important terms that it contains; enrichment, advanced linguistics, spelling checks, word stemming and anti-phrasing, multi-language support, and query federation. (Note: If your customer is not speaking in these terms, or others like them, they are probably better suited to a Basic Search solution at this time, which will give them the solid footing they need to grow into the more robust Enterprise Search solution over time.) Users of Business Enterprise Search solutions go to provide a single, coherent search application interface to find the best, most relevant documents for a topic of interest from available s that they are searching for in many data repositories or collections. In many cases, the interface is customized to deliver a very specific user search and results navigation experience, which may include a variety of search
21
By implementing Enterprise Search, customers benefit by centralizing their users point of access for finding documents. Thi s increases end user efficiency, reduces the time users waste consume by individually querying separate repositories, and increases the likelihood of IP re-use within the user community. As the customers experience with their Enterprise Search solution grows, they will find that the centralized searc h experience can become the foundation upon on which knowledge management and corporate taxonomies can be built which begins to move the customer beyond Enterprise Search to the next level in the Enterprise Search Maturity Model, Unified Access Platforms
22
Mitigating Risk
The three keys to mitigating risk in a search engagement are universal to all engagement risk management: 1. 2. 3. communication communication communication Address issues/risks/questions as soon as possible with project team Require short turnaround times to provide data and make decisions Document and track non-verbalized or un-documented expectations Make sure to put risks on the table during the requirement discussions if it truly is an expectation and success factor Focus on the real critical drivers and make sure they are addressed during engagement For expectations deemed out of scope, realign expectations or create change request
Topology Planning
Architectural Components
There are four key architectural components that need to be understood prior to pursuing any topology design work:
Crawler
The crawl component invokes connectors that are capable of communicating with content sources. Because SharePoint 2013 can crawl different types of content sources (such as SharePoint sites, other Web sites, file shares, Lotus Notes databases, and data exposed by Business Connectivity Services), a specific connector is used to communicate with each type of source.
23
Indexing
The index component performs two main functions: managing documents in the index (received from the content processing component) and responding to queries (from the query component). The index components are tuned for to to allow new documents to be discoverable to query components with very short latency. There is no longer any need to wait for a full crawl before documents are searchable.
Query Processing
The query component is responsible for returning results from the index in response to a query received via the query object model. The query component is also responsible for processing query rules prior to submitting the query to the index component.
Analytic Processing
Analytic processing combines information gleaned during the document crawl, as well as usage information captured as users interact with the search application. These analytics are used to influence the relevance of documents based on user activity.
24
Client Application
Custom
Event Store
Crawl Components
The crawl component uses connectors to traverse each content source, according to crawl rules that an administrator can define. For example, the crawler uses the file connector to connect to file shares by using the FILE:// protocol, and then traverses the folder structure in that content source to retrieve file content and metadata. Similarly, the crawler uses the Web connector to connect to external Web sites by using the HTTP:// or HTTPS:// protocols, and then traverses the Web pages in that content source by following hyperlinks to retrieve Web page content and metadata. The crawl component is responsible for crawling content sources. It delivers crawled items both the actual content as well as their associated metadata to the content processing component. The crawl component invokes connectors or protocol handlers that interact with content sources to retrieve data. Multiple crawl components can be deployed to crawl simultaneously. The crawl component uses one or more crawl databases to temporarily store information about crawled items and to track crawl history. Crawls content based on what is specified in the crawl databases. Add crawl components to address capacity requirements and to increase crawling performance. Typically add 1 crawl component per 10 million items.
Crawl Database
The crawl database contains detailed tracking and historical information about crawled items. This database holds information such as the last crawl time, the last crawl ID and the type of update during the last crawl. Crawls of a single data source can be spread across multiple crawl databases to improve crawling performance. There is no longer a need to assign a single data source host to a single crawl database. Stores the crawl history Manages crawl operations Each crawl database can have one or more crawlers associated with it.
25
Analytics Architecture
The analytics architecture consists of the analytics processing component, analytics reporting database and link database.
The analytics processing component analyzes both types of information. The results are then returned to the content processing component (using a partial update) to be included in the search index. Results from usage analytics is also stored in the analytics reporting database.
Link Database
The link database stores information extracted by the content processing component. In addition, it stores information about search clicks; the number of times people click on a search result from the search result page. This information is stored unprocessed, the analytics processing component performs the analysis. Stores the information extracted by the content processing component and also stores click-through information.
To translate from the language of FAST Search For SharePoint 2010, an index partition can be thought of as a column, and an index replica can be thought of as a row.
26
2.
As a rule of thumb, an index replica should be sized at no more than 10 million documents. This example shows an index configured with 3 index partitions and 3 index replicas.
Index partition 1 Index partition 2
Index partition 3
Index Components
The index component receives processed items from the content processing component and writes those items to an index file. The index component receives queries from the query processing component and provides results sets in return. There are two types of index components: primary index replica and secondary index replica. Each index component (i.e. index replica) generally runs on its own server.
Search Administration
Search administration is composed of the search administration component, and its corresponding database.
Note that the FAST Search For SharePoint 2010 High density index configuration has no direct corollary in SharePoint 2013. (The SharePoint 2013 strategy is to scale out, not scale up)
27
28
Database Server
The database server hosts the four search-related databases: Crawl Database Link Database Search Administration Database Analytics Reporting Database
It can host other SharePoint 2013 databases. As with any other database, it can be mirrored or clustered. To increase performance and capacity, consider adding disks to the database server or adding database servers (depending on the bottleneck).
29
Application Server
Application Server
Crawl Component
Crawl Database
Link Database
In
Index Component
Qu
What is not indicated in this diagram is the fact that the two index components constitute primary and secondary index replicas in the same index partition. Also not indicated is any database mirroring or clustering to provide database availability.
30
Content Capacity
Unlike SharePoint 2010 Enterprise Search, and like FAST Search For SharePoint 2010, search in SharePoint 2013 does NOT put the content of the index into a relational database. The index itself is stored directly in the file system for each Applicatio n Server, With Index. Databases *are* used to store administrative, link, and analytical data as well as detailed tracking and historical information about crawled items. But not the crawled items or content. As a rule of thumb, (and going on the premise that disk is relatively inexpensive) the scale-out strategy for index components means that content capacity can be estimated based on the number of documents in the index. Since 1TB of disk is recommended for each index component, which will support up to 10M documents, simply divide the total required documents by 10M, and multiply by the number of index replicas per index partition to determine overall storage requirements. See TechNet (http://technet.microsoft.com/en-us/library/jj219628.aspx) for more details on server requirements, disk sizing and database requirements for each index component.
Corpus Size
Most customers will estimate their content by citing the size of the database supporting SharePoint. This is not quite sufficient. What is needed is a document, or item, count. Therefore, you must help your customers to determine their total item count before you estimate the architectural requirements outlined in this document. The first pass estimate is to take the database size and divide by an estimated average document size. This does not take into account things like versioning. For those who care to spend the time, the right database queries (against the document table, etc.) will provide a more accurate estimate of the documents to be indexed keeping in mind that only the most recent version of each document is indexed. A more typical and manageable approach is to estimate corpus size rather than measuring it. The steps for estimating corpus size are as follows: 1. 2. 3. Categorize the different content forms, such as files, Web pages, lists items, and database items. Multiply the average size of each content form by the number of items in each form, to obtain size estimates of each content form. Add together all of the size estimates.
Customers must also estimate corpus growth characteristics, based on past growth patterns, and gather expected growth characteristics from analysts and systems management staff in the organization.
Content Characteristics
Although the main governing factor that affects index size is the size of the corpus, the relationship is not a simple one. Most productivity search engagements do not analyze the content characteristics. Most simply estimate the number of documents, and then adjust capacity demands based on discoveries made during the Envisioning, Planning and sometimes, even Build Phase of the engagement. An example of this might be where the team discovers that documents are larger, or smaller, than expected. Frequently, customers will discover that they have more or less documents than they originally expected.
31
Content Versions
Another factor that affects the ratio between corpus size and index size is the versioning strategy in the farm. SharePoint Versioning and Indexing. The SharePoint 2013 indexer only indexes one version of each item, so it is not possible to index all of the versions of files in a document library, or all of the versions of items in a list. Versioned Corpus and Index Ratios. If a corpus is characterized by many versions of items in SharePoint lists or libraries, the ratio of the entire corpus (including all item versions) to the size of the index file is higher than if versioning in SharePoint lists and libraries is disabled. You should draw your customers attention to this if the corpus size measurement is based on content database sizes. Content Access Accounts and Versioning. The content access account affects the versioned content that is being indexed (although it does not affect the ratio between corpus size and index space requirements). SharePoint technologies can maintain multiple versions of a page or document and present specific versions to different users based on their roles. For example, if a user checks out and modifies a published page, and then saves it but does not checked it back in, the next time that she requests the page, she is presented with the saved version. Anyone else who requests the page is presented with the latest published version. Then, if the user makes further changes and checks the page back in and submits it for approval, the next time she requests the page, she is presented with the edited version that is waiting for approval. And any person who is in the approvers role is also presented with that version. However, all other readers are presented with the latest published version. In the same way, when the indexer requests a page or file for indexing purposes, SharePoint
32
Query Capacity
Query capacity is defined by the number of simultaneous queries that the index can support, as indicated in queries per second or QPS. Most intranet/productivity search implementations tend to have fairly low user QPS - <5QPS on average. However, with SharePoint 2013, multiple queries may be executed against the back end index for a single user query. (This is dependent upon things like the query rules that are implemented, etc.) This raises the QPS required for the underlying search engine, and increases the likelihood that additional index replicas will be required for each index partition which is the mechanism for scaling-out query capacity. For planning purposes, you want to determine the average and peak user QPS required of the system, and balance that against the expected query latency (the time for the search to return) that is acceptable. In other words, if its OK that searches t ake longer at peak times, then you can get away with less server hardware. But if you need to handle the peak load without increasing your query latency, then you are likely to need more server hardware. If historical query data is available, that is the most accurate predictor of future usage. It is not un-common for basic intranet, productivity search applications even for some large organizations whose names you would recognize to be measured in queries per day or queries per hour. But you do need to document the requirement.
Crawling/Indexing Capacity
Crawling/Indexing capacity is defined by the number of documents per second that the search engine can ingest, as indicated in: documents per second or DPS. document latency (i.e. how long until a changed or new document is searchable)
This DPS rate defines the time it will take you to perform the initial, bulk crawl of the corpus. Tuning indexing performance for DPS is as much art as science, and requires knowledge of: The source repository performance characteristics. (Is it bound on CPU, disk, memory or network access?) Physical infrastructure (networking, servers, RAM, disk I/O, CPU) The index topology (How many search components? And of which type? Which servers are they on? Which VM Hosts are the VMs on?) The CPU, disk I/O, RAM and network capacity usage of each type of search component The corpus itself (are the documents text based or binary formats, etc.)
Tuning for document latency requires analyzing the needs of the various crawl schedules, targeting the most valuable (& presumably volatile) information for more frequent incremental crawls. SharePoint 2013 search is an entirely new architecture, that supports being able to search for documents immediately after indexing, without having to wait for a full crawl to occur. It also supports continuous crawling which lets you focus on high value, highly volatil e SharePoint data.
Planning Objectives
Using all the information that you have been able to collect thus far, you should be nearly prepared to propose a search architecture that includes the following: The number of servers and server roles required to support search The number & type of search components required to support performance, isolation, and redundancy requirements The number of databases and their association with the search components The number and distribution of index partitions and index replicas across those servers
33
You should also have sufficient information to describe the basic search application interface (including the information architecture) to be supported by the search solution, including: A wire-frame diagram of the search user interface A listing of the managed properties required by that search user interface A listing of the crawled properties by data source, Any unique crawled-property-to-managed-property data mapping requirements
You should also have sufficient information to describe the user communities to be supported by the search solution, including: A description of each community The general search requirements for that user community Any unique search requirements for that user community
You should also have sufficient information to identify any specialized search requirements that call for customization of the search solution, including: Custom data source integration Custom query processing Custom document content processing Custom user interface functionality
Search Migration
SharePoint 2013 provides limited out-of-the-box automated assistance for search migration, but does provide a PowerShell cmdlet interface that makes search migration a good entre for services engagements. Due to the changes in the various underlying search implementations between SharePoint 2010 and SharePoint 2013, customers are able to migrate some configuration information - such as content sources, crawl rules, start addresses, server name mapping, and federated location from SharePoint 2010 to SharePoint 2013 search using a database attach strategy. Some other, but not all, FAST Search for SharePoint 2010 feature configurations are able to be migrated to SharePoint 2013, using 3 custom PowerShell scripts. Considering the major architectural changes to search in SharePoint 2013, there is no direct mapping for either the search topology or the index itself. You cannot use the database attach approach to upgrade any other search databases, such as crawl databases or property databases. (These databases are re-created when you perform a full crawl in the new farm.) Also, the upgrade process does not preserve or upgrade logical components of the SharePoint Server 2010 farm topology. After you perform the upgrade, you must manually re-create a topology as appropriate to meet the requirements of the organization.
Information on migration scripts to address the other feature configurations is pending, as of the time of this writing.
34
Planning Migration
Planning for migration engagement adds the following steps to an overall implementation plan: 1. 2. 3. 4. Analyse the existing use of the feature Document (in detail) the configured items for each migrate-able feature Document the user functionality implemented by each configured items for those features that are not able to be migrated. Determine which features to migrate and which to re-implement from scratch in SharePoint 2013
For those features that you wish to migrate, follow the steps in the Appendix.
35
The supported feature migration paths are indicated in the table below: From To SharePoint 2013 To SharePoint 2013 (SharePoint 2010 mode) (SharePoint 2013 mode) SharePoint 2010 Search Yes In-direct SharePoint 2010 Search + Yes, with some loss of functionalityIn-direct FAST Search For SharePoint Requires custom scripting Requires custom scripting Other SharePoint versions No No Other versions of FAST SearchNo No All other migration paths are out of scope, including anything involving earlier versions of either SharePoint Search or FAST Search, and should be treated as new search implementations for SharePoint 2013.
36
No No
37
Promotions/Demotions
No
No No
Migration Steps
The basic steps in the migration process are: 1. If using FAST Search For SharePoint 2010 search a. Backup databases from the SQL Server 2008 database instance supporting FAST Search For SharePoint 2010 using documented backup procedures: i. Content SSA ii. Admin DB iii. Query SSA b. Restore the databases to a SQL Server 2012 database instance (or SQL Server 2008 R2 for SharePoint 2013) c. Merge the Content SSA, Query SSA and Admin SSA databases into a single Content SSA database i. This requires custom Powershell scripting d. Run the migration tool against that Content SSA to create an intermediary search configuration database in SharePoint 2010 mode i. This is a PowerShell cmdlet restore Search SSA provided by the SharePoint 2013 search product team ii. This also creates the Search SSA in SharePoint 2010 mode e. Create crawled properties and & crawled property categories, and managed properties i. This requires a custom Powershell script If using SharePoint 2010 search a. Backup the Content SSA database out of the SQL Server 2008 database instance supporting FAST Search For SharePoint 2010 using documented backup procedures b. Restore the Content SSA database to a SQL Server 2012 database instance (or SQL Server 2008 R2 for SharePoint 2013) At this point, the SharePoint 2010 mode Search SSA has only legacy SharePoint search functionality. a. It does not contain advanced (read: FAST Search For SharePoint 2010) functionality, so we (FAST) LOSE functionality. b. The search center DOES operate, but only with SP Search functionality (i.e. without FAST Search For SharePoint 2010 functionality) c. Synonyms are only one-way, and no longer affect the query. They only trigger Best Bets d. Visual Best Bets turn into regular Best Bets e. Promotion & Demotion of documents does not function To convert from SharePoint 2010 mode to SharePoint 2013 mode, you have to run another Powershell cmdlet to convert the SharePoint Site a. Convert each SharePoint Site (CONTENT SITE!) from SharePoint 2010 mode to SharePoint 2013 mode i. This actually changes the underlying DB tables to support full SharePoint 2013 fun()
2.
3.
4.
38
5.
39