This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious.  No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft, Access, Active Directory, Backstage, Excel, Groove, Hotmail, InfoPath, Internet Explorer, Outlook, PerformancePoint, PowerPoint, SharePoint, Silverlight, Windows, Windows Live, Windows Mobile, Windows PowerShell, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

Contents

If you have a plotter, you can print these posters in their full size. If you don’t have plotter, use the following steps to print on smaller paper.

Print posters on smaller paper

Site and solution planning (SharePoint Foundation 2010)

This section describes how to plan your site and solution components in a Microsoft SharePoint Foundation 2010 environment.

Fundamental site planning (SharePoint Foundation 2010)

This section provides information that helps IT pros plan sites that use Microsoft SharePoint Foundation 2010 features.

The effectiveness of a site or a group of sites depends on many factors, but one of the most important factors is the ability to predictably locate the site and the content that you need within the site. The structure of a site or a group of sites and the navigation inside and among sites are important for helping users find and share information and work together.

In this section:

Sites and site collections overview (SharePoint Foundation 2010)

A Microsoft SharePoint Foundation 2010 site collection is a hierarchical site structure that is made up of one top-level site and any sites below it. This article describes site collections and sites and contains information about the site templates that are used to create sites in SharePoint Foundation 2010.

In this article:

The sites in a site collection have shared administration settings, common navigation, and other common features and elements. Each site collection contains a top-level site and (usually) one or more sites below it in a hierarchical structure.

You must group your site’s content and features into a site collection. This provides the following benefits:

    For site designers, a site collection’s galleries and libraries (such as the master page gallery or the site collection images library) provide a means for creating a unified, branded user experience across all sites in the site collection.

    For site collection administrators, a site collection provides a unified mechanism and scope for administration. For example, security, policies, and features can be managed for a whole site collection; Site Collection Web Analytics Reports, audit log reports, and other data can help administrators track site collection security and performance.

    For farm administrators, site collections provide scalability for growth based on how much content is stored. Because each site collection can use a unique content database, administrators can easily move them to separate servers.

    For site authors, a site collection’s shared site columns, content types, Web Parts, authoring resources, workflows, and other features provide a consistent authoring environment.

    For site users, a site collection’s unified navigation, branding, and search tools provide a unified Web site experience.

A site collection consists of a top-level site and one or more sites below it. Each top-level site and any sites below it in the site structure are based on a site template and can have other unique settings and unique content. Partition your site collection content into separate sites to obtain finer control of the appearance, content, and features of the various pages in your site collection. The following list includes site features that you can configure uniquely:

The following section contains information about the site templates that are included in SharePoint Foundation 2010. Although you can use a site template with its default configuration, you can also change the site’s default settings by using the site administration pages, and then saving the site as a new template. In addition, you can modify a template’s design and features by using Microsoft SharePoint Designer 2010 or Microsoft Visual Studio 2010.

The following table lists every site template, describes the purpose of each, and indicates whether the template is available at the site collection level, site level, or both. The category that is used to group the templates might be different, depending on the level at which a site is created.

• See Also
  

In general, you plan your sites and site collections in the following order:

    Determine the number and types of top-level sites and any sites below them in the hierarchy that are needed.

    Determine the number and types of site collections into which the sites will be organized.

The first step in planning a solution that is based on SharePoint Foundation 2010 is to determine the types of sites your organization and its customers need. Determining the types of sites affects later planning decisions, such as where the sites will be implemented in your server topology, what features to plan for each site, how processes that span multiple sites are implemented, and how information is made available across one or more sites. This section contains information about how to plan different kinds of sites.

Plan the basic sites that you need based on the scale and structure of your organization. Each of these sites can contain information that is needed for a project or division within your larger organization, and each will link to collaboration sites that are relevant to that project or division. Some sites for larger divisions or projects will also aggregate information that is found on all the smaller sites that are devoted to smaller divisions or projects.

Use the following guidelines when you plan sites that are based on your organizational structure:

Divisional or team sites   Plan to create one site for a small organization or one site for every division or project of 50–100 people in a medium to large organization. In large organizations, there might be several levels of sites, with each site focusing on the content that is created and managed at its level of the organization.

You can design a site for members of your organization to collaborate on content related to your business or organizational goals. These can be self-contained or they can work with other sites as part of a publishing process. Often, these sites will have a mixture of collaborative content that is used internally and content that is intended for publication to an audience.

Rollup sites   A rollup site contains general cross-organization content. It makes it possible for users across divisions to find information, experts, and access to organization-wide processes. It often contains sites that are related to the overall organizational information architecture and that are usually mapped to the structure of the divisional or project sites. For each organization, plan to create a centralized rollup site that uses an aggregated view of all related sites.

An application site organizes team processes and provides mechanisms for running them. Application sites often include digital dashboards and other features to view and manipulate data that is related to the site’s purpose. The information that is presented in an application site usually comes from diverse sources, such as databases or other SharePoint sites.

For example, the human resources organization in an organization could design an application site to provide employees with:

    Access to general information, such as employee handbooks and career opportunities.

    Ways to do common tasks, such as submitting timecards and expense reports.

    Dashboards to view personalized information, such as an employee’s salary and benefits history.

As another example, the internal technical support group in an organization could design a Help Desk application site to provide technical support to members of the organization. Features of the application site could include the following:

    Access to a knowledge base of past support incidents and best-practices documentation.

    Ways to do common tasks, such as starting a support incident or reviewing the status of an ongoing incident.

    Integration with communications features that support online meetings and discussions.

    Personalized views of data. For example, support managers could view dashboards that provide views of their team members’ productivity and customer satisfaction ratings. Support engineers could view their current unresolved incidents.

Internet presence sites are customer-facing sites. They are usually branded and are characterized by consistent stylistic elements, such as colors, fonts, and logos in addition to structural elements such as navigation features and the structure of site pages. Although the appearance of an Internet presence site is tightly controlled, the content of the site can be dynamic and can frequently change.

For example, a corporate Internet presence site communicates important company information to customers, partners, investors, and potential employees. This includes descriptions of products and services, company news, annual reports, public filings, and job openings. As another example, an online news Internet site provides frequently updated information, together with interactive features such as stock tickers and blogs.

You can make it possible for team members to create other sites, such as Document Workspace sites, when they collaborate on documents and other projects. Similarly, you can give users of an Internet site access to collaboration sites as part of a Web-based service. For example, you can give them permissions to create Meeting Workspace sites and participate in online meetings as part of their experience of using your site.

After you determine what types of sites your solution requires, the next step is to plan how these sites are implemented across site collections. A site collection is a hierarchical set of sites that can be managed together. Sites in a site collection have common features, such as shared permissions, galleries for templates, content types, and Web Parts, and they often share a common navigation. A site is often implemented as a site collection with the top-level site as the home page of the site collection.

In general, when you plan a solution that is based on SharePoint Foundation 2010, put the following kinds of sites in separate site collections:

    Internet sites (staging)

    Internet sites (production)

    All team sites related to a divisional site or Internet site

All sites in a site collection are stored together in the same SQL database. This can potentially affect site and server performance, depending on how your site collections and sites are structured, and depending on the purpose of the sites. Be aware of the following limits when you plan how to allocate your content across one or more site collections:

    Keep extremely active sites in separate site collections. For example, a knowledge base site on the Internet that allows anonymous browsing could generate lots of database activity. If other sites use the same database, their performance could be affected. By putting the knowledge base site in a separate site collection with its own database, you can make resources available for other sites that no longer have to compete with it for database resources.

    Because all content in a site collection is stored in the same content database, the performance of database operations — such as backing up and restoring content — will depend on the amount of content across the site collection; the size of the database; the speed of the servers hosting the database; and other factors. Depending on the amount of content and the configuration of the database, you might have to divide a site collection into multiple site collections to meet service-level agreements for backing up and restoring, throughput, or other requirements. It is beyond the scope of this article to provide prescriptive guidance about how to manage the size and performance of databases.

    Creating too many sites below a top-level site in a site collection might affect performance and usability. Limit the number of sites of any top-level site to a maximum of 2,000.

Navigation controls can be displayed on master pages, and—by using Web Part zones—directly in a page’s content.

SharePoint Foundation 2010 bases its navigation model on the hierarchical structure of the site collection. By using the navigation features, you can link to the following:

    Sites below the current site

    A site’s peer sites

    Sites higher in the site structure

    Web pages in a site

Additionally, you can create links to arbitrary locations, such as to an external Web site.

Navigation links in SharePoint Foundation 2010 are security-sensitive. If a site user does not have permissions to a SharePoint Foundation 2010 site or page that is linked from the site navigation, the user cannot see the link. Other content which has had links manually added to the navigation are still visible to users.

SharePoint Foundation 2010 navigation is based on the ASP.NET features in the .NET Framework version 3.5, which you can use to customize the following:

    The site map provider.

    The data source, which anchors and filters the structure that is provided by the site map provider.

    The menus, which control the visual appearance of the navigation elements and how deep a hierarchy to display.

A master page defines the outer frame of the Web pages in a site. Master pages contain the elements that you want all pages in your site to share, such as branding information; common commands, such as Search; and navigation elements that you want to be available throughout the site. This includes top link bar navigation, and Quick Launch navigation.

Master pages also provide the menu style of the navigation controls. You can configure master-page menu style by using Microsoft SharePoint Designer 2010 or Microsoft Visual Studio 2010.

The top link bar is a navigation menu which typically links to the sites that are one level below the current site in a site hierarchy. It is common for the top link bar to appear at the top of each page in a site. By default, all sites that are one level below the current site are added to the top link bar, and each site has its own unique top link bar for navigation. Site administrators can customize the navigation for a specific site by removing a site from the top link bar. They can also configure the top link bar so that only the home page link is shown and no other sites in the site hierarchy are displayed.

Site administrators can choose to inherit the top link bar from the parent site. This approach allows users to switch from one site to another from anywhere within the site collection, by allowing the top link bar to stay the same in all the sites in the site collection. For example, an Internet site that is used to market an organization’s products could have a site for each line of its products. By displaying each product’s site in the top link bar of each site, site designers can make it possible for users to easily switch from one site to another without having to return to the site home page.

Other top link bar configuration features include the following:

    Linking to specified external sites.

    Linking to specified sites or pages that are anywhere in the site.

    Manually sorting the items on the top link bar.

All top link bar features, such as linking to external, can be defined uniquely for each site.

By using SharePoint Designer 2010 or Visual Studio 2010, you can additionally customize the appearance and functionality of the top link bar. For example, you can do the following:

    Customize the cascading style sheets to change the appearance of the top link bar.

    Modify the data source, for example to decrease the number of sites that are displayed in the top link bar.

The Quick Launch navigation typically highlights the important content in the current site, such as lists and libraries. It is common for Quick Launch navigation to appear on the left of each page in a site.

Quick Launch navigation configuration features include the following:

    Linking to specific external sites or to pages in the current site.

    Organizing links under headings.

    Manually sorting the items in the Quick Launch navigation.

Just as you customize the top link bar, you can also customize the appearance and functionality of Quick Launch navigation by using SharePoint Designer 2010 or Visual Studio 2010.

Breadcrumb navigation displays a dynamically generated set of links at the top of Web pages, to show users their current position in the site hierarchy. By using SharePoint Designer 2010 or Visual Studio 2010, you can configure the breadcrumb navigation control. For example, you can specify a custom navigation provider.

Tree view navigation displays site content, such as lists, libraries, and sites that are below the current site, in a hierarchical structure. It is common for tree view navigation to appear on the left of each page in a site.

By default, tree view navigation is turned off. Site administrators can add tree view navigation to a site by using the Tree View page.

• See Also
  

Make a diagram of the sites that you want to create. For example, the following diagram is for a small travel company named Margie’s Travel. The company has a set of internal sites to help them organize their core business, which is planning conventions.

Your diagram might include a single site collection, such as the example for Margie’s Travel, or it might have multiple site collections if you have a more complex set of sites. Be sure to include all top-level Web sites, sites, Meeting Workspace or Document Workspace sites, and other sites that you plan to create, and leave room for future expansion.

You might also want to include the lists and libraries for each site, especially if you are deciding whether to create a site for document storage or one or more document libraries.

The global navigation, or top link bar, appears at the top of all pages in the site, below the site title. By default, each site uses its own, unique top link bar, or you can decide to allow sites to inherit the top link bar from the parent site.

The top link bar can display two levels of sites in a site collection. For example, the top link bar for the Margie’s Travel site collection might contain links for Margie’s Travel Home, Office Management, Convention Planning, and Sales and Marketing. In this example, the top link bar looks like the following:

Home | Office Management | Convention Planning | Sales and Marketing

Note:

Although the top link bar can display two levels of sites, this does not mean that all sites at the second level have to be displayed on the top link bar. You can determine whether a site appears on the top link bar when you create it, or you can configure the navigation later in Site Settings.

However, by default, sites at a third level in the hierarchy do not appear on the top link bar for the top-level site, even if they inherit the navigation. For example, the Reports site would not be displayed on the top link bar of Margie’s Travel Home because it is a site that is below the Convention Planning site. If you want this site to be displayed, you can manually add it to the top link bar or create it at the second level in the site hierarchy (as a site below Margie’s Travel Home, instead of as a site below the Convention Planning site).

The top link bar cannot be shared between sites in different site collections. However, you can always manually add a link to a site in a different site collection.

If you want the Home tab of a site to open that site’s home page instead of the inherited navigation site’s home page, then you should use unique navigation. Otherwise, you should use inherited navigation. For example, the Margie’s Travel site collection could inherit the top links among all of the second-level sites so that all sites have the same navigation:

Home | Office Management | Convention Planning | Sales and Marketing

This works for a small team, such as in Margie’s Travel, where all the users in the organization work with all the sites. Each user in the site collection uses each site so an inherited top link bar is useful. However, if the Convention Planning and Sales and Marketing teams work fairly independently and do not need access to each other’s sites, then the navigation for Margie’s Travel could be customized to be inherited at the second level, instead of the top level, as in the following:

Margie’s Travel Home site: Home | Office Management

Convention Planning site: Convention Planning | Reports

Sales and Marketing site: Sales and Marketing

Remember that the global breadcrumb navigation always contains a link back to the top-level site in the site collection. Therefore, even though users of the Convention Planning site cannot visit Margie’s Travel Home from the top link bar, they can visit it directly from the global breadcrumb navigation.

Note:

Although the choice of whether to inherit a navigation bar is made during site creation, you can change this option later. You might have to manually create links if you change your mind, but you can do so easily by using the Top Link Bar page in Site Settings for the affected sites.

Whether or not you decide to inherit the top link bar, you can customize the top link bar to include links to any other URL that you need. Depending on the extent of customization that you need, you can choose between the following methods to customize the top link bar:

    If you want to add, remove, or rearrange the links in a top link bar, use the Top Link Bar page in Site Settings for the site.

    If you want to create a completely customized top link bar and apply it to all sites in a site collection or to sites in a different site collection, use Microsoft SharePoint Designer 2010 or Microsoft Visual Studio 2010.

Other site navigation options that you can configure include Quick Launch and the tree view. The Quick Launch navigation typically highlights the important content in the current site.

You can customize the items that are displayed in the Quick Launch by adding new links, adding or changing headings, and changing the order in which links are displayed. To configure the Quick Launch navigation, use the Quick Launch page in Site Settings for the site.

Tree view navigation displays site content such as lists, libraries, and sites below the current site in a hierarchical manner. It is common for tree view navigation to appear on the left of each page in a site. By default, tree view navigation is turned off.

If you want to display your site content in a hierarchical way, you can display the tree view for users of your site. To enable the tree view for a site, use the Tree view page in Site Settings for the site.

Themes enable lightweight branding of a SharePoint Foundation 2010 site by allowing a site owner or a user with designer rights to make changes to the colors and fonts of user interface elements of a site. Themes are applied directly in the user interface, and do not require knowledge of cascading style sheets or master pages.

Note:

If you apply a theme to a SharePoint Foundation 2010 site, anonymous users who browse the site will see only the default theme. To make the selected theme appear for all users, you must add a link in the master page to the generated CSS file.

An advantage of using themes is that developer resources are not needed for site owners and users with designer rights to make basic changes to a site. Themes are a simple method of branding a site; they do not affect the layout of a site.

Note:

Themes in SharePoint Foundation 2010 have been redesigned to simplify the process of generating themes. Themes created in Windows SharePoint Services 3.0 are not compatible with SharePoint Foundation 2010. If you are upgrading from Windows SharePoint Services 3.0 to SharePoint Foundation 2010, you can use Visual Upgrade to continue to use sites in the old user interface. However, we recommend that you use the new user interface in SharePoint Foundation 2010 to create themes and apply them to your sites.

There are two ways to use themes on a site:

    Use a preinstalled theme.

    Upload a custom theme to the theme library.

SharePoint Foundation 2010 comes with preinstalled themes, including the default SharePoint theme. When a new site is created, it will use the default SharePoint theme.

You can create custom themes by modifying styles in an Office 2010 application, such as Microsoft PowerPoint 2010, and saving the theme. This creates a .thmx file that you can upload to the theme gallery for a site collection. Customized themes in the theme gallery are available to all sites in that site collection.

• See Also
  

There are three primary decisions to make as you plan to use themes:

    Decide whether or not to use themes.

    If you are going to use themes, determine how many themes are needed.

    Decide who will make the custom themes.

The remainder of this article will explain these decisions and describe additional planning considerations.

The first step to planning for using themes is to decide whether or not themes are the appropriate option for your scenario. Other options for customizing a site include using an alternate CSS file and creating custom master pages. These options require the skills of either a designer or a developer to implement, and so they may not be appropriate for your scenario.

To decide whether or not to use themes, determine how much change to the existing look and feel is needed for your sites, and then choose the option that most closely fits what you want to do. You can use a combination of one or more of these options, depending on the customization that you want to do for your sites. The following table describes different levels of customization and recommends the option best suited for each level.

Note:

If you apply a theme to a SharePoint Foundation 2010 site, anonymous users who browse the site will see only the default theme. To make the selected theme appear for all users, you must add a link in the master page to the generated CSS file.

If you decide to use themes, continue reading the rest of this article.

After deciding to use themes, you must determine how many themes are needed for your sites. Consider whether the themes that are installed with SharePoint Foundation 2010 are sufficient for your purposes, or if you will need to create custom themes to be used across sites. If you will be creating custom themes, you must also determine how many themes will be needed and decide which sites will use which themes.

Use the site planning data worksheet to record which sites should use a theme, and to determine how many unique themes are needed.

If you will be using custom themes, you must determine who will be responsible for creating the *.thmx files. Because custom themes are created in an Office 2010 application such as PowerPoint, you do not need a graphic designer to make a theme; however, you may want to include a graphic designer during the planning phase to provide guidance on color values and font styles that will be used in the themes.

You must also decide who will be responsible for uploading the themes to the theme gallery. Will the person who creates the themes also be responsible for uploading the *.thmx files to the theme gallery, or will they save the theme files to a directory for a site collection administrator to upload? A user must have either administrator or designer privileges for the site collection that contains the theme gallery in order to upload *.thmx files to the gallery.

If your organization has to support users in different regions or users who speak different languages, you must determine what your multilingual requirements are and plan for multilingual site deployment when you plan your overall site structure and navigation.

To determine your multilingual requirements, you must:

    Determine the languages and locales that you have to support.

To plan for multilingual site deployment, you must determine which language features and components to install or configure on your servers. These can include:

    Language packs.

    Word breaker support.

Note:

Although Windows SharePoint Services 3.0 supported internationalized domain names (IDNs), SharePoint Foundation 2010 does not. If you currently use IDNs with Windows SharePoint Services 3.0 and you plan to upgrade or migrate to SharePoint Foundation 2010, you must stop using IDNs, delete any IDN settings, and set up a non-IDN environment before you upgrade or migrate to SharePoint Foundation 2010.

You might have to create sites in multiple languages for any of the following reasons:

    You want to provide Web site content to users in different regions.

    You are required by government regulation or organizational policy to provide Web site content in more than one language.

Based on the language requirements of your Web site, determine the language packs that have to be installed on your front-end Web servers. Language packs enable you to create sites and site collections in multiple languages without requiring separate installations of SharePoint Foundation 2010. Language packs are installed on the front-end Web servers in your server farm and contain language-specific site templates. When you create a site or a site collection that is based on a language-specific site template, the user interface text that appears on the site or the site collection is displayed in the language of the specified site template. For example, when you decide to create a site in French, the toolbars, navigation bars, lists, and column headings for that site will appear in French. Likewise, if you decide to create a site in Arabic, the toolbars, navigation bars, lists, and column headings for that site will appear in Arabic, and the default left-to-right orientation of the site changes to a right-to-left orientation to properly display Arabic text.

If your site will have users who cannot work in the default language that you plan to use for the site, you should also install language packs that will enable users to work in their chosen language by using the multilingual user interface. If you do not provide support for additional languages, users might find it difficult to use site features in their non-native language. Language packs provide language-specific translation of user interface elements such as the following:

    Ribbon elements

    List and site column headers

    Site settings interface

    Templates for new lists, document libraries, and sites

    Relevant search indexing of content that is not in the default language of the site.

Note:

Language packs provide translation only of the user interface. They do not translate content that is created and displayed in content pages or Web Parts.

Word breakers and stemmers are components that are part of the indexing and querying processes. A word breaker is a component that is used to break strings of text into individual words during the indexing and querying processes. A stemmer is a component that finds the root word of a term and can also generate variations of that term. The rules for word breaking and stemming differ for different languages, and you can specify different rules for different languages. Word breakers for each language enable the resulting terms to be more accurate for that language. Where there is a word breaker for a language family, but not for a specific sub-language, the major language is used. For example, the French word breaker is used to handle text that is French Canadian. If no word breaker is available for a particular language, the neutral word breaker is used. With the neutral word breaker, words are broken at neutral characters such as spaces and punctuation marks.

The multilingual user interface enables users to collaborate in a single site by using their selected secondary language, regardless of which language was selected when the site was created. When you create a new site, if language packs have been installed on the server, you can specify the primary language for the site. The site will use that primary language to display the site user interface, such as site navigation and administrative pages. If you want site users to be able to view the site user interface in a secondary language, you can specify which languages are available to users by using the Language Settings page. A user who is logged on to the site can use the Select Display Language option on the user menu to select a secondary language in which to display the site user interface. After the user selects a language, all sites within that domain name are displayed in their preferred language. However, this does not change the default, primary language of the site. Other users who view the site still see the site user interface displayed in the primary language. The site user interface is changed only for those users who have selected a different, secondary language in which to display the site.

By using the multilingual user interface, team members can work on documents and projects in a shared, common language, while they are viewing the site and performing tasks in their preferred language. In addition to team collaboration, the multilingual user interface enables farm and site administrators to perform administrative tasks in their preferred language. For example, farm administrators can change the primary language of the Central Administration Web site so that the administrative links and instructions are displayed in their preferred language.

Note:

The multilingual user interface displays only site user interface elements in another language. It does not translate or display content such as documents or list items in another language.

In addition to letting users change the primary language for a site, the multilingual user interface also enables users to make changes to new and existing application content, such as list or library titles and descriptions, and it enables users to have those changes be reflected in the user interface for other users of other languages. For example, a team member who uses English as the preferred language creates a new document library named “Team Reports.” Another team member who has the preferred language set to German, logs on to the site and changes the library title to “Mannschaftsberichte.” The next time that a user, who has the preferred language set to German, logs on to the site, the name of the document library is displayed as “Mannschaftsberichte.” However, a user who has the preferred language set to English still sees the document library name displayed as “Team Reports.”

SharePoint Foundation 2010 provides three methods that you can use to translate certain application content, such as list or library titles and descriptions: by using the user interface, by exporting and importing translations for a site, and by using the object model.

When a user views a site in a secondary language, certain elements of the user interface are provided in the preferred language. The following list includes examples of items that are supported by the multilingual user interface:

    Settings pages, such as those in the _layouts and the _admin virtual directories.

    Help.

    Application content, such as menus, controls, site actions, site title and description, list or library titles and descriptions, top link bar links, Quick Launch links, local breadcrumbs, site and list content types, and site and list columns.

    Developer content, such as features, and solutions.

However, not all user interface elements are translated. The following list includes examples of items that are not supported by the multilingual user interface:

    Web Parts (except those that are linked to lists or libraries).

    Global breadcrumbs.

    User created content, such as list item data, documents and Web pages in libraries, permissions levels, groups, views, and Web Parts.

Although most site templates are supported by the multilingual user interface, the following site templates are not supported:

    The Blog template.

    Any of the meeting workspace templates.

    Any of the Web database templates.

A user can add or modify application content, such as list titles or column names and descriptions, in one of two ways: by adding or modifying content in the primary language or by adding or modifying content in one or more secondary languages.

When a user views a site by using the primary language of the site, any new application content that is created is displayed in the primary language, even when the site is viewed in a secondary language. For example, if the primary language for a site is English, when a user views the site in the primary language and creates a new document library called “Team Documents”, the library title is still displayed as “Team Documents” when a user views the site in any secondary language. To translate new user interface strings into a secondary language, a user must change the user preferences to display the site in a secondary language and then make the change to the user interface element.

When a user views a site by using a secondary language, any new application content that is created is displayed in that language even when the site is viewed in the primary language or in any other secondary language. For example, if the primary language for a site is English, and a user views the site in German and adds a document library called “Mannschaftsdokumente”, the library title is displayed as “Mannschaftsdokumente” even when the site is viewed in English. To translate new user interface strings into the primary language or to other secondary languages, the user must change the user preferences to display the site in the required language and then make the change to the user interface. The Language Settings page contains an Overwrite Translations option that affects how changes to existing application content are made to other languages for the site. If the Overwrite Translations option is enabled, any changes that are made to the user interface in the primary language overwrite any changes that have been made to user interface elements in secondary languages.

By default, when a user views a site by using the primary language of the site, any changes that are made to existing application content are changed for that language only. The strings that are associated with that user interface element in the secondary languages remain unchanged. However, if the Overwrite Translations option is enabled, the strings that are associated with that user interface element for every language are replaced with the new primary language string. For example, if the primary language for a site is English, and a user changes the title of the “Shared Documents” library to “Team Documents”, by default, the title is changed only for the primary language of the site. However, if the Overwrite Translations option is enabled, the title is changed to “Team Documents” for every secondary language, and it must be retranslated.

When a user views a site by using a secondary language, any changes that are made to existing application content are changed for that language only. The strings that are associated with that user interface element in the primary language and other secondary languages remain unchanged. To translate user interface strings into the primary language, or to other secondary languages, the user must change the user preferences to display the site in the required language and then make the change to the user interface.

The multilingual user interface feature lets you export and import application content for bulk translation. Instead of translating application content one item at a time, you can export the strings for any new or modified application content in the primary language or in one of the secondary languages. To export content, you use the Export Translations link on the Site Settings page. When you export application content for a secondary language, you can decide to export all content or only content that has not been translated.

As mentioned previously, not all user interface elements are supported by the multilingual user interface. The following list describes additional limitations that apply when you use the multilingual user interface:

    Search   Search indexes content in the default language of the SharePoint installation. Even if content is provided in secondary languages, that content is only searchable by using the default language of the site. For example, if your preferred language is German, but the primary language for the site is English, a search for “Freigegebene Dokumente” does not return any search results. However, a search for “Shared Documents” does return search results.

    Web Parts   Web Part titles and descriptions do not change in the user interface, unless a Web Part is a list-based Web Part. For example, the title and description for Web Parts that display list and library data, such as Announcements and Shared Documents, are displayed in a user’s preferred language, whereas the title and description for other Web Parts, such as the Content Editor and the Content Query Web Parts, are displayed only in the primary site language.

• See Also
  

If you will enable the multilingual user interface on your site to provide users a way to collaborate while they are using their preferred language, you must decide whether using the default multilingual user interface will be sufficient or whether application content will have to be translated. If you have application content that has to be translated, you should consider the following questions:

    How will new and existing application content be translated?   Will individual team members translate application content directly in the user interface as it becomes necessary, or will you export resource files in the languages that are needed for the site and have them all translated at once? If users create new application content in a secondary language, you must plan for who will translate that content into the primary language of the site and for the other secondary languages. If you plan to create complex pages, such as new menu pages, or develop custom solutions, such as features that create lists, you must plan to use the object model to provide translations in secondary languages.

    Who will translate the application content?   Will the translation of resource files be done by someone within your organization, or will you need to have a third-party translate them for you?

    How will updates to the application content be handled?   Will changes to the user interface be translated as changes are made, or will changes be made on a periodic schedule? This might depend on the size and scale of the sites and the content that is included.

    How should translation overwrites be handled?   Do you want changes in the primary language to overwrite string values in secondary languages? If so, then you must enable the Overwrite Translations option on the Language Settings page.

    What column names must be changed?   What column names must be translated, and for which languages? Will the column names be at the list level or at the site level?

If language packs are updated as part of a service pack release for SharePoint, you must update the language packs on the server when the service pack is installed. You should plan to coordinate with the farm administrator to monitor the release of service packs and any associated language packs so that you are aware of updated language packs that need to be installed for your users.

• See Also
  

Plan site permissions (SharePoint Foundation 2010)

This article helps you plan access control at the site collection, site, and subsite levels. This article also describes permission inheritance and fine-grained permissions, and explains how to determine effective permissions for users and groups at different scopes within a site collection hierarchy.

In this article:

You should understand the following concepts before you configure access to sites and site content:

You can assign a user or group a permission level for a specific securable object. Individual users or groups can have different permission levels for different securable objects.

About permission inheritance

Permissions on securable objects within a site are inherited from the site itself by default. You can use fine-grained permissions — unique permissions on the list or library, folder, or item or document level — to gain more control of the actions users can take on your site.

You can break permission inheritance for any securable object at a lower level in the site hierarchy by creating a fine-grained permission on that securable object. For example, you can edit the permissions for a document library, which breaks the inheritance from the site. However, the inheritance is broken only for the specific securable object for which you changed permissions; the rest of the site’s permissions are unchanged. You can resume inheriting permissions from the parent list or site at any time.

Tip:

If you are using fine-grained permissions, you should use groups to avoid having to track individual user accounts. For example, because people move in and out of teams and change responsibilities frequently, tracking those changes and updating the permissions for uniquely secured objects would be time-consuming and error-prone.

The following securable objects can accept fine-grained permission assignments:

    Site: Controls access to the site as a whole.

    List or library: Controls access to a specific list or library.

    Folder: Controls access to folder properties (such as the name of the folder).

    Item or document: Controls access to a specific list item or document.

Inheriting permissions is the default behavior and is the easiest way to manage a group of Web sites. However, if a subsite inherits permissions from its parent, that set of permissions is shared with the parent. If the subsite’s owners edit its permissions, the site’s permissions will also change, which could compromise security or prevent users from accessing content.

If you want to change permissions for the subsite only, you must first stop inheriting permissions from the site and then create fine-grained permissions on the subsite. For example, if specific lists, libraries, folders, items, or documents contain sensitive data that requires an increased level of protection, you can create fine-grained permissions for a specific group or individual user who requires access.

Creating unique permissions copies the groups, users, and permission levels from the parent site to the subsite and then breaks the inheritance. If you restore inherited permissions, the subsite will inherit its users, groups, and permission levels from the parent site again, and you will lose any users, groups, or permission levels that were unique to the subsite.

Note:

As a best practice, you should arrange sites and subsites so they can share most of their permissions, and do the same for lists and libraries. Place any sensitive data into separate lists, libraries, or subsites.

Configuring security settings or performing bulk operations requires accurate information about user and group permissions on site resources. For example, many SharePoint sites give all authenticated users (the NTAUTHORITY\AUTHENTICATED USERS domain group) access to at least some site content. If you want to additionally restrict access, you must determine exactly which permissions authenticated users have, and on which site content.

Tracing inherited permissions and areas where inheritance is broken complicates the process of determining the correct permissions. Microsoft SharePoint Foundation 2010 uses effective permissions to determine a user or group’s permissions on all resources within a site collection. You can now find both the user’s directly assigned permissions and the permissions assigned to any groups of which the user is a member.

Important:

Effective permissions make it easier to find permissions in a site collection. However, they should never be used as a substitute for a carefully planned permissions structure.

When you create permissions, you must balance ease of administration and performance against the need to control access to individual items. If you use fine-grained permissions extensively, you will spend more time managing the permissions, and users may experience slower performance when they try to access site content.

Use the following guidelines to configure site permissions:

    Follow the principle of least privilege: Users should have only the permission levels or individual permissions they need to perform their assigned tasks.

    Use standard groups (such as Members, Visitors, and Owners) and control permissions at the site level.

    Make most users members of the Members or Visitors groups. By default, users in the Members group can contribute to the site by adding or removing items or documents, but cannot change the structure, site settings, or appearance of the site. The Visitors group has read-only access to the site, which means that they can see pages and items, and open items and documents, but cannot add or remove pages, items, or documents.

    Limit the number of people in the Owners group. Only those users you trust to change the structure, settings, or appearance of the site should be in the Owners group.

You can create additional SharePoint groups and permission levels if you need more control over the actions that your users can take. For example, if you do not want the Read permission level on a specific subsite to include the Create Alerts permission, break the inheritance and customize the Read permission level for that subsite.

It is much easier to manage permissions when there is a clear hierarchy of permissions and inherited permissions. It becomes more difficult when some lists within a site have fine-grained permissions applied, and when some sites have subsites with unique permissions and others with inherited permissions.

For example, it is much easier to manage a site that has permission inheritance, as shown in the following table.

However, it is not as easy to manage a site that has permission inheritance, as shown in the following table.

Determine permission levels and groups (SharePoint Foundation)

This article reviews the default groups and permission levels and helps you decide whether to use them, customize them, or add new groups and permission levels to promote security.

In this article:

The most important decision about your site and content security in Microsoft SharePoint Foundation 2010 is to decide how to categorize your users and what permission levels to assign.

There are several default SharePoint groups that are intended to help you categorize your users based on the kinds of actions they need to perform, but you might have unique requirements or other ways of looking at sets of users. Likewise, there are default permission levels, but they might not always align exactly with the tasks that your groups need to perform.

In this article, you review the default groups and permission levels and decide whether to use them as they are, customize them, or create different groups and permission levels.

With SharePoint groups, you manage sets of users instead of individual users. SharePoint groups can be composed of many individual users, can hold a single Windows security group, or can be some combination of the two. SharePoint groups confer no specific rights to the site; they are merely a way to contain a set of users. You can organize users into any number of groups, depending on the size and complexity of your organization or Web site.

The following table shows the default groups that are created for sites in SharePoint Foundation 2010.

In addition, the following special users and groups are available for higher-level administration tasks:

    Site collection administrators   You can designate one or more users as primary and secondary site collection administrators. These users are recorded in the database as the contacts for the site collection, have full control of all sites within the site collection, can audit all site content, and receive any administrative alerts (such as verifying whether the site is still being used). Generally, you designate site collection administrators when you create the site, but you can change them as needed by using the Central Administration site or Site Settings pages.

    Farm administrators   Controls which users can manage server and server farm settings. The Farm Administrators group replaces the need for adding users to the Administrators group for the server. Farm administrators have no access to site content by default; they must take ownership of the site to view any content. They do this by adding themselves as site collection administrators, which action is recorded in the audit logs. The Farm Administrators group is used in Central Administration only, and is not available for any sites.

    Administrators   Members of the Administrators group on the local server can perform all farm administrator actions and more, including the following:

    Installing new products or applications.

    Deploying Web Parts and new features to the global assembly cache.

    Creating new Web applications and new IIS Web sites.

    Starting services.

Like the Farm Administrators group, members of the Administrators group on the local server have no access to site content, by default.

After you determine the groups you need, determine the permission levels to assign to each group on your site.

The ability to view, change, or manage a particular site is determined by the permission level that you assign to a user or group. This permission level controls all permissions for the site and for any subsites, lists, document libraries, folders, and items or documents that inherit the site’s permissions. Without the appropriate permission levels, your users might be unable to perform their tasks, or they might be able to perform tasks that you did not intend them to perform.

By default, the following permission levels are available:

    Limited Access   Includes permissions that enable users to view specific lists, document libraries, list items, folders, or documents when granted permissions.

    Read   Includes permissions that enable users to view items on the site pages.

    Contribute   Includes permissions that enable users to add or change items on the site pages or in lists and document libraries.

    Design   Includes permissions that enable users to change the layout of site pages by using the browser or Microsoft Office SharePoint Designer 2007.

    Full Control   Includes all permissions.

The default groups and permission levels provide a general framework for permissions, covering many different organization types and roles within those organizations. However, they might not map exactly to how your users are organized or to the many different tasks that your users perform on your sites. If the default groups and permission levels do not suit your organization, you can create custom groups, change the permissions included in specific permission levels, or create custom permission levels.

Choose security groups (SharePoint Foundation 2010)

This article describes the security and distribution groups that are included in Active Directory Domain Services (AD°DS). This article also provides recommendations for using those groups to organize the users of your SharePoint sites.

In this article:

Each organization sets up its Windows security groups differently. For easier permission management, security groups should be:

    Large and stable enough that you are not continually adding groups to your SharePoint sites.

    Small enough that you can assign appropriate permissions.

For example, a security group called “all users in building 2” is probably not small enough to assign permissions, unless all users in building 2 have the same job function, such as accounts receivable clerks. This is rarely the case, so you should look for a smaller, more specific set of users, such as “Accounts Receivable.”

If you want all users within your domain to be able to view content on your site, consider granting access to all authenticated users (the Domain Users Windows security group). This special group enables all members of your domain to access a Web site (at the permission level that you choose), without your having to enable anonymous access.

You can enable anonymous access to let users view pages anonymously. Most Internet Web sites allow for anonymous viewing of a site, but might ask for authentication when someone wants to edit the site or buy an item on a shopping site. Anonymous access must be granted at the Web application level at the time that the Web application is created.

If anonymous access is enabled for the Web application, site administrators can decide whether to:

    Grant anonymous access to a site.

    Grant anonymous access only to lists and libraries.

    Block anonymous access to a site completely.

Anonymous access relies on the anonymous user account on the Web server. This account is created and maintained by Internet Information Services (IIS), not by your SharePoint site. By default in IIS, the anonymous user account is IUSR. When you enable anonymous access, you are in effect granting that account access to the SharePoint site. Allowing access to a site, or to lists and libraries, grants the View Items permission to the anonymous user account. However, even with the View Items permission, there are restrictions to what anonymous users can do. Anonymous users cannot:

    Open sites for editing in Microsoft SharePoint Designer 2010; in other words, they cannot use remote procedure call (RPC).

    View sites in My Network Places; in other words, they cannot use Web Distributed Authoring and Versioning (WebDAV), the Web Folders protocol in Windows.

    Upload or edit documents in document libraries, including wiki libraries.

Important:

To improve security for sites, lists, or libraries, do not enable anonymous access. Enabling anonymous access lets users contribute to lists, discussions, and surveys, possibly using up server disk space and other resources. Anonymous access also allows for anonymous users to discover site information, including user e-mail addresses and any content posted to lists, and libraries, and discussions.

You can set permission policies for the anonymous user for different zones (Internet, Extranet, Intranet, Other) if you have the same Web application serving content in those different zones. The policies are described in the following list:

    None   No policy. This is the default option. No additional permission restrictions or additions are applied to site anonymous users.

    Read   Anonymous users can read content, unless the site administrator turns off anonymous access.

    Deny Write   Anonymous users cannot write content, even if the site administrator specifically attempts to grant the anonymous user account that permission.

    Deny All   Anonymous users cannot have any access, even if site administrators specifically attempt to grant the anonymous user account access to their sites.

Choose administrators and owners for the administration hierarchy (SharePoint Foundation 2010)

This article describes the administrator roles that correspond to the Microsoft SharePoint Foundation 2010 server and site hierarchy. Many people can be involved in managing SharePoint Foundation 2010. Administration of SharePoint Foundation 2010 occurs at the following levels:

    Server farm

    Shared services

    Sites

    Document library or list

    Individual items

In this article:

The following groups of users have administrative permissions at different levels of the administration hierarchy:

    Server or server farm level

    Farm Administrators group   Members of the Farm Administrators group have permissions to and responsibility for all servers in the server farm. Members can perform all administrative tasks in Central Administration for the server or server farm. Members of this group can also use Windows PowerShell to create and manage configuration database objects. They can assign administrators to manage service applications, which are instances of shared services. This group does not have access to individual sites or their content.

    Administrators group   Members of the Administrators group on the local server can perform all farm administrator actions. Administrators on the local server can perform additional tasks, such as installing new products or applications, deploying Web Parts and new features to the global assembly cache, creating new Web applications and new Internet Information Services (IIS) Web sites, and starting services. Like farm administrators, members of this group on the local server have no access to site content, by default.

Note:

Farm administrators and local administrators can take ownership of specific site collections, if it is necessary. For example, if a site administrator leaves the organization and a new administrator must be added, the farm administrator or a member of the local Administrators group can take ownership of the site collection to make the change.

    Shared services level

    Service application administrators   These administrators are delegated by the farm administrator. They can configure settings for a specific service application within a farm. However, these administrators cannot create service applications, access any other service applications in the farm, or perform any farm-level operations, including topology changes. For example, the service application administrator for a Search service application in a farm can configure settings for that Search service application only.

    Feature administrators   A feature administrator is associated with a specific feature or features of a service application. These administrators can manage a subset of service application settings, but not the entire service application. For example, a Feature administrator might manage the Audiences feature of the User Profile service application.

    Site level

    Site collection administrators   These administrators have the Full Control permission level on all Web sites within a site collection. They have access to content in all sites in that site collection, even if they do not have explicit permissions on that site.

    Site owners   By default, members of the Owners group for a site have the Full Control permission level on that site. They can perform administration tasks for the site, and for any list or library within that site. They receive e-mail notifications for events, such as the pending automatic deletion of inactive sites and requests for site access.

Best practices for using fine-grained permissions (white paper) (SharePoint Foundation 2010)

This white paper describes best practices for fine-grained permissions (FGP) and how to use them within your organization when implementing Microsoft SharePoint Foundation 2010.

Sandboxed solutions overview (SharePoint Foundation 2010)

You can deploy a Microsoft SharePoint Foundation 2010 solution directly onto your SharePoint Foundation farm, or you can deploy the solution into a sandbox. A sandbox is a restricted execution environment that enables programs to access only certain resources, and that keeps problems that occur in the sandbox from affecting the rest of the server environment.

Any page of a SharePoint Foundation application can contain components that run in a sandbox in addition to components that run directly on the farm. The components that are deployed to the farm run in the Internet Information Services (IIS) worker process. The components that are deployed to the sandbox run in a sandboxed process.

The following list identifies several of the components that you might deploy in a sandbox:

    Web Parts

    Event receivers

    Feature receivers

    Custom Microsoft SharePoint Designer workflow activities

    Microsoft InfoPath business logic

The following steps describe how to deploy a sandboxed solution:

1.    A farm administrator performs the following tasks. These have to be done only one time.

    A farm administrator enables sandboxing and starts the sandboxing service on each server that will run sandboxed solutions.

    A farm administrator determines which load balancing scheme to use. The load balancing scheme applies to all sandboxed solutions in all site collections on the farm.

    A farm administrator sets resource quotas that the combination of all sandboxed solutions in a site collection cannot exceed.

2.    A site collection administrator or a user who has full control at the root of the site collection uploads a solution the site collection’s solution gallery.

3.    A site collection administrator activates the solution. If the solution does not contain an assembly, a user who has full control at the root of the site collection can also activate the solution. Validation tools run against the solution. If the solution fails validation, it is not activated.

When a request to run a sandboxed solution is processed, the following activities occur:

1.    Based on load balancing scheme, SharePoint Foundation determines which server to run the solution on. If load balancing is local, the solution runs on the same server that is servicing the request. If load balancing is remote, the server that the solution runs on is selected based on solution affinity. In both cases, the server must be running the sandboxing service.

2.    SharePoint Foundation selects a sandbox worker process to run the solution in; loads a “shim” dynamic-link library (dll) into the process; and then loads the solution assembly into the process.

3.    As the solution runs, its code passes through the shim before it is executed by SharePoint Foundation. If the solution code attempts to use APIs that sandboxed solutions are restricted from using, the shim signals an exception instead of letting the code pass through and run.

4.    SharePoint Foundation monitors the resources that sandboxed solutions use. If the sandboxed solution exceeds a hard limit (for example, if it uses more than a predefined amount of CPU time,) SharePoint Foundation terminates the sandbox worker process. If the combination of all sandboxed solutions in the site collection exceeds the site collection’s resource quota, SharePoint Foundation turns off all sandboxed solutions in the site collection for the rest of the day.

5.    A site collection administrator can monitor the resources that sandboxed solutions use, and can deactivate solutions in the site collection.

If necessary, a farm administrator can block a solution from running on the farm. Optionally, a farm administrator can also remove the requirement that a solution be run in a sandbox. If the requirement to run in a sandbox is removed, when the solution runs in any site collection in the farm, it will no longer run in a sandbox.

You can isolate sandboxed solutions to various degrees. Each additional level of isolation increases your ability to protect the main part of your SharePoint Foundation site from code that might consume too many resources. At the first level, sandboxed code runs in a rights-restricted, isolated process. Code Access Security (CAS) limits the operations that the code can perform. You can increase isolation by using remote load balancing and by running the sandboxing service on only specific servers. In a production environment, we recommend that you use remote load balancing and dedicate a separate server to running sandboxed solutions.

A SharePoint Foundation solution must contain the configuration file that is named manifest.xml, and may also contain additional configuration files and assemblies. If the solution will run in a sandbox, the assembly and configuration files are limited in what they can contain.

The following list identifies the most common things that an assembly that will run in a sandbox cannot do.

    Connect to resources that are not located on the local server.

    Access a database.

    Change the threading model.

    Call unmanaged code.

    Write to disk.

    Access resources in a different site collection.

The manifest.xml file refers to feature files; feature files refer to element files; and element files contain feature elements. The only feature elements that are permitted in a sandboxed solution are:

    ContentType

    Field

    CustomAction

    Module

    ListInstance

    ListTemplate

    Receivers

    WebTemplate

    WorkflowAssociation

    PropertyBag

    WorkflowActions

The following table compares aspects of solutions that run in a farm to solutions that run in a sandbox.

The main benefits of using sandboxed solutions are as follows:

    Solutions can be added to a production SharePoint Foundation environment without the risk of affecting processes outside the sandbox.

    Site collection administrators can deploy sandboxed solutions, freeing farm administrators from this task.

    Scalability and flexibility are increased because sandboxes run in separate process that can be restricted by quotas, and their effect on the farm can be monitored.

    A solution does not have to be modified or recompiled if it is moved from a sandbox to running directly on the farm.

• See Also
  

Using sandboxed solutions is appropriate in scenarios where you want to load balance solutions across multiple servers, or where you want to provide the ability to run code that has not been fully tested or that your organization does not support. Sandboxed solutions can play a valuable part of a scaled deployment path for developers in your organization, from their test environment to a sandboxed solution in the production environment. Sandboxed solutions can later be changed to full trust status by a farm administrator when the solution is shown to be safe for full deployment.

It is especially appropriate to use sandboxed solutions in the following scenarios:

    When you want to load balance solutions between multiple SharePoint Foundation servers.

    When an organization wants to run code for employees on a production SharePoint Foundation site, and that code has not been stringently code reviewed and tested.

    When an Internet hosting provider wants to let the owners of hosted SharePoint Foundation sites upload and run custom code.

When you use sandboxed solutions, you must activate the SharePoint 2010 User Code Host service on each server on which you want to run the sandboxed solutions.

You can select one of two load balancing schemes for sandboxed solutions. Based on the load balancing scheme, Microsoft SharePoint Foundation 2010 determines which server to run the solution on. In local load balancing, the solution runs on the same server that received the request. If you choose remote load balancing, the server that the solution runs on is selected based on solution affinity, and the sandboxed solution is run on a server where it is already loaded and has already been run. This saves time in servicing the request for the solution. In both cases, each server must be running the SharePoint Foundation Sandboxed Code Service.

Your load balancing choice determines the model that is used by the entire SharePoint Foundation farm. You cannot use a mixture of local and remote load balancing, but instead you must choose to implement one or the other. When you are deciding which mode to implement consider the following:

    Local mode requires less administration, but its scalability is limited by the resources of the local server.

    Remote mode is more scalable than local mode, but it requires administrative tasks to be performed on more servers.

You obtain better performance by using the remote load balancing model in a SharePoint Foundation farm where there are multiple servers on which to run sandboxed solutions. If you are using sandboxed solutions as part of a development process, and you want to keep them restricted to the server from which they are called, use the local mode load balancing.

Sandboxed solutions are deployed at the root of a site collection. Anyone who is a site collection administrator can deploy a sandboxed solution. When it is deployed in a site collection, the sandboxed solution can be used anywhere within that site collection.

You can choose to run sandboxed solutions only on certain servers within your SharePoint Foundation farm or to all servers. To enable sandboxed solutions on a server, you must enable the SharePoint Foundation Sandboxed Code Service. This service must be enabled on every server on which you want to run sandboxed solutions.

When you plan for the user roles that are involved in deploying sandboxed solutions, you must determine who will be authorized to deploy the solutions and who will be authorized to administer the solutions. Members of the site collection administrators group can deploy sandboxed solutions.

You must be a member of the farm administrators group to perform administrative tasks such as enabling or disabling the SharePoint Foundation Sandboxed Code Service, blocking or unblocking a solution, and adjusting or resetting quotas.

Note:

It is not enough to be a site collection owner, to deploy and activate a sandboxed solution you must be a site collection administrator for the site collection where you are deploying the sandboxed solution.

Because farm administrators can change sandboxed solutions to fully trusted solutions that can be deployed anywhere on the farm, you should be careful to limit the membership of the farm administrators group to appropriate users. The same consideration applies to adding users to the site collection administrators group if there is any concern over the security of the sandboxed solutions being deployed.

Sandboxed solutions can be enabled or disabled on specific site collections by adjusting their quotas. If you set the quota for sandboxed solutions to 0 on a specific site collection, sandboxed solutions will not run on that site collection. In this way you can fine tune the use of sandboxed solutions in your farm.

To plan where to deploy sandboxed solutions you should consider both which servers will run the SharePoint Foundation Sandboxed Code Service, and which site collections will be able to run sandboxed solutions. If you enable sandboxed solutions on some site collections you should disable them on the remaining site collections by setting the quotas on those site collections to 0.

Sandboxed solutions are monitored for resource usage based on default resource quotas. If a sandboxed solution exceeds any of the resource quotas, the solution is disabled for the remainder of the day or until a farm administrator manually resets the solution. This helps administrators to know when a particular sandboxed solution is making excessive demands on shared resources or in some cases where a resource-intensive sandboxed solution requires an increased quota.

The default quotas are satisfactory for most scenarios; however, you can adjust individual quota limits to permit higher limits where appropriate.

While you are still planning for sandboxed solutions, you should consider your processes for governance issues, including the following:

    At what point will the farm administrator block or unblock a sandboxed solution? Identifying the administrative policy for blocking and unblocking sandboxed solutions will eliminate confusion if there is any doubt about the need to block a solution.

    At what point will you transfer a sandboxed solution to the global catalog as a full trust solution? This decision applies to solution code that is developed by your organization’s developers. You should establish a policy for determining what level of testing is required for a sandboxed solution to be considered ready for production use in your organization.

    When you are planning for who can deploy sandboxed solutions, will you choose to add people to the site collection administrators group or establish a procedure for a limited number of site collection administrators to deploy sandboxed solutions on behalf of their users? Depending on the security concerns in your organization, you can decide to add people directly to the site collection administrators group rather than requiring them to ask permission to deploy the sandboxed solution.

Plan for collaboration sites (SharePoint Foundation 2010)

With Microsoft SharePoint Foundation 2010, you can support collaboration sites in your environment. Collaboration sites store information that individuals and groups can collectively author, share, and revise. These sites do not need to be associated with a particular portal site collection or part of a publishing site collection. They can be stand-alone sites that are available for teams or groups of users who need to collaborate on projects or share information. For example, a team at an engineering firm might want a collaboration site to discuss current project status, assign tasks, or arrange group lunches, without publishing this internal information to the corporate intranet.

Collaboration sites can be made available for searching from your portal or publishing site so that information from these sites is not lost to your organization. However, for easier data recovery and maintenance, collaboration sites should be hosted either on a separate Web application or in separate content databases in the same Web application as your portal or publishing site.

You can create these collaboration sites for your users, or you can allow the users to create these sites on their own.

For more information about collaboration sites and architectural planning, see Logical architecture sample design: collaboration sites.

In this article:

Estimate approximately how many collaboration sites to expect in your environment, and how many such sites that you are willing to support. If you require users to request a collaboration site, you can control how many are created. If you let users create their own collaboration sites, you will have many of these sites in your environment.

You can use specific paths in Microsoft SharePoint Foundation 2010 to contain the SharePoint site collections, similar to the way that folders contain files or documents in the file system. By default, when you create a Web application, two paths are made available for you:

    Root path (/)   This is an explicit inclusion that can contain one site collection. For example, if you want a URL to appear as http://company_name/default.aspx, you would create the site collection at this root path.

    Sites path (/sites)   This is a general path that can contain many site collections. For example, when you use the /sites path, the URL for a site named Site_A would be similar to http://server_name/sites/Site_A/default.aspx.

Note:

The name of the /sites path varies depending on the specific language that was used during installation.

You can also create additional paths. This enables you to group site collections. Then, when you create a site collection, you can choose from the following alternatives:

    Create the site collection at the root of the Web application (if no site collection has already been created there).

    Create the site collection under the /sites path.

    Create the site collection under any additional paths that have been made available for that Web application.

In general, the /sites path should be sufficient for most installations. However, consider using other paths for the following situations:

    You have a complex installation and expect to have many site collections, and you want to group similar sites together.

For example, you could use /personal for individual user sites and /team for group collaboration sites, instead of using /sites for all.

    You want to be able to add a filter to your firewall or router to constrain a specific namespace to internal access only.

For example, you could expose the /team path for external collaboration, but not /personal.

This article describes how to use document libraries to organize documents in your enterprise.

This article describes how to plan content types, which are the SharePoint Foundation 2010 mechanism to define and share the attributes of documents, list items, and folders.

This article describes how to plan content governance by using versioning, check-in and check-out, and approval for publishing content.

Plan document libraries

Document libraries are collections of files on SharePoint Foundation 2010 that you share with other site users. Most SharePoint Foundation 2010 document management features are delivered through document libraries. As part of document management planning, you should determine the document libraries that best fit your organization’s needs.

SharePoint Foundation 2010 includes the following kinds of document libraries:

    Document Library    Use a Document Library for general purpose document storage, document collaboration, and easy sharing of content.

    Picture Library    Use a Picture Library to share, manage, and reuse digital pictures.

Use document libraries to store content on which your workgroup is collaborating and to create shared knowledge bases. For example, a workgroup that designs products can use a document library to store works-in-progress such as design proposals, specifications, and supporting information. Using metadata, displayed as columns of information, the status of each design document can be maintained and made public, together with each document’s author, the project name, and so on. Completed documents can be stored separately in a searchable knowledge base document library that is used as source of information when researching new projects

In this section:

A content type defines the attributes of a list item, a document, or a folder. Each content type can specify:

    Properties to associate with items of its type.

    Workflows that can be launched from items of its type.

    Document templates (for document content types).

    Document conversions to make available (for document content types).

    Custom features.

You can associate a content type with a list or library. When you do this, you are specifying that the list or library can contain items of that content type and that the New command in that list or library will let users create new items of that type.

Note:

You can also associate properties, workflows, policies, and templates directly with a list or library. However, doing this can limit these associations to the list or library and is not reusable across your solution. In SharePoint Foundation 2010 site level workflows can be associated with multiple lists or libraries.

Document libraries and lists can contain multiple content types. For example, a library can contain both the documents and the graphics related to a project. When a list or library contains multiple content types, the following apply:

    By default, the New command in that list or library lets users select from among all available content types when they create a new item. Content type owners can configure the New command to display only certain content types.

    The columns associated with all available content types are displayed.

You can define custom content types in a site’s content type gallery. A custom content type must be derived, directly or indirectly, from a core content type such as Document or Item. After it is defined in a site, a custom content type is available in that site and in all sites below that site. To make a content type most widely available within a site collection, define it in the content type gallery of the top-level site.

For example, if your organization uses a particular contract template, in the content type gallery of the top-level site in a site collection you can create a content type that defines the metadata for that contract, the contract’s template, and workflows required to review and complete the contract. Then, any document library in your site collection to which you associate the Contract content type will include all these features and will enable authors to create new contracts based on the template.

In sites based on SharePoint Foundation 2010, each default list item or library item, such as Contact, Task, or Document, has a corresponding content type in the site’s content type gallery. When planning content types, you can use these out-of-box content type definitions as starting points, basing new content types on existing content types as needed or modifying the default types.

Content types are organized into a hierarchy that enables one content type to inherit its characteristics from another content type. This enables classes of documents to share characteristics across an organization, while also enabling teams to customize these characteristics for particular sites or lists.

For example, all customer deliverable documents in an enterprise may require a set of metadata such as account number, project number, and project manager. By creating a top-level Customer Deliverable content type, from which all other customer deliverable document types inherit, you ensure that required information such as account numbers and project numbers will be associated with all variants of customer deliverable documents in your organization. Note that if another required column is added to the top-level Customer Deliverable content type, the content type owner can propagate the changes to all content types that inherit from it, which will add the new column to all customer deliverable documents.

Each item of metadata that is associated with a content type is a column, which is a location in a list to store information. Lists or libraries are often displayed graphically as columns of information. However, depending on the view associated with the list, the columns can appear in other forms, such as days in a calendar display. In forms associated with a list or library, columns are displayed as fields.

You can define columns for use in multiple content types. To do this, create them in a Column Templates gallery. There is a Column Templates gallery in each site in a site collection. As with content types, columns defined in the Column Templates gallery of a site are available in that site and in all sites below it.

Folder content types define the metadata that is associated with a folder in a list or library. When you apply a folder content type to a list or library, the New command in that list or library will include the folder content type, which makes it possible for users create folders of that type.

You can define views in a list or library that are available only in folders of a particular content type. This is useful when you want a folder to contain a particular kind of document and you want views in that folder to only display columns that are relevant to the document type contained in that folder.

By using the SharePoint Foundation 2010 object model, you can customize the New command for a folder content type so that, when a user creates a new folder of that type, the folder is prepopulated with multiple files and documents based on templates stored on the server. This is useful, for example, for implementing a compound document type that requires multiple files to contribute to a single deliverable document.

Versioning, content approval, and checkout planning (SharePoint Foundation 2010)

This article describes how to plan to use versioning, content approval, and check-out in Microsoft SharePoint Foundation 2010 to control document versions throughout their life cycle.

In this article:

SharePoint Foundation 2010 includes the following features that can help you control documents in a document library:

    Versioning is the method by which successive iterations of a document are numbered and saved.

    Content approval is the method by which site members with approver permissions control the publication of content.

    Check-out and Check-in are the methods by which users can better control when a new version of a document is created and also comment on changes that were made when a document is checked in.

You configure settings for the content control features discussed in this article in document libraries. To share these settings across libraries in your solution, you can create document library templates that include your content control settings; this ensures that new libraries will reflect your content control decisions.

The default versioning control for a document library depends on the site collection template. However, you can configure versioning control for a document library depending on your particular requirements. Each document library can have a different versioning control that best suits the type of documents in the library. SharePoint Foundation 2010 has three versioning options:

    No versioning   Specifies that no previous versions of documents are saved. When no versioning is being used, previous versions of documents are not retrievable, and document history is also not retained because comments that accompany each iteration of a document are not saved. Use this option on document libraries that contain unimportant content or content that will never change.

    Create major versions   Specifies that numbered versions of documents are retained using a simple versioning scheme (such as 1, 2, 3). To control the effect on storage space, you can specify how many previous versions to keep, counting back from the current version.

In major versioning, every time that a new version of a document is saved, all users who have permissions to the document library will be able to view the content. Use this option when you do not want to differentiate between draft versions of documents and published versions. For example, in a document library that is used by a workgroup in an organization, major versioning is a good choice if everyone on the team must be able to view all iterations of each document.

    Create major and minor (draft) versions   Specifies that numbered versions of documents are retained by using a major and minor versioning scheme (such as 1.0, 1.1, 1.2, 2.0, 2.1). Versions ending in .0 are major versions and versions ending with non-zero extensions are minor versions. Previous major and minor versions of documents are saved together with current versions. To control the effect on storage space, you can specify how many previous major versions to keep, counting back from the current version. You also can specify how many major versions being kept should include their respective minor versions. For example, if you specify that minor versions should be kept for two major versions and the current major version is 4.0, then all minor versions starting at 3.1 will be kept.

In major and minor versioning, any user who has read permissions can view major versions of documents. You can specify which users can also view minor versions. Typically, grant users who can edit items permissions to view and work with minor versions, and restrict users who have read permissions to viewing only major versions.

Use major and minor versioning when you want to differentiate between published content that can be viewed by an audience and draft content that is not yet ready for publication. For example, on a human resources Web site that describes organizational benefits, use major and minor versioning to restrict employees’ access to benefits descriptions while the descriptions are being revised.

Note:

Regardless of the versioning control you choose, you must consider the effect that retaining multiple versions of the same document can have on storage space.

Use content approval to formalize and control the process of making content available to an audience. For example, an enterprise that publishes content as one of its products or services might require a legal review and approval before publishing the content. Content publishing can also be scheduled depending on the document state.

A document draft awaiting content approval is in the Pending state. When an approver reviews the document and approves the content, it becomes available for viewing by site users who have read permissions. A document library owner can enable content approval for a document library and optionally can associate a workflow with the library to run the approval process.

The way that documents are submitted for approval varies depending on the versioning settings in the document library:

    No versioning   If no versioning is being used and changes to a document are saved, the document’s state becomes Pending. SharePoint Foundation 2010 keeps the earlier version of the document so that users with read permissions can still view it. After the pending changes have been approved, the new version of the document is made available for viewing by users who have read permissions and the earlier version is not retained.

If no versioning is being used and a new document is uploaded to the document library, it is added to the library in the Pending state and is not viewable by users who have read permissions until it is approved.

    Create major versions   If major versioning is being used and changes to a document are saved, the document’s state becomes Pending and the previous major version of the document is made available for viewing by users who have read permissions. After changes to the document are approved, a new major version of the document is created and made available to site users who have read permissions, and the previous major version is saved to the document’s history list.

If major versioning is being used and a new document is uploaded to the document library, it is added to the library in the Pending state and is not viewable by users who have read permissions until it is approved as version 1.

    Create major and minor (draft) versions   If major and minor versioning is being used and changes to a document are saved, the author has the choice of saving a new minor version of the document as a draft or creating a new major version, which changes the document’s state to Pending. After the changes to the document are approved, a new major version of the document is created and made available to site users who have read permissions. In major and minor versioning, both major and minor versions of documents are kept in a document’s history list.

If major and minor versioning is being used and a new document is uploaded to the document library, it can be added to the library in the Draft state as version 0.1, or the author can immediately request approval in which case the document’s state becomes Pending.

You can require that users check out documents from a document library before editing the documents. It is always recommended to do this. The benefits of requiring check-out and check-in include the following:

    Better control of when document versions are created. When a document is checked out, the author can save the document without checking it in. Other users of the document library will be unable to see these changes and a new version is not created. A new version (visible to other users) is only created when an author checks in a document. This gives the author more flexibility and control.

    Better capture of metadata. When a document is checked in, the author can write comments that describe the changes that were made to the document. This promotes creation of an ongoing historical record of the changes that are made to the document.

If your solution requires that users check in and check out documents when editing them, the Microsoft Office 2010 client applications include features that support these actions. Users can check out documents, undo check-outs, and check in documents from Office 2010 client applications.

When a document is checked out, it is saved in the user’s My Documents folder in a subfolder named “SharePoint Drafts.” This folder is displayed in the Office 2010 client applications. When the document is checked out, the user can only save edits to this local folder. When the user is ready to check the document in, the document is saved back to the original server location.

From Office 2010 client applications, users can also decide to leave checked-out documents on the server by changing content editing options.

• See Also
  

In traditional collaboration, documents are shared via e-mail attachments. Tracking versions and edits from multiple authors is difficult and time-consuming for users. E-mail systems have to contend with storing multiple copies of the same document, not to mention increased network traffic as documents are sent repeatedly.

The use of SharePoint Foundation to store documents for collaboration has reduced these problems by providing consistent access to up-to-date versions of documents, the ability to track previous versions, and centralized management. Storing a single document, instead of many attachments, also reduces network and storage overhead.

But this solution hasn’t been perfect. When one author has a document open, other authors cannot work on it. If someone forgets to close a document or check it in, other users may be locked out indefinitely, a situation that often requires a call to the IT department to resolve the problem.

Co-authoring in SharePoint Foundation 2010 addresses these issues by making it possible for multiple users to work on a document, at any time, without interfering with each other’s changes. This approach streamlines many common document-collaboration scenarios. For example:

    Two or more authors are working on different parts of a composite document. While one author works on his section of the document, another author can work on hers, without either interrupting their work.

    Several authors are working on a composite slide show. Each author can add slides to the presentation and edit them, instead of working in isolation and trying to merge several documents and make them consistent all at the same time.

    A document is sent out to several experts and stakeholders, each of whom has some edits or additions. No user’s edits are lost, because they are all working on a central, server-stored document.

Co-authoring is easy to use from the end user’s point of view. When a user wants to work on a document in Word 2010, PowerPoint 2010, or OneNote 2010, he or she merely opens it from SharePoint Foundation, as usual. If another user already has the document open, both users are able to edit the document at the same time; access to the document is not blocked and no error appears

In Word 2010 and PowerPoint 2010, saving to a document notifies other users viewing the document that there are new edits. Those users can refresh their view immediately to see those changes or continue their work and refresh later to see the latest edits. The authors can also see one another’s work, and everyone knows who is working on the document. SharePoint Foundation 2010 versioning and tracking tools protect the document so that authors can roll back unwanted changes. When Office Communication Server is available, users can see the online status of fellow co-authors and initiate instant messaging conversations without leaving the document.

With OneNote 2010, shared notebooks enable users to share notes seamlessly. When a user edits a page of the notebook, those edits are automatically synchronized with other users of that notebook to ensure everybody has a complete set of notes. Edits made by multiple users on the same page appear automatically, enabling near real-time collaboration. Versioning and other shared features in OneNote make it possible for users to roll back edits, show what edits are new, and determine who made a specific edit.

There are several factors that administrators will want to consider when planning how to use co-authoring in their environment.

Co-authoring functionality in SharePoint Foundation is designed to be easy to set up and requires minimal effort to manage. However there are several things to consider when you set up and manage co-authoring:

    Permissions – For multiple users to be able to edit the same document, users need edit permissions for the document library where that document is stored. The simplest way to ensure this is to give all users access to the SharePoint site where documents are stored. In cases in which only a subset of users should have permission to co-author documents in a particular library, SharePoint permissions can be used to manage access.

    Versioning –SharePoint Foundation versioning keeps track of changes to documents while they are being edited, and even stores previous versions for reference. By default, this feature is turned off in SharePoint Foundation 2010. SharePoint Foundation 2010 supports two kinds of versioning, major and minor. It is best that minor versioning not be turned on for document libraries used for co-authoring in OneNote, as this may interfere with the synchronization and versioning capabilities that are part of the product. This limitation only applies to minor versioning; major versioning may be used with OneNote.

    Number of versions – The number of document versions retained affects storage requirements on the server. This number can be tuned in the document library settings to limit the number of versions retained. OneNote notebooks that are frequently updated may result in many versions being stored on the server. To avoid using unnecessary disk space, we recommend that an administrator set the maximum number of versions retained to a reasonable number on document libraries used to store OneNote notebooks.

Unlike Microsoft Word and Microsoft PowerPoint, Microsoft OneNote stores version information within the file itself. For this reason, administrators should follow these recommended practices when storing OneNote notebooks in a SharePoint Foundation document library:

    Do not enable minor versioning. By default, minor versioning is not enabled in SharePoint Foundation 2010.

    If major versioning is enabled, set a reasonable maximum number of versions to store. By default, major versioning is not enabled in SharePoint Foundation 2010.

For users to co-author documents by using Office 2010, those documents must be stored in SharePoint Server 2010 or SharePoint Foundation 2010. To take advantage of the co-authoring functionality, users must have Word 2010, PowerPoint 2010, or OneNote 2010.

Note:

The co-authoring functionality in Office 2010 can also be used without SharePoint Server 2010 or SharePoint Foundation 2010 if users have Windows Live SkyDrive accounts. Using co-authoring without SharePoint Server 2010 or SharePoint Foundation 2010 is not covered in this article.

Some organizations may want to use co-authoring in an environment where users have different versions of Office.

• Mixed environment that has Microsoft Office PowerPoint and Word 2007
  

Users of earlier versions of PowerPoint and Word can share and edit documents stored in SharePoint Foundation 2010 exactly as with previous versions of SharePoint Foundation. However, they cannot use co-authoring to work on them at the same time. To collaborate best in PowerPoint and Word, we recommend that all users work with Office 2010. Users of Office PowerPoint and Word 2007 will not experience any significant difference between their current experience and their user experience on Office 2010. For instance, if Office 2007 users open a document stored in Office 2010 that is currently being edited by another user, they will see a message that the document is being used and will be unable to edit it. If no other user is editing the document, Office 2007 users will be able to open it as usual. When an Office 2007 user opens a document, this creates a lock on the document and prevents users of Office 2010 from using co-authoring to edit the document. This behavior matches earlier versions of SharePoint Foundation.

• Mixed environment that has Microsoft Office OneNote 2007
  

OneNote 2010 is backward compatible with the Office OneNote 2007 file format and supports co-authoring with OneNote 2007 users. In mixed environments, notebooks must be saved in the OneNote 2007 file format for OneNote 2007 and OneNote 2010 users to work on it together. By upgrading to the OneNote 2010 file format, however, users gain several key features, including compatibility with the Microsoft OneNote Web App that allows users without any version of OneNote installed to edit and co-author notebooks.

OneNote 2010 includes the ability to upgrade OneNote 2007 files to OneNote 2010 files at any time, providing an easy upgrade path for organizations that are moving from a mixed environment to a unified environment on Office 2010.

SharePoint Foundation 2010 and Office 2010 applications have been designed to minimize the performance and scalability impact associated with co-authoring in your environment. Office clients do not send or download co-authoring information from the server until more than one author is editing. When a single user is editing a document, the performance impact resembles that of previous versions of SharePoint Foundation.

Office clients are configured to reduce server impact by reducing the frequency of synchronization actions related to co-authoring when the server is under heavy load, or when a user is not actively editing the document, further helping to reduce overall performance impact.

• See Also
  

Plan for Business Connectivity Services (SharePoint Foundation 2010)

This section describes how to plan for Business Connectivity Services within a Microsoft SharePoint Foundation 2010 environment.

In this section:

Business Connectivity Services security overview (SharePoint Foundation 2010)

This article describes the security architecture of the Microsoft Business Connectivity Services server and client, the supported security environments, the authentication modes available to connect external content types to external systems, the authorization options available on stored objects, and the general techniques for configuring Microsoft Business Connectivity Services security.

In this article:

Microsoft Business Connectivity Services include security features for authenticating users to access external systems and for configuring permissions on data from external systems. Microsoft Business Connectivity Services are highly flexible and can accommodate a range of security methods from within supported Microsoft Office 2010 applications and from the Web browser.

This section describes the Microsoft Business Connectivity Services security architecture.

noteDXDOC112778PADS Security Note

We recommend that you use Secure Sockets Layer (SSL) on all channels between client computers and front end servers. Also we recommend using Secure Sockets Layer or Internet Protocol Security (IPSec) between servers running Microsoft SharePoint Foundation 2010 and external systems. An exception is that you cannot use SSL when transmitting messages to external systems using the SOAP 1.1 protocol or when connecting to a SQL server database. However, in those cases you can use IPSec to protect the data exchange.

• Accessing external data
  

When a user accesses external data from a Web browser, three systems are involved: the logged on user’s client computer, the Web server farm, and the external system.

1.    From Web browsers, users typically interact with external data in external lists or by using Web Parts.

2.    The BDC Server Runtime on front-end servers uses data from the Business Data Connectivity service to connect to and execute operations on external systems.

3.    The Secure Store Service securely stores credential sets for external systems and associates those credential sets to individual or group identities.

Important:

The Secure Store Service is not included in SharePoint Foundation 2010. If you need a secure store in SharePoint Foundation 2010, you must supply a custom secure store provider.

4.    The Security Token Service is a Web service that responds to authentication requests by issuing security tokens made up of identity claims that are based on user account information.

Microsoft Business Connectivity Services can be configured to pass authentication requests to external systems by using the following types of methods:

    Credentials These are typically in the form of name/password. Some external systems may also require additional credentials such as a personal identification number (PIN) value.

    Claims Security Assertion Markup Language (SAML) tickets can be passed to claims-aware services that supply external data.

Microsoft Business Connectivity Services can use credentials that a user supplies to authenticate requests for external data. The following methods by which users can supply credentials for accessing external data are supported:

    Windows authentication:

    Windows Challenge/Response (NTLM)

    Microsoft Negotiate

    Authentication other than Windows

    Forms-based

    Digest

    Basic

When configuring Microsoft Business Connectivity Services to pass credentials, the solution designer adds authentication-mode information to external content types. The authentication mode gives Microsoft Business Connectivity Services information about how to process an incoming authentication request from a user and map that request to a set of credentials that can be passed to the external content system. For example, an authentication mode could specify that the user’s credentials be passed directly through to the external data system. Alternatively, it could specify that the user’s credentials should be mapped to an account that is stored in a Secure Store Service which should then be passed to the external system.

You associate an authentication mode with an external content type in the following ways:

    When you create an external content type in Microsoft SharePoint Designer.

    If the external system is a Web service, you can use the Microsoft Business Connectivity Services administration pages to specify the authentication mode.

    You can specify the authentication mode by directly editing the .XML file that defines the external content type.

The following table describes the authentication modes of the Microsoft Business Connectivity Services:

The following illustration shows the Microsoft Business Connectivity Services authentication modes when it uses credentials.

    In PassThrough (User’s Identity) mode (A) the logged-on user’s credentials are passed directly to the external system.

    In RevertToSelf (BDC Identity) mode (B) the user’s logon credentials are replaced with the credentials of the process account under which Microsoft Business Connectivity Services is running, and those credentials are passed to the external system.

    Three modes use the Secure Store Service: WindowsCredentials (Impersonate Windows ID,) RdbCredentials (Impersonate Custom ID,) and Credentials. In those modes, the user’s credentials are mapped to a set of credentials for the external system and Microsoft Business Connectivity Services passes those credentials to the external system. Solution administrators can either map each user’s credentials to a unique account on the external system or they can map a set of authenticated users to a single group account.

Microsoft Business Connectivity Services can provide access to external data based on an incoming security tokens and it can pass security tokens to external systems. A security token is made up of a set of identity claims about a user, and the use of security tokens for authentication is called “claims-based authentication.” SharePoint Foundation includes a Security Token Service that issues security tokens.

The following illustration shows how the Security Token Service and the Secure Store Service work together in claims-based authentication:

1.    A user tries an operation on an external list that is configured for claims authentication.

2.    The client application requests a security token from the Secure Token Service.

3.    Based on the requesting user’s identity, the Secure Token Service issues a security token that contains a set of claims and a target application identifier. The Secure Token Service returns the security token to the client application.

4.    The client passes the security token to the Secure Store Service.

5.    The Secure Store Service evaluates the security token and uses the target application identifier to return a set of credentials that apply to the external system.

6.    The client receives the credentials and passes them to the external system so that an operation (such as retrieving or updating external data) can be performed.

Permissions in Microsoft Business Connectivity Services associate an individual account, group account, or claim with one or more permission levels on an object in a metadata store. By correctly setting permissions on objects in Microsoft Business Connectivity Services, you help enable solutions to securely incorporate external data. When planning a permissions strategy, we recommend that you give specific permissions to each user or group that needs it, in such a way that the credentials provide the least privilege needed to perform the needed tasks.

Caution:

Properly setting permissions in Microsoft Business Connectivity Services is one element in an overall security strategy. Equally important is securing the data in external systems. How you do this depends on the security model and features of the external system and is beyond the scope of this article.

Note:

Business Connectivity Services uses the permissions on the metadata objects and the permissions on the external system to determine authorization rules. For example, a security trimmer can keep external data from appearing in users’ search results. However, if users somehow discover the URL to the trimmed external data, they can access the external data if they have the necessary permissions to the metadata object and the external system. The correct way to prevent users from accessing external data is to set the appropriate permissions both in Business Connectivity Services and in the external system.

• What can permissions be set on?
  

Each instance of the Business Data Connectivity service (or, in the hosting case, each partition) contains a metadata store that includes all the models, external systems, external content types, methods, and method instances that have been defined for that store’s purpose. These objects exist in a hierarchy as depicted in the following illustration:

Note: