The site-level search box (callout 2) is a text box on the top-right corner of Web site pages in which users can type their search queries. After users type a query, they click the Go Search button (callout 3) to run the query. Advanced users can click the Advanced Search link (callout 4) to use the Advanced Search page to construct queries. Information about the Advanced Search page is provided later in this article.

The first thing you might expect users to ask when looking at a search box in a user interface is, "What body of content will my query be run against?" The Search Scope list to the left of the search box (callout 1) specifies the body of information in the content index that the query will be run against.

Note:
Search scopes, also referred to as scopes, define the items in the index against which a search query is run. The scope determines, in part, what items are displayed on the search page for a particular query.

This enables users to perform queries against subsets of content in the content index, which improves the relevance of their search results.

The search user interface at the list and library levels looks and functions the same as the site-level search user interface, except that an additional default scope, called This List, is available. The list-level search box is at the top-right corner of each list and library in all site collections. The Search Scope list is set to the All Sites scope by default, but users can select another scope from the list.

The Search Center provides a centralized and highly customizable user interface in which users can perform search queries. The Search Center consists of a search box for entering search queries, and a link to an Advanced Search page so users can construct advanced search queries. By default, the search box is set to the All Sites scope so users search across all content in the index. However the People scope, used to search for people in your organization, is also available on a separate tab. Administrators can choose to add tabs and associate them with custom scopes that users can use to query over different subsets of content.

Users go to the Search Center by clicking the Search tab on the top link bar (callout 1). Similar to the search box at the site-level, the search box in the Search Center (callout 3) is a text box in which users can type their search queries. Users then click the Go Search button (callout 4) to run their queries. By default, the All Sites scope is selected but a user can select another available tab, such as the People tab, to use a different scope to search.

Advanced users can click the Advanced Search link (callout 5) to use the Advanced Search page to construct queries. The Search Center uses the same Advanced Search page as the site-level search box. Information about the Advanced Search page is provided later in this article.

Unlike the site-level search box, the search box in the Search Center does not have an adjoining Search Scope list to the left of it, by default, for selecting different scopes. Instead, users click the tab (callout 2) that corresponds to the scope with which they want to search. Office SharePoint Server 2007 provides two default scopes in the Search Center: All Sites and People.

Note:
The site owner of the Search Center site can add an adjoining Search Scope list to a search box by editing the Search Box Web part.

The following table shows the default scopes that are available in Office SharePoint Server 2007 and the levels at which they are available.

Note:
The All Sites scope is the default scope at all levels in each site collection. However, users can select any available scope.

During content and site structure planning for a large organization, it is determined that human resources is a large division that delivers content relevant to all employees on several SharePoint sites and line-of-business applications. Therefore, the SSP administrator creates a shared scope for content relating to human resources.

The site collection administrator of the human resources site uses that shared scope and creates additional scopes at the site collection level. The site-collection-level scopes are for company policies and new hire information because those are core concepts that are relevant for the site collection. The site-collection-level scopes do not make sense as shared scopes because people searching in other site collections are unlikely to want scopes that are so specific.

Site collection administrators can either use the shared scopes as defined by the shared services administrator or copy the shared scopes they want to use in their site collection and modify them. They can then select the display groups in which to include each scope, such as the search box drop-down list and the Advanced Search page.

Note:
Site collection administrators cannot modify or delete shared scopes, but they can copy a shared scope and then modify the copy.

To summarize, SSP and site collection administrators first create the scopes that are needed for their organization and then a site collection administrator associates them with display groups to make them available to the search boxes that are associated with those display groups. Site collection administrators can associate one or more scopes with a display group. More information about display groups is presented later in this article.

When planning search scopes, you look at your information architecture to identify broad content sets on which people are likely to want to search. (For more information, see Determine the information architecture of your site.) Some of these content sets will span the information architecture across many sites, and some will span subsets of information within site collections. Site collection administrators decide whether to implement shared scopes or site-collection-level scopes for a particular site collection based on the needs of the users of that site collection. Content that is only relevant within certain site collections should be left for scope planning at the site collection level.

Because certain site collections are tied to a particular SSP, all settings for a particular SSP affect all of its associated sites. The SSP administrator manages shared scopes for all sites that use the same SSP. SSP administrators can perform the following tasks:

• Create and edit shared scopes.

• Add scope rules to shared scopes.

• Delete shared scopes.

• Refresh changes made to scopes.

Shared scopes are visible and available for use by administrators for all site collections that are using the same set of shared services.

The following shared scopes are automatically created for each SSP and are available on the Search Center, by default:

• All Sites

• People

During planning, each site collection administrator will want to create scopes based on the information architecture within the site. They can choose to create new scopes, make a copy of shared scopes (a copy of a shared scope becomes a site collection level scope), or both. For example, site collection administrators can add scopes by selecting shared scopes that are useful for people using their site collection, and then supplementing those scopes by creating scopes for the site collection.

The following table shows the actions related to scopes that can be performed by site collection administrators.

Site collection administrators cannot create or add matching rules to shared scopes directly, though they can copy a shared scope as a site-collection scope and modify the copy.

Note:
After a site collection administrator copies a shared scope, the copy becomes a site-collection-level scope that the site collection administrator can use to perform any of the actions that they can perform on any other site-collection-level scope.

When creating or editing a new site-collection-level scope, you specify the following:

• Unique title.

• Description for the scope (optionally).

• Display group, sometimes called scope group. Site collection administrators can assign scopes to display groups to determine where they appear on the site. By default, Office SharePoint Server 2007 provides display groups for the search box drop-down list and the Advanced Search page. Site collection administrators can assign one or more scopes to any display group.

• Results page. You can choose to use the default search results page to display search results when this scope is used or specify a different page. Note that if you choose to use a different page, you must first create that search results page.

No site collection level scopes exist, by default, but each site collection has access to all shared scopes.

Display groups provide a way to assign scopes to a particular search box. Site collection administrators have several options for configuring the existing display groups or they can choose to create one or more new display groups. Typically, a site owner identifies a particular need for a display group. For example, users of a particular team site might frequently need to search for content that is scattered across multiple document libraries. To narrow the body of content they are searching over, they currently must perform separate searches in different search boxes —for example, in the search box of each library — or construct an advanced query to filter the search results. To provide users with an easier way to perform this frequent search, the site collection administrator creates a display group and assigns the appropriate scope to it. Site Owners can then associate this display group with a particular search box — for example, a search box on a custom search page on the site. Users then use that search box to search over the content defined by the scope, in this case, the document libraries. Office SharePoint Server 2007 provides two display groups, by default:

• Search Dropdown   The All Sites and People scopes are assigned to this display group and it is used by the search box, by default.

• Advanced Search   The All Sites scope is assigned to this display group and it is used by the search box on the Advanced Search page, by default.

Site collection administrators can perform the following actions:

• Add scopes to any display group.

• Remove scopes from any display group.

• Create new display groups and assign the scopes they want to them.

• Change the order in which scopes appear in the Search Scopes list.

• Specify which scope is selected, by default, in the Search Scopes list.

Site owners can perform the following:

• Assign different display groups to the search box and the Advanced Search page in the Search Center site.

• Create new search pages using the Search Box and Advanced Search Box Web parts and assign the display group or groups that they want to use.

You define a scope by adding scope rules to the scope. Scope rules define what content to associate with the scope and what content to not associate with it. Scope rules added to a particular scope define the extent of the scope.

Each scope rule is based upon a particular scope rule type, which defines the properties, locations, and sources of content. The following table lists the scope rule types that are available to shared search scopes and site-collection-level search scopes.

The All Content scope rule type is the simplest because it associates all crawled content with the scope. For each of the other three scope rule types, an SSP administrator can specify the behavior of the scope rule which determines the content to associate with the scope. These behaviors are described in the following list:

• Include   Items matching this rule appear in search results unless another rule removes them. When combining rules, this behavior is similar to the OR logical operator.

• Require   Items matching other rules must also match this rule to appear in search results. This behavior is equivalent to the AND logical operator.

• Exclude   Items matching this rule are excluded from search results even if they match other rules. This behavior is equivalent to the AND NOT logical operator.

Scopes will often be based on a single scope rule. However, there are good reasons to use scopes with multiple rules. You can create scopes based around a specific theme or conceptually-related set of content. To do this, you can include and exclude several locations, properties, or a combination of locations and properties that are conceptually related. The logical combination of rules determines the content that is either included or excluded from the scope.

Using scope rules that are based on location

Using scope rules that are based on managed properties

Using scope rules that are based on a content source

Using the All Content scope rule type

Excluding content using a scope rule with the exclude behavior

Contoso Corporation has an IT services division, a customer service division, and a sales division. Each of these three divisions has its own site collection, and there is also a central portal site collection for company news and human resources information. All crawled content is indexed into one content index.

Because the content for each division is distinct, the SSP administrator creates a separate content source for each of the three divisional site collections so each can be crawled on a different schedule. The SSP administrator also creates a fourth content source used for crawling the central portal site collection that contains the human resources and company news content.

By default, all content that has been indexed from each of the site collections is included in the All Sites shared scope that is available to all site collections. The SSP administrator creates a separate shared scope for each divisional site collection and then creates a scope rule for each shared scope that includes the appropriate content source for each site collection's shared scope.

For example, for the Customer Service division, the SSP administrator creates a scope called Customer Service, and then adds a scope rule to that scope. When adding the scope rule, the SSP administrator selects Content Source as the scope rule type, selects the Customer Service content source from the list of available content sources, and then selects the include behavior to include all items crawled using that content source.

Note:
All existing content sources appear in the Content Source list on the Add Scope Rule page when creating a scope rule based on a content source.

The following table lists the shared scopes that have been created by the SSP administrator at Contoso Corporation.

In addition to the shared scopes created by the SSP administrator, the default All Sites scope includes all of the crawled content in the index. The All Sites shared scope is available, by default, to all site collections.

The site collection administrator for each division decides to use the All Sites shared scope and the shared scope that contains the content for their site collection, but none of them plans to use the Central Portal scope, even though it is a shared scope. That option will only be available from the Search Scope drop-down list in the central portal site collection.

The site collection administrator for each division makes copies of the shared scope that the SSP administrator created for their site collection. (The copies of the shared scope become site collection-level scopes.) Each site collection administrator then adds scope rules to the site collection-level scopes to target only the most important set of content that their users want to query against when using those scopes.

For example, the site collection administrator for the sales site collection creates scopes for content related to each product line, based on the managed properties of marketing documents and other content, and the location of related team sites and document libraries.

When content is crawled, the crawler also crawls the metadata properties associated with that content. Crawled properties include the metadata of content that is stored in files, databases, and line-of-business applications used by your organization. Crawled properties can represent different kinds of information, such as author, title, and e-mail address.

In previous versions of Microsoft SharePoint Products and Technologies, you could reduce property duplication by mapping some properties to other common properties, but many properties confused search results because they weren't relevant. Thus, relevant properties were hard to find amid the many irrelevant properties.

Office SharePoint Server 2007 mitigates this confusion by enabling SSP administrators to create managed properties. They can then map crawled properties, which are the properties that the crawler collects and adds to the property store when crawling content, to managed properties that are used by search queries.

The relationship between managed properties and crawled properties is a simple but powerful one. SSP administrators can map one or more crawled properties (the properties discovered by the crawler) with managed properties (properties that can be used in scope rules and queries. This mapping is important because many crawled properties contain the same kind of metadata and crawled properties often have names that are not intuitive. For example, by default, the crawled properties named "Mail:6" and "Office:4" are mapped to a managed property named Author. This is because the values of these two crawled properties contain the name of the author. This mapping of crawled properties to managed properties eases administration and benefits users. Administrators benefit because they have fewer properties to work with when creating scopes. End users that construct advanced queries in the search box benefit because they also have fewer and more intuitive property names to remember.

Managed properties have the following benefits:

• Users can use managed properties to construct queries in the search box that filter search results.

• You can use properties on the Advanced Search page to enable end users to easily filter search results.

• Site owners can customize the Advanced Search page to use different managed properties.

• SSP and site collection administrators can create custom scopes with rules that filter search results based on queries. End users benefit from advanced property-based queries without the need to learn how to construct an advanced query.

Several managed properties are created and mapped to crawled properties, by default. SSP administrators can map additional crawled properties to existing managed properties and create new managed properties.

For the value of crawled properties to affect a search query, the crawled properties must be mapped to a managed property and the user must perform a search against that managed property. Including the values of too many crawled properties can have a negative effect on search relevance and performance.

If you want to use the manage property in a scope, you must make the managed property available to scopes. However, you do not need to do this to use the managed property on the Advanced Search page or as part of a query in a search box.

Administrators planning the initial deployment of Office SharePoint Server 2007 should record the initial set of managed properties planned for the search service for every SSP used in the deployment.

Many of these crawled properties can be found by looking at the properties of business data applications and the properties displayed in applications for content types such as Microsoft Office Word or Office Excel documents.

If you have access to a test server, you can crawl high-priority content and use the crawled properties that appear to help with planning.

You can make the content on your site easier to find by carefully planning your managed properties and how you implement them. When planning your deployment, we recommend that you keep the number of managed properties to a minimum. This means carefully considering what properties are most useful for your organization and deploying those as a starting point. You can always create additional managed properties after deployment, if needed.

One practical way to identify potential managed properties is to examine your existing content and its high-priority metadata. If you have access to a test farm prior to active deployment of Office SharePoint Server 2007, you can crawl your content and see what crawled properties appear, and use those properties to identify part of your information architecture. However, most organizations will benefit from planning information architecture on paper before staging a deployment, because it can help to focus your planning and identify content and processes that are not as well-organized as they could be.

The key to creating a useful set of managed properties is to determine the most important concepts and find properties in your content that you can map to managed properties that enable users to find relevant content when searching. Mapping more properties increases the size of the search database, and reduces performance accordingly, so it's a good idea to map properties only when you are confident that the mapping is relevant.

It is difficult to discover properties of content without first crawling content. Therefore, it is best to wait to plan managed properties until you already have a good idea of the content of each site collection. Then, on a test server, you can crawl all that content so that you have a list of crawled properties to compare against your information architecture when creating managed properties. It can be difficult to map properties even after crawling content because it is difficult to identify the content type or application that uses the property. If you are unsure of the nature and content of a particular property, you might want to set up a mapping in a test environment and experiment with searches over this property.

Many of the most useful managed properties are automatically created when Office SharePoint Server 2007 is installed. Use these managed properties as a starting point when planning your other managed properties. The automatically created properties include:

• Author

• Description

• Site Name

• Type

• File Size

• Last Modified Date

• URL

• Title

Keep in mind that in order to effectively search by using properties, the crawled properties must first be assigned values. For example, if you have a document that has a property that maps to a managed property called Author, and no value is assigned to that property on that document, the document will not be displayed in search results when users query using the Author property for a particular author.

Avoid duplicating managed properties

Some properties are fairly basic and might appear as different properties in different types of content. Examples include the Author and Title properties for documents.

The most important thing you can do with these basic properties during planning is to reduce duplication by creating one set of managed properties and mapping the crawled properties with the same meaning to properties in the set of managed properties. In the case of the Author property, you can map each unique appearance of a crawled property for authors with a single Author managed property.

You can map one or more crawled properties to one or more managed properties.

Tip:
Adding each Author property as a separate managed property doesn't make sense, because it adds additional managed properties to the database without simplifying the user experience.

You can choose to prioritize multiple crawled properties so that if more than one property is found during crawling, only the value of the highest priority property is used for queries using the managed property or properties. If you don't prioritize crawled properties, values for all crawled properties mapped to the managed property are used for queries, so that the managed property becomes multi-valued. This means the search result returns results for all content that contains values for any of the mapped properties that match the query. A sensible approach for a single-value property is to choose the most common crawled property as the managed property, and then prioritize mapped properties by how often they occur. It is not always easy to determine which property is crawled most often, but one strategy is to prioritize properties that you know are associated with commonly used applications.

Be careful when mapping properties that you do not map poorly matched or irrelevant properties because imprecise mappings can actually reduce the relevance of search results. If possible, test searches for managed properties before initial deployment, and plan to review usage data for search queries during normal operations to fine tune the properties you have mapped.

Add properties to present key concepts in the information architecture

As part of business data search planning, SSP administrators must map the properties of business applications to managed properties. Those properties must be selected as managed properties for business data for an application to appear in search results. The customer service example described previously illustrates mapping business data properties to managed properties used by search. For more information about business data planning, see Plan for business data search.

Each managed property can be exposed as a property for search scope rules. For more information about planning search scopes, see the "Plan search scopes" section earlier in this article.

Office SharePoint Server 2007 uses property categories to group crawled properties based on the properties that are discovered when the documents are crawled.

For information about property categories associated with file types, see Managing Metadata (http://go.microsoft.com/fwlink/?LinkID=81062). For more information about crawling content, see Plan to crawl content (Office SharePoint Server).

A site collection administrator knows that end users are having difficulty finding the calendar that is used to track when team members are out of the office. Users report that when they search for the calendar, their queries produce several pages of irrelevant search results, and that they give up after looking through the first few search results pages.

The site collection administrator decides to create a keyword named "oof" containing the following items:

• Keyword definition: This is the acronym we use to mean out of office.

• Synonym: time off

• Best bet: URL to the calendar and a description for the best bet.

The site collection administrator then asks the end users to use this new keyword "oof" or its synonym "time off" when searching for the calendar.

The following figure shows an example of the default search results page that end users see when searching on the keyword "oof" from the Search Center in this scenario. Note that best bets and keyword descriptions only appear on search results pages for searches that are run using the Search Center, by default.

In the figure above, the query that the end user ran is shown (callout 1). The keyword highlighting feature also shows the keywords in the content as bold text (callout 2). The description that the site collection administrator assigned to this keyword appears in the top-right corner of the search results page, by default (callout 3). Each keyword can be associated with a definition and you can include a URL in definitions. Accordingly, it is a good idea to:

• Identify definition sources during planning.

• Include a separate step during planning to design a glossary of all definitions used by keywords in each site collection.

• Create some keywords for the sole purpose of associating the keywords with a definition.

The Best Bet (callout 4) appears directly below the keyword description, if there is one. A best bet is more than a URL. It also has a title and can optionally have a description. In this example, the site collection administrator named the best bet "Out of Office page". The description that the administrator assigned to the best bet appears directly below its name, and then the URL of the best bet appears below that.

Specific documents, sites, and people with expertise in the concept associated with a search term are common uses of best bets. It is important to consider the title and description of each best bet during content planning to increase the relevance and usability of each best bet. You can associate up to 25 best bets with each keyword in the administration user interface, and many more with the object model, but it is a good idea to not overuse best bets. Effective content planning can help you identify an appropriate number of best bets for each keyword that balances the number of search results with search relevancy.

Note:
Because the URL of a best bet is hard coded by the site collection administrator, it can be any URL. It can even point to content that has not been crawled.

You can use the same best bet for more than one keyword. If the best bet already exists, you can add it to any keyword without having to enter the properties for the best bet again and possibly introduce redundant best bets. You can also simultaneously change the URL and description for that best bet for all keywords that use it. This is particularly useful if you are using a test site during planning and before initial deployment.

Synonyms are one or more words that closely relate to a particular keyword. For example, an effective synonym for the keyword "car" might be "auto", "automobile", or "SUV". These are all effective synonyms for that particular keyword because you would expect that some users that are searching for cars to type one of those words into the search box instead. Site collection administrators can define one or more synonyms for each keyword. The purpose of a synonym is to display the same keyword definition and best bet on the search results page that is displayed when using the keyword. Following the previous example, if end users run a search query using the synonym "out of office" they see the same keyword description and best bets that they see when they run the search query using the keyword "oof." The difference, however, is that they see search results for only content that contains the words "out of office" instead of content that contains the word "oof".

Synonyms are useful when several search terms are used for the same concept and content, so that search results are consolidated and not scattered across several search terms. The list that is updated when a site collection administrator creates keywords and adds synonyms is called a thesaurus. The thesaurus for Office SharePoint Server 2007 is compatible with the thesaurus for Microsoft Office SharePoint Portal Server 2003.

You can analyze the content in your information architecture to compile a list of terms with which to create keywords that you can associate with specific and highly relevant content.

Relevant content is anything specific that you want people to see first or most prominently when they search using a specific keyword. Examples of relevant content for each major business concept or content area include:

• Documents

• Sites

• People

• Definitions

• Approved or official terms that mean the same thing, but were not included in the search query.

Associating keywords with a best bet is helpful to encourage people to view the key documents that are needed to collaborate on key business processes. For example, a business might have a special template for expense reports, and a keyword "expense report" that promotes that template to the top of search results. Without that keyword, each employee might spend several minutes asking their colleagues for the appropriate URL or browsing the company Web site. With the keyword associated with the URL to the expense report template as a best bet, employees can quickly locate the template.

Keywords for sites are helpful for identifying the location of sites for relevant information in a large organization. For example, "holidays" could be a keyword associated with a best bet that contains the URL of the human resources site that contains information about paid time off for employees. Ideally, the best bet could contain the URL of the exact page that provides company holiday information.

Keywords that help people find other people encourage collaboration between people across the organization who have important knowledge to share, or just about important people in the company. For example, you can associate a title such as "CEO" with the chief executive officer for a company, or you can make a person's My Site a best bet for a keyword relating to their organization or area of expertise, such as "chemistry department."

Unlike previous versions of Office SharePoint Portal Server, keywords and best bets are not affected by security permissions, and all readers on the site collection can see all best bets and keywords for that site collection that appear in search results. Users who do not have permissions to see the page to which a best bet is linked cannot go to the page. However, they can see the description of the best bet on the search results page and the URLs to the content. This could expose information that some users were not intended to see.

Keywords are meant to provide high-priority results for all users.

If you want to target content to certain users based on their permissions, you can use audiences and targeted Web Parts in the appropriate places on the site collection.

It is important to plan keywords in advance to help ensure consistency of keywords across your organization. Even though keywords are implemented at the site collection level, you should ensure consistency of keywords across site collections whenever possible.

Example of good keyword planning

Contoso Corporation has two site collections, one for the sales and one for the marketing department. A different site collection administrator is assigned to each. Because users of these site collections are spending too much time finding the corporation's customer list, these two site collection administrators decide that they need to create a keyword for their site collection and associate a best bet with that keyword that links users directly to the customer list.

To ensure that end users have a consistent experience on both site collections, the two site collection administrators collaborate to decide how the keyword and best bet should be defined.

Tip:
Planning for consistency of keywords across your organization requires good collaboration among site collection administrators. Whenever possible, ensure that keywords and best bets are consistent across site collections.

By avoiding the use of different keywords and best bets across site collections that point to the same content, you can avoid end-user confusion. For example, if the site collection administrator of the sales site collection had created a keyword named "super list" and the site collection administrators of the marketing site collection had created a keyword named "master list", end users who use both site collections would become confused when their keyword searches do not consistently display the best bet they expect to see on the search results page. That is, an employee who primarily uses the sales site collection is accustomed to searching using the keyword "super list" and would expect it to work from either site collection.

In small organizations, the content planning team is likely to be small and organized around a single site collection, and planning for keywords might be organized by only one or two people. In large organizations, on the other hand, a larger planning team can be helpful. You should include business planners and administrators at each level to make sure all business needs are addressed.

Best bets appear in search results even if the content hasn't been crawled. This is another reason to plan keywords during initial deployment, so that high-priority content can be available in the early stages of a deployment before all content sources have been crawled. In rare cases where content cannot be crawled because search is missing a relevant IFilter or for any other technical reason, you can use best bets to make the content easier to find even though it hasn't been crawled.

Key people at each level of the organization plan keywords for their site collections. Those people use the same overall content plan, adapted for the content on the site collections that they are planning. When planning keywords, which starts before deployment and continues in waves after deployment, each set of content planners can communicate with each other to keep consistency in the overall plan.

Not all keywords will be planned before deployment. The role of your content planning teams is to identify the high-priority concepts that are most relevant to search queries in your organization, so that search queries are relevant to users from the first day of your deployment. The planning team can identify a contact person for each keyword who may or may not be someone on the planning team. After deployment, site collection administrators can expand the keyword list after identifying common search terms in the query logs.

In the planning phase, keyword list managers should consider how keywords match to queries. Keywords must match the complete string of search terms exactly, and must not use special syntax such as a plus sign (+) and a minus sign (-) when searching for content in lists. This prevents the return of multiple lists of keywords for the same search query, which streamlines search results.

The details of keyword management are mostly relevant to the daily operations of your site collections, but there are some aspects of administration that are worth considering when planning your deployment. Specifically the optional contact and publishing properties that site collection administrators can assign to properties.

Tip:
The more planning you do before deployment, the less management will be needed during day to day operations.

In addition to the properties listed in the "Plan keywords, best bets, and synonyms" section earlier in this article, each has the following optional properties:

• Start, end (expiration), and review dates

• Contact

Keywords can be required to go through approval before they affect search results, and can also be set to start or expire after a certain amount of time. The high-priority keywords identified during initial planning are unlikely to be temporary, except for content that is relevant to people using a site collection during the initial deployment.

The contact for each keyword is the person who should be contacted when a keyword expires, if it is set to expire. Content planners for each site collection should consider who is going to be managing keywords after the initial deployment, and include at least some of those people in the planning process at the site collection level.

However, part of the planning process is anticipating who will make decisions about keywords in the future. Making those decisions during the planning process can improve the transition to regular operations of the site collection, and promote consistent and efficient use of keywords in the future.

By using the object model, you can also import and export keywords between site collections as an Excel spreadsheet, so if some best bets apply to other site collections, you can plan once and deploy on all relevant site collections. This also allows keyword managers for a site collection at the divisional or project level to suggest best bets for a central site collection in a shared services environment.

For more information about managing keywords, see the Operations Guide for Office SharePoint Server 2007.