Share PT Serv Plan Sands 1
Share PT Serv Plan Sands 1
Abstract
This book provides information about planning for deploying Microsoft SharePoint Server 2010.
Subjects include site security, governance, and enterprise content management. The audiences for this
book are business application specialists, line-of-business specialists, information architects, IT
generalists, program managers, and infrastructure specialists who are planning a solution based on
SharePoint Server 2010. This book is part of a set of four planning guides that provide comprehensive
IT planning information for SharePoint Server.
For further information about planning for site and solutions created by using SharePoint Server, see
Planning guide for sites and solutions for Microsoft SharePoint Server 2010, part 2
(http://go.microsoft.com/fwlink/?LinkId=208024). Subjects in Part 2 include web content management,
site creation, business intelligence, business data, and enterprise search.
For information about planning the architecture of a SharePoint Server 2010 deployment, see Planning
guide for server farms and environments for Microsoft SharePoint Server 2010
(http://go.microsoft.com/fwlink/?LinkID=189513).
For information about planning for capacity and performance in SharePoint Server 2010, see Capacity
planning for Microsoft SharePoint Server 2010 (http://go.microsoft.com/fwlink/?LinkID=208221).
The content in this book is a copy of selected content in the SharePoint Server 2010 technical library
(http://go.microsoft.com/fwlink/?LinkId=181463) as of the publication date. For the most current content,
see the technical library on the Web.
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.
2011 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.
Contents
Getting help.............................................................................................................................................. 15
Technical diagrams (SharePoint Server 2010)........................................................................................ 16
Models .................................................................................................................................................. 16
Tips for printing posters ........................................................................................................................ 28
Plan for sites and solutions (SharePoint Server 2010) ............................................................................ 29
Fundamental site planning (SharePoint Server 2010) ............................................................................ 32
Sites and site collections overview (SharePoint Server 2010) ................................................................ 33
Site collections overview ...................................................................................................................... 33
Sites overview ...................................................................................................................................... 34
Site templates included in SharePoint Server 2010 ............................................................................. 35
Plan sites and site collections (SharePoint Server 2010) ........................................................................ 43
About planning sites and site collections ............................................................................................. 43
Determine types of sites ....................................................................................................................... 43
Plan sites by organizational hierarchy .............................................................................................. 44
Plan application sites ........................................................................................................................ 44
Plan Internet presence sites ............................................................................................................. 45
Plan publishing sites ......................................................................................................................... 45
Plan other sites ................................................................................................................................. 46
Determine site collections .................................................................................................................... 46
Site planning data worksheet ............................................................................................................... 47
Site navigation overview (SharePoint Server 2010) ................................................................................ 48
Navigation controls overview................................................................................................................ 48
Navigation controls on master pages ................................................................................................... 49
Top link bar navigation ...................................................................................................................... 49
Quick Launch navigation ................................................................................................................... 50
Breadcrumb navigation ..................................................................................................................... 50
Tree view navigation ......................................................................................................................... 50
Metadata navigation .......................................................................................................................... 51
Navigation controls on page layouts .................................................................................................... 51
Summary Links ................................................................................................................................. 51
Table of Contents .............................................................................................................................. 52
Content Query ................................................................................................................................... 52
Navigation Web Parts ........................................................................................................................... 52
Plan site navigation (SharePoint Server 2010)........................................................................................ 54
About planning navigation .................................................................................................................... 54
Privacy and security implications of social tagging (SharePoint Server 2010) ..................................... 191
How social tagging information is hidden ........................................................................................... 191
Private tags ..................................................................................................................................... 191
Ratings control ................................................................................................................................ 191
Security trimming ............................................................................................................................ 191
How social tagging information is displayed ...................................................................................... 192
My Profile pages ............................................................................................................................. 192
Following ......................................................................................................................................... 193
Web pages ...................................................................................................................................... 193
What information is still exposed ........................................................................................................ 193
Recommendations ............................................................................................................................. 193
Enterprise Wikis overview (SharePoint Server 2010) ........................................................................... 195
Comparison of Enterprise Wikis with Team Sites .............................................................................. 195
Uses and benefits of Enterprise Wikis ............................................................................................... 196
Limitations of Enterprise Wikis ........................................................................................................... 196
Example: Fabrikam Enterprise Wiki ................................................................................................... 196
Enterprise wiki planning (SharePoint Server 2010) ............................................................................... 197
About planning an Enterprise Wiki ..................................................................................................... 197
Decide whether to use an Enterprise Wiki ......................................................................................... 197
Evaluate prerequisites ........................................................................................................................ 199
Choose a location for hosting an Enterprise Wiki .............................................................................. 199
Collaboration site planning (SharePoint Server 2010) .......................................................................... 200
Determine number of collaboration sites ............................................................................................ 200
Specific paths ..................................................................................................................................... 200
Additional paths .................................................................................................................................. 201
Integration with Microsoft SharePoint Workspace 2010 .................................................................... 201
Enterprise content management planning (SharePoint Server 2010) ................................................... 203
Document management planning (SharePoint Server 2010) ................................................................ 204
Document management overview (SharePoint Server 2010) ............................................................... 206
The elements of a document management system ........................................................................... 206
The planning process ......................................................................................................................... 207
Identify users and analyze document usage (SharePoint Server 2010) ............................................... 209
Identify users ...................................................................................................................................... 209
Analyze document usage ................................................................................................................... 210
Worksheets ..................................................................................................................................... 212
Metadata-based routing and storage overview (SharePoint Server 2010) ........................................... 214
About metadata-based routing and storage ....................................................................................... 214
Getting help
Every effort has been made to ensure the accuracy of this book. This content is also available online in
the Office System TechNet Library, so if you run into problems you can check for updates at:
http://technet.microsoft.com/office
If you do not find your answer in our online content, you can send an e-mail message to the Microsoft
Office System and Servers content team at:
itspdocs@microsoft.com
If your question is about Microsoft Office products, and not about the content of this book, please
search the Microsoft Help and Support Center or the Microsoft Knowledge Base at:
http://support.microsoft.com
File type
Software
.vsd
.xps
Models
Models are 34-by-44-inch posters that detail a specific technical area. These models are intended to be
used with corresponding articles on TechNet. These models are created by using Office Visio 2007.
You can modify the Visio files to illustrate how you plan to incorporate Microsoft SharePoint 2010
Products in your own environment.
Title
Description
Title
Description
Visio (http://go.microsoft.com/fwlink/?LinkId=196969)
PDF (http://go.microsoft.com/fwlink/?LinkId=196970)
XPS (http://go.microsoft.com/fwlink/?LinkId=196971)
Design Sample: Corporate Portal with Claims-based
Authentication
Visio (http://go.microsoft.com/fwlink/?LinkId=196972)
PDF (http://go.microsoft.com/fwlink/?LinkId=196973)
XPS (http://go.microsoft.com/fwlink/?LinkId=196974)
SharePoint 2010 Products Deployment
Title
Description
Visio (http://go.microsoft.com/fwlink/?LinkId=183024)
PDF (http://go.microsoft.com/fwlink/?LinkId=183025)
XPS (http://go.microsoft.com/fwlink/?LinkId=183026)
Services in SharePoint 2010 Products
Visio (http://go.microsoft.com/fwlink/?LinkID=167090)
PDF (http://go.microsoft.com/fwlink/?LinkID=167092)
XPS (http://go.microsoft.com/fwlink/?LinkID=167091)
Cross-farm Services in SharePoint 2010 Products
Title
Description
Visio (http://go.microsoft.com/fwlink/?LinkID=167093)
PDF (http://go.microsoft.com/fwlink/?LinkID=167095)
XPS (http://go.microsoft.com/fwlink/?LinkID=167094)
Topologies for SharePoint Server 2010
Visio (http://go.microsoft.com/fwlink/?LinkID=167087)
PDF (http://go.microsoft.com/fwlink/?LinkID=167089)
XPS (http://go.microsoft.com/fwlink/?LinkID=167088)
Extranet Topologies for SharePoint 2010 Products
Visio (http://go.microsoft.com/fwlink/?LinkId=187987)
PDF (http://go.microsoft.com/fwlink/?LinkId=187988)
XPS (http://go.microsoft.com/fwlink/?LinkId=187986)
Hosting Environments in SharePoint 2010 Products
Title
Description
Visio (http://go.microsoft.com/fwlink/?LinkID=167084)
PDF (http://go.microsoft.com/fwlink/?LinkID=167086)
XPS (http://go.microsoft.com/fwlink/?LinkID=167085)
Search Technologies for SharePoint 2010 Products
Visio (http://go.microsoft.com/fwlink/?LinkID=167731)
PDF (http://go.microsoft.com/fwlink/?LinkID=167733)
XPS (http://go.microsoft.com/fwlink/?LinkID=167732)
Search Environment Planning for Microsoft SharePoint
Server 2010
Title
Description
Visio (http://go.microsoft.com/fwlink/?LinkID=167734)
PDF (http://go.microsoft.com/fwlink/?LinkID=167736)
XPS (http://go.microsoft.com/fwlink/?LinkID=167735)
Search Architectures for Microsoft SharePoint Server
2010
Visio (http://go.microsoft.com/fwlink/?LinkID=167737)
PDF (http://go.microsoft.com/fwlink/?LinkID=167739)
XPS (http://go.microsoft.com/fwlink/?LinkID=167738)
Design Search Architectures for Microsoft SharePoint
Server 2010
Title
Description
Visio (http://go.microsoft.com/fwlink/?LinkID=167740)
PDF (http://go.microsoft.com/fwlink/?LinkID=167742)
XPS (http://go.microsoft.com/fwlink/?LinkID=167741)
Business Connectivity Services Model
Visio (http://go.microsoft.com/fwlink/?LinkId=165565)
PDF (http://go.microsoft.com/fwlink/?LinkID=165566)
XPS (http://go.microsoft.com/fwlink/?LinkId=165571)
Title
Description
Visio
(http://go.microsoft.com/fwlink/?LinkID=179391&clcid=0x409)
PDF
(http://go.microsoft.com/fwlink/?LinkID=179523&clcid=0x409)
XPS
(http://go.microsoft.com/fwlink/?LinkID=179524&clcid=0x409)
Microsoft SharePoint Server 2010 Upgrade Planning
Title
Description
Visio (http://go.microsoft.com/fwlink/?LinkId=167101)
PDF (http://go.microsoft.com/fwlink/?LinkId=167102)
XPS (http://go.microsoft.com/fwlink/?LinkId=167103)
Microsoft SharePoint Server 2010 Test Your Upgrade
Process
Visio (http://go.microsoft.com/fwlink/?LinkId=167104)
PDF (http://go.microsoft.com/fwlink/?LinkId=167105)
XPS (http://go.microsoft.com/fwlink/?LinkId=167106)
Microsoft SharePoint Server 2010 Services Upgrade
Title
Description
Visio (http://go.microsoft.com/fwlink/?LinkId=167107)
PDF (http://go.microsoft.com/fwlink/?LinkId=167108)
XPS (http://go.microsoft.com/fwlink/?LinkId=167109)
Microsoft SharePoint Server 2010 Upgrading Parent
and Child Farms
Visio (http://go.microsoft.com/fwlink/?LinkId=190984)
PDF (http://go.microsoft.com/fwlink/?LinkId=190985)
XPS (http://go.microsoft.com/fwlink/?LinkId=190986)
Getting started with business intelligence in SharePoint
Server 2010
Title
Description
information.
Visio (http://go.microsoft.com/fwlink/?LinkId=167409)
PDF (http://go.microsoft.com/fwlink/?LinkId=167170)
XPS (http://go.microsoft.com/fwlink/?LinkId=167171)
Databases That Support SharePoint 2010 Products
Visio (http://go.microsoft.com/fwlink/?LinkId=187970)
PDF (http://go.microsoft.com/fwlink/?LinkId=187969)
XPS (http://go.microsoft.com/fwlink/?LinkId=187971)
SharePoint 2010 Products: Virtualization Process
Title
Description
Foundation 2010)
Visio (http://go.microsoft.com/fwlink/?LinkId=195021)
PDF (http://go.microsoft.com/fwlink/?LinkId=195022)
XPS (http://go.microsoft.com/fwlink/?LinkId=195023)
Governance for SharePoint Server 2010
Visio (http://go.microsoft.com/fwlink/?LinkId=200532)
PDF (http://go.microsoft.com/fwlink/?LinkId=200533)
XPS (http://go.microsoft.com/fwlink/?LinkId=200534)
Duet Enterprise for Microsoft SharePoint and SAP
Poster
Title
Description
Visio
(http://go.microsoft.com/fwlink/?LinkID=208107&clcid=0x409)
PDF
(http://go.microsoft.com/fwlink/?LinkID=208108&clcid=0x409)
XPS
(http://go.microsoft.com/fwlink/?LinkId=208109&clcid=0x409)
The articles in this section will guide you in planning solutions for sites that include digital
assets such as video, audio, and images.
The articles in this section contain guidance about how to create, maintain, and delete sites, as well
as how to determine settings for quota templates and recycle bins.
See Also
Plan for server farms and environments (SharePoint Server 2010)
Sites and site collections overview (SharePoint Server 2010) describes site collections and sites,
and it contains information about the site templates that are used to create sites in SharePoint
Server 2010.
Plan sites and site collections (SharePoint Server 2010) describes the process and important
considerations for planning SharePoint Server 2010 sites and site collections.
Site navigation overview (SharePoint Server 2010) provides an overview of the types of navigation
that are available in a site.
Plan site navigation (SharePoint Server 2010) helps you design the navigation for your site.
Themes overview (SharePoint Server 2010) provides an overview of themes and how they work.
Plan for using themes (SharePoint Server 2010) discusses how to plan for using themes across
your sites, and it includes important steps to plan how to use themes for your sites.
Plan for multilingual sites (SharePoint Server 2010) discusses how to plan for multilingual
SharePoint Server 2010 sites.
Multilingual user interface overview (SharePoint Server 2010) describes the multilingual user
interface in SharePoint Server 2010.
Plan for the multilingual user interface (SharePoint Server 2010) describes how to plan for using
the multilingual user interface in your SharePoint Server 2010 site solution.
Sites overview
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.
The following list includes some examples of solutions that benefit from being implemented as site
collections:
Team site A site collection to support authoring and collaboration tasks for people in your
organization who are working together to produce content useful for your organizational goals.
Often, this kind of site includes collaborative content that is not published but only used internally,
and content intended for publication to an outside audience.
Publishing site A site collection configured to let site members view, author, and interact with the
site's content. Publishing sites are often implemented as two site collections a production site
collection and an authoring site collection. The production site collection is the published site that
the content audience uses. The authoring site collection is a mirror of the production site, and it is
used by the authoring team to create and view site content and test site features. SharePoint
Server 2010 includes a content deployment feature that copies content from an authoring site
collection to a production site collection. For information about content deployment, see Content
deployment overview (SharePoint Server 2010)
Sites overview
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:
Templates You can make each site have a unique template. For more information, see Site
templates included in SharePoint Server 2010.
Language If language packs have been installed on the Web server, you can select a languagespecific site template when you create a new site. Text that appears on the site is displayed in the
site templates language. For more information, see Deploy language packs (SharePoint Server
2010).
Security You can define unique user groups and permissions for each site.
Navigation You can fine-tune your site's navigation experience by configuring unique navigation
links in each part of your site's hierarchy. Site navigation reflects the relationships among the sites
in a site collection. Therefore, planning navigation and planning sites structures are closely related
activities. For more information, see Site navigation overview (SharePoint Server 2010).
Web pages You can make each site have a unique welcome page and other pages. For more
information, see Plan Web pages.
Site layouts You can make unique layouts or master pages available in a site. For more
information, see Plan Web pages.
Themes You can change colors and fonts on a site. For more information, see Plan for using
themes (SharePoint Server 2010).
Regional settings You can change the regional settings, such as locale, time zone, sort order,
time format and calendar type.
Search You can make each site have unique search settings. For example, you can specify that a
particular site never appears in search results.
Content types You can make each site have unique content types and site columns. For more
information, see Content type and workflow planning (SharePoint Server 2010).
Workflows You can make each site have unique workflows. For more information, see Plan
workflows (SharePoint Server 2010).
Template
Purpose
Category in Site
Category in Site
Collection
Custom
N/A
An assets database to
N/A
keep track of assets,
including asset details and
owners.
Web Databases
Basic Meeting
Workspace
Meetings
Meetings
Enterprise
Search
Blank Meeting
Meetings
Meetings
Template
Purpose
Category in Site
Category in Site
Collection
Workspace
Blank Site
Collaboration
Blog
Collaboration
Content
Business Intelligence
Center
Data
Charitable Contributions
Web Database
A database to track
information about
fundraising campaigns
including donations made
by contributors,
campaign-related events,
and pending tasks.
N/A
Web Databases
Web Databases
Decision Meeting
Workspace
Meetings
Meetings
Template
Purpose
Category in Site
Category in Site
Collection
Enterprise
Document Workspace
A site on which
Collaboration
colleagues can work
together on a document. It
provides a document
library for storing the
primary document and
supporting files, a tasks
list for assigning to-do
items, and a links list to
point to resources that are
related to the document.
Collaboration, Content
Enterprise Search
Center
Search
Enterprise Wiki
Collaboration, Content
Publishing
Content
Template
Purpose
Category in Site
Category in Site
Collection
Search
Collaboration
An issues database to
manage a set of issues or
problems. You can
assign, prioritize, and
follow the progress of
issues from start to finish.
N/A
Web Databases
Collaboration
Tracking
Template
Purpose
Category in Site
Category in Site
Collection
Server 2010.
Multipage Meeting
Workspace
Meetings
My Site Host
Enterprise
N/A
N/A
Enterprise
N/A
PowerPoint Broadcast
Center
Template
Purpose
Category in Site
Category in Site
Collection
A project tracking
database to track multiple
projects, and assign tasks
to different people.
Publishing Portal
N/A
Web Databases
N/A
Template
Purpose
Category in Site
Category in Site
Collection
Publishing Site
N/A
Content
Content
Data
Social Meeting
Meetings
Meetings
Template
Purpose
Category in Site
Category in Site
Collection
Workspace
Team Site
Visio Process
Repository
Collaboration
Collaboration
Content
Some Microsoft Office SharePoint Server 2007 site templates, such as the site directory, news, and
collaboration portal templates, are not available as an option in SharePoint Server 2010. These
templates can still be accessed and used programmatically by developers. These templates are also
still available as options in the UI if the SharePoint Server 2010 farm is upgraded from SharePoint
Server 2007. Otherwise use the social tagging features in SharePoint Server 2010 to get much of the
functionality provided in these templates.
See Also
Plan sites and site collections (SharePoint Server 2010)
Site navigation overview (SharePoint Server 2010)
Plan site navigation (SharePoint Server 2010)
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.
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:
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.
be another intranet site within your organization, depending on the size of your organization and the
complexity of your publishing needs.
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 servicelevel 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.
If you plan to use content deployment to move content between an authoring site collection and a
production site collection, the site collections must be either in separate Web applications, or they
must use separate content databases within the same Web application. For information about
content deployment, see Content deployment overview (SharePoint Server 2010).
Breadcrumb navigation
Metadata navigation
Summary Links
Table of Contents
Content Query
Additionally, you can create links to arbitrary locations, such as to an external Web site.
Navigation links in SharePoint Server 2010 are security-sensitive. If a site user does not have
permissions to a SharePoint Server 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. Also, pages, sites, and links that are manually added to navigation can be configured to be
available only to members of a particular audience. Users who are not members of that audience
cannot see links to sites and pages that are targeted to that audience.
SharePoint Server 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 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.
Restricting the maximum number of items to show at the global navigation level.
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.
Modify the menu style of the navigation. For example, you can select submenus or specify how
many levels of the site hierarchy to display in the navigation.
Linking to sites that are on the same level of the site hierarchy as the current site.
Restricting the maximum number of items to show at the Quick Launch navigation level.
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
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, and you can remove breadcrumb navigation from a page layout.
Metadata navigation
Metadata navigation displays metadata about library and list content in tree view navigation, and makes
it possible for users to filter library or list content based on specified fields. Site administrators can
configure metadata navigation by using the Metadata Navigation Settings page for a list or library to
configure the navigation hierarchies and key filters that are available to users. Metadata navigation is
displayed only when a user views the list or library for which metadata navigation has been configured.
Summary Links
Table of Contents
Content Query
Summary Links
You can use the Summary Links control to add a set of links to a page. You can control the
appearance, organization, and presentation of the links that you add to a Summary Link control.
You can add a Summary Link control to a page layout in three ways:
You can add the control directly to the page layout and configure the links. When you do this, any
page that uses the page layout displays the links.
You can add the control as a field control on the page layout. When you do this, you can choose to
configure the links, and you can also choose to allow authors to modify the links and add new ones.
You can add the control as a Web Part to a Web Part zone. When you do this, authors can modify
the links, add new ones, and delete the Summary Link control.
For example, in a site in which you publish topics from a technical support knowledge base, you can
add a Summary Link control to the page layouts that are used for articles, to provide links to related
sites that contain relevant information, and you can give authors the ability to add links to content that is
related to a particular page's content.
Table of Contents
You can use the Table of Contents control to add a table of contents of all or part of your site to a page
layout so that top link bar and Quick Launch navigation is included in the master pages of the site.
When you add a Table of Contents control to a page layout, you specify which part of your site
collection the control should display, how the links are presented, and how they are organized.
You can add a Table of Contents control to a page layout in two ways:
You can add the control directly to the page layout and configure it. When you do this, any page
that uses the page layout displays the table of contents.
You can add the control as a Web Part to a Web Part zone. When you do this, authors can modify
the scope of the Table of Contents control.
For example, if you are presenting a set of articles in an online news site, you can add a Table of
Contents control directly to the layout of the article pages so that users can switch from one article to
another from any article page.
Content Query
You can use a Content Query control to link to pages or other items that are displayed based on a
query that you design. For example, if you are presenting articles in an online news site, you could add
a Content Query control to the Welcome Page layout of your site so that new articles are highlighted on
that page. You can build complex queries by using the Content Query control. For example, you can
specify which sites in your site collection to query, which lists to use, and what audience to target. You
can also filter queries that are based on items in a library or list.
You can add a Content Query control to a page layout in two ways:
You can add the control directly to the page layout and configure it. When you do this, any page
that uses the page layout displays the results of the query.
You can add the control as a Web Part to a Web Part zone. When you do this, authors can modify
the query or delete the Content Query control.
Site in Category Displays sites from the Site Directory within a specific category.
Tag Cloud Displays the most popular subjects being tagged inside your organization.
The following navigation Web parts are available only on Publishing sites:
Summary Links Allows authors to create links that can be grouped and styled.
If you make it possible for authors to insert navigation Web Parts on pages, you reduce the control that
you have over your site's navigation because authors can then control part of the navigation experience
of site users. This might be appropriate in a loosely controlled environment, such as a collaboration site
in an organization, where individual authors have to be able to point users to content that is related to
the author's work. It is less appropriate in a more tightly controlled environment, such as an Internet
presence site, in which the navigation experience is planned and implemented in a consistent,
controlled way by the designers and planners of the site.
Note:
If you want to include Web Part zones on page layouts but prevent authors from inserting
navigation Web Parts into these zones, you can change the permissions that are required to
use navigation Web Parts in the Web Parts gallery of your site to make those Web Parts
unavailable to authors based on their permission level.
See Also
Plan site navigation (SharePoint Server 2010)
Sites and site collections overview (SharePoint Server 2010)
Plan sites and site collections (SharePoint Server 2010)
You configure global (top link bar) navigation elements and site-level (Quick Launch) navigation
elements on master pages.
You can add navigation elements that provide tables of contents, dynamic access to content based
on a query, or authored links to page layouts.
You can allow page content to contain tables of contents, dynamic access to content based on a
query, or authored links. Be aware that if you allow authors to add navigation elements to page
content, site designers will have less control of a site's navigation experience.
You can use breadcrumbs to display a set of links that show the site hierarchy, starting from the
current page up to the top-level site.
The decisions that you make about your site's navigation reflect its unique purpose and structure. When
you plan navigation, consider the tradeoff between having too many navigation links, which could make
your site confusing, and having too few, which could make it difficult for site users to locate important
information. Also remember the following:
Inheriting the parent site's navigation can place the current site in a larger context. In an intranet
site, this inheritance can help information workers use the other sites in the site collection to
complete their tasks. If site users do not have to use other sites to complete their tasks, consider
defining a unique top link bar at the site so that site users are not distracted by irrelevant navigation
links. For example, records managers who are using a Records Center site might not have to go
outside the Records Center to accomplish their tasks and so would not benefit from a set of
inherited top link bar navigation links.
Displaying peer sites on the Quick Launch navigation can imply that the peer sites have a purpose
that is similar to that of the current site. For example, in an Internet site that markets a set of
products, peer sites on the Quick Launch navigation can help site users find descriptions of related
products and services. However, if site users are unlikely to want to visit peer sites, consider not
displaying them in the current navigation. For example, a university's Internet site that has sites for
each graduate school could omit peer links from the current navigation of each parent site because
students who are interested in a particular graduate school, such as Business Administration, are
unlikely to want to visit sites related to other graduate schools, such as Nursing.
To tightly control site navigation, you can put navigation controls directly on page layouts and
eliminate Web Part zones from page layouts, or restrict the use of navigation Web Parts in those
zones. For example, in a corporate Internet presence site that has millions of site users, you might
decide to restrict authors from inserting navigation controls.
You can provide a more varied site navigation by putting Web Part zones on page layouts, and by
giving authors the ability to insert navigation Web Parts onto their pages. For example, in an
intranet site in which authors and site users are part of the same workgroup, you might decide to
give authors the ability to control the navigation experience of their content by adding navigation
Web Parts to their pages. For more information, see Plan Web pages.
See Also
Site navigation overview (SharePoint Server 2010)
Sites and site collections overview (SharePoint Server 2010)
Plan sites and site collections (SharePoint Server 2010)
If you are going to use themes, determine how many themes are needed.
The remainder of this article will explain these decisions and describe additional planning
considerations.
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.
If you want to
Then use
Themes
Master Pages
If you decide to use themes, continue reading the rest of this article.
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.
You are required by government regulation or organizational policy to provide Web site content in
more than one language.
Be sure to consult all potential site owners when you determine your language requirements, and be
sure to list all languages that you might have to support in the future. It is easier to install language
support during initial deployment instead of waiting to install language support when your servers are
running in a full production environment. After a site has been created for a specific language, the
default language of the site cannot be changed. However, a user who is logged on to the site can use
the multilingual user interface to select an alternative language in which to display the site. This
changes the way the site user interface is displayed to the user, but it does not change the site content.
For example, if the site was provisioned in French, and the Spanish language pack has also been
installed on the server, a site user can change the language to Spanish so that when they view the site,
the user interface will be in Spanish. This changes the user interface for that user only and does not
affect how the site is displayed to other users. Also, any content that was created in French will still be
displayed in French. For more information about the multilingual user interface, see Multilingual user
interface overview (SharePoint Server 2010).
Note:
If a user changes their personal site settings to display the site in an alternative language,
some site elements, such as column names, might still be displayed in the default site
language.
Do not assume that you have to create a Web site or a site collection in multiple languages only
because a document library contains documents in multiple languages. A document library can contain
documents in multiple languages without requiring you to create Web sites or site collections in multiple
languages. For example, the document library for an English site collection can contain documents that
are written in French and documents that are written in Japanese. For publishing sites, content can be
created in any language. You do not have to create a Web site in specific language in order to display
pages that contain content in other languages.
When you are planning multilingual sites, you should also consider what locales are necessary to
support your sites. Locale is a regional setting that specifies the way numbers, dates and times are
displayed on a site. However, locale does not change the language in which the site is displayed. For
example, selecting the Thai locale changes the default sort order of list items and uses the Buddhist
calendar instead of the default calendar. The locale is a setting that is configured independently of the
language specified when a site is created, but unlike the language, the locale can be changed at any
time. For more information about translation of the user interface, see Determine language pack
requirements.
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
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.
The list of available languages that you can use to create a site or site collection, and which users can
select in the multilingual user interface, is generated by the language packs that are installed on the
front-end Web servers of your server farm. By default, sites and site collections are created in the
language in which SharePoint Server 2010 was installed. For example, if you install the Spanish
version of SharePoint Server 2010, the default language for sites, site collections, and Web pages is
Spanish. If you have to create sites, site collections, or Web pages in a language other than the default
SharePoint Server 2010 language, you must first install the language pack for that other language on
the front-end Web servers before you can select another language in which to create a site. For
example, if you are running the French version of SharePoint Server 2010 and you want to create sites
in French, English, and Spanish, then you must install the English and Spanish language packs on the
front-end Web servers before you can create the English and Spanish sites.
Language packs for SharePoint Server 2010 are not bundled or grouped into multilingual installation
packages: you must install a specific language pack for each language that you want to support. Also,
language packs must be installed on every front-end Web server in the server farm to ensure that each
Web server can render content in the specified language. For information about what language packs
are available, see Language packs (SharePoint Server 2010). For information about how to deploy
language packs, see Deploy language packs (SharePoint Server 2010).
Even though you specify a language for a site, some user interface elements such as error messages,
notifications, or dialog boxes might not appear in the language that you choose. This is because
SharePoint Server 2010 relies on several supporting technologies such as the .NET Framework,
Microsoft Windows Workflow Foundation, ASP.NET, and Microsoft SQL Server and some of these
supporting technologies are localized into only a limited number of languages. If a user interface
element is generated by one of the supporting technologies, and if the supporting technology is not
localized into the language that the site administrator specified for the site, the user interface element
appears in English.
In addition, some text might originate from the original installation language, which can create a mixedlanguage experience. This type of mixed-language experience is typically seen only by content creators
or site administrators and is not seen by site users.
Note:
Error logs that SharePoint Server 2010 stores on the server are always in English.
For more information about installing language packs, see Deploy language packs (SharePoint Server
2010).
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 Server 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.
1. Does the user have a preferred language for this site collection on this computer? If so, use the
user's preferred language.
2. Is the language preference that is specified in the Web browser one of the supported languages for
the page? If so, use the preferred language of the browser.
3. Otherwise, use the default language for the site collection.
SharePoint Server 2010 provides three methods that you can use to modify 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 SPUserResource class in the Microsoft.SharePoint namespace.
Not all user interface elements can be changed directly in the user interface. For example, user actions
and commands can be changed only by using the SPUserResource class. For more information, see
SPUserResource class.
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.
However, not all user interface elements are translated. The following list includes examples of items
that are not supported by the multilingual user interface:
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:
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
Plan for the multilingual user interface (SharePoint Server 2010)
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?
Choose administrators and owners for the administration hierarchy (SharePoint Server 2010)
Defines the levels of administration from the server level to the subsite level and helps you choose
administrators for each level.
Best practices for using fine-grained permissions (white paper) (SharePoint Server 2010) provides
guidance for using fine-grained permissions in SharePoint 2010 Products.
Introduction
You can control access to site and site content by assigning permissions to users or groups for a
specific site or site content at the following levels within a site collection:
Site
Library or list
Folder
Document or item
Before developing your plan for site and content access, you should consider the following questions:
To what granularity do you want to control permissions for the site or site content? For example,
you might want to control access at the site level, or you might need more restrictive security
settings for a specific list, folder, or item.
How do you want to categorize and manage your users by using SharePoint groups? Groups do
not have any permission until they are assigned a permission level for a specific site or for specific
site content. When you assign permission levels to SharePoint groups at the site collection level, by
default, all sites and site content inherit those permission levels.
For more information about using groups to help manage permissions, see Choose security groups
(SharePoint Server 2010).
Permissions Permissions grant a user the ability to perform specific actions. For example, the
View Items permission allows a user to view items in a list or folder, but not to add or remove items.
Permissions can be granted to individual users at site or site content levels.
For information about available permissions, see User permissions and permission levels
(SharePoint Server 2010).
Permission level Permission levels are collections of permissions that allow users to perform a
set of related tasks. For example, the Read permission level includes the View Items, Open Items,
View Pages, and View Versions permissions (among others), all of which are needed to view
pages, documents, and items in a SharePoint site. Permissions can be included in more than one
permission level.
Permission levels are defined at the site collection level and can be customized by any user or
group whose permission level includes the Manage Permissions permission. For more information
about customizing permission levels, see Configure custom permissions (SharePoint Server 2010).
The default permission levels are Limited Access, Read, Contribute, Design, and Full Control. For
information about default permission levels and the permissions included in each level, see User
permissions and permission levels (SharePoint Server 2010).
SharePoint group A SharePoint group is a group of users that are defined at site collection level
for easy management of permissions. Each SharePoint group is assigned a default permission
level. For example, the default SharePoint groups are Owners, Visitors, and Members, with Full
Control, Read, and Contribute as their default permission levels respectively. Anyone with Full
Control permission can create custom groups.
User A user can be a person with a user account from any authentication provider supported by
the Web application. We recommend that you assign permissions to groups rather than users,
although you can directly grant individual users permissions to a site or specific content. Because it
is inefficient to maintain individual user accounts, you should assign permissions on a per-user
basis only as an exception.
Securable object A securable object is a site, list, library, folder, document, or item for which
permissions levels can be assigned to users or groups. By default, all lists and libraries within a site
inherit permissions from the site. You can use list-level, folder-level, and item-level permissions to
further control which users can view or interact with site content. You must first break the
permission inheritance before you change or assign permissions for that securable object. You can
resume inheriting permissions from the parent list or site at any time.
You can assign a user or group permissions for a specific securable object. Individual users or groups
can have different permissions for different securable objects. The following diagram illustrates the
relationships among permissions, users and groups, and securable objects.
Tip:
If you choose to break inheritance and use fine-grained permissions, you should use groups to
avoid having to track individual users. 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.
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.
applied, and when some sites have subsites with unique permissions and others with inherited
permissions. As much as possible, arrange sites and subsites, and lists and libraries so they can share
most permissions. Separate sensitive data into their own lists, libraries, or subsites.
For example, it's much easier to manage a site that has permission inheritance as described in the
following table.
Securable object
Description
SiteA
Unique
SiteA/SubsiteA
Sensitive group
Unique
SiteA/SubsiteA/ListA
Sensitive data
Unique
SiteA/SubsiteA/LibraryA
Sensitive documents
Unique
SiteA/SubsiteB
Inherited
SiteA/SubsiteB/ListB
Non-sensitive data
Inherited
SiteA/SubsiteB/LibraryB
Non-sensitive documents
Inherited
However, it is not as easy to manage a site that has permission inheritance as shown in the following
table.
Securable object
Description
SiteA
Unique
SiteA/SubsiteA
Sensitive group
Unique
SiteA/SubsiteA/ListA
Non-sensitive data
SiteA/SubsiteA/LibraryA
SiteA/SubsiteB
Inherited
SiteA/SubsiteB/ListB
SiteA/SubsiteB/LibraryB
Securable object
Description
sensitive documents
document level
The most important decision about your site and content security in Microsoft SharePoint Server 2010
is how to group your users and which permission levels to assign.
Group name
Description
Visitors
Read
Members
Contribute
Owners
Full Control
Group name
Description
SharePoint site.
If you use a site template other than the team site template, you will see a different list of default
SharePoint groups. For example, the following table shows the additional groups provided by a
publishing site template.
Group name
Description
Restricted Readers
Group name
Description
Approvers
Hierarchy Managers
Note:
The Limited Access permission level is used to give groups access to a specific list, library,
folder, document, or item, without giving them access to the entire site. Do not remove this
permission level from the groups listed above. If this permission level is removed, the groups
might not be able to navigate through the site to get the specific items with which they need to
interact.
Make most users members of the Visitors or Members 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.
If the default groups do not map to the exact user groups in your organization, you can create custom
groups. For more information about how to determine whether you need additional groups, see
Determine whether you need custom permission levels or groups.
Besides the above SharePoint groups, there are also administrator groups for higher-level
administration tasks. They are Windows administrators, SharePoint farm administrators, and site
collection administrators.
For more information, see Choose administrators and owners for the administration hierarchy
(SharePoint Server 2010).
Limited Access Includes permissions that enable users to view specific lists, document libraries,
list items, folders, or documents, without giving access to all the elements of a site. You cannot edit
this permission level directly.
Note:
If this permission level is removed, group members might be unable to navigate the site to
access items, even if they have the correct permissions for an item within the site.
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 SharePoint Designer 2010.
For more information about permissions that are included in the default permission levels, see User
permissions and permission levels (SharePoint Server 2010).
The following additional permission levels are provided with the publishing template by default:
View Only Includes permissions that enable users to view pages, list items, and documents.
Approve Includes permissions to edit and approve pages, list items, and documents.
Manage Hierarchy Includes permissions to sites and edit pages, list items, and documents.
Restricted Read Includes permissions to view pages and documents, but not historical versions
or user rights information.
You have more (or fewer) user roles within your organization than are apparent in the default
groups. For example, if in addition to Approvers, Designers, and Hierarchy Managers, you have a
set of people who are tasked with publishing content to the site, you might want to create a
Publishers group.
There are well-known names for unique roles within your organization that perform very different
tasks in the sites. For example, if you are creating a public site to sell your organization's products,
you might want to create a Customers group that replaces Visitors or Viewers.
You want to preserve a one-to-one relationship between Windows security groups and the
SharePoint groups. For example, if your organization has a security group called Web Site
Managers, you might want to use that name as a group name for easy identification when
managing the site.
A default permission level includes all permissions except one that your users need to do their jobs,
and you want to add that permission.
A default permission level includes a permission that your users do not need.
Note:
Do not customize the default permission levels if your organization has security or other
concerns about a specific permission that is part of the permission level. If you want to
make that permission unavailable for all users assigned to the permission level or levels
that include that permission, turn off the permission for all Web applications in your server
farm, rather than change all of the permission levels. To manage permissions for a Web
application, see Manage permissions for a Web application (SharePoint Server 2010).
If you need to make several changes to a permission level, create a custom permission level that
includes all of the permissions you need.
You might want to create additional permission levels if either of the following conditions applies:
You want to define a unique set of permissions for a new permission level.
To create a permission level, you can create a permission level and then select the permissions that
you want to include.
For more information about how to configure custom permissions, see Configure custom permissions
(SharePoint Server 2010).
Note:
Some permissions depend on other permissions. If you clear a permission that another
permission depends on, the other permission is also cleared.
Introduction
Managing users of SharePoint sites is easier if you assign permission levels to groups rather than to
individual users. SharePoint group is a set of individual users and can also include Active Directory
groups. In Active Directory Domain Services (ADDS), the following groups are commonly used to
organize users:
Distribution group A group that is used only for e-mail distribution and that is not securityenabled. Distribution groups cannot be listed in discretionary access control lists (DACLs), which
are used to define permissions on resources and objects.
Security group A group that can be listed in DACLs. A security group can also be used as an email entity.
You can use security groups to control permissions for your site by adding security groups to
SharePoint groups and granting permissions to the SharePoint groups. You cannot add distribution
groups to SharePoint groups, but you can expand a distribution group and add the individual members
to a SharePoint group. If you use this method, you must manually keep the SharePoint group
synchronized with the distribution group. If you use security groups, you do not need to manage the
individual users in the SharePoint application. Because you included the security group instead of the
individual members of the group, ADDS manages the users for you.
Note
For ease of security management, the following items are not recommended in managing
Active Directory groups.
Adding security groups that contain nested security groups, contacts, or distribution lists.
For intranet sites that are broadly accessed by your users, use security groups because you do not
care about the individual users who accessed the intranet site home page.
For collaboration sites that are accessed by a small group of users, add users directly to
SharePoint groups. In this case, there is more of a need to know who is a member so the group
members know each others e-mail addresses and how to contact each other.
Large and stable enough that you are not continually adding additional security groups to your
SharePoint sites.
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.
Permission policies provide a centralized way to configure and manage a set of permissions that
applies to only a subset of users or groups in a Web application. You can manage permission policy for
anonymous users by enabling or disabling anonymous access for a Web application. If you enable
anonymous access for a Web application, site administrators can then grant or deny anonymous
access at the site collection, site, or item level. If anonymous access is disabled for a Web application,
no sites within that Web application can be accessed by anonymous users.
None No policy. This is the default option. No additional permission restrictions or additions are
applied to site anonymous users.
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.
For more information about permission policies, see Manage permission policies for a Web application
(SharePoint Server 2010).
Shared services
Web application
Sites
Individual items
In this article:
Levels of administration
Levels of administration
Most levels of the server and site hierarchy have a corresponding administration group. The
administration groups who have administrative permissions at different levels are described in the
following list:
Farm Administrators group Members of the Farm Administrators group have Full Control
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. 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.
Windows Administrators group Members of the Windows 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 members of the local Administrators group can take
ownership of specific site collections if 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. To take ownership, they can add themselves as the site collection
administrator on the Application Management page.
The Web application level does not have a unique administrator group, but farm administrators
have control over the Web applications within their scope. Members of the Farm Administrators
group and members of the Administrators group on the local server can define a policy to grant
individual users permissions at the Web application level. For more information about policy,
see "Policy for Web applications" in the Logical architecture components (SharePoint Server
2010) article.
Site level
Site collection administrators These administrators have the Full Control permission level
on all Web sites within a site collection. They have Full Control access to all site content in that
site collection, even if they do not have explicit permissions on that site. They can audit all site
content and receive any administrative alert. A primary and a secondary site collection
administrator can be specified during the creation of a site collection.
Site owners By default, members of the Owners group for a site have the Full Control
permission level on that site. They can perform administrative tasks on the site, and on 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.
Book excerpt: SharePoint Development and Governance Using COBIT 4.1: A Practical Approach
These book excerpts are from "SharePoint Deployment and Governance Using COBIT 4.1: A
Practical Approach."
This white paper focuses on the back end of SharePoint governance the technical
implementation. It provides high-level guidance on the many configuration options that SharePoint
Server 2010 provides to enable you to manage the environment for the benefit of all.
About governance
About governance
Governance is the set of policies, roles, responsibilities, and processes that guide, direct, and control
how an organization's business divisions and IT teams cooperate to achieve business goals. A
comprehensive governance plan can benefit your organization by:
Streamlining the deployment of products and technologies, such as SharePoint Server 2010.
Helping ensure the best return on your investment in technologies, for example, by enforcing best
practices in content management or information architecture.
Information architecture
The goal of information architecture is to create a system that helps users collect, store, retrieve,
and use the information that is needed to achieve business objectives. A Web sites information
architecture determines how the information in that site its Web pages, documents, lists, and
data is organized and presented to the sites users.
A comprehensive assessment of your organization's information architecture can help you identify
potential inefficiencies, such as the following:
Inconsistent use of metadata that can make it difficult to search for and compare related data or
content.
Poorly designed and managed storage of content that can result in multiple versions of
documents with no way to identify the authoritative version.
Poorly catalogued and managed storage of data that can cause decision-makers to find and
rely on the wrong data.
Poorly designed navigation or poorly presented information that can make it difficult to find
important sites and information.
A new service application architecture, built into Microsoft SharePoint Foundation 2010, that
replaces the SSP model.
Multitenancy, which creates a true hosting environment and makes it possible to share service
resources across customers (tenants) while partitioning data based on site subscriptions.
Windows PowerShell, the new command-line interface and scripting language that was
designed specifically for system administrators.
Unless you have a governance plan, the rapid and uncontrolled growth of individually managed
Web servers running SharePoint Server 2010 can have unanticipated results. These include the
following:
Isolated servers hosting a loosely organized group of sites that do not have a common search
index, navigation, or security scheme. If you want to support self-service site creation, you
should have a plan that covers content disposition and site archival.
Servers hosting applications that are not secure, which may compromise the integrity of your
content.
Requests for technical support for local servers that are running SharePoint Server 2010
without the support team's knowledge.
Regular maintenance activities, such as backing up and restoring data or installing product
updates, that may not be performed correctly because of poor training or inconsistent server
configuration.
Changes in site ownership that raise questions about content ownership or cause sites to be
locked.
As the use of SharePoint Server 2010 increases in your enterprise, your IT department should
implement a set of well-governed hosting services that makes SharePoint Server 2010 available
and establishes control over its use and configuration.
For effective and manageable SharePoint Server 2010 solutions, your organization should consider
governing one or more of the following additional areas:
Customization policy
SharePoint Server 2010 includes customizable features and capabilities that span multiple product
areas, such as business intelligence, forms, workflow, and content management. Customization
introduces risks to the stability, maintenance, and security of the SharePoint Server 2010
environment. To support customization while controlling its scope, you should develop a
customization policy that addresses the following considerations:
Approved customization tools. For example, you should decide whether to allow the use of
Microsoft SharePoint Designer 2010 and specify which site elements can be customized, and
by whom.
Ways to manage source code, such as a source control system, and standards for
documenting the code.
Required packaging and installation methods. You should control the use of sandboxing, which
enables site owners to host custom solutions in a partially trusted context so they do not affect
the rest of your SharePoint implementation.
The kinds of customizations supported. For example, you might want to allow the use of Web
parts to integrate Microsoft Silverlight 3 applications together with SharePoint sites.
For more information about processes for managing customizations, see the white paper
SharePoint Products and Technologies customization policy
(http://go.microsoft.com/fwlink/?linkid=92311).
Branding
If you are designing an information architecture and a set of sites for use across an enterprise,
consider including branding in your governance plan. A formal set of branding policies helps ensure
that sites consistently use enterprise imagery, fonts, themes, and other design elements. For
example, in SharePoint Server 2010, you can import a Microsoft PowerPoint 2010 theme directly
into a SharePoint site, which automatically applies the theme to all subsites.
Training
Although SharePoint Server 2010 has an intuitive, Web-based interface and includes online help,
using and especially administering sites based on SharePoint Server 2010 can be a challenge for
some users. Additionally, the set of governance policies your IT and business divisions implement
may require explanation. By training your user community appropriately, you can increase
satisfaction with your implementation of SharePoint Server 2010 and reduce support costs.
Executive stakeholders: Key executives should define the overall goals of the governance
committee, provide it with authority, and periodically evaluate the success of the implemented
practices and policies.
Financial stakeholders: Financial officers should ensure that governance rules and processes help
increase the return on the enterprise's investment in SharePoint products and technologies.
IT leaders: IT leaders must help develop their service offerings and determine how to achieve their
IT responsibilities (for example, improving security and maintaining reliability) while they support the
features required by the business teams.
Business division leaders: Business leaders represent the teams that do the primary work of the
enterprise and drive the architectural and functional requirements of the SharePoint Server 2010
deployment. They must work with information architects to determine the enterprise's information
architecture and organizational taxonomy standards. Business leaders must also work with IT
leaders to create service-level agreements and other support policies.
Compliance officers: Governance includes making sure that an enterprise meets its regulatory and
legal requirements and manages its corporate knowledge. If your enterprise has roles that are
responsible for compliance or legal oversight, include representatives from those disciplines in your
governance committee.
Development leaders: Leaders in your software development organization should help determine
which customization tools are approved, how to verify code security, and other code-related best
practices.
Information workers: The members of your organization who do the day-to-day work should help
ensure that the SharePoint Server 2010 services and information architecture meet their needs.
Trainers: Instructional experts should be responsible for developing a training plan and conducting
all appropriate training and education.
IT service features
Information management
The following Group Policy object disables the installation of SharePoint Server 2010 and related
products:
HKLM\Software\Policies\Microsoft\Shared Tools\Web Server Extensions\14.0\
SharePoint\DWORD DisableInstall
To block installation, set DWORD DisableInstall=00000001.
When this registry key is set, users who try to install SharePoint Server 2010 receive the following
error message: SharePoint installation is blocked in your organization. Please contact your
network administrator for more details.
An Active Directory Domain Services (AD DS) Marker identifies the SharePoint servers in an
organization. By default, the marker contains the URL for the topology service application.
For more information about setting the group policy object and the AD DS marker, see Track or block
SharePoint Server 2010 installations.
IT service features
A SharePoint service is an IT service that offers hosted sites and portals based on SharePoint Server
2010. An IT service can include the following components:
Sites and portals at a scope, such as site collection, Web application, or server farm
Content storage
Security
This section describes features in SharePoint Server 2010 that are useful in maintaining and governing
a SharePoint Server 2010 service.
Site templates
Site templates are a set of customizations that are applied to a site definition. By using a site template,
a SharePoint Server 2010 service can promote consistent branding, site structure, and layout in the
sites that users create. You can create customized site templates for provisioning sites and use them
instead of the templates that are included in SharePoint Server 2010 as part of a SharePoint Server
2010 service.
For more information, see Working with site templates and definitions
(http://go.microsoft.com/fwlink/?LinkID=184756).
Quotas
A quota specifies limits to the amount of storage that a site collection can use. This process prevents
users from adding content when the limit is reached. For more information, see Plan quota
management (SharePoint Server 2010).
Locks
Locks prevent users from either adding content to a site collection or using the site collection. For
example, you can lock a site that violates a usage policy or exceeds a quota. For more information, see
Lock or unlock site collections (SharePoint Server 2010).
Workflows
Workflows are programs that implement business processes for users of a SharePoint Server 2010
site. They are associated with items in the site, such as documents, forms, or list items. Workflows have
many applications as part of an IT service. For example, you can use a workflow to provision a new
site, track a support issue, or take action when a site collection's quota is exceeded. For more
information, see Plan workflows (SharePoint Server 2010).
Features
A feature, which is a container for various defined extensions for SharePoint Server 2010 and
SharePoint Foundation 2010, is composed of a set of XML files that are deployed to Web servers. You
can deploy a feature as a part of a site definition or a solution package, and you can individually
activate a feature.
A site administrator can transform a SharePoint site's functionality by toggling a feature on or off in the
user interface. Features make it easier to activate or deactivate functionality in the course of a
deployment, and help administrators to easily transform the template or definition of a site. Features
can be hidden, which prevents site users from manually deactivating them.
When you implement new site functionality as features, you make it easier for administrators to control
sites and enforce a governance plan. A technique named feature stapling enables you to attach a
feature to all new instances of sites that use a given site definition without modifying the site definition.
This lets you control the features that users of your service can access. For more information, see
Using Features (http://go.microsoft.com/fwlink/?LinkID=183450.
SharePoint Designer
You can manage how Microsoft SharePoint Designer 2010 is used in an organization at either the Web
application level or the site collection level. You can control the following types of access to SharePoint
Designer 2010:
Enable or disable SharePoint Designer 2010 use for an entire application or site collection.
If you want to ensure that all designers and owners within a specific site collection can use
SharePoint Designer 2010, enable this setting at the site collection level.
Enable or disable the ability to detach pages from the site definition.
If you want to preserve the branding for all sites in a site collection, you should not allow users to
make changes that would result in detaching the page from the site definition.
Enable or disable master pages and page layouts in SharePoint Designer 2010.
If you do not want users to see the master pages and page layouts for a site, you should disable
this setting.
Sandboxing
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. Solutions that you deploy in a sandbox are called sandboxed solutions. Code Access
Security (CAS) limits the operations that these solutions can perform.
A member of the Farm Administrators group must implement the sandboxed environment before any
sandboxed solutions can be uploaded. Site collection administrators can upload and activate
sandboxed solutions. 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.
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. Only members of the Farm
Administrators group can block sandboxed solutions, configure load balancing, and reset exceeded
quotas.
For more information, see Plan sandboxed solutions (SharePoint Server 2010).
Information management
Information management in SharePoint Server 2010 comprises organizing, retrieving, acquiring, and
maintaining information.
This section describes SharePoint Server 2010 features that are useful for managing documents,
records, and digital assets, and for planning eDiscovery.
Document management
Document management controls the lifecycle of documents in an organization how they are created,
reviewed, and published, and how they are ultimately disposed of or retained. It includes policies that
implement auditing, document retention, labeling, and barcodes (to ensure that printed content can be
correlated with corresponding electronic versions). Policies can be implemented to help an organization
comply with legally mandated requirements, such as the need to retain records. For more information,
see Information management policy planning (SharePoint Server 2010).
An organization that uses the Microsoft Office system client applications and SharePoint Server 2010
can enforce policies both on the server and in the client applications.
Content approval
The content approval process gives site members who have approver permissions control of the
publication of content. An owner of a document library can enable content approval for a document
library or Web pages library and can optionally associate a workflow with the library to run the approval
process.
Use content approval to formalize and control the process of making content available to an audience.
For example, an enterprise that publishes content might require a legal review and approval before
publishing the content.
For more information, see Versioning, content approval, and check-out planning (SharePoint Server
2010).
Versioning
Versioning is the method by which successive iterations of a document are numbered and saved in
SharePoint Server 2010. As a governance tool, versioning prevents users with read permissions from
viewing drafts of documents.
For more information, see Versioning, content approval, and check-out planning (SharePoint Server
2010).
Records management
Records management is the process by which an organization determines the types of information that
should be considered records, how records should be managed while they are active, and for how long
each type of record should be retained. Records management includes the performance of recordsrelated tasks such as disposing of expired records, or locating and protecting records that are related to
external events such as lawsuits.
Records management enables you to do the following:
Determine whether you will manage e-mail within SharePoint Server 2010 or within an e-mail
application.
Determine how to translate social content such as blogs, wikis, or My Site Web sites into records.
For more information, see Records management planning (SharePoint Server 2010).
managing digital assets enables an organization to exert tighter control over brand-sensitive content,
and helps to ensure that only approved assets for products are made available to the appropriate users.
For more information, see Versioning, content approval, and check-out planning (SharePoint Server
2010).
eDiscovery
Electronic discovery, or eDiscovery, is the process of locating and producing electronic information to
support events such as litigation, audits, or investigations. If you use Microsoft SharePoint Server 2010
to manage any electronic information, you should consider eDiscovery when you plan your SharePoint
Server solution. Auditing, expiration policies, and search considerations should be part of your planning
process, which should be completed before the need to use eDiscovery arises.
We recommend that you enable the auditing policy in all site collections that contain active document
libraries. You should also consider implementing an expiration policy to delete documents automatically
when they are no longer needed. For more information, see Planning for eDiscovery (SharePoint
Server 2010).
The Auditing policy feature logs events and operations that are performed on documents and list
items. You can configure Auditing to log events such as editing documents, viewing them, or
changing a document's permissions level.
The Expiration policy feature helps dispose of content in a consistent way that can be tracked and
managed. For example, the policy can delete a document, or define a workflow task to have
SharePoint Server 2010 route the document for permission to destroy it.
The Labeling policy feature specifies a label to associate with a type of document or list item.
Labels are searchable text areas that SharePoint Server 2010 generates based on metadata
properties and formatting that you specify.
The Barcode policy feature enables you to track a physical copy of a document. You create a
unique identifier value for a document and then insert a barcode image of that value in the
document. By default, barcodes are compliant with the common Code 39 standard (ANSI/AIM BC1-
1995, Code 39), and you can use the object model of the policies to plug in other barcode
providers.
Information management policy reports help you monitor how consistently your organization uses
policies. Because information management policies are often implemented to help an organization
comply with regulations, frequent monitoring of policy usage can help you ensure that an organization is
compliant. For more general information about information management policies, see Information
management policy planning (SharePoint Server 2010).
Content types
Content types enable enterprises to organize, manage, and handle content in a consistent way. They
define the attributes of a type of list item, document, or folder. Each content type can specify metadata
properties to associate with items of its type, available workflows, templates, and information
management policies. Use content types to encourage consistent information management policies,
metadata requirements, and other policies. To govern content types, consider associating event
receivers and workflows with the forms that are used to modify the content types.
For more information, see Content type and workflow planning (SharePoint Server 2010).
consider restricting permissions on the destination site collection so that users cannot make changes
directly to content that is stored within that site collection.
Permissions to content on the destination server farm will usually differ from permissions to content on
the source server farm. In many publishing solutions, the destination server farm authenticates users by
using a different AD DS domain than the one used in an authoring or staging environment, and there
might not be a trust relationship between the two domains. For more information, see Content
deployment overview (SharePoint Server 2010).
Service-level agreements
Content storage
Security
The governance policies that you develop must be publicized to your enterprise. Maintain a Web
site that describes the set of services.
Quota templates
A quota template consists of values that specify how much data can be stored in a site collection.
The value also indicates the limit that triggers an e-mail alert to the site collection administrator.
You can associate quotas with sites that are offered at various service levels to govern the growth
of SharePoint Server in an enterprise. Note that you can set separate quotas for sandboxed
solutions.
based on a custom workflow. For various levels of service, you can govern the size of such sites
and control their longevity.
Customization policy
A primary benefit of using sites that are based on SharePoint Server is the ability of site owners to
customize them. For example, site owners might change a site's appearance or provide new
functionality, such as a custom Web Part or workflow. Carefully consider the type and amount of
customization that is allowed and supported at each level of service because some types of
customizations are global to the server farm.
Consider using sandboxed solutions to limit the impact of customizations in a farm. For example,
services that allow self-service site creation may include thousands of sites that share a single Web
application. In this instance, you could limit customizations to only those sites that are supported by
the user interface, such as adding Web Parts to pages. If you use sandboxed solutions, the
customizations apply only to that site collection. In a service that provides virtual or physical
isolation of the server farm, such as for an enterprise intranet site, you might allow a large range of
customizations, such as custom event handlers and workflows.
At the Web application level, there is also the ability to control whether SharePoint Designer can be
used to modify sites in that Web application. For more information, see Configure settings for a
Web application (SharePoint Server 2010).
For a full discussion of the range of customizations that SharePoint Server 2010 supports and the
risks and benefits of supporting each type of customization at various levels of service, see the
white paper SharePoint Products and Technologies customization policy
(http://go.microsoft.com/fwlink/?linkid=92311). Although this content is specifically written about
Microsoft Office SharePoint Server 2007, much of the information applies to SharePoint Server
2010. For more information about sandboxed solutions, see Plan for sandboxed solutions
(SharePoint Server 2010).
Asset classification
You can develop and implement a classification system for sites and content supported by a
service that identifies the impact and value of the information to an organization. For example,
metadata can classify content as having high, moderate, or low business impact or value.
Impact is related to exposure and content: if the content were distributed externally, would it
hurt your business? Or would it expose personally-identifiable information about users or
customers? If so, that's high business impact content.
Value is related to availability: if the content were unavailable, could it impact the enterprise's
day-to-day business? If so, that's high value content.
Each classification would then cause other behaviors for example you could require that high
business impact content be transferred only in encrypted form, or you could require that an
approval process be run on medium impact content before it can be published on a public-facing
Web site. Perhaps high business impact content should be hosted on a service that provides more
restrictive policy and aggressive disaster recovery processes.
Lifecycle management
A service should provide lifecycle guidelines or tools for active sites and unused sites. For lower
service levels, you could, for example, implement a mechanism that lets only site owners create
sites that last six months before the user would have to extend the request for the site. Also, you
can implement a tool that looks for sites that have not been used for a specified period of time and
deletes them. Lifecycle management also means integrating a service with the records
management tools and processes in place in an organization. For more information, see Records
management planning (SharePoint Server 2010).
Data protection
Features that provide data protection include backup and recovery. You can vary the level of data
protection based on the service levels that you provide. Higher levels may require charges to the
site owner. For each level of service, plan the frequency at which you will back up sites and the
response time you will guarantee for restoring sites. For more information, see Plan for backup and
recovery (SharePoint Server 2010) and the Business Continuity Management Resource Center
(http://go.microsoft.com/fwlink/?LinkID=199235).
Training
A well-trained user community provides benefits to IT. It reduces support calls, encourages
adoption, helps ensure proper use of SharePoint Server, and helps users understand their
responsibilities when using the SharePoint Server service. For each level of service, consider an
appropriate level of training requiring as a requirement. Even for a basic service, users with site
administration permission will have access to many features that affect the functionality of the site.
Online training, such as tutorials, for these users can help them take the best advantage of their
site.
Training for a user community is available at SharePoint 2010 Resources for End Users
(http://go.microsoft.com/fwlink/?LinkID=199542)
Short-lived, single-purpose workspaces for planning events and managing meetings and projects
Enterprise intranet sites to broadcast information and supply services to the entire organization
Consider dividing a SharePoint Server service into a set of services that meets the range of needs in an
enterprise. Each user of a particular service would get the same level of support and would be charged
a similar cost. As more complex or costly solutions are needed, you could add new services to support
them. One benefit of this approach is that you can introduce one service at a time, which eases the
burden on your IT staff. Work with executive stakeholders, business division leaders, and IT managers
to determine the requirements of each level of service and the order in which services are introduced.
The following table illustrates a sample approach to creating a tiered set of services. In this example,
three service levels are offered. Note that provided values are not recommendations but are supplied
as samples:
Sample approach to a set of services
Description
Basic Service
Advanced Service
It is intended to support
short-lived sites along
with small team sites.
Premium Service
The topology is
scalable depending on
the agreed upon
hosting requirements
between the customer
and the hosting team.
Example
Collaboration site to
plan an event
Scope
Site collection
Web application
Basic Service
Advanced Service
Premium Service
Customizations
Only customizations
Some server-side
available in the user
customizations, such as
interface are supported. custom site templates,
are supported. All
customizations are
tested and reviewed
before being accepted
for deployment.
Alternatively,
customizations are
allowed only as
sandboxed solutions.
Extensive
customizations are
permitted. All
customizations are
tested and reviewed
before being accepted
for deployment.
Alternatively,
customizations are
allowed only as
sandboxed solutions.
Cost to user
None to minimal
Moderate
High
Self-service
provisioning?
Yes
No
No
500 MB
2 GB
Unlimited
Backup frequency
Twice weekly
Daily
Daily
Backups maintained
for
14 days
30 days
60 days
Service-level agreements
Establish service-level agreements for each service level. A service-level agreement should include the
following items at a minimum:
The length of time and approvals that are necessary to create a site.
What's the process to create a site? Who's involved?
Operational-level agreements that specify the teams that perform operations and the frequency.
Which team applies updates? Which team performs backups? How frequently do these occur?
Negotiated performance targets for the first load of a site, subsequent loads, and performance at
remote locations.
Multi-language support.
Which languages will be installed and supported?
See Also
Track or block SharePoint Server 2010 installations
Governance in SharePoint Server 2010 (http://go.microsoft.com/fwlink/?LinkID=200590)
SharePoint - Sample Service Level Agreement (SLA) - "From the Field" blog
(http://go.microsoft.com/fwlink/?LinkId=203973)
Sample template: SharePoint Products and Technologies governance plan
(http://go.microsoft.com/fwlink/?LinkID=162169)
Points to available resources to help an organizations information architects plan and implement
an information architecture in SharePoint Server 2010
Presents a case study that illustrates the benefit of effective information architecture to promote
collaboration across an enterprise
In this article:
The goals and implementation of information architecture will vary depending on the type of solution
you are creating. For example:
If you are designing the information architecture of an enterprises intranet portal site, you might
focus on the following considerations:
When you design the information architecture of an Internet presence Web site, you might focus on
the following considerations:
How the site is organized into a hierarchy of sub-sites and Web pages
Information architecture decisions may also affect the flow of information. For example, in an intranet
portal site, information may initially be drafted in sites that are not available to most members of an
organization. To make that information discoverable, useful, and actionable across the organization, the
information architecture design could include methods and guidelines for exposing information in
locations that are available to all users.
Depending on the size of an organization, you should consider including an information architect who is
responsible for designing and implementing solutions based on SharePoint Server on your team.
Information architects have expertise in structuring information in large Web environments such as
intranet portal sites.
Information architecture meets the regulatory requirements, privacy needs, and security goals of
the enterprise.
Information architecture meets an organizations business goals. Remember that a poorly designed
and governed information architecture can subtract from an organizations effectiveness. Well
designed and governed information architecture can multiply that organizations effectiveness.
Governing content
When you create a plan that governs content in an environment, consider the following best practices:
Use workflows and approval for document centers and site pages wherever official
documentation is stored.
Use version history and version control to maintain a history and master document.
Use content types with auditing and expiration for document libraries to manage document
lifecycle.
Identify important corporate assets and sites that contain personally identifiable information be
sure that they are properly secured and audited.
Integrate the information architecture with the environment's search strategy. Take advantage of
enterprise search features like:
Best Bets
People search
Content sources
Authoritative pages
Keywords
Scopes
Thesauruses
Important:
Governance doesn't work without user adoption and compliance. End-user training and
education, in addition to good content and search, is the key to user adoption.
As you create a governance plan, determine the rules or policies that you need to have in place for the
following types of items:
Pages
Lists
Documents
Records
Rich media
Wikis
Blogs
Anonymous comments
Anonymous access
External data
When you think about content, consider the balance between the following factors and determine which
of these factors is the highest priority for each type of content:
Availability Content needs to be available when users need it, and users need to know where
and how they can get to it.
Redundancy Exposing a single copy of content in multiple places rather than duplicating the
content reduces redundancy and provides one version of the truth.
Access Consider who has access to the content. If it should be secure, is it?
Map the preferred content lifecycle. What steps need to happen when a list item, document, or page is
created, updated, or deleted? For best results, start with what you want to use long term rather than a
temporary solution.
As part of a governance plan, determine who does what. For example, who creates sites, who controls
keywords in Search, or who manages the metadata and ensures that the metadata is applied correctly?
Much of this should be explained by the document and records management plans but also consider
the storage costs for the content. Understand the capacity planning limits for documents and items, and
keep performance and scale in mind.
Important:
A governance team should identify a process for periodically reviewing the site to ensure that it
complies with a governance plan.
Access
Compliance officers
You also need to include compliance officers or others who are responsible for ensuring that legal
or compliance requirements are met.
Include influential information workers to ensure that the processes and structure the team sets up
will be usable.
Executive stakeholders
The executive stakeholder is a key participant in the governance team. Although this person may
not attend all sessions of the governance team, inclusion of this role is essential so that the
governance team is kept accountable to its mission. Furthermore, the executive sponsor helps to
ensure that benchmarks are used that help mark the progress of the ongoing effort of governing
information architecture.
Along with these primary stakeholders, depending on the type of enterprise, you may decide to include
other participants, such as the following:
Development leaders
Trainers
IT managers
Financial stakeholders
The best way to run the information architecture governance team will be based on the culture and
methodologies of an enterprise. However, here are some general guidelines:
Meet regularly and allow enough time, especially in early sessions, to consider every issue.
Exemplify good information architecture practices in deliberations. For example, you might use a
well-designed collaboration site to record deliberations and maintain artifacts.
Report to the wider organization (and gather requirements across the organization) by using a Web
site and online surveys.
Consider piloting information architecture practices in some divisions of the organization and using
that experience to incrementally improve the information architecture practices across the wider
organization.
See
Document libraries
Navigation
Metadata
Content expiration
Records management
Moving content
Templates
Content approval
Social computing
Provide central access to content and applications such as expense report submissions
The next step in the evolution of Fabrikams information architecture had begun.
The following diagram illustrates the initial architecture of the Fabrikam portal. A corporate portal at the
top of the architecture provided a central location from which to broadcast general corporate
information. At the next level, a few sites provided shared resources to the organization, such as human
resources, legal services, and financial services.
Below the shared resources level in the Fabrikam architecture were divisional portals for the various
regional offices of Fabrikam. Initially, North America, Europe, and East Asia were piloted. Gradually
other divisional portals were added: Australia, Africa, and South America. Each divisional portal
contained repositories for its policies, product designs, research and development, and customer data.
The result of the change from collaboration that is based on file shares to collaboration that is based on
portals was disappointing to the sponsors of the portal effort and to the Fabrikam work force. Content
chaos had not been alleviated. It had just moved from file shares to portal sites.
Because key functions at Fabrikam, such as materials purchasing, customer relationships, parts design
and specification, and even some human resources processes occurred at the divisional level, each
division had developed local content to support these functions. Policy statements, parts blueprints and
specifications, personnel documents, documents related to customer relationships, and similar content
was created and managed locally. Templates and metadata for these documents diverged across
divisional portals. As metadata became more specific to each division it became more difficult to search
for content from one division to another. When a document was found across divisions, it was often
copied to another divisions portal to make it more accessible. This process made it increasingly difficult
to find the official version of a document as duplicates proliferated. Also, some documents in divisional
portals were secured in such a way that employees of other divisions could not view them. Although
this was appropriate when a document was being drafted, there was no guideline for when and how a
document should be made viewable across the enterprise.
To address the growing discontent with the portal, the company formed a strategy team was formed,
which was comprised of managers from across the various Fabrikam divisions, core IT team members,
and portal architects. The team had the following tasks:
The team that developed the portal strategy concluded that the current portal taxonomys divisional
organization was the root to the problem. Each division was duplicating processes and hoarding
content without taking advantage of the expertise and best practices developed in peer divisions. This
contributed to poor collaboration, wasted resources, and content chaos. Their insight was to move
towards a more operational organization for the enterprise portal. Shared resources such as
information technology and finance were currently exposed in the portal taxonomy above (and visible
to) all divisions. The team that developed the portal strategy concluded that other operational
disciplines, such as customer relationships, vendor relationships, plant configuration, and research and
design should be moved from divisional silos to the same level as the shared resources in the sites
hierarchy. Instead of the contents location, metadata would associate information with the various
divisions.
The following illustration is the revised architecture of the Fabrikam portal:
Reorganizing the Fabrikam portal in this way had the additional benefit of forcing collaboration across
parts of the enterprise that had similar responsibilities but were not accustomed to working together on
standards and processes. For example, storing design files in a central repository forced the various
divisions to standardize on a tool for designing automobile parts. This change saved money and
reduced training time. Also, best practices in design were made available for engineers to view across
the enterprise and to use as a basis for new design projects.
Here is a summary of the benefits of the redesigned portal architecture:
Standardizes metadata.
Standardizes templates.
The redesign and reimplementation of the portal was just the start. The team that developed the portal
strategy received executive sponsorship to become a governance team for the portal. As a result, the
group represented the needs of portal users by developing policies and standards. This helped ensure
accountability across the organization and provided a forum for evaluating and evolving the portal
both to improve portal features but also to help maximize the return on the enterprises investment in
the SharePoint Server technology. The governance body oversaw the following elements:
Metadata standards
Template standards
Guidelines for when information needed to be made available across the enterprise
Training standards
Fabrikam started seeing a large return on its portal investment. A year into the project, the strategy
team did an inventory of content and found that out of 500,000 documents, only 230 were duplicates.
The company identified millions of dollars in savings due to the centralization of efforts. And a survey of
employees showed a large increase in satisfaction with the portal. Collaboration was healthy at
Fabrikam.
See Also
Governance Resource Center (http://go.microsoft.com/fwlink/?LinkID=200590)
Site and solution governance (SharePoint Server 2010)
Governance overview (SharePoint Server 2010)
Plan information architecture for Web content management
In this section
When an organization want to run code for employees on a production SharePoint Server 2010
site, and that code has not been stringently code reviewed and tested.
When a hoster wants to let the owners of hosted SharePoint Server 2010 sites upload and run
custom code.
This article introduces the concepts that are related to sandboxed solutions, explains the differences
between sandboxed solutions and solutions that are deployed on the farm, and summarizes how
sandboxed solutions are deployed and run. This article does not contain detailed procedures for
configuring sandboxing or for deploying sandboxed solutions.
In this article:
The following list identifies several of the components that you might deploy in a sandbox:
Web Parts
Event receivers
Feature receivers
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 collections 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 Server 2010 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 Server 2010 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 Server
2010. 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 Server 2010 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 Server 2010 terminates the sandbox worker process. If the combination of all
sandboxed solutions in the site collection exceeds the site collections resource quota, SharePoint
Server 2010 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.
Access a database.
Write to disk.
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
Aspect
Farm
Sandbox
Deployment process
Add the solution, and then Upload the solution to a site collection, and then
deploy it to the farm.
activate it in the site collection.
Farm administrator.
Data access
Unrestricted.
Monitoring
Not monitored.
Load balancing
Solution functionality
Unrestricted.
Solutions can be added to a production SharePoint Server 2010 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
Sandboxed solutions administration (SharePoint Server 2010)
Plan for sandboxed solutions (SharePoint Server 2010)
Sandboxed solutions architecture (http://go.microsoft.com/fwlink/?LinkId=177368)
Deploying a sandboxed solution (http://go.microsoft.com/fwlink/?LinkId=177369)
When you want to load balance solutions between multiple SharePoint Server 2010 servers.
When an organization wants to run code for employees on a production SharePoint Server 2010
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 Server 2010 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.
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 Server 2010
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.
For more information, see Sandboxed solutions overview (SharePoint Server 2010).
If you determine that a sandboxed solution is consistently misusing server resources, you can block
that solution until the developer can correct the situation. For more information about blocking and
unblocking sandboxed solutions, see Block or unblock a sandboxed solution (SharePoint Server 2010).
The default values that are assigned to sandboxed solution quotas are listed in the following table.
Resource
Description
Units
Resources
per Point
Absolute
Limit
AbnormalProcessTerminationCount
Abnormally
terminated
process
occurrence
CPUExecutionTime
CPU Execution
Time for site
seconds
3,600
60
CriticalExceptionCount
Critical
Exception
Events
events
10
InvocationCount
Solution
Invocation
Events
events
<TBD>
<TBD>
PercentProcessorTime
Percent CPU
usage by
solution
percentage
85
100
ProcessCPUCycles
Solution CPU
cycles
cycles
1 x10^11
1 x10^11
ProcessHandleCount
Windows
handles count
items
10,000
1,000
ProcessIOBytes
Windows
handles count
items
1 x10^8
ProcessThreadCount
Thread count in
overall process
instances
10,000
200
ProcessVirtualBytes
Memory
consumed
bytes
1.0x10^9
SharePointDatabaseQueryCount
Number of
SharePoint
database
queries
instances
20
100
SharePointDatabaseQueryTime
Elapsed time to
execute query
seconds
120
60
UnhandledExceptionCount
Number of
unhandled
exceptions
instances
50
UnresponsiveProcessCount
Number of
unresponsive
processes
instances
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 organizations 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.
Audiences
My Site settings
For more information, see User Profile service overview (SharePoint Server 2010).
A My Networks page that shows the people, interests, and activities that a user is tracking.
A My Content page that lists shared and personal documents, shared pictures, and libraries, lists,
discussion boards, and surveys that a user owns.
Information on the My Profile page can be targeted to the user only or to a users manager, team,
colleagues, or everyone. Planning for My Site Web sites includes preparing to set up My Site Web
sites, planning social tags and notes, planning My Site Web site policies and permissions, and planning
personalization sites.
For more information, see My Site Web sites overview (SharePoint Server 2010).
Users who you want to have a My Site Web site and the appropriate permissions for those users
The user profile information that you want to synchronize with directory services or business
systems
The policies that will be applied for viewing user profile information in the public profile
For more information, see Plan for My Site Web sites (SharePoint Server 2010).
Social tags, which allow users to save items of interest, organize all information for a project, and
connect to others who share their interests.
Ratings, which allow users to assess the value of content against a scale, for example, one through
five stars.
Bookmarklets, which enable users to add tags and notes to pages that are outside of the
SharePoint environment, for example, Web sites that are external to an enterprise, and then have
those tags and notes appear on the Tags and Notes tab of their My Site.
This article contains information to help you plan for using the social tagging features of SharePoint
Server 2010 in your enterprise, and includes key steps to follow in the planning process.
For more information, see Privacy and security implications of social tagging (SharePoint Server 2010).
Architecture
Related services
User profiles contain detailed information about individuals in an organization. A user profile
organizes and displays all of the properties related to each user together with social tags,
documents and other items related to that user.
Profile synchronization provides a reliable way to synchronize user, group, and organization
profile information that is stored in the SharePoint Server 2010 profile store with profile information
that is stored in directory services across the enterprise.
Audiences enables organizations to target content to users based on their job or task, as defined
by their membership in a SharePoint Server group or distribution list, by the organizational reporting
structure, or by the public properties in their user profiles.
My Site Host a dedicated site for hosting My Site Web sites. A My Site Host is needed in order to
deploy the social features of SharePoint Server.
My Site Web site a personal site that gives users in your organization a central location to
manage and store documents, links, and colleagues.
Social tags and notes enables users to add social tags to documents, to other SharePoint
Server items, and to other items, such as external Web pages and blog posts. Users can also leave
impromptu notes on profile pages of a My Site Web site or any SharePoint Server page.
Administrators can delete all tags for employees when they leave the company or remove a tag
they do not want.
These features make it possible for users in an organization to share information and to stay informed
about what is happening within the organization. Social tags, for example, enable users to tag and track
the information they are most interested in. Users can be alerted when people they work with author
new blog posts or when there is a change in organizational metadata. They can also see how people
relate to organizations and how organizations relate to sites.
Like other shared services in SharePoint Server 2010, the User Profile service is easy to deploy and set
up. Farm administrators can delegate the management of all or part of the features of the User Profile
service to one or more service application administrators. For more information, see Assign or remove
administrators to a service application (SharePoint Server 2010).
Architecture
When you create an instance of the User Profile service, SharePoint Server creates three databases for
storing user profile information and associated data:
a social tagging database - used to store social tags and notes created by users. Each social tag
and note is associated with a profile ID.
Each of these databases can be accessed by SharePoint sites, My Site Web sites, and Team Sites by
using the User Profile service. This provides a dynamic, personalized experience for the users in an
organization. For more information about these databases, see Databases used by SharePoint 2010
Products.
The User Profile service can be managed by the appropriate business group and advertised in the
corporate resource center. One administrator can manage all areas of the User Profile service. As an
alternative, areas can be isolated and managed by different administrators who need not know about
the existence of other areas of the service. For example, one administrator can manage My Site Web
sites while a different administrator manages social tags and notes. The User Profile service can be
restricted and available only to certain departments or sets of sites based on business need, security
restrictions, and budgets. For more information about the shared services architecture in SharePoint
Server, see Logical architecture components (SharePoint Server 2010).
Related services
The User Profile service relies on other shared services to implement the full range of social computing
features in SharePoint Server. These related shared services include the following:
Managed Metadata Service - makes it possible to use managed metadata and share content
types across site collections and Web applications. For more information, see Managed metadata
service application overview (SharePoint Server 2010)
See Also
Plan for social computing and collaboration (SharePoint Server 2010)
User Profile Service administration (SharePoint Server 2010)
connections between User Profile Services, directory services, and line-of-business applications
the user profile properties and organization profile properties that are needed
how user profiles are used by other personalization features, such as personalization sites
In this article:
Before reading this article, you should understand the concepts described in User Profile service
overview (SharePoint Server 2010).
User profiles are more than merely groupings of imported and custom properties about users in an
organization. The properties are also used to display information about the relationships of each user to
other users in an organization. Profile subtypes can be used to create a different set of properties for a
different set of users. For example, you can create a subtype that categorizes a user as either an intern
or a full-time employee.
Every site that uses the same User Profile service application receives the same set of properties from
the user profile store and displays them in the site's user information list. This also includes a list of
documents that are shared by each user. For more information about creating a User Profile service
application, see Create, edit, or delete a User Profile service application (SharePoint Server 2010).
What are the existing and planned directory services? These services will form the foundation for
user profiles. Determine the properties that you will use for your core user profiles based on those
that are relevant across the organization (or across the User Profile Service in an organization that
has multiple sets of User Profile Service applications). Properties that can be used when finding
users, creating audiences to use when targeting content, and establishing relationships between
colleagues and workgroups are important. Start by reviewing the list of properties in directory
services, followed by the default properties provided by SharePoint Server 2010 and modify that list
according to these considerations.
What areas of your organization require different user profile subtypes? For example, do you can
create user profile subtypes for full-time employees, part-time employees, and interns?
Which line-of-business applications that you use have information about users? Which properties
can be mapped to the properties of directory services?
Based on the business intelligence planning, what other properties of business applications that are
not related to users might be useful for users in the organization? You can use these properties in
personalized Web Parts to target business data based on audiences.
How many user records are you planning to import from all sources, and how often do you want to
synchronize these records between the SharePoint profile store and these sources? The frequency
of scheduled synchronization will depend on the number of records, how heavily you are using
personalization features, and when you can schedule synchronizations to have the least effect on
performance and availability. Let the IT administrators know this information so they can include it
in their deployment planning.
Which user profile properties at the site level do you expect? In some organizations, this might be
dictated centrally. At other organizations, this decision might be left to the discretion of each site
collection administrator.
Indexed
Replicated
AboutMe
yes
yes
AccountName
yes
no
ADGuid
no
no
Assistant
no
no
CellPhone
yes
yes
Department
yes
yes
Fax
yes
no
FirstName
yes
yes
HomePhone
yes
no
LastName
yes
yes
Manager
no
no
Office
yes
yes
PersonalSpace
no
no
PictureURL
yes
yes
PreferredName
yes
yes
PublicSiteRedirect
no
no
QuickLinks
yes
no
SID
no
no
SPS-AboutUs
yes
no
SPS-Birthday
yes
no
SPS-ClaimID
no
no
SPS-ClaimProviderID
no
no
SPS-ClaimProviderType
no
no
SPS-DataSource
yes
no
SPS-DisplayOrder
no
no
SPS-DistinguishedName
no
no
SPS-DontSuggestList
no
no
SPS-Dotted-line
no
no
SPS-EmailOptin
no
no
SPS-FormerNames
yes
no
SPS-HireDate
yes
no
SPS-Interests
yes
no
SPS-JobTitle
yes
no
SPS-LastColleagueAdded
no
no
SPS-LastKeywordAdded
yes
no
SPS-Location
yes
no
SPS-LogoURL
yes
no
SPS-MasterAccountName
no
no
SPS-MemberOf
yes
no
SPS-MySiteUpgrade
no
no
SPS-ObjectExists
no
no
SPS-OWAUrl
no
no
SPS-Parent
yes
no
SPS-ParentType
yes
no
SPS-PastProjects
yes
no
SPS-Peers
no
no
SPS-PhoneticDisplayName
yes
no
SPS-PhoneticFirstName
yes
no
SPS-PhoneticLastName
yes
no
SPS-ProxyAddresses
no
no
SPS-ResourceAccountName
no
no
SPS-ResourceSID
no
no
SPS-Responsibility
yes
yes
SPS-SavedAccountName
no
no
SPS-SavedSID
no
no
SPS-School
yes
no
SPS-Section-BasicInfo
yes
no
SPS-Section-ContactInfo
yes
no
SPS-Section-CustomProperties
yes
no
SPS-Section-Delegation
yes
no
SPS-Section-Details
yes
no
SPS-Section-OrganizationMembers
yes
no
SPS-Section-Preferences
yes
no
SPS-SipAddress
no
yes
SPS-Skills
yes
no
SPS-SourceObjectDN
no
no
SPS-StatusNotes
no
no
SPS-Team-Site
no
no
SPS-TimeZone
no
no
Title
yes
yes
UserName
yes
yes
UserProfile_GUID
yes
no
WebSite
no
yes
WorkEmail
yes
yes
WorkPhone
yes
yes
colleagues
Memberships
In SharePoint Server 2010, a users profile contains a list of all memberships and distribution lists to
which a user belongs. Information in a distribution list is synchronized with the directory service, LDAP
service, or line-of-business applications during profile synchronization. The User Profile to SharePoint
Full Sync synchronizes the timer job Membership information. By default this timer job will add site
memberships to a user profile. User profiles contain information about users site memberships only if
they belong to the default membership group for a site.
Colleagues
Colleagues can include each user's immediate associates which includes one's manager, peers, and
direct reports. Organizations that have key relationships that cross groups of users, managers or other
users might want to add people to the Colleagues lists for certain groups. You can also configure
Outlook to export colleague suggestions to users in SharePoint Server. For more information, see
Enable SharePoint Server 2010 Colleague in Outlook 2010.
People search results contain links to the public profiles of each user and links to contact them by
e-mail or messaging programs.
Expertise finding used with people search and expertise tagging to help users locate people
within an organization who have identified themselves as having significant experience with a
particular subject. If e-mail analysis is enabled, colleague suggestions are imported from Outlook if
using Microsoft Office Outlook 2007 e-mail. If Microsoft Outlook 2010 is used, colleagues, and
keywords are analyzed and suggestions are made to the user based on this analysis. Although email analysis can be enabled in Outlook, users can opt out of this feature if they want. For more
information about e-mail analysis, see Enable SharePoint Server 2010 Colleague in Outlook 2010.
When planning for users, you might want to consider supplementing the default people search scope
and Search Center tab with customized search scopes and tabs for more specific groups of users.
User Profile Service administrators will want to consult the information architecture and site hierarchy to
identify key business concepts that might relate to specific groups of users who might be sought out by
users across sites. Then, User Profile Service administrators can work with the Search Service
administrator to develop search scopes and people search tabs for those specific groups. They can
also use their knowledge of the user profiles they manage to identify other useful groups of users and
create additional specific search scopes and search tabs for those groups.
Site collection administrators can create site-level search scopes for users who are members of their
site collection.
People search planning also feeds back into user profile planning. Initial planning might reveal
individuals or groups of users whom you want to make it easier to find, but the right properties might not
exist to allow for those users to be found easily.
identifying the directory services and line-of-business applications with which you want to
synchronize profile information
A key planning principle is consistency across content sources for all users in an organization.
The User Profile Service enables you to collect information about users in an organization across
directory services and business applications so that consistent and timely information is always
available. Information about users is synchronized across the deployment to all site collections that use
the same User Profile Service application. This information can also be used by personalization
features to increase the value of collaboration and relationships in an organization.
When planning synchronization of user profiles, you should include the following tasks:
Start with the default properties of user profiles in SharePoint Server 2010.
Identify connections to directory services that will provide supplemental information for properties of
user profiles.
Consider additional business data that enables you to connect users to line-of-business
applications.
SharePoint Server 2010 includes the ability to do a two-way sync of user profile properties between
SharePoint Server 2010 and directory services. The User Profile Service maintains the connections
with the relevant business applications and updates the properties of user profiles during regularly
scheduled synchronizations of all relevant content sources.
For more information about Profile Synchronization, see Plan for profile synchronization (SharePoint
Server 2010).
See Also
Plan for social computing and collaboration (SharePoint Server 2010)
Understanding Forefront Identity Manager 2010 (http://go.microsoft.com/fwlink/?LinkID=165841)
the effect on performance and capacity of servers that are running Profile Services.
In this article:
Default policies
Before reading this article, you should understand the concepts described in Plan user profiles
(SharePoint Server 2010).
Default policies
Every personalization feature and property exposed in user profiles and personal sites has a
recommended default policy that can be customized based on the needs of the organization. Each
policy has two parts: the policy setting and the default visibility setting.
Policy setting Some personalization features provide important information for key business
processes in an organization, whereas other information might be inappropriate for sharing across
an organization. Between these extremes is the information that should be shared among some
users but not made available to everyone. In the latter case, you must create policies to address
these specific situations. You should work with representatives from the business side of your
organization to determine the appropriate features or properties. The policy settings are:
Enabled The feature is visible to the administrator of the User Profile service and to users
other than the User Profile Service administrator, depending on the default visibility setting.
Required This property must contain information and the information is shared based on
default access. Forms that contain these features or properties cannot be submitted until the
required information is provided. For example, the Manager property is often mandatory so that
it can be used to provide information for the Organization feature and audiences based on an
organization's reporting hierarchy.
Optional The property is created but its values might not be provided automatically. Each
user decides whether to provide values for the property or leave the property empty. For
example, the My Colleagues feature is optional. Instead of being blank, the full list of
colleagues, which includes everyone in a users My Team list, is visible by default to users who
have access. Users can decide to opt out by removing colleagues from the list, or expand the
list by adding colleagues.
Disabled The property or feature is visible only to the User Profile Service administrator. It
does not appear in personalized sites or Web Parts, and it cannot be shared.
User Override Properties that have the User Override option selected enable users to change
the default visibility settings for those properties. With this option selected, each user can
decide who can see the values they entered for the property. If this option is not selected, only
administrators of the User Profile Service can change default access settings.
Note:
Properties and features can be replicated to other SharePoint sites if the default access
policy is set to Everyone and the User Override option is not selected.
Default visibility setting The visibility setting determines who can see information for a specific
personalization feature. Available settings include the following:
Everyone Every user who has viewer permissions to the site can see the relevant
information.
My Colleagues Every user in this user's My Colleagues list can see the information for this
user.
My Team Every colleague in the user's immediate team, a subset of the My Colleagues list,
can see the information.
My Manager Only the user and the user's immediate manager can see the information.
Only Me Only the user and the administrator of the User Profile service can see the
information.
Which properties should be mandatory? Some properties such as account name, preferred
name, work telephone number, department, title, and work e-mail address are mandatory by
default and cannot be overridden or changed by users. In most organizations, these properties are
key ways to enable collaboration and develop relationships across the organization. SharePoint
Server 2010 also uses many of them to enable other features, such as colleagues and audiences.
For more information, see Plan audiences.
Which properties should be visible to everyone? By default, most properties are visible to
everyone, but sensitive information can be configured to have limited visibility. For example, a
company that has many employees in the field might decide that mobile phone information is
important for everyone to see. Other organizations might choose to keep all non-work telephone
numbers private.
Which properties can be changed by users? Some properties can be made available without
requiring that users provide information or allow a certain action to be performed. For example,
some users might not want automatic population of colleague lists. Other users might want to
change the default visibility setting for a property.
When planning the policy setting for a property, consider the following factors:
Condition
optional
required
Condition
optional
required
administrators expect
consistent and meaningful
values for the property.
The property will rarely be
used.
When you plan the default visibility settings for an organizations policies, consider the following factors:
Condition
Action
Condition
Action
See Also
Plan for social computing and collaboration (SharePoint Server 2010)
Managing privacy (SharePoint Server 2010)
Plan permissions
Below is a list of things that you have to do before you enable Profile Synchronization. These planning
steps should be performed in the order given.
Service
Users
Groups
Incremental
Yes
Yes
Yes
Yes
No
Yes
Novell eDirectory
(LDAP) 8.7.3
Yes
No
No
Yes
No
Yes
You must know the full path of the forest name and the full path of the domain controller name to create
a connection between SharePoint Server 2010 and a domain service.
Although you can connect to more than one directory service from a single User Profile service
application, we recommend that you create only one Profile Synchronization connection per directory
service forest. If, however, you have logon information in one directory service forest and resource
information in another forest, you should create one connection to the logon forest and one connection
to the resource forest. For more information about cross-forest deployments, see Resolve accounts
across multiple forests (SharePoint Server 2010).
Business systems
Profile information that is stored in business systems, such as SAP or Siebel, can be added to profile
information contained in the SharePoint Server 2010 profile store by using the Business Data
Connectivity service. For example, if a profile that contains the name and employee number for a user
has been imported to the SharePoint Server profile store from AD DS, you can augment that
information with the hire date for that employee from a business system such as Siebel or SAP. To do
this, you must know the name of the Business Data Connectivity service that you will use to connect to
the business systems that you have identified.
Exporting profile properties from SharePoint Server 2010 to business systems, importing new profiles
from business systems to the SharePoint Server profile store, and synchronizing incrementally between
business systems and SharePoint Server 2010 are not supported. For more information about the
Business Data Connectivity service, see Business Data Connectivity service administration overview
(SharePoint Server 2010).
Important:
If you are connecting to a Business Data Connectivity service, the Business Data Connectivity
model must include Finders and Specific Finders methods in SharePoint Server 2010. For
more information about Finders and Specific Finders methods, see Designing a Business Data
Connectivity Model (http://go.microsoft.com/fwlink/?LinkId=179316).
Tip:
You should first test Profile Synchronization with a Business Data Connectivity service by using
external lists. For more information about external lists, see Business Connectivity Services
security overview (SharePoint Server 2010).
Plan permissions
After you have identified the directory services and business systems with which you want to
synchronize profiles, you must identify the credentials that you will use to connect to them. You will
need to contact the appropriate administrator to get these credentials. Depending on which directory
service or business system you are connecting to and the type of profile synchronization you wish to
perform, the account, whose credentials the connection will use, must have specific permissions in
order to perform profile synchronization.
Note:
We recommend that you determine the required permissions for the environment before setting
up Profile Synchronization. For more specific information about setting up Profile
Synchronization, see Configure profile synchronization (SharePoint Server 2010).
The following tables identify the account types and the permissions that the directory service or
business system must grant, depending on the functions that the connection will perform.
Active Directory Domain Services (AD DS)
Function
Account type
Permissions
Connect
Function
Account type
Permissions
Function
Account type
Permissions
Incremental synchronization
SunOne (LDAP)
Function
Account type
Permissions
Connect
SunOne user
Full synchronization
SunOne user
Incremental synchronization
SunOne user
Function
Account type
Permissions
Connect
Full synchronization
None
Not supported.
Account type
Permissions
Connect
Must be a member of an
administrative group.
Full synchronization
Same as connect.
Incremental synchronization
Same as connect.
Account type
Permissions
Augmentation of profile
information in the SharePoint
profile store from a business
system
System.Boolean
Boolean
System.String
System.DateTime
Date/DateTime
System.Int64
BigInteger
System.Int32
BigInteger/Integer
System.Int16
BigInteger/Integer
System.SByte
BigInteger/Integer
System.UInt64
BigInteger
System.UInt32
BigInteger/Integer
System.UInt16
BigInteger/Integer
System.Byte
BigInteger/Integer
System.Single
Float
System.Double
Float
page in Central Administration. You can also create custom properties in SharePoint Server 2010 and
map those properties to the corresponding properties in a directory service or business system. We
recommend that you identify property mappings before you set up Profile Synchronization.
By default, some user profile properties, such as first name, last name, and so on are automatically
mapped to their corresponding properties in the external directory service or business system. For
example, the following properties are automatically mapped when using AD DS:
Users:
AD DS attribute
<dn>
SPS-DistinguishedName
objectSid
SID
manager
Manager
displayName
PreferredName
givenName
FirstName
Sn
LastName
PhoneticDisplayName
PhoneticDisplayName
PhoneticFirstName
PhoneticFirstName
PhoneticLastName
PhoneticLastName
telephoneNumber
WorkPhone
WorkEmail
physicalDeliveryOfficeName
Office
title
Title
department
Department
sAMAccountName
UserName
wWWHomePage
PublicSiteRedirect
SIP Address
proxyAddresses
Groups:
AD DS attribute
<dn>
SourceReference
objectSid
SID
displayName
PreferredName
description
Description
url
Url
member
Member
groupType
GroupType
MailNickName
Important:
In order to synchronize user profile pictures between Microsoft SharePoint Server, AD DS, and
Outlook 2010 by using the Microsoft Outlook Social Connector, you must set the Data Source
Connection for the Picture property mapping to Export. For more information about
synchronizing user profile pictures, see Enable SharePoint Server 2010 Colleague in Outlook
2010.
displays the Profile Synchronization settings for that instance of the User Profile service. These
numbers display progress for each individual container and the numbers reset each time
synchronization starts on a container. After all containers have been synchronized, you will see the total
number of user and organization profiles imported into the SharePoint Server 2010 profile store. You
can also click on the link in this section to see detailed data for a completed profile synchronization job.
See Also
User Profile service overview (SharePoint Server 2010)
Plan policies for user profiles (SharePoint Server 2010)
Plan user profiles (SharePoint Server 2010)
Related features
A profile for each user where users can share their expertise, profile pictures, and so on
A newsfeed for tracking activities such as social tags, status updates, and comments by colleague
A tag and note tool that helps you conveniently tag or post notes on sites directly from a Web
browser
A shared picture library, shared document library, and personal document library
The ability to add custom Web Parts such as a Really Simple Syndication (RSS) viewer for viewing
RSS feeds from blogs, news sources, and so on
to personalize the data presented on a users My Site Web site. In order to provision My Site Web sites
and enable social computing features such as social tagging and newsfeeds, you must enable the User
Profile service. For more information about the User Profile service, see User Profile service overview
(SharePoint Server 2010).
My Site Host
The My Site Host is a kind of site collection that is used for hosting the profile and newsfeed parts of My
Site Web sites. The content part of My Site Web sites is hosted in its own site collection. My Site Host
site collections are not created automatically in SharePoint Server 2010. An administrator of the User
Profile service application must first create a My Site Host site collection before provisioning My Site
Web sites.
Trusted My Site Host locations
In organizations where multiple server farms are deployed or where multiple User Profile Service
applications are configured, users can create multiple My Site Web sites. For example, in a geographic
deployment with a central farm in Europe and a regional farm in Africa, a user can click the My Site link
when browsing content hosted by either farm. Consequently, the user can create a My Site Web site on
the Europe farm and a My Site Web site on the Africa farm.
If your organization includes multiple farms or multiple User Profile service applications that host My
Site Web sites, you can prevent users from creating multiple My Site Web sites by using the Trusted My
Site Host Locations feature. This feature enables you to specify trusted My Site locations. When trusted
My Site locations are specified, users are redirected to the My Site that is intended for their user
accounts, regardless of where they are browsing when they click the link to create a My Site Web site.
This feature ensures that each user creates only one My Site Web site in the organization.
Pages
My Site Web sites have three distinct views:
a My Content page that lists shared documents, personal documents, pictures, libraries, lists,
discussion boards, and surveys that a user owns
Users can navigate between these pages by clicking the links on the My Site link bar at the top of the
page.
Related features
My Site Web sites rely on the following related features:
Profile Synchronization
Enables you to integrate profile information that you have stored in a directory service such as
Active Directory Domain Services (AD DS) or a business system, such as SAP or Siebel, with
SharePoint Server 2010. For more information about Profile Synchronization, see Plan for profile
synchronization (SharePoint Server 2010).
Expertise tagging
Lets users list the areas in which they have experience as part of their profile. This information can
be used by other users in the organization to locate subject matter experts for a particular area.
People Search
Lets users find people by department, job title, knowledge, expertise, and common interests.
See Also
Plan for social computing and collaboration (SharePoint Server 2010)
Service application and service management (SharePoint Server 2010)
Before reading this article, you should understand the concepts described in My Site Web sites
overview (SharePoint Server 2010).
Users who you want to have a My Site Web site and the appropriate permissions for those users
The user profile information that you want to synchronize with directory services or business
systems
The policies that will be applied for viewing user profile information in the public profile
The following sections discuss the steps that help you to prepare for a successful deployment of My
Site Web sites in an enterprise.
My Site host
The My Site host is a special site collection that is used for hosting the profile and newsfeed parts of My
Site Web sites. The content part of My Site Web sites is hosted in its own site collection. My Site Host
site collections are not created automatically in SharePoint Server 2010. However, a site collection that
contains the content portion of a My Site Web site is created automatically for each user. An
administrator of a User Profile service application must first create a My Site Host site collection before
provisioning My Site Web sites. This template must be provisioned only once per User Profile Service
application.
For optimal performance, we recommend that you create the My Site host in a dedicated Web
application.
Geographically distributed deployments
Administrators of User Profile Service applications can add links to trusted My Site host locations to
give users access to My Site Web sites on multiple farms or multiple User Profile Service applications.
In most cases, links to trusted My Site host locations will be targeted to individual users or groups of
users based on an identified business need. The links can be maintained and changed over time as
business and user needs change. When you specify trusted My Site host locations, users are
redirected to the My Site Web site that is intended for their user accounts, regardless of where they are
browsing, when they click the link to create a My Site Web site. This feature ensures that each user
creates only one My Site Web site in the organization.
When planning for My Site Web sites, you must consider the location of the users in the organization
and the number of farms or User Profile service applications that will host My Site Web sites.
Self-service site creation
You must plan for self-service site creation to enable users to create their own My Site Web sites. Selfservice site creation can be enabled for the Web application that hosts My Site Web sites. Users must
have Create Personal Site permissions to create their own My Site Web site. By default, this
permission is enabled in SharePoint Server 2010 for all authenticated users. For more information
about Create Personal Site permissions, see the user permissions section later in this article.
In addition to planning which users in an organization will have a My Site Web site, you must also plan
which My Site Web site features will be available to each user. These features include the following:
We recommend that you use security groups to manage permissions. The following table provides
guidance for configuring permissions:
Permission
Guidance
application. This information can also be used by personalization features to increase the value of
collaboration and relationships in an organization.
If you plan to synchronize user profiles, you should include the following tasks:
Start with the default properties of user profiles in SharePoint Server 2010.
Identify connections to directory services that will provide supplemental information for properties of
user profiles.
Consider additional business data that enables you to connect users to line-of-business
applications.
For more information about steps that help you to plan for profile synchronization, see Plan for profile
synchronization (SharePoint Server 2010).
Users can also find people through the use of e-mail analysis in Outlook 2010. If e-mail analysis is
enabled, colleague suggestions are imported from Outlook if you are using Microsoft Office Outlook
2007 e-mail. If you are using Microsoft Outlook 2010, SharePoint Server analyzes sent e-mail
messages and makes colleague and keyword suggestions based on this analysis. Users can then add
these colleagues and keywords to their profile.
Although e-mail analysis can be enabled for all users in Outlook or just for specific groups by using
group policy, users can opt out of this feature. If e-mail analysis is disabled for all users, individual users
can still opt in. For more information about e-mail analysis, see Enable SharePoint Server 2010
Colleague in Outlook 2010.
A newsfeed that is used for tracking activities such as social tags, status updates, and comments
by colleague.
By default, the newsfeed feature is disabled. To enable the newsfeed feature, you must start the
Activity Feed timer job. Newsfeed events are kept for 14 days and can be deleted sooner by
running the Activity Feed Clean up timer job. After the Activity feed timer job is started, users can
follow colleague activities on the newsfeed page of their My Site Web sites. Users can only view
activities in the newsfeed for which they have permission. However, activity creators cannot
otherwise configure activities that other users can see. When planning My Site Web sites, you
should consider privacy implications before enabling this feature and provide mitigations based on
your requirements.
A tag and note tool that helps you conveniently use a Web browser to tag or post notes on sites.
The tag and note tool can be turned on or off in Central Administration by using the Use Social
Features permission. This setting applies to all users who have the Use Social Features
permission. Users can also add tags or notes to content outside of SharePoint Server 2010 by
using the bookmarklet tool.
When planning My Site Web sites, you must consider both the benefits and the impacts of enabling
these features.
Global audiences Global audiences are defined by properties in a User Profile service
application. Global audiences include audiences that are defined by relationships (reporting
structures), as well as other properties.
Windows security groups and distribution lists The Windows security groups that are
available when you are creating audiences are those that are imported when user profiles
synchronized with the User Profile service application.
The distribution lists that are available when you are creating audiences are those that are imported
when user profiles are imported into the User Profile service application.
For more information about including security groups and distribution lists in the User Profile
Service application, see Plan user profiles (SharePoint Server 2010).
Note:
Although SharePoint groups can be used with Web Parts to target content, they cannot be
used to define audiences.
An audience is defined by a collection of one or more audience rules and by whether all or only one of
the audience rules must be met when evaluating membership. An audience rule can be based on
membership in a Windows security group, membership in a distribution list, position in an organizational
hierarchy, or by a user profile property. To define each audience rule, you must select an operand,
operator, and value. An example of an audience rule based on membership in a Windows security
group is as follows:
Element
Value
Operand
User
Operator
Member of
Value
Sales
Once an audience has been defined, it must be compiled on a regular basis because the underlying
user profile properties and membership in directory services and groups can frequently change. An
administrator schedules the timer job that controls when audiences are compiled.
Planning for audiences and content targeting is usually approached in the following stages:
1. Plan key audiences.
2. Plan content targeting to audiences.
We recommend that you following this process for planning audiences in an initial deployment:
1. Record the central purpose for each site collection and site.
In general, each site collection has a focused set of business processes that are associated with
specific groups of users.
2. Determine the smallest number of audiences that can enable you to target content as needed.
You may want to start by identifying requirements in the existing environment. For example,
existing working teams, cross-group projects, key business processes, and site structure may
include groups of users that can be translated to audiences.
3. Record all existing distribution lists and existing SharePoint groups, and map them to your
audience needs.
4. Identify additional audiences that must be defined.
You may be able to create the audiences that you want from distribution lists, and Windows
security groups. However, it is common to require additional audiences that are defined by user
profile properties.
Planning audiences may also help you find gaps in plans for user profiles and distribution groups.
To support a specific audience, you may find that you need to add more profile properties or
distribution groups.
5. Identify additional SharePoint groups that must be defined.
As you determine which Web Parts will target audiences or SharePoint groups, you may find gaps
in plans for SharePoint groups. To support a specific target, you may find that you need more
SharePoint groups.
By the end of the audience planning process, you should have a list of audiences that meet the needs
of the groups of users who are using each site collection.
For Microsoft Office 2010 client applications, a User Profile service administrator can define the
links that display in the SharePoint locations, and set the audiences that each link is visible to.
On My Site Web sites, a User Profile service administrator can set audiences for the My Site
navigation links that appear on the top bar.
For My Site scenarios in which users must have access to one or more additional My Site host
locations, a User Profile service administrator can manage a list of Trusted My Site host locations,
and then target each trusted location to the audiences that need to view it.
In an environment with multiple My Site host locations, audiences also determine in which trusted
My Site host location a My Site Web site is created.
In an environment in which a User Profile service application and audiences are configured, site
administrators can use Web Parts to target content by audience.
Site administrators can use SharePoint groups to target content to Web Parts both in environments
that are running a User Profile service application, and in environments that are not running a User
Profile service application.
Another group of Web Parts that are frequently used with audiences are filters. Filters can be
connected to other Web Parts so that they only display results based on certain properties, such as
audience. Filters are often connected to business data Web Parts to enable users to target business
data based on audience.
When another group starts to use the site, a second audience rule is added based on the User
operand and a different Reports Under value.
Users from a distribution list also begin to use the personalization site. To accommodate them,
another new audience rule that is based on the User operand, the Member of operator, and the
value for a distribution list that contains these additional users is added.
Later, the manager of a branch office requests that his staff be granted access to the
personalization site. The administrator creates a new audience rule with the Property operand, by
using the Office property.
Finally, the administrator is asked to grant access to the personalization site to all financial
analysts. The administrator creates another audience rule, based on the Title property.
Social tags, which enable users to save items of interest, organize all information for a project, and
connect to others who share their interests.
The Note Board, which enables users to add comments about Web pages, documents, and library
items to be tracked in a central location.
Ratings, which are social tags that allow users to assess the value of content against a scale, for
example, one through five stars.
Bookmarklets, which enable users to add tags and notes to pages that are outside a SharePoint
environment. For example, if users add tags to a page on an Internet Web site, those tags and
notes can appear on the Tags and Notes tab of their My Site Web site.
Social tags, the Note Board, and ratings are controlled by the Use Social Features permission of the
User Profile service.
Social tags
Social tags are user-generated words or phrases that describe pieces of information. They are not part
of a formal taxonomy, such as the enterprise keywords in the term store associated with a Managed
Metadata service application in SharePoint Server, or the International Statistical Classification of
Diseases and Related Health Problems (ICD) codes used in medicine to represent specific diagnoses.
Users create social tags based on their subjective experience with a specific piece of information.
Social tags consist of a user identity, an item URL, and the tag itself. Social tags are stored in the social
tagging database that is part of the User Profile service. By default, all authenticated users can add
social tags to documents and other SharePoint items. Anyone with the Manage Social Data permission
can delete a tag.
Tag clouds provide an aggregate view of the tags that a group of users have applied to a single piece of
information. SharePoint Server 2010 includes a tag cloud Web Part that appears by default on a My
Site Web site. Administrators and users can filter the tag cloud to display tags that are used by the
owner of the My Site Web site, specific groups, or everyone who can view the My Site Web site. The
display can also be filtered based on date and language. Frequently used tags are displayed in large,
bold text, whereas tags that are less often used appear in smaller text. Each tag can display an
associated number that indicates how many times the tag was applied.
Note Board
The Note Board is a Web Part that enables users to make impromptu comments on any SharePoint
Server 2010 site. Users can also make Note Board comments on the My Profile pages of others or on
their own page. Anonymous users cannot add notes.
The Note Board helps users express thoughts in their immediate context rather than having to move to
e-mail, instant messaging, or phone. For example, users can make comments about a Web page while
they are viewing the page. Other users can then see the comment and a link to the Web page, which
they can visit if they are interested in the subject. This immediacy helps My Site Web sites and My
Profile pages become centralized places to manage public conversations.
Ratings
A rating in SharePoint Server 2010 is an assessment or classification of content on a scale according to
how well the content meets specific criteria. Ratings show an average score that can range from 1 to
100, and a popup window that displays additional information about the score. Users can rate items in a
SharePoint list, document library, and individual Web pages. Users do not require write permission on
an item in order to rate it.
Each rating consists of a user identity, an item URL, and the rating itself. A rating also contains the date
and time when the rating was applied. Ratings are stored in a table in the same database that stores
social tags.
By default, ratings support is enabled across a farm. However, to use ratings in a specific site
collection, ratings must first be enabled for that site collection. Ratings can be enabled on any site
template if support for ratings is enabled on the farm. By default, the Ratings feature is on for the
Publishing Portal site template.
Bookmarklets
A bookmarklet is a JavaScript control that users can save as a bookmark in their browsers.
Bookmarklets enable users in a SharePoint environment to tag, write notes about, and rate items on
Web sites outside the SharePoint environmentfor example, Internet Web sitesand then share those
tags, notes, and ratings with their team and colleagues.
Note:
Although tags themselves are always public, you can choose to prevent others from seeing that
you have tagged a specific item. Notes are always public.
When a user tags an external Web site, the http://my/_layouts page within the user profile of the user
opens. All tags and notes entered on that page will then appear on both the Tags and Notes tab of the
user's My Site Web site and the user's profile page, where the user's team and colleagues can see
them.
A bookmarklet consists of a user identity, a word or phrase, and a URL for the content being tagged.
Users can make bookmarklets on the Tags and Notes tab of their own Profile page private; they can
also delete a bookmarklet.
Business benefits
The social tagging features of SharePoint Server 2010 help businesses to improve collaboration and to
improve the discoverability of business information.
Improve collaboration to encourage innovation
User profiles enable users to identify themselves and find experts. Note Board comments can identify a
group of users who are interested in a specific topic. Suggestions for a user's My Colleagues list can be
derived from these social connections.
Improve the discoverability of business information
Social tagging features can help increase the visibility of high-quality content and identify the latest
version of content. For example, a My Site Web site feed can notify a user when a Web page is tagged
with a tag that the user has included in his or her user profile. These features can also integrate with
business intelligence applications to connect users with enterprise data that they need to do their jobs
without having to leave their SharePoint environments.
IT benefits
The social tagging features of SharePoint Server 2010 give IT organizations the following capabilities:
1. Set policies that control group activities while allowing users to manage some settings themselves,
which can reduce the need for IT to be involved in the day-to-day management of some social
tagging activities.
2. Grant a limited set of read-only permissions to anonymous users, to restrict their access to selected
site collections.
3. Plan ahead of time to use the scalable architecture of SharePoint Server 2010 to enable gradual
rollouts and add capacity when the number of users increases.
4. Manage social tagging features at the level of Central Administration, a site collection, or a site. IT
administrators can assign a user to be the administrator for a site collection or a site and give the
designated administrator the Manage Social Data permission for that scope. This distribution of
administrative responsibilities helps IT use resources more efficiently.
5. Use social computing functionality to relieve IT staff of some support activities. For example, a
hosted Enterprise wiki can encourage users to share tips and tricks, or an RSS feed can send
support updates.
6. Integrate new tools with existing applications to maintain a consistent user experience, which can
encourage adoption and minimize training costs.
Users must understand the security and privacy implications of social tagging features. For example,
they must understand that when someone tags a site or document, the title and URL of that site or
document is broadcast to anyone who lists that user as a colleague on their My Site Web site and to
anyone who has that tag as an interest in their user profile. For more information, see Privacy and
security implications of social tagging (SharePoint Server 2010).
Recommendations
Private tags
Security trimming
Private tags
A user who adds a tag to a Web page can indicate that the tag is private. Other people cannot see the
fact that the tag was added to the Web page. Other people do not see the tag in the users tag cloud,
unless the user who added the tag also applied the same tag to another Web page without making the
tag private.
Ratings control
The ratings control only displays the aggregate rating that an item has received. It does not display
which users rated the item or what individual ratings were provided.
Security trimming
Adding a tag, a note, or a rating to a Web page creates an activity. Before SharePoint Server displays
an activity, it uses a component called the security trimmer to determine whether the current user has
permission to view the Web page that the activity applies to. If the user is not permitted to view the Web
page, SharePoint Server does not display the activity.
As the search service crawls Web pages, it records the permissions that are required to view each Web
page. The security trimmer uses this information to determine whether a given user has permission to
view a specific Web page. If the security trimmer has insufficient information to determine whether a
user has permission to view a Web page, it errs on the side of caution and reports that the user does
not have permission to view the Web page. As a result, if the search service has not crawled a Web
page, activities that relate to that Web page will not be displayed.
Note:
There is one exception: when you view your own My Profile page, all of your activities are
displayed. See How social tagging information is displayed is displayed for an explanation of
why this happens.
My Profile pages
Every user who is known to the User Profile Service has a My Profile page, which shows information
about the user. When you view someone elses My Profile page, the content that you see is security
trimmed. The content that you see on your own My Profile page is not security trimmed.
The Tags and Notes tab of a users My Profile page contains a tag cloud that consists of the tags that
the user has added to Web pages. Everyone can view the tag cloud. The tag cloud that you see on
your own My Profile page contains both public and private tags. The tag cloud that you see on
someone elses My Profile page contains only public tags.
When you select a tag in the tag cloud, activities that are associated with the tag are displayed in the
Activities section. If you are viewing someone elses My Profile page, the activities are security
trimmed. Therefore, you could see a tag that did not appear to have any activities associated with it.
The Overview tab of a users My Profile page contains a section titled Recent Activities. As its name
implies, this section contains a list of the users recent social tagging activities. The list is security
trimmed, unless you are viewing your own My Profile page.
The Overview tab of a users My Profile page also contains a Note Board. Notes that people have
added to the users My Profile page are displayed here. All notes are public.
Following
You can express your interest in knowing when a specific tag is used by following the tag. When you
follow a tag, you are notified every time someone adds the tag to a Web page. These notifications are
security trimmed so that if someone adds the tag to a page that you do not have permission to view,
you are not notified of that activity. The fact that you are following a tag is public; people can view a list
of everyone who is following a tag from the tags Tag Profile page.
You can express interest in knowing about the social tagging activity of someone else by adding the
person as a colleague. When you make someone your colleague, you are notified every time the
person adds a tag, a note, or a rating to a Web page. The information is security trimmed so that you
only see activities that are related to Web pages that you have permission to view.
Note:
The security trimmer removes ratings that are applied to list items. It does not remove ratings
that are applied to other items, such as documents and Web pages.
Web pages
When you add a tag or a note to a Web page within the SharePoint Server farm, you can see the tags
and notes that other users have added to the Web page. You can see all notes, but you can only see
public tags.
Recommendations
Although SharePoint Server 2010 provides features that help protect privacy and security when social
tagging is used, you should take additional actions to benefit the most.
Educate users about which aspects of their social tagging activity are public and which are private.
Train users to mark tags as private when they do not want other users to see that they have applied
a tag to a Web page.
Carefully evaluate all custom code before you deploy it. A custom application can access social
tagging data by using the SharePoint Server 2010 social tagging object model, or directly from the
database. An application can access the same social tagging data that would be available to the
account it runs under. If the application runs under an account that has database administrator
permissions or under an account that is a User Profile Service administrator and has Manage
Social Metadata permission, the application can access all social tagging information, such as
private tags, without security trimming. Ensure that custom applications only present information
that meets your organizations privacy and security standards.
Consider a custom security trimmer. If SharePoint Servers security trimmer has insufficient
information to determine whether a user has permission to view a Web page, it errs on the side of
caution and reports that the user does not have permission. One result of this behavior is that tags,
notes, and ratings that are added to external Web sites are always trimmed. If this behavior is not
appropriate for your situation, consider implementing a custom security trimmer. For a sample
custom security trimmer, see ISocialSecurityTrimmer Interface
(http://go.microsoft.com/fwlink/?LinkId=188524&clcid=0x409).
When the permissions that are required to access a Web site change, have the search service
crawl the Web site again. The security trimmer will not recognize the new permission requirements
until the site is crawled again.
See Also
Social tagging overview (SharePoint Server 2010)
Managing privacy (SharePoint Server 2010)
Plan user profiles (SharePoint Server 2010)
Tagging (http://go.microsoft.com/fwlink/?LinkId=188521)
Editorial control Administrators of a Team Site, or anyone with Full Control permissions on a
Team Site, can allow a subset of users to edit entries and allow all users to read the entries.
Version control Users can view previous versions of an entry and see when and by whom
changes were made. If the changes were incorrect or inappropriate, the entry could be rolled back
to an earlier version.
In SharePoint Server 2010, the Team Site template home page is a wiki page. The Enterprise Wiki
template uses the publishing features of SharePoint Server 2010 to add page ratings, managed
metadata, and customization capabilities. Integration with Microsoft SharePoint Designer 2010 makes it
easy to modify the display of content by changing page layouts and implement consistent branding by
changing master pages. For more information, see Sites and site collections overview (SharePoint
Server 2010).
The following table suggests several criteria to consider when choosing between a Team Site template
and an Enterprise Wiki template. For more information, see Enterprise wiki planning (SharePoint Server
2010).
Team Site
Enterprise Wiki
Team Site
Enterprise Wiki
Enterprise Wiki
Evaluate prerequisites
names for these roles, or one person might assume more than one role.) The group should consider
the following questions during its decision-making process:
What purpose will the Enterprise Wiki serve? An Enterprise Wiki should have a clear purpose.
For example, it might address a specific business goal or it might be a centralized body of
knowledge about a specific topic, process, or business problem. The goal is to provide a space
where members of a virtual community can create, change, or remove content, which might include
content that previous authors created. For example, you might want to use an Enterprise Wiki to
enable employees to contribute content to Tips and Tricks pages about the business applications
that an organization uses. However, if you determine that that you must have a more structured
way to exchange knowledge, and that most communication will be one-to-many instead of the more
free-form wiki behavior, you should consider using either a team site with Web Edit or a blog.
How many users should be allowed to contribute? Several factors will influence this decision.
Will you be able to support increasing growth and a need for increased network and server
capacity? Should you determine key contributors from each business area who will become the
primary contributors? Are there legal considerations about who can contribute?
How can we control who has access to the Enterprise Wiki? In theory, all members of an
organization can be granted access to contribute, edit, and update content in an Enterprise Wiki for
the organization. If you have to separate information by group, consider using either a team site
with Web Edit or a blog.
How much control should be implemented over the content? Unlike blogs, which are
designed for a more structured knowledge exchange, a wiki encourages informal contributions.
However, an organization might have guidelines or requirements for handling specific kinds of
content or content about a specific subject. You should also consider how to address inappropriate
or inaccurate entries.
The following table compares the features of an Enterprise Wiki with those of a Team Site.
Team Site
Enterprise Wiki
Team Site
Enterprise Wiki
Enterprise Wiki
Enterprise wiki
Enterprise Wiki
Enterprise Wiki
If you decide to implement an Enterprise Wiki in an organization, continue with Evaluate prerequisites.
Evaluate prerequisites
You must complete the following tasks before you can create an Enterprise Wiki.
Create a Managed Metadata service application to provide storage for social tags and notes. For
more information, see Managed metadata service application overview (SharePoint Server 2010).
Create a User Profile service application if you plan to use the Enterprise Wiki with My Site Web
sites. For more information, see User Profile service overview (SharePoint Server 2010).
To manage the site collection where the Enterprise Wiki is located, you must have at least site
collection administrator permissions.
Specific paths
Additional paths
Specific paths
You can use specific paths in Microsoft SharePoint Server 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.
Additional paths
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 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.
Microsoft Office 2010 or it can be installed separately from Microsoft Download Center
(http://go.microsoft.com/fwlink/?LinkID=48516).
For more information, see Plan for SharePoint Workspace 2010.
Identify users and analyze document usage (SharePoint Server 2010) describes the creation of a
document management planning team and provides guidance on how to determine the types of
documents used in your enterprise and how to analyze the stages in the documents' life cycles.
Metadata-based routing and storage overview (SharePoint Server 2010) provides information to
help solution planners and designers understand how metadata-based routing and storage using
the Content Organizer Feature can be used as part of a comprehensive document management
solution.
Metadata-based routing and storage planning (SharePoint Server 2010) provides information to
help solution planners and designers plan a metadata-based routing and storage solution by using
the Content Organizer Feature.
Metadata navigation overview (SharePoint Server 2010) provides information to help solution
planners and designers understand how the Metadata Navigation and Filtering Feature can be
used to locate content in a document library based on metadata.
Document library planning (SharePoint Server 2010) describes how to use document libraries to
organize documents in your enterprise.
Enterprise content storage planning (SharePoint Server 2010) contains information to help solution
planners and designers properly plan enterprise content management solutions from small to large
scale.
Document Sets planning (SharePoint Server 2010) describes how to use document sets to
organize a collection of documents as a single project or work product.
Content type and workflow planning (SharePoint Server 2010) describes how to plan content types,
which are the SharePoint Server mechanism to define and share the attributes of documents, list
items, and folders. This article also describes how to use the SharePoint Server workflow feature to
design document-related processes.
Information management policy planning (SharePoint Server 2010) describes how to plan
enterprise-wide policies that will help your organization comply with regulatory and legal
obligations, in addition to best practices such as document audits and proper document retention.
Versioning, content approval, and check-out planning (SharePoint Server 2010) describes how to
plan content control by using versioning, check-in and check-out, and approval for publishing
content.
Co-authoring overview (SharePoint Server 2010) describes the feature and provides administrators
an understanding of the settings that can be used to manage co-authoring.
Document management controls the life cycle of documents in your organization how they are
created, reviewed, and published, and how they are ultimately disposed of or retained. Although the
term "management" implies control of information from the top of the organization, an effective
document management system should reflect the culture of the organization that is using it. The tools
you use for document management should be flexible enough to allow you to tightly control a
document's life cycle, if that fits your enterprise's culture and goals, but also to let you implement a
more loosely structured system, if that better suits your enterprise.
What types of documents and other content can be created within an organization.
How to move documents within the organization as team members contribute to the documents'
creation, review, approval, publication, and disposition.
What policies to apply to documents so that document-related actions are audited, documents are
retained or disposed of properly, and content that is important to the organization is protected.
Whether a document has to be converted from one format to another as it moves through the
stages of its life cycle.
How documents are treated as corporate records, which must be retained according to legal
requirements and corporate guidelines.
SharePoint Server 2010 includes features that implement all these aspects of document management.
To ensure that information workers can easily take advantage of these capabilities without having to
depart from their day-to-day operations and familiar tools, applications in the the Microsoft Office
system such as Microsoft Outlook and Microsoft Word also include features that support each
stage in a document's life cycle.
8. Plan policies For each content type, plan information management policies to ensure that
documents are properly audited, retained, labeled, and otherwise handled according to your
organization's institutional and legal requirements. SharePoint Server 2010 includes policies that
implement auditing, document retention, labeling, and barcodes (to ensure that printed content can
be correlated with corresponding electronic versions). For more information, see Information
management policy planning (SharePoint Server 2010).
Identify users
Worksheets
Identify users
To determine the stakeholders and participants in your document management solution, you can use a
survey to collect this information. For example, your survey might contain the following questions:
Who deploys and maintains the servers on which documents are stored?
Worksheet action
Position
Types of documents
Role
Financial analyst
Author
Technical writer
Financial model
Web page
Financial analyst
Manager
Financial model
Technical editor
Reviewer
Editor
Web page
Customer
Reader
Financial model
Web page
Corporate lawyer
Manager
Financial model
Content approver
Web page
Server administrator
All
IT specialist
Database manager
All
Database specialist
Compliance officer
All
Legal specialist
Records manager
All
Records manager
Site manager
All
Content publisher
Site administrator
All
Content auditor
Identifying content stakeholders can help you ensure that your document management solution is
comprehensive and that you design sites and document libraries that suit your enterprise's content
needs and processes.
Which physical server topology you will need to implement your solution.
Document type, such as equity research note, employee performance review, internal memo, or
product specification.
Purpose of each document type, such as "provides customers with recommendations about
equities along with supporting data."
Author of each document type (it is helpful to list the role of the author such as "financial analyst
or "product manager" rather than individual names).
Format of the document. If the document has to be converted from one format to another at any
point in its life cycle, record that information.
Other roles that apply to the document's life cycle, such as "technical reviewer" or "copy editor."
Location of the document, such as "client computer," "Web server," or "file server." Note that this
question could have multiple answers, for example when a document is authored on a client
computer and then published to a Web server.
How readers view the document, such as from a Web page or a file share.
Worksheet action
Type
Purpose
Author
Equity
research
note
Gives
Financial
premium
analyst
customers
of a financial
service
guidance on
User
Format
Other Roles
Locations
Customer
DOCX (for
authoring);
PDF (for
publishing)
Reviewer
(technical);
reviewer
(legal);
approver; copy
editor; records
Authoring
site
Testing
site
Internet
Records
Type
Purpose
Author
User
Format
whether to
buy or sell
one or more
stocks
Other Roles
Locations
manager; site
administrator
repository
Analysis The separate authoring and publishing formats require a format conversion. The large
number of reviewers requires one or more workflows (business processes implemented on the server).
The four sites (authoring, testing, Internet, and records repository) require mechanisms for moving the
content from one site to another. The need to archive the content in a corporate records repository and
the regulatory implications of publishing equities advice require corporate policies and best practices,
such as content auditing and retention.
Type
Purpose
Author
User
Format
Other Roles
Locations
Employee
performance
review
Evaluates the
performance
of an
employee
including selfevaluation
and
manager's
evaluation
Information
worker;
manager
Managers;
human
resources
specialists
.DOC
Reviewer
(human
resources);
reviewer
(legal);
approver
(upper
manager);
records
manager
Client
computer
E-mail
server (as
attachmen
t)
Corporate
Web
server
Corporate
records
repository
Analysis Two authors and multiple reviewers require one or more workflows. The document is
handled by many different people, then resides in a corporate Web server (presumably highly secured)
and is archived in a records repository. The sensitive nature of this content requires Information Rights
Management (IRM) on the desktops and servers, in addition to corporate policies and best practices
(such as auditing) that protect the employee's privacy and the enterprise's legal standing.
Worksheets
Use the following worksheets to record the information discussed in this article:
Upload a document to a Drop-off library. A Drop off library is created in every site in which the
Content Organizer Feature is been activated.
Use an E-mail drop-off zone. By using Exchange, documents can be e-mailed to the site, where
metadata then must be applied before being routed by rules.
Submit to a Record Center site as part of a documents life cycle or expiration. For example, as part
of a workflow or retention policy.
Once a document is uploaded, based on the document's metadata, Content Organizer can route the
document to a specified folder or automatically create a new folder. For example,
A new folder can be created as a child of the target folder, because the target folder of the routing
rule grew too large.
Folders are created for each new value in a field (must be a required field for the content type). For
example, if you have taxonomy with 100 terms, folders can be created automatically for each of
those 100 terms, each folder being created the first time Content Organizer evaluates a document
that has a particular tag.
New folders will inherit settings from the parent folder. New folders can then also have additional rules
that define additional parameters such as permissions, default metadata, retention policies, and
workflows that the documents in them will inherit. For example;
By tagging a document with "Corporate Affairs", the document is routed to a folder that has more
restricted permissions than other documents in different folders in the library. This lets metadata to
effectively apply permissions to a document in SharePoint.
By tagging a document with "Accounting", the document is routed to a folder where it is subject to a
retention policy insuring the document is saved.
By tagging a document with "Human Resources", the document is then routed to a folder where
any number of additional metadata tags is applied. This can reduce the need for users to apply lots
of metadata tags reducing time that is spent tagging and potential errors when tagging.
By tagging content with metadata and by using Content Organizer settings and rules, in combination,
you can effectively determine, route, store, and apply additional content parameters to any document in
your organization.
Redirect Users to the Drop Off Library If enabled, this setting specifies that users are redirected
to the Drop Off Library when uploading content in a site that has one or more content organizer
rules applied. If this setting is disabled, users can bypass using the content organizer and upload
files directly to a library or folder. This setting applies only when uploading a document by using the
document library page or by using a client application.
Sending to Another Site If enabled, rules can be created to redirect uploads in the current site to
be sent to another site that also has the Content Organizer Feature activated.
Folder Partitioning If enabled, subfolders will be created when a specified number of items in a
folder is exceeded.
Duplicate Submissions This option specifies whether to use SharePoint versioning or append
unique characters to the end of duplicate file names if a document is uploaded that has the same
name as a document that is already in the destination library.
Rule Managers This setting specifies users or groups that can create rules and respond to and
manage uploaded content that do not match any rule.
Submission Points This non-configurable setting provides Web service and URL, and an E-mail
address that you can use to set up other sites or e-mail messaging to send content to the site.
When creating a new Send To location in Central Administration, this is the service URL that you
specify as the destination for files submitted to the Send-To location. Send To locations must be
configured before they can appear as a submission point.
Rule Status and Priority Specifies this rules priority on a scale of 1 to 9 if more than one rule is
applied. You can also specify that this rule is inactive and will not be applied to any incoming
content.
Submission's Content Type Specifies the content type group such as Document Content Types,
Publishing Content Types, and so on. Based on the content group type group, you can additionally
select a content type for the rule. If a content type in your organization uses a different name, you
can specify an alternative name.
Target Location Specifies where to put content that matches the rule.
Submission Points Where the item that has met all the criteria above will be saved. If you
checked the Sending to Another Site option in the Content Organizer settings, you will see a dropdown box that has a list of other locations outside the current site to which a document can be
routed.
with this article when planning how to configure settings and rules that will apply to content organized
using a content organizer.
Download worksheets
Upload content to a Drop-Off Library. A drop-Off library is created in every site in which the Content
Organizer Feature is activated.
Use Send To from other SharePoint sites manually or as part of a workflow, or as part of
documents life cycle or expiration.
Use an E-mail drop-off zone. By using Exchange, content items can be e-mailed to the site.
Worksheet action: On the Content Organizer settings worksheet, record how content will be uploaded
or submitted to the site.
Content redirection
With the Redirect Users to the Drop Off Library setting, you can specify whether users are redirected
to the drop-off library. If this setting is checked (default), then all uploads are automatically sent to their
target location that is specified by the rules or are put in the drop-off library if no rules apply. If not
selected, users can bypass rules and the drop-off library and upload documents to another library or
folder.
A drop-off library is created in each site that has the Content Organizer Feature activated. By default,
when content is submitted, the rules are applied to the document and it is then sent to its target
location. If no rules apply, the item is then put in the drop-off library and an e-mail notification is sent to
the rule managers. Rule managers can then apply additional metadata to those items to match a rule
and allow the document to be sent to its target location. The drop-off library uses a timer job that
specifies when to process items in the library. If a rule manager applies additional metadata to an item
in the drop-off library, the rule will be applied and the item sent to its target location when the timer job
is next run.
When a document is uploaded, the document properties window for the drop-off library is displayed.
Then metadata properties can be selected and the submission process completed. After submitted, the
content organizer rules are applied to send the document to its target location. The user is then shown
a URL for the item. The URL includes a permalink created from the Document ID Feature, so that the
URL that was provided will always link to the item even if it is moved again. If no rules are applied, the
document is then put in the drop-off library and rule managers can be notified by e-mail.
A well designed metadata-based routing and storage solution uses content organizer rules to send to
its intended target location every document that is submitted to a drop-off library. The drop-off library
should then only include items submitted that did not match any rule. Documents that remain in the
library enable rule managers to identify those that do not match any rule, and to then create a rule or
require additional metadata tags that will apply.
When redirecting users to a drop-off library, it is important for those users to be aware of the specific
drop-off library's purpose, and what they will see in the properties window will reflect the content types
that are defined in the site gallery, and not necessarily those content types in the library they may be
working in.
Worksheet action: On the Content Organizer settings worksheet, record whether users are redirected
to the Drop-Off library.
Worksheet action: On the Content Organizer settings worksheet, record whether you will allow rules to
specify another site as a target location.
Folder partitioning
In SharePoint Server 2010, there is no limit on the number of items a folder can contain. There is
however a practical limit on the number of items a list view can display when viewing the contents of a
folder: known as the List View Threshold, and by default, it is 5000 items. By using a content organizer,
you can specify what happens when a folder exceeds a maximum specified number of items, effectively
becoming too large to be useful in standard list views.
Using the Folder Partitioning setting in Content Organizer Settings, you can specify that subfolders
should be created when the target location becomes too large. By default, this setting specifies to
create new folders when the target location exceeds 2500 items. Each subfolder will inherit the
properties of the target location which it was derived from. So, if for example, you have a folder named
"Resumes" that has special permissions that are required to view and edit items in it, subfolders
created from the Resumes folder will inherit those same permissions requirements.
It is important to be aware of your site or library's overall folder structure. The main purpose of folders is
to organize content to match the expected functionality of the site or library. The Folder Partitioning
setting should be considered carefully as part of an overall folder structure or even after a folder
structure is established.
Worksheet action: On the Content Organizer settings worksheet, record whether to create subfolders
when the number of items in the target location is exceeded, and the format of the folder name
subfolders should be created by using folder partitioning.
Duplicate submissions
In any large organization there is always the possibility more than one document that has the same
name and metadata is submitted to a site. By default, the content organizer will use SharePoint
versioning to differentiate items with the same name if versioning is enabled in the document library. In
Content Organizer Settings, you have two options for duplicate submissions. First, and by default, is to
use SharePoint versioning. To use SharePoint versioning, versioning must be enabled for the
document library. For more information about how to plan versioning, see Versioning, content approval,
and check-out planning (SharePoint Server 2010). The second option is to specify that the Content
Organizer will append unique characters to the end of the duplicate file names. If versioning is not
enabled for a target library, the Content Organizer will append unique characters to duplicate
submissions regardless of the setting selected. It is important to remember that the unique characters
appended to the file name may not identify the item in any particular way. This could prevent users from
correctly identifying the document that they want if there are too many documents that have the same
name, but unique characters added to the name do not provide any meaningful form of identification.
Worksheet action: On the Content Organizer settings worksheet, record whether you want to use
SharePoint versioning (default) or to append unique characters to the end of duplicate file names.
Preserve context
When this setting is checked, for documents that include original audit logs and properties are retained
and stored with it. This can be important when you want to retain all of the historical information about
the document, such as a document sent to a Record Center site. When the context is preserved, users
can click on Compliance Details from the View Properties page of an item.
Note:
Preserving context will affect storage. Audit data can quickly compound and occupy large
amounts of space in a content database, especially if view auditing was turned on. For more
information about how audit data may affect storage capacity, see Storage and SQL capacity
planning and configuration.
Worksheet action: On the Content Organizer settings worksheet, record whether you want to save the
original audit log and properties for documents submitted to this site.
Rule managers
You can specify users who can create and edit rules. Rule managers must have Manage Web Site
permissions in order to create and edit rules. Rule managers must be familiar with your metadata term
sets and terms in order to create rules that most effectively implement your metadata based routing and
storage solution. It is also important for rule managers to determine the broader implications of rules
they create, for example, it is important that all rule managers in your organization determine the correct
action when a folder becomes too full.
In most cases, the person creating the rule will serve as the rule manager, however, in some
circumstances, such as when you are creating a series of new rules, you may want to specify other rule
managers that will be responsible for making sure the rule is meeting the goals originally intended. If
you specify that rule managers are to be e-mailed when submissions do not match a rule, or when
content was left in the drop-off library, you may want to specify several rule managers in-case the
original rule manager is not available. Rule managers have permissions to edit all items in the drop-off
library in order to enter missing or incorrect metadata necessary for a document to match a rule.
Worksheet action: On the Content Organizer settings worksheet, record users or groups that will act
as rule managers for the site.
it is important to verify those items to determine why no rules are being applied. This can occur if rules
do not reflect the metadata properties available to users when tagging a document.
Information provided in this section is meant to help you plan rules that will be an effective part of your
metadata-based routing and storage solution. The Content Organizer rule worksheet is provided to help
in planning rules. Fill out a separate worksheet for each new rule that you plan to create.
Business
Content
Intelligence Organizer
Report
Web Page
Part with
Digital
Document
Asset
E-mail
Audio
Submission
Basic
Page
Image Document
Document
Page
Set
Layout
Document Article
Set
Page
Redirect
Page
Publishing
Special
Page
Unknown
Document
Type
Page
Layout
Custom
Business
Content
Intelligence Organizer
Digital
Document
Asset
Document
Page
Set
Layout
Publishing
Special
Custom
Status List
Rich
Dublin
Media Core
Asset Columns
Video
Welcome Publishing
Page
Master
Page
Form
Link to a
Document
List View
Style
Master
Page
Picture
Web Part
Page
Wiki Page
You can also create a rule that will apply to a custom content type that was derived from a default
content type (in the table above) as the parent content type.
Worksheet action: On the Content Organizer rule worksheet, record the content type group, type, and
alternate names in other sites.
Plan conditions
Rules are applied on property-based conditions. You can define up to 6 conditions in a single rule. All of
the conditions must be true for the rule to be applied and the item sent to its target location. The
properties that are available to be used in a condition are those associated with the content type.
Because you must specify at least a content type, there will be at least one condition. When you specify
a content type, but do not define any additional property-based conditions, the rule will organize all
items based only on the content type.
When defining a condition, for the condition to be true, a value must be the product of a property and an
operator. You cannot specify wildcards as a value for a condition. If a value does not match the
condition, the rule will not be applied and the item will remain in the drop-off library.
Worksheet action: Use the Content Organizer Rule page to determine the properties available for the
selected content type, and then on the Content Organizer rule worksheet, record conditions for the rule.
Permissions By routing content to a target location based on metadata, you can specify a target
location with unique permissions, effectively using metadata to apply permissions.
Versioning By routing content to a target location based on metadata, that target location can
specify a particular document version history (versioning).
Metadata By routing content to a target location based on metadata, that target location can apply
additional metadata and enterprise keywords.
Retention and content type policies By routing content to a target location based on metadata,
content in that target location can be subject to a retention policy, assuring that the content is
saved.
Workflows By routing content to a target location based on metadata, content in that target
location can be subject to workflows.
Worksheet action: On the Content Organizer rule worksheet, record additional properties that will be
applied at the target location.
See Also
Plan managed metadata (SharePoint Server 2010)
Metadata-based routing and storage overview (SharePoint Server 2010)
Metadata navigation overview (SharePoint Server 2010)
Automatic indexing
Indexed Queries
Fallback queries
A simple user interface Metadata navigation builds upon the SharePoint Tree view hierarchy
control and combines it with a new Key Filters control providing users a powerful tool in finding
content based on metadata.
List owner controls By configuring metadata navigation settings, list owners can promote fields
on a list as key navigation fields. Users viewing those lists can then further filter the current list view
to show only items with the desired values in those fields.
Automatic indexing This optional process can create list indices automatically depending on the
fields promoted as navigational fields for the list. Automatic indexing can improve query results and
improve performance.
By default, the list view threshold is 5000 items. Administrators can change the list view
threshold by using Windows PowerShell.
Metadata navigation expands the capabilities of list views and combines it with a Key Filters control
making it easier for users to find content by filtering a view of documents to a subset based on one or
more navigation filters.
Metadata navigation includes the following user controls:
Navigation hierarchies Use and expand the capabilities of list views to navigate hierarchies of
folders, content types, choice fields, or managed metadata term sets. This allows users to use list
views to filter on a metadata hierarchy just like navigating folders.
When selecting an item in a hierarchy for a managed metadata column, all items will be shown that
are tagged with the specified term or any of its descendant terms for the field associated with that
hierarchy. Users can then select the item again to filter only on that particular term and not include
the descendant child terms.
Navigation hierarchies' work together with filters specified in the list view definition and filters
specified in the columns in the list view Web Part. Along with key filters, in-combination, provide up
to four distinct ways that a list view can be filtered.
Key Filters This control appears below the site hierarchy control and can consist of several fields
such as date, choice, content type, single and multi-value fields, currency, yes / no, and user fields.
Any number of key filters can be applied in combination with a selected navigation hierarchy.
Key filters can be specified for a much larger range of column types and consist of a blank field that
matches the kind of column it represents. Users can then type text into the field to filter on that
column. For example, you can add the modified by column as a key filter and then type a user
display name or username alias and resolve to get results where modified by matches the user
entered. Any number of key filters can be used at the same time and they can also be used in
combination with a navigation hierarchy.
Managed metadata key filter fields enable entering multiple terms by typing and selecting from the
suggestions displayed. A specially handled managed metadata field that is named All Tags can
also be used, which matches the input terms against field values for an item in any of the managed
metadata fields in the list schema. If the user is in the root folder of the list then applying key filters
will query over all of the items from any of the folders in the list.
Automatic indexing
On the Metadata Navigation Settings page for a list or library, with the Configure automatic column
indexing for this list setting, list owners can specify whether indices are automatically created on the
list to match selected navigation hierarchy and key filter fields. If this setting is enabled (default), when
the metadata navigation settings page is saved, the following occurs:
Single column indices will be created on all supported navigation hierarchy fields.
Single column indices will be created on all supported key filter fields, except for the Content Type
field and Choice fields
Compound indices will be created on all supported combinations of navigation hierarchies and key
filters.
When indices are created automatically, queries are allowed for lists that have more items than the list
view threshold. In some cases, you may have to disable this setting and configure custom indices. For
example, if a combination of single column and compound indices exceeds 20, Automatic Indexing
must be disabled.
Indexed Queries
When the Metadata Navigation and Filtering Feature is enabled for a site, built-in optimization will select
the best index to work every time that a list view is loaded. Each time that a user loads a list view,
refreshes a list view by applying a new filter, clearing a filter, or by applying a sort on a field, query
optimization determines the best way in which to query the database without view throttling.
Fallback queries
If metadata navigation determines that the current user request cannot be expressed as an indexed
query that is selective, it will construct and perform a fallback query. A fallback query is a modified
version of the original user query that queries against only a part of the list instead of the complete list.
Fallback queries are intended to show the user a partial set of results that can be useful, even when the
original query could not be run because of list view throttling. In addition, fallback queries can serve as
a warning to list owners that the data distribution in the list is skewed and certain queries that users are
running cannot return a full set of results, which means that users may be blocked from accessing
content that they need. Fallback queries occasionally will return 0 results if no items in the part of the
list scanned by the query contain results that match the original user query.
Since the results of a fallback query are only a partial set of the items that the user is requesting, the
user is prompted via an on-screen message that only a partial set of results is being shown and that the
user must apply additional filters in order to view a complete set. Every time that a user specifies an
additional filter, this is another opportunity for the query engine to find a selective filter/index
combination that does not exceed the list view threshold that result in a throttling exception.
See Also
Metadata-based routing and storage overview (SharePoint Server 2010)
Worksheet
Library
Purpose
Library
Purpose
Slide library
The following example illustrates how to use the analysis that you completed in Analyze document
usage to help you plan document library organization for your enterprise. In this example, Contoso Ltd.
delivers content to clients based on market research. The content is created primarily by consultants
operating remotely. This is done in a cycle in which:
1. A partner evaluates engagement ideas and requests for proposals.
2. After a contract is established, a project manager assembles a team of consultants and creates an
engagement-specific working site in which the results of the research are recorded and the project
is completed.
3. When the project is done, the deliverable documents are published to a secured Internet site,
where customers have access to them.
4. The team writes best practices documents and case studies based on the project.
5. Knowledge managers collect, organize, and archive the best practices and other documents.
6. Deliverables, contracts, and other documents are retained as corporate records.
7. By using the content maintained by the knowledge managers, partners evaluate opportunities and
create new proposals.
The following table illustrates a document usage analysis for this scenario:
Documents
Purpose
Author
Users
Format
Engagement ideas
and requests
Develop new
customer
engagements
Project leader
Sales manager;
project leader
.doc
Proposals
Describe a proposed
customer
engagement
Project leader
Project managers;
project team
members;
customers
.doc
Contracts
Commit to a
consulting
engagement
Lawyer
Project leader;
project manager;
sales manager;
customers
.doc
Research results
and project
deliverable drafts
Editors; technical
reviewers
Deliverable
documents
Generate final
deliverables,
probably converted
from .doc format
Project leader
Customers
Capture
organizational
knowledge
Various types
Corporate records
Retain some
content, such as
deliverable
documents, as
corporate records
All
All
Corporate records
managers;
corporate lawyers
Project leaders need libraries in team sites for storing engagement ideas, engagement requests,
and proposal drafts.
Lawyers need libraries in a portal or centralized document management site for storing contract
templates and active contracts.
Project leaders and contributors need libraries in team sites for authoring research results,
deliverables, and case studies.
All members of the enterprise need access to a Document Center site for viewing best practices
and case study documents.
Corporate records managers and lawyers need access to an enterprise Records Repository to
maintain corporate records.
The following figure illustrates how these libraries might be distributed. The sites are hosted in three site
collections: an Internet site collection for customer access, an extranet site collection for remote
authoring by team members, and an intranet site collection for secure maintenance of the records
management site.
Worksheet action
Worksheet action
You can create custom workflows that copy or move content from one site or library to another. A
workflow guides a document through a business process and assigns tasks to participants when
their role in the document's life cycle becomes active. A workflow can be designed to move a
document from one site or library to another. For information about planning workflows, see
Content type and workflow planning (SharePoint Server 2010).
Authors can copy a document to a library in any site in which they have authoring permissions. The
relationship between the source and the destination document is maintained so that the copy can
be refreshed as needed.
Web pages and entire Web sites can be staged and published from one site to another either
manually or automatically based on a schedule.
Content can be sent to the records management site by using the SharePoint Server user interface,
by using a workflow, or by using a custom solution based on the Microsoft SharePoint Foundation
object model.
By using Web Folders or Network Places, an author can manually copy or move the contents of a
document library from one library or site to another.
Returning to the example, the following figure illustrates how to apply some of these content flow
techniques. Note that the Staged Internet site has been added to the Authoring portal site.
By using publishing features, an author can publish Web pages to the Internet site.
By using the Copy command, an author can copy documents to the Document Center site.
By using a custom workflow, an author can copy documents to document libraries on the Internet
site.
By using the Send to Records Repository command, an author can send contracts to the enterprise
Records Repository.
configured, Office Professional 2010 adds an entry to the My Places bar and populates it with the
locations that are defined by the Web service.
Alternatively, administrators can set registry keys to add specific sites to the My Places bar in the Office
Open dialog box and the Save dialog box. Registry keys are deployed by using Group Policy and a
Microsoft Active Directory directory service template provided in the Office 2010 Resource Kit.
You can limit the locations that organization members can save content to by using the Office Save
dialog box. For example, you can restrict the ability to save files to desktops and force users to save
content in a document library. In Office Professional 2010, you can control where users are allowed to
browse to save their documents, thereby guiding users to save in approved locations. Note that this
does not guarantee that users won't save files to their local computers or other unapproved locations.
There are many ways to get files onto a computer, and motivated people can work around most
restrictions. However, by limiting access to these locations through the Office Save dialog box, you can
dramatically reduce the number of team members who use these unapproved locations.
To restrict the locations available in the Office Save dialog box, use Group Policy to set the appropriate
registry keys to enable this setting and define the approved local, network, or server locations. When
this setting is enabled, any location not defined in this manner including standard links to the
Desktop and My Network Places folders will be removed from the My Places bar.
The list of approved locations can be limited to one or more Office applications. For example, an
administrator can restrict save locations in Microsoft Access while allowing other Office applications to
save anywhere.
Worksheet
Use the following worksheet to record the information discussed in this article:
List views
Additional resources
users. For example, if users view or query a set of documents in a document library that contains
thousands of documents, performance can decrease if the site is not configured correctly. Or if a
service-level agreement requires that content be backed up two times a day, the service might not
perform satisfactorily if the set of content is too large.
The scenario descriptions provided here are intended to clarify what we mean by large-scale solutions
and to provide high-level examples that hopefully reflect your content management goals. Of course,
these descriptions do not include all aspects of a particular scenario. There are dozens, even hundreds,
of unique aspects of a particular scenario that are beyond the scope of this article.
Another kind of large-scale content archive is a records center, based on the Records Center site
template. Using the Records Center site template is recommended for sites that contain one million or
more documents. This site template contains features that you can use to manage the retention and
disposition of records (documents that serve as evidence of activities or transactions performed by the
organization and that must be retained for some time period). Similar to a knowledge base site, a
records center contains a single version of each document and could typically hold millions of
documents. Many more users submit content to a records center than view or read it.
Content types and columns managed in a site collection can be shared across sites in the site
collection. The managed metadata service can be used to syndicate content types and column
definitions across multiple site collections.
Information management policies managed in the site collection can be made available to content
in all sites in the site collection.
Some views list documents from multiple sites in a single site collection (for example, a view
enumerating all tasks assigned to a user across a site collection). Also, developers can create
cross-site database queries in a site collection, but cross-site queries are not supported across
multiple site collections.
Content quotas and other quotas can only be managed at the site-collection level.
Consider the following limits when planning how to allocate your content across one or more site
collections:
All sites in a site collection share the same back-end resources. In particular, all content in a site
collection must be stored in the same content database. Because of this, 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 segment a site collection into multiple site collections to meet servicelevel 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.
Particularly, keep very active sites in separate site collections. For example, a knowledge base site
on the Internet that enables 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 free resources for other sites that
no longer have to compete with it for database resources.
Note:
SharePoint Foundation and SharePoint Server 2010 include several features that reduce the
need to have the IT department restore content. The Recycle Bin and the Site Collection
Recycle Bin provide a double safety mechanism for restoring unintentionally deleted items.
Document versioning also provides a safety net of sorts: if a document is lost, at least its
previous version will be available. To better ensure the availability of previous versions, an
administrator can remove an author's Delete Versions permission; this can help guarantee that
previous versions of content are available without having to restore them from the database.
Sites
A web site is the primary way to organize related content in SharePoint Server 2010 and SharePoint
Foundation.
Storing content in the same site has the following benefits:
It is easier to create pages that display views of multiple libraries and lists when they are in the
same site.
You can use the Document Center site template to create a site that is optimized for creating and
using many documents.
The site navigation user interface is optimized to make it easy to find and locate libraries within the
same site.
You can define a set of content types and site columns for use in a site.
Libraries
Storing content in the same library provides the following benefits:
It is easier for users to add new documents or find existing documents in a single library.
Many document management settings such as permissions, content versioning, and approval
are applied at the library level.
Views created by using the user interface are bound to a particular library.
Information management policies, such as content auditing and retention settings, can be applied
to a library. For certain libraries, only retention policies can be used.
Think about the following limits when you plan how to organize content into the same library:
Settings such as required checkouts or versioning are specified at the document library level. If you
want to specify different settings for other documents, you must put those documents in a different
library with the necessary particular settings.
Views that contain columns that are used only on one content type may not be useful because no
metadata value will be displayed for items of other content types.
View performance is limited when the number of items viewed exceeds the list view threshold of
5,000 items (default). In addition, queries are prevented when they exceed the list view threshold.
Organize content in the library into folders that contain 5,000 or fewer items, or create views that
take advantage of metadata navigation and indexed columns to return sets of 5,000 or fewer items.
Folders
A folder is a named subdivision of the content in a library similar to folders in a file system. The main
purpose of folders is to logically organize content to match the expected functionality of the library. For
example, if a library is intended to provide product specifications, the set of folders in the library could
be named for each feature area in the product or for each team member who writes product
specifications.
When you divide content across multiple folders each of which contains 5,000 (list view threshold
default) or fewer items views on the folders can perform well. Note that to take advantage of this,
views available within folders must be configured to only show items inside the folders (this feature is
available in the default view-creation interface). Note also that if folders contain 5,000 or fewer items,
views in the folders do not have to be filtered by using indexed columns. For folders that contain more
than 5,000 items, you can improve performance using metadata navigation and/or indexed columns
and then filter the views to return less than 5,000 items.
Consider creating folders as part of a content routing and storage solution that is based on metadata.
By using Content Organizer, you can configure settings that automatically create folders when a target
folder becomes too large or to automatically create folders for each value of a metadata property. For
more information, see Routing and storing enterprise content based on metadata later in this article.
List views
At the heart of every enterprise content management solution is the ability for users to easily search for
and find the content they are looking for. When moving through a library or folder, tree views and list
views provide a simple interface for users to visually navigate through content storage taxonomy. At the
same time, when a library or folder contains too many items, the ability for the list to query and quickly
display results can require considerable system resources. SharePoint Server 2010 can maximize list
view performance while minimizing system resource consumption by using Resource Throttling.
Resource Throttling properties are set for a web application in General Settings in Central
Administration and affect resources allocated to querying and displaying lists within that web
application.
Configuring your storage in ways so that when you view the contents of a library or folder the list view
threshold is not exceeded prevents resource throttling and maximizes list view performance.
Resource Throttling includes the following properties that relate to list view performance:
Property
Description
Default value
5000
Yes
20,000
Property
Description
Default value
Disabled
Additional resources
In addition to the information in this article, the following resources can help you understand and plan
an enterprise content storage solution.
SharePoint Server 2010 capacity management: Software boundaries and limits: This article
provides information to help you understand the tested performance and capacity limits of Microsoft
SharePoint Server 2010.
Microsoft SharePoint Server 2010 departmental collaboration environment: Technical case study:
This article describes an actual SharePoint Server 2010 environment at Microsoft. Use this
document to compare to your planned workload and usage characteristics.
Designing Large Lists and Maximizing List Performance: This white paper provides guidance on
performance of large document libraries and lists in SharePoint Server 2010.
Metadata-based routing and storage overview (SharePoint Server 2010): This article contains
information to help solution planners and designers understand how metadata-based routing and
storage using the Content Organizer feature in Microsoft SharePoint Server 2010 can be used as
part of a comprehensive document management solution.
Metadata navigation overview (SharePoint Server 2010): This article contains information to help
solution planners and designers understand how the Metadata Navigation and Filtering feature in
Microsoft SharePoint Server 2010 can be used as part of a comprehensive document management
solution.
Document library planning (SharePoint Server 2010): This article describes how to plan document
libraries and integrate libraries into a Microsoft SharePoint Server 2010 document management
solution.
Plan managed metadata (SharePoint Server 2010): Articles in this section explain key concepts
about managed metadata in SharePoint Server 2010. Additional articles provide guidance about
how to identify managed metadata for your solution, and how to determine the services and
connections that you must have to implement your solution.
Worksheets
For more information about how to create and manage Document Sets in SharePoint Server 2010, see
Document Sets in SharePoint Server 2010 Help.
(http://go.microsoft.com/fwlink/?LinkId=186368&clcid=0x409).
There is no limit on the number of documents that can exist in a Document Set. However, display
load times may be limited by the list view threshold which by default is set at 5,000 items. Folders
are not allowed in document sets, and metadata navigation cannot be used in a Document Set.
Therefore, it is important to consider the possibility of exceeding list view thresholds and navigation
design concerns when you determine how many items should exist in a Document Set. In addition,
when you use the Send to feature with a Document Set, the sum for all documents in a Document
Set cannot be larger than 50MB. For a collection or work product with a very large number of items,
a folder structure in a document library may be a better solution.
There is no limit on the number of Document Sets that can exist in a document library. However,
the number of Document Sets that can appear in lists will be limited by the list view threshold.
When using shared metadata, if there are more than 10 items in a Document Set, metadata
updates will be run by a timer job every 15 minutes.
When using Document Set routing, Document Sets that are sent to a content organizer will remain
in the drop-off library and be moved to the appropriate location by the content organizer processing
timer job, which by default runs daily.
In order to use Document Sets in a site collection, the Document Sets Feature must be enabled.
To enable Document Sets Feature for a site collection
1. On the Site Settings page, under Site Collection Administration, click Site collection
features.
2. On the Features page, for Document Sets, click Activate.
After the Document Set Feature is enabled, you can create Document Set content types.
Determine shared columns Specify whether column values for the Document Set should be
automatically synchronized to all documents that are contained in the set.
d. Determine Welcome Page columns Specify which columns should be shown on the
Welcome Page for each Document Set.
e. Determine the Welcome Page view Specify the view to display the contents of the
Document Set on the Welcome Page.
5. Determine the columns and column order In the Plan Columns table of the Content type
worksheet:
a. Enter each column that is inherited from the parent content type. In the New? column, type No
for each entry.
b. For each additional column, enter the name of a predefined column or of a column that you will
create. Enter the names of the additional columns, their types, and indicate whether they are
new.
6. In the Plan Template section of the worksheet, type None.
7. Determine the workflows If there is an available workflow that is relevant to the Document Set
content type, you can optionally associate it with the content type. The workflow can then be
initiated on any list item of that content type. For a full discussion of workflow planning, see Plan
workflows. After reviewing workflows and determining which workflows are available, enter each
workflow to associate with the content type in the Plan Workflows table of the Content type
worksheet. If the workflow is not inherited from the parent content type, enter that information in the
New? column.
8. Determine the policy A policy is a set of rules for a kind of content; policy features provide the
details of each rule, such as whether items of the content type can be printed or which actions on
the item should be audited. You can apply a policy to any custom content type. Note that you
cannot apply a policy to a core content type. For more information about policy planning, see
Information management policy planning (SharePoint Server 2010). After reviewing policies and
determining which policy features and policy templates are available, in the Plan a Policy section
of the Content type worksheet, do the following:
a. If the parent content type has policy settings, they will apply unchanged in the new content
type. This ensures that policies, after they are set, are enforced in all relevant content types. If
the current content type is inheriting its policy settings from its parent type, in the Plan a Policy
section of the Content type worksheet, answer Yes to the question, "Is the policy defined in the
parent content type?."
b. If the current content type is inheriting a policy based on the parent content type, in the Record
the Policy Name field of the Plan a Policy section, type the name of the policy template.
Similarly, if the current content type does not inherit a policy and you want to apply a policy
template, in the Record the Policy Name field of the Plan a Policy section, type the name of
the policy template.
c.
If the current content type is inheriting one or more individual policy features from the parent
content type, enter each policy feature in the Feature table in the Plan a Policy section of the
worksheet. Conversely, if the current content type does not inherit a policy and you want to
associate policy features with the current content type, enter those policy features in the
Feature table. Note that you cannot associate both individual policy features and a policy by
name to a content type.
Worksheets
Use the following worksheets to record the information that is discussed in this article:
See Also
Content type and workflow planning (SharePoint Server 2010)
Plan workflows
Worksheets
Column templates
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 Server 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 choose 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 broadly available within a site collection, define it in the content type gallery of the top-level
site. You can also create a custom content type in a content type hub that is defined in a managed
metadata service instance. When it is created in a content type hub, the content type will be available to
other site collections that are part of Web applications associated with that managed metadata service
instance.
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, workflows required to review and complete the contract, policies that
enforce auditing of actions related to the contract, a retention period for retaining the contract, and
labels to insert in printed versions of the contract. Then, any document library in your site collection to
which you associate the Contract content type will include all of these features and will enable authors
to create new contracts based on the template.
In sites based on SharePoint Server 2010, each default list item or library item such as Contact,
Task, or Document has a corresponding core content type in the site's content type gallery. When
you plan content types, you can use these core content type definitions as starting points and base new
content types on existing ones as needed or modify the core types.
Content types are organized into a hierarchy that allows one content type to inherit its characteristics
from another content type. This inheritance allows classes of documents to share characteristics across
an organization, and it allows teams to tailor these characteristics for particular sites or lists.
For example, all customer-deliverable documents in an enterprise might 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 the content type owner adds another
required column 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.
Column templates
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.
1. Enter the document type from the Analyze document usage worksheet.
2. Enter the site URL at which the new content type will be defined. Keep in mind that content types
are available in the site in which they are defined and in all sites below that site.
3. Determine the parent content type Enter the parent content type in the Parent Content Type
field of the Content type worksheet. This will be either a core content type or a custom content type
that you have already planned.
4. Determine the columns In the Plan Columns table of the Content type worksheet, do the
following:
a. Enter each column that is inherited from the parent content type. In the New? column, type No
for each entry.
b. For each additional column, enter the name of a predefined column or of a column that you will
create. The name of a column is important, because it can communicate the column's purpose.
Therefore, even if a column of a type that you need is already defined in the Site Collection
Column gallery, you might decide to define a similar column by using a more relevant name for
your application. Along with the names of the additional columns, enter their types and indicate
whether or not they are new.
5. Determine the template In the Plan Template section of the worksheet, enter the name of the
template to associate with this content type along with its type (such as .Docx) and a brief
description of the purpose of the template. If the template is not inherited from the parent content
type, in the New? field, type No.
6. Determine the workflows Workflows attach business logic to documents and list items. You can
associate any available workflow with a content type; the workflow can then be initiated on any
document of that content type. After reviewing workflows and determining which workflows are
available, enter each workflow to associate with the content type in the Plan Workflows table of
the Content type worksheet. If the workflow is not inherited from the parent content type, enter that
information in the New? column.
7. Determine the policy A policy is a set of rules for a type of content and is made up of policy
features that provide the details of each rule, such as whether items of the content type can be
printed or which actions on the item should be audited. You can apply a policy to any custom
content type. Note that you cannot apply a policy to a core content type. For more information
about policy planning, see Information management policy planning (SharePoint Server 2010).
After reviewing policies and determining which policy features and policy templates are available, in
the Plan a Policy section of the Content type worksheet, do the following:
a. If the parent content type has policy settings, they will apply unchanged in the new content
type. This ensures that policies, after they are set, are enforced in all relevant content types. If
the current content type is inheriting its policy settings from its parent type, in the Plan a Policy
section of the Content type worksheet, answer Yes to the question, "Is the policy defined in the
parent content type?."
b. If the current content type is inheriting a policy based on the parent content type, in the Record
the Policy Name field of the Plan a Policy section, type the name of the policy template.
Similarly, if the current content type does not inherit a policy and you want to apply a policy
template, in the Record the Policy Name field of the Plan a Policy section, type the name of
the policy template.
c.
If the current content type is inheriting one or more individual policy features from the parent
content type, enter each policy feature in the Feature table in the Plan a Policy section of the
worksheet. Conversely, if the current content type does not inherit a policy and you want to
associate policy features with the current content type, enter those policy features in the
Feature table. Note that you cannot associate both individual policy features and a policy by
name to a content type.
Worksheet action
Plan new list content types by using the following steps. For each list content type that you plan, fill
in a separate Content type worksheet. In the Document Type field of the worksheet, enter List.
1. Enter the site URL at which the new content type will be defined. Note that the Content types
Worksheet action
are available in the site in which they are defined and in all sites below that site.
2. Determine the parent content type Enter the parent content type in the Parent Content
Type field of the Content type worksheet. This will be either a core content type or a custom
content type that you have already planned.
3. Determine the columns In the Plan Columns table of the Content type worksheet, by doing
the following:
a. Enter each column that is inherited from the parent content type. In the New? column, type
No for each entry.
b. For each additional column, enter the name of a predefined column or of a column that you
will create. Along with the names of the additional columns, enter their types and indicate
whether or not they are new.
4. In the Plan Template section of the worksheet, type None.
5. Determine the workflows If there is an available workflow that is relevant to the list content
type, you can optionally associate it with the content type. The workflow can then be initiated on
any list item of that content type. For a full discussion of workflow planning, see Plan workflows
later in this article. After reviewing workflows and determining which workflows are available,
enter each workflow to associate with the content type in the Plan Workflows table of the
Content type worksheet. If the workflow is not inherited from the parent content type, enter that
information in the New? column.
6. In the Plan a Policy section of the worksheet, type None.
1. In the document usage analysis that you perform in Identify users and analyze document usage
(SharePoint Server 2010), identify candidates for document conversion that is, documents that
are written in one format but that should be published or archived in another.
2. For each conversion your documents require, locate converter programs that you can use to
implement the conversion on your servers.
3. If needed, install the conversion programs on application (middle tier) servers in your farm.
4. Configure the launcher and load balancer services, either on the Web servers or application
(middle tier) servers.
5. Identify the points in your document life cycle at which conversions take place.
6. Identify how conversions will be implemented either manually or by using custom solutions that
launch them.
Plan workflows
Workflows implement business processes on documents, Web pages, forms, and list items in
SharePoint Server 2010. They can be associated with libraries, lists, or content types.
In document management, use workflows to route documents from person to person so that they can
each complete their document management tasks, such as reviewing documents, approving their
publication, or managing their disposition. Also, use custom workflows to move documents from one
site or library to another. For example, you can design a workflow to copy a document from one site to
another when the document is scheduled to be archived.
SharePoint Server 2010 includes workflows that address the following document management needs:
East Asian Document Approval Routes a document for approval by using stamp signatures and
a group-oriented consensus process.
Associate a workflow with a content type when you want to make that workflow available whenever that
content type is in use. For example, a purchase order content type could require approval by a
manager before completing the transaction. To ensure that the approval workflow is always available
when a purchase order is initiated, create a Purchase Order content type and associate the approval
workflow with it. Then add the Purchase Order content type to any document libraries in which
purchase orders will be stored.
To plan workflows for your document management solution, analyze each document content type you
plan to implement and identify the business processes that need to be available to run on content of
that type. Then identify the workflows you will need to make available for that content.
Worksheet action
The following is a sample table that analyzes workflows for a contract content type:
Contract Process
Contract Workflow
New?
Review drafts.
Collect feedback
No
Approval
No
Issue tracking
No
Get signatures.
Collect signatures
No
Worksheets
Use the following worksheets to record the information that is discussed in this article:
Auditing, to record the editing and viewing history of each employee-related document.
Retention, to ensure that work-in-progress content is not kept for an unnecessarily long period of
time.
Labels, to ensure that physical copies of each document are properly identifiable.
Print Restrictions, to ensure that sensitive employee-related documents are printed only on secure
printers. Note that this is an example of a custom policy feature that must be implemented by using
the Microsoft SharePoint Server 2010 object model or acquired from a third-party software vendor.
Policy features are implemented as programs that run on SharePoint Server 2010. They can be
enabled and configured by a server administrator and, when they are enabled, they can be used by site
administrators to define policies. SharePoint Server 2010 includes policy features to help you manage
your content. By using the SharePoint Server 2010 object model, you can design and install custom
policy features that meet unique enterprise needs.
A policy feature might use one or more policy resources, which are programs that provide some
functionality to a policy feature. For example, a policy resource for a Barcode Generation policy feature
could provide the unique barcode value. You can develop custom policy resources and install them to
support policy features.
When your organization uses the Microsoft Office system client applications along with SharePoint
Server 2010, policies are enforced both on the server and in the client applications. This is done
transparently; policy features that apply to a document are described in a policy statement that is
associated with the document, and policy-aware applications prevent users from doing tasks that
violate the document's policy.
To implement a policy, associate it with content types, libraries, or lists in sites.
Note:
In the Site Content Type Gallery, you can apply a policy to any custom content type, but you
cannot apply a policy directly to a core content type.
You can associate a policy with a library, list, or content type in the following ways:
Associate policy features with a Site Collection policy, and then associate that policy with a
content type or with a list or library. The top-level site of a site collection includes a Site
Collection Policies gallery where administrators of the top-level site can create new policies. After
creating a Site Collection policy, you can export it so that administrators of other site collections can
import it into their Site Collection Policies galleries. This makes it possible for you to standardize
policies across your organization.
When a Site Collection policy is associated with a content type and that content type is associated
with a list or library, the owner of the list or library cannot modify the Site Collection policy in the list
or library. This ensures that policies that are assigned to a content type are enforced at each level
of the site hierarchy.
Associate a set of policy features directly with a content type, and then add that content
type to one or more lists or libraries. To ensure that a policy that is created by using this
method will be used in an entire site collection, associate it with a content type in the Site Content
Type gallery of the top-level site collection. Then every item of that content type in the site
collection, and every item of a content type that inherits from the original content type, will have the
policy. When you use this method of associating a policy with a content type, it is harder to reuse
the policy in other site collections, because policies created by using this method cannot be
exported.
Note:
To more tightly control which policies are in use in a site collection, site collection
administrators can disable the ability to set policy features directly on a content type. When
setting policy features on a content type is restricted, content type designers can only
associate policies from the Site Collection Policies gallery with content types. To learn more
about setting policy features for a site collection, see Create, delete, and view site
collections.
Associate a set of policy features directly with a list or library. You can only use this method
if the list or library does not support multiple content types. This method of creating a policy is only
useful for a narrowly defined policy that applies to a single list or library.
Note:
To more tightly control which policies are in use in a site collection, site collection
administrators can disable the ability to set policy features directly on a library. When
setting policy features on a library is restricted, content type designers can only associate
policies from the Site Collection Policies gallery with libraries.
For each policy in use, either based on a Site Collection policy or configured in a content type, a
summary of that policy its description, along with a description of each policy feature.
policy, users can insert labels into documents from the Insert menu of most the Office system client
applications. If a label is required, users are prompted when they are saving documents in which a label
has not been inserted. Similarly, users will be able to insert barcodes from client applications if that
policy feature is part of the document's policy.
Custom policy features can also be integrated in the Office system client applications. However, you
must implement policy-specific behaviors that you want to be available from the Office system client
applications, and you must give users a way to install these behaviors on their client computers via
mechanisms such as add-ins to make them available from the Office system client applications. For
example, if you implement a custom policy feature that restricts the printers that can be used to print a
content type, you must provide a custom add-in for Microsoft Office client applications to enforce the
restriction from these applications.
Expiration The Expiration policy feature helps dispose of or process content in a consistent way
that can be tracked and managed. When a content item expires, you can specify that it is disposed
of or that a custom workflow is run. You can set content of a specific type to expire on a particular
date, based on a date or time columns that are associated with the content type, list, or library, or
within a calculated amount of time after some document activity (such as creating the document).
Auditing The Auditing policy feature logs events and operations that are performed on documents
and list items. You can configure Auditing to log events such as:
Labeling The Labeling policy feature specifies a label to associate with a type of document or list
item. Labels are searchable text areas that SharePoint Server 2010 generates based on properties
and formatting that you specify. For example, in a law firm, a document related to a legal matter
could include a label containing the clients' names, the case number, and the attorney assigned to
the matter. Labels are particularly useful in printed versions of documents as a way to display
document properties in printed copy. Along with using labels for documents, you can associate a
label with a list item and include that label in views of the list.
Barcode The Barcode policy feature enables you to track physical copies of a document by
creating a unique identifier value for a document and inserting a barcode image of that value in the
document. By default, barcodes are compliant with the common Code 39 standard (ANSI/AIM BC11995, Code 39), and you can plug in other barcode providers by using the policies object model.
Worksheet action
All content types that the policy will be applied to and list
all site collections in which the content types are in use.
Worksheet
Use the following worksheet with this article to help plan your deployment:
Plan versioning
Worksheet
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 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.
Plan versioning
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 Server 2010 has three versioning options:
No versioning Specifies that no previous versions of documents are saved. When no versioning
is in use, previous versions of documents are not retrievable, and document history also is not
retained because comments that accompany each iteration of a document are not saved. Use this
option on document libraries containing 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, each time a new version of a document is saved, all users with 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 needs to 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 along 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 with 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 with 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, it is important to consider the effect that
retaining multiple versions of the same document can have on storage space.
Worksheet action
No versioning If no versioning is in use and changes to a document are saved, the document's
state becomes Pending. SharePoint Server 2010 keeps the previous version of the document so
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 with read permissions and the
previous version is not retained.
If no versioning is in use 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 with read permissions until it is approved.
Create major versions If major versioning is in use 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 with read permissions. After changes to the document are approved,
a new major version of the document is created and made available to site users with read
permissions, and the previous major version is saved to the document's history list.
If major versioning is in use 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 with read permissions until it is
approved as version 1.
Create major and minor (draft) versions If major and minor versioning is in use 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 with 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 in use 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.
Worksheet action
Worksheet action
(http://go.microsoft.com/fwlink/?LinkID=165874&clcid=0x409),
specify whether or not to require content approval for each
document library listed.
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 not be
able 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 made to the document. This promotes creation of an ongoing historical
record of the changes 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. While 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 optionally choose to leave checked-out documents on
the server by changing content editing options.
Worksheet action
Worksheet
Use the following worksheet to help you plan versioning, content approval, and check-outs:
See Also
Document library planning (SharePoint Server 2010)
Important considerations
OneNote Notebooks
But this solution hasnt 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 Server 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 users edits are lost, because they are all working on a central, server-stored
document.
2010 volume licensing and document management solutions based on Microsoft SharePoint 2010
Products. For more information, see Office Web Apps (Installed on SharePoint 2010 Products).
Important considerations
There are several factors that administrators will want to consider when planning how to use coauthoring in their environment.
Co-authoring functionality in SharePoint 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 Server 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 Server 2010. SharePoint Server 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.
Versioning period The versioning period determines how often SharePoint Server will create a
new version of a Word or PowerPoint document that is being co-authored. Setting this period to a
low value will capture versions more often, for more detailed version tracking, but may require more
server storage. The versioning period does not impact OneNote notebooks. This value can be
altered by adjusting the coAuthoringVersionPeriod property on the server. For more information
about adjusting this setting, see Configure the co-authoring versioning period (SharePoint Server
2010).
Check out When a user checks out a document for editing, this locks the document for editing to
only that user, which prevents co-authoring. Require Check Out should not be enabled in document
libraries where co-authoring will be used. By default, Require Check Out is not enabled in
SharePoint Server 2010. Users should not check out documents manually when co-authoring is
being used.
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 Server document library:
Do not enable minor versioning. By default, minor versioning is not enabled in SharePoint Server
2010.
If major versioning is enabled, set a reasonable maximum number of versions to store. By default,
major versioning is not enabled in SharePoint Server 2010.
Determines how active documents that will become records should be handled while they are being
used, and determines how they should be collected after they are declared to be records.
Determines in what manner and for how long each record type should be retained to meet legal,
business, or regulatory requirements.
Researches and implements technological solutions and business processes to help ensure that
the organization complies with its records management obligations in a cost-effective and nonintrusive way.
Performs records-related tasks such as disposing of expired records, or locating and protecting
records related to external events such as lawsuits.
The articles in this section describe records management in Microsoft SharePoint Server 2010 and
provide guidelines for planning your records management solution. In this section:
Using a records archive versus managing records in place (SharePoint Server 2010)
This article describes the differences between managing records in a records archive and
managing records in place.
Choose an e-mail and messaging records management strategy (SharePoint Server 2010)
This article contains an overview and comparison of the records management functionality
available in Exchange Server 2010 and SharePoint Server 2010 to help you choose a management
solution for messages if your organization uses both products.
Determines how active documents that will become records should be handled while they are being
used, and determines how they should be collected after they are declared to be records.
Determines in what manner and for how long each record type should be retained to meet legal,
business, or regulatory requirements.
Researches and implements technological solutions and business processes to help ensure that
the organization complies with its records management obligations in a cost-effective and nonintrusive way.
Performs records-related tasks such as disposing of expired records or locating and protecting
records that are related to external events such as lawsuits.
Determining which documents and other physical or electronic items in your organization are records is
the responsibility of corporate compliance officers, records managers, and lawyers. By carefully
categorizing all enterprise content in your organization, these people can help you ensure that
documents are retained for the appropriate period of time. A well-designed records management
system helps protect an organization legally, helps the organization demonstrate compliance with
regulatory obligations, and increases organizational efficiency by promoting the disposition of out-ofdate items that are not records.
A content analysis that describes and categorizes content in the enterprise that can become
records, that provides source locations, and that describes how the content will move to the records
management application.
A file plan that indicates, for each kind of record in the enterprise, where they should be retained
as records, the policies that apply to them, how long they must be retained, how they should be
disposed of, and who is responsible for managing them.
A compliance requirements document that defines the rules that the organization's IT systems
must follow to ensure compliance and the methods that are used to ensure the participation of
enterprise team members.
A method for collecting records that are no longer active from all record sources, such as
collaboration servers, file servers, and e-mail systems.
A method for capturing records' metadata and audit histories and for maintaining them.
A process for holding records (suspending their disposition) when events such as litigations
occur.
A system for monitoring and reporting on the handling of records to ensure that employees
are filing, accessing, and managing them according to defined policies and processes.
Microsoft SharePoint Server 2010 includes features that can help organizations implement integrated
records management systems and processes.
Records managers and compliance officers to categorize the records in the organization and to
run the records management process.
Content managers to find where organizational information is kept and to ensure that their
teams follow records management practices.
2. Analyze organizational content Before creating a file plan, records managers and content
managers survey document usage in the organization to determine which documents and other
items can become records.
3. Develop a file plan After you have analyzed your organizational content and determined retention
schedules, fill in the rest of the file plan. File plans differ from organization to organization, but
generally they describe the kinds of items the enterprise acknowledges to be records, indicate
where they are stored, describe their retention periods, and provide other information, such as who
is responsible for managing them and which broader category of records they belong to.
4. Develop retention schedules For each record type, determine when it is no longer active (being
used), how long it should be retained after that, and how it should ultimately be disposed of.
5. Evaluate and improve document management practices Make sure that required policies are
being applied in document repositories. For example, ensure that content is being appropriately
audited so that suitable audits are retained together with records.
6. Design the records management solution Determine whether to create a records archive, to
manage records in place, or to use a combination of the two approaches. Based on your file plan,
design the record archive, or determine how to use existing sites to contain records. Define content
types, libraries, policies, and, when it is required, metadata that determines the location to route a
document to.
7. Plan how content becomes records If you are using SharePoint Server 2010 for both active
document management and records management, you can create custom workflows to move
documents to a records archive. If you are using either SharePoint Server 2010 or an external
document management system, you can plan and develop interfaces that move content from those
systems to the records archive, or that declare a document to be a record but do not move the
document. You also create a training plan to teach users how to create and work with records.
8. Plan e-mail integration Determine whether you will manage e-mail records within SharePoint
Server 2010, or whether you will manage e-mail records within the e-mail application itself.
9. Plan compliance for social content If your organization uses social media such as blogs, wikis,
or My Site Web sites, determine how this content will become records.
10. Plan compliance reporting and documentation To verify that your organization is performing its
required records management practices, and to communicate these practices, you should
document your records management plans and processes. If your enterprise becomes engaged in
records-related litigation, you might have to produce these records management guidelines,
implementation plans, and metrics on effectiveness.
See Also
Create a file plan to manage records in SharePoint Server 2010
Plan how records are collected (SharePoint Server 2010)
This article describes the contents of a file plan and summarizes how to create a file plan for your
organization. The article also directs you to a worksheet in which you can record the file plan.
In this article:
Worksheet
4. Categorize the records. Records in the same category often have the same retention periods and
might require similar treatment in other ways.
Record the information that you collected. You can use the worksheet mentioned in the section
Worksheet for this purpose. Record the kind of record, the category that records of this kind belong to,
and a brief description of the kind of record.
The following is a sample worksheet:
Kind of record
Record category
Description
Payroll timesheets,
Payroll Records
supplementary payroll information
Vendor invoices
Invoices
Training Materials
Shipping Records
Press Releases
Personnel Records
Records of individuals'
employment histories and
related personnel actions.
Records
Description
Media
Record
Retention
Disposition
Contact
category
401k plans
Description of
employee
benefit plan.
Web pages
Employee
Benefit
Plans
X years
None
Kathi
Flood
Employee
Benefit
Plans
X years
None
Reshma
Patel
Pension plans
Description of
employee
pension plan.
Employee
Benefit
Plans
X years
None
Reshma
Patel
Payroll
timesheets
Summaries of
hours worked,
overtime, and
salaries paid.
Electronic
documents
Payroll
Records
X years
Destroy
Reshma
Patel
Supplementary
payroll
information
Summaries of
sick time,
vacation time,
and other nonsalary payroll
items.
Electronic
documents
Payroll
Records
X years
Destroy
Reshma
Patel
Invoices
X years
Destroy
Eric Lang
Product
surveys
Customer
satisfaction
survey.
Web pages
Survey
Materials
X years
Archive
Molly
Dempsey
Questionnaires
Questionnaire
to determine
customer
demographics.
Survey
Materials
X years
Archive
Molly
Dempsey
Training
manuals
Hard-copy
training
content.
Training
Materials
X years
Destroy
Molly
Dempsey
Records
Description
Media
Record
Retention
Disposition
Contact
Training
Materials
X years
Destroy
Molly
Dempsey
category
Training videos
Video training
content.
Video
Shipping forms
Configuration of Print
materials
shipments
Shipping
Materials
X years
Destroy
Eric Lang
Shipping
reports
Documentation
of the shipment
of materials.
Electronic
spreadsheets
Shipping
Materials
X years
Destroy
Eric Lang
Press releases
Releases about
products and
services.
Electronic
documents
Public
Relations
Information
X years
Archive
Molly
Dempsey
Newspaper
articles
News about
products and
services.
Public
Relations
Information
X years
Archive
Molly
Dempsey
Emergency
contact sheets
Employee
information.
Electronic
documents
Personnel
Records
X years
Destroy
Reshma
Patel
Medical plan
enrollment
forms
Employees'
sign-up forms
for health
plans.
Electronic
documents
Personnel
Records
X years
Destroy
Reshma
Patel
Resumes
Resumes
received.
Mixed
Personnel
Records
X years
Destroy
Reshma
Patel
Note:
The example earlier in this section is a sample. It is not a recommendation of any particular file
plan settings. To reinforce that this is an example and not a recommendation of any records
management policy, no retention periods are supplied.
Worksheet
You can use the following worksheet with this article to help plan your deployment:
Manually declaring a document to be a record by using a Web site based on Microsoft SharePoint
Server.
Using a custom solution that is based on the SharePoint Server object model.
Although manually sending records to the Records Center site is not a practical large-scale solution,
you can use it to supplement other methods of creating records.
Defining a policy
A retention policy specifies actions to take on documents at certain points in time. Policy actions occur
automatically; users do not need to start the action.
Two policy actions relate specifically to managing records: transferring a document to another location,
and declaring a document to be a record. If a connection to a Records Center site exists, you can
create a policy that sends documents to a Records Center site. The policy also specifies whether to
copy the document to the Records Center site, move it, or move it and leave a link in the document
library. If in-place records management is enabled for the site, you can create a policy that declares a
document to be a record. You can also use the SharePoint Server object model to create a custom
action.
A retention policy can have multiple stages. For example, you could create a retention policy that
deletes all previous versions of a document one year after the document was last modified, and
transfers the document to a Records Center site five years after the document was last modified.
If in-place records management is enabled for a site, the site can contain both active documents and
records. In this case, you can specify different retention policies for active documents and records. For
example, you could create a policy that declares an active document to be a record two years after the
document was created, and create a second policy that deletes a record seven years after it was
declared to be a record.
For more information about defining information management policies, see Office.com
(http://go.microsoft.com/fwlink/?LinkId=191521&clcid=0x409).
Creating a workflow
When you use Microsoft Office SharePoint Designer to create a workflow, you can add an action to
send an item to a repository. By using this action, you can create workflows that send documents to a
Records Center site. You can also include other actions in the workflow. For example, you could create
a workflow that sends an e-mail message to a documents author requesting approval, and then sends
the document to a Records Center site. You could combine policies and workflows by creating a
retention policy that runs the new workflow one year after a document is created.
You can also use the SharePoint Server object model to create a custom workflow that copies files to
the Records Center site. A workflow that sends files to the Records Center site can be integrated into
your document management system as part of a workflow that guides a document through its life cycle.
For document types that have a predictable life cycle, such as expense reports, you could implement a
workflow that guides the document through its various stages and, as a final step, sends a copy of the
document to the Records Center site. The workflow could be triggered by creating a new document.
Can you depend on the cooperation of users in your organization to comply with records
management processes? In general, avoid manual processes. However, where they are needed,
create suitable training and monitoring to ensure team compliance.
Are you maintaining physical content? Managing active physical content, such as hard copy or CDROM, and sending it to a records vault for retention (together with tracking the record in a Records
Center site) requires unique planning not described in this topic. For example, if no electronic
version of a paper document exists, you might have to track the item by using a list that has
associated policies and workflows. For a full discussion of strategies and techniques for tracking a
physical record, both while it is active and after it is sent to the Records Center site, see the article
Physical records planning (SharePoint Server 2010).
The following table shows how some records in a sample file plan will move to a Records Center site:
Documents
Description
Media
Source location
Becomes a
record...
Benefit plan
Description of
employee benefit
plan.
Web pages
Insurance plan
Description of
employee insurance
plan.
Physical
document
associated with
list item in
SharePoint Server
2010
By sending to a
physical vault and
creating a list item
in the Records
Center site to
track (using a
barcode)
Documents
Description
Media
Source location
Becomes a
record...
Payroll timesheets
Summaries of hours
worked, overtime,
and salaries paid.
Electronic
documents
Payroll records
server not based
on SharePoint
Server 2010
Using a custom
program
Product
development files
Specifications of
products and
associated
documents.
Electronic
documents
See Also
Add, modify, or delete a connection to a document repository or a records center (SharePoint Server
2010)
Create a file plan to manage records in SharePoint Server 2010
Physical records planning (SharePoint Server 2010)
Worksheet
Forms
For each type of record, identify the attributes that you want to capture for records of this type. These
attributes will be columns of the SharePoint Server content type that represents this kind of record.
Information that you would use to categorize records might be an attribute. Data that people search for
might also be an attribute. Other attributes of physical records tie the record in SharePoint Server,
represented by an item in a list, to the physical object that is stored in a physical location. The location
and some way to identify the physical object are probably attributes that you will want to capture.
As with electronic records, you probably want to apply certain policies to physical records. All records
are likely to have an expiration policy and an auditing policy. Physical records in particular might have a
policy that requires a barcode. An image of the barcode that is attached to the physical object could be
associated with the list item that represented the physical record. A labeling policy could require that
each physical object be labeled with the same attributes that are associated with the list item that
represents the physical object. For each kind of physical record, indicate whether the expiration,
auditing, barcode, and label policies are required. Also note any additional policies that are required.
A physical record in SharePoint Server (an item in a list) is only a placeholder for the actual record; it is
not the physical object itself. Therefore, it is likely that you will add processes to keep the physical items
synchronized with actions that are taken on the list items. These processes correspond to SharePoint
Server workflows. Identify the processes that should be associated with each type of record. Common
processes for physical records include the following:
Disposing of the physical record when the list item that represents the record has expired.
Moving the physical object to a storage location when a new item is added to the list.
Are there any forms that should be associated with records of this type? You might need a form for
each process that you identified. Or you might use a form to provide access to the inventory of physical
records.
Use the Physical records tab of the worksheet in the Worksheet section to record the information that
you identified about each type of physical record. Do not fill in the content type for the type of record
yet.
1. Create a flat structure in which each content type that represents a type of physical records is a
child of the parent content type that you created previously.
2. Create a hierarchy, descending from the parent content type, based on the similarities between the
properties of the content types.
On the Content Types tab of the worksheet, identify each content type that represents a type of
physical record. For each content type, note its parent content type. In the Columns column, enter the
name of every column that is defined at the level of the content type. Do not enter the names of
columns that are inherited from other content types. In the Workflows column, enter the name of every
workflow that is defined at the level of the content type. In the Information Management Policies
column, enter the name of every information management policy that is defined at the level of the
content type. In the Forms column, enter the name of every form that is defined at the level of the
content type.
By record type
In the same manner that the physical objects are organized. (For example, a folder could represent
a box, and the items in the folder could represent the objects in the box.)
By year
Because physical records will not be moved to the records archive by using the Send to option, you
cannot use the content organizer with physical records. Instead, the records manager who creates the
physical record must put the record in the correct folder in the correct list.
In the Lists and folders tab of the worksheet, enter the URL of each list that you identified. For each
list, in the Content Types column, determine the content types that will be allowed within the list. Use
the Folder Level 1, Folder Level 2, Folder Level 3, and Folder Level 4 columns to record the
hierarchy of folders and sub-folders in the list. Add more columns if you will nest folders deeper than
four levels.
Worksheet
You can use the following worksheet to help plan how you will manage physical records:
Auditing
Expiration
Search
The eDiscovery search runs at a time that is controlled by the Search and Process timer job. By
default this is 10:30 PM every day. Search results are added to the hold automatically.
3. Review the items in the hold and create additional eDiscovery searches.
4. Locate documents manually, and add them to the hold.
5. Run reports against the hold.
Hold reports are run at a time that is controlled by the Hold Processing and Reporting timer job. By
default this is 11:30 PM every day.
6. Review the documents in the hold and remove irrelevant documents.
7. Identify specific documents in the hold for which more information is needed, and review the audit
log for these documents.
8. Deliver all documents that are associated with the hold.
Auditing
When you send a document to a content organizer, the documents version history is erased. To keep a
history of who changed a document and when each change was made, you will need an audit log. We
recommend that you enable the auditing policy in all site collections that contain active document
libraries. For more information about the auditing policy, see Governance overview (SharePoint Server
2010).
Expiration
Any information that an organization stores is subject to discovery. In addition, electronic documents
consume disk space. Consider implementing an expiration policy to delete documents automatically
when they are no longer needed. For more information about the expiration policy, see Governance
overview (SharePoint Server 2010).
Search
When an organization has to produce documents in a litigation scenario, it must often produce them
quickly or pay a fine. Make sure that Search is configured correctly before the first time that you have to
use eDiscovery. In particular, ensure that Search is configured to crawl all sites in which you may have
to discover content.
Search engines are usually optimized to return only a few highly relevant results. In eDiscovery, the
goal of search is to return all results that match a query, not just the few most relevant results. Search
in SharePoint Server 2010 was improved to better meet the needs of eDiscovery.
To help protect against common malicious attacks, SharePoint Server 2010 searches that run for more
than a specific time are stopped. If your eDiscovery search might run for a long time, consider the
following options:
Create a more tightly scoped search. If you are searching for documents related to a potential
partnership with Contoso, Ltd., for example, consider searching for documents that contain the
word Contoso and that were created in a specific date range, instead of only searching for the
word Contoso.
Run multiple, narrower searches. For example, assume that you are searching for documents
related to recruiting a new CEO from Fabrikam, Inc. Instead of doing one search for Fabrikam
(CEO, Anders Riis, recruit), do three separate searches for Fabrikam CEO, Fabrikam Anders
Riis, and Fabrikam recruit.
Is the governance of the collaboration site appropriate for managing records? Is your industry
subject to regulatory requirements that mandate records be separated from active documents?
Should the administrator of a collaboration site be trusted to manage a site that contains records?
You might want to store records in a site that uses more restricted access than the collaboration
site, or in a site that is backed up on a different schedule.
How long will the collaboration site be in use? If records will have to be kept for longer than the
project is ongoing, choosing an in-place records management strategy means that you will have to
maintain the collaboration site even after it is no longer used.
Will the project members need frequent access to the documents after the documents have
become records? If you use an in-place approach, project members can access documents in the
same manner regardless of whether the documents are active or are records.
Are records managers in your organization responsible for only records, or are they responsible for
all information, regardless of whether it is active or a record? If records managers are responsible
only for official records, having a separate records center might be easier for them.
The following table describes differences between what you can do with records in a record center and
with records that are managed in-place in a collaboration site. The differences are presented from the
point of view of both records managers and employees collaborating on a project team.
Differences between a records archive and in-place records
Factor
Records archive
In-place records
Factor
Records archive
In-place records
Easier.
Yes.
Scope of eDiscovery
Administrative security
The following table describes differences between the two records management approaches that might
affect how you manage IT resources.
Records archive
In-place records
Fewer sites.
Scalability
Ease of management
Storage
Decide what actions will cause an active document to become a record. For example, a user could
select an option to declare a document to be a record; a workflow could run after a specific event
and turn an active document into a record; or you could define a retention policy that turns an active
document into a record after a certain time.
Restrict who can perform records-related operations. For example, you could specify that any user
can declare a document to be a record, but only records managers can edit or delete a record.
Restrict what actions users can perform on records. For example, you might prevent users from
deleting records, or from both editing and deleting them.
Specify a retention policy for active documents, and a different retention policy for records.
For more information about deciding whether to use in-place records management or a records archive,
see Using a records archive versus managing records in place (SharePoint Server 2010).
This article describes how to make the planning decisions that are required before you can implement
in-place records management. It does not explain how to implement the decisions that you make.
Before working through the steps in this article, you should already have created a file plan. For more
information about file plans, see Create a file plan to manage records in SharePoint Server 2010.
If you are using in-place records management, it is assumed that you are also using SharePoint Server
for another purpose, such as team collaboration sites. (If this is not true, consider using a records
archive.) Therefore, you should already know the content types and folder hierarchy that your existing
solution uses, or be defining these in parallel with designing your records management solution if your
other SharePoint Server solution is being developed at the same time.
In this article:
Worksheets
Do all records of the same record type have the same retention policy? If so, organize based on
content types.
Do most record types consist of records with the same retention policy? Is the case of a record type
having records of different retention policies rare? If so, can you easily and logically create
subtypes so that the same retention policy applies to every record of the subtype? If so, organize
based on content types.
For example, if non-disclosure agreements (NDAs) are retained for five years; leases are retained
for 10 years; and partnership agreements are retained for 15 years but you classified them all as
legal agreements, not all legal agreements have the same retention period. But if you subdivided
legal agreements into three separate kinds of legal agreement records NDAs, leases, and
partnership agreements then all records of the same type would have the same retention period.
Will all records have common attributes, or metadata, that determine the retention policy? If so,
organize based on location.
For example, if every record will have a customer attribute, and records for government
customers have a different retention policy than records for corporate customers, then organize
based on location.
Does your organization already have a folder structure that users are familiar with? Does the same
retention policy apply to all records in a folder? Can you rely on users to store documents in the
correct place in the folder structure? If all these are true, organize based on location.
If none of the previous heuristics applies, an in-place records management implementation is probably
not a natural fit for your situation. Reconsider whether using a records archive will work. If you use an
in-place approach, you have two options. The first option is to create additional content types whose
only purpose is to differentiate items with different retention periods. The second option is organize
items within folders as much as possible, and then to use sub-folders to hold items with different
retention periods. Either of these options is likely to be confusing to users.
If your organization already uses SharePoint to manage documents and you are now starting to use the
Records Management functionality, content types and a folder structure already exist. If neither of these
map well to retention policies, you will either have to convert some items to new content types or move
some items to new folders.
If the previous task resulted in a folder having more than one retention policy, you will have to create
subfolders. For each folder that could contain items with different retention policies, create a sub-folder
for each retention policy. Since users will determine where they want to store documents, there must be
an easy way to explain to users what to put in each sub-folder. If there is not, consider forbidding users
from choosing where they want to store documents and using the Content Organizer instead. Update
your mapping of record types to folders to reflect the new sub-folders.
If you have an existing SharePoint Server solution, you will probably have to move some existing
documents to put them in the folders that have the appropriate retention policies.
Determine how you will train users to place documents in the correct location and whether you will audit
where documents are put. The successful application of retention policies depends on records being
stored in the correct folder.
How a document will become be a record There are several ways that a document can become a
record:
You can define a retention policy on active documents that automatically makes an active
document a record after a certain time.
You can create a workflow that makes an active document a record, and cause the workflow to be
triggered by specific events.
You can configure a library so that every document that is placed in the library is converted to a
record.
How will active documents become records in your solution? If a document should become a record a
fixed time period after it is created or modified, using a retention policy is a good solution. For example,
you can specify that six months after the last time that a document is modified, the document becomes
a record. Users will not have to take any action to make documents become records; this will occur
automatically.
If there is no standard time when documents become records in your organization, there are two
possibilities. If you can specify the rules under which a document becomes a record, you can create a
workflow that evaluates a given document against the rules, and declares the document to be a record
when it is suitable. You can then create a retention policy that starts the workflow periodically. However,
if only users of a document know when a document should become a record, you should provide a
manual way for a user to declare a document to be a record.
Who can declare and undeclare records You can specify that anyone can declare documents to be
records, that only administrators can declare documents to be records, or that only policy actions can
declare documents to be records. If you select only policy actions, then users cannot manually declare
a document to be a record. Documents can be converted to records only by a rule in a retention policy.
The same options are available for defining who can un-declare a record as for defining who can
declare a document to be a record.
What actions can users take on records You can restrict the actions that users can take on records
without restricting what users can do to active documents in the same library. The three levels of
restriction that you can set are as follows:
No restriction. Users can perform the same actions on records that they can perform on active
documents.
Retention policies Your retention policies should already have been defined in the file plan.
Auditing The same auditing policies apply to both records and active documents. Determine which
actions that users might perform on a document that you want to track. You can define the auditing
policy either at the folder level or by content types. Defining auditing policies based on content types
usually results in fewer unnecessary events being logged.
Note:
All policies are removed when a record is sent to the records archive. Therefore, if you are
using a multi-stage retention policy that includes sending a record to an archive after a certain
time, the archives retention policies will apply after the record is in the archive.
Workflows Will you use workflows to track any actions that are specific to records management? If so,
determine what the workflows will be, and which type of items they will be applied to. For example, you
could have a workflow requests approval from a records manager when a user tries to declare an item
to be a record.
Worksheets
You can use the following worksheet with this article to help plan for in-place records management:
See Also
Using a records archive versus managing records in place (SharePoint Server 2010)
Retention tags: An administrator creates retention tags and links those tags to a retention policy.
The administrator also configures a default retention policy that applies to untagged messages.
Users can tag their messages and folders, and use rules to apply retention policies that define how
messages are handled as records. This is a user-centric approach that enables end-users to tag
and store content based on their individual needs. For more information, see Understanding
Retention Tags and Retention Policies (http://go.microsoft.com/fwlink/?LinkID=195435).
Managed folders: An administrator creates managed folders and links them to a managed folder
mailbox policy. Users can then organize their messages in those managed folders to apply the
desired policy. This is an administrator-centric approach that enables the organization to define
specific rules for classifying content that end-users must follow. For more information, see
Understanding Managed Folders (http://go.microsoft.com/fwlink/?LinkId=205098).
For more information about Exchange Server 2010 MRM, see Understanding Messaging Records
Management (http://go.microsoft.com/fwlink/?LinkId=205099).
If you must have a message archive solution that provides retention management for messages in your
organization, Exchange functionality might be all that you need. However, if you have additional needs
for your messages, SharePoint Server can provide useful functionality for your messages in addition to
other content. Consider SharePoint Server in the following situations:
You prefer to manage messages in context with other content for completeness or to use
collaboration, metadata, workflow, and search capabilities.
You must manage message records together with other content records as part of a centrallymanaged file plan that defines metadata, workflow, and sophisticated retention requirements.
Review the considerations in the following table to determine whether Exchange Server 2010 MRM or
SharePoint Server 2010 records management fits the needs of your organization. If you use a product
other than Exchange Server 2010, you can still use the information about SharePoint Server 2010 to
compare considerations with your product.
Consideration
Isolation
Consideration
Scope of holds
See Also
Records management overview (SharePoint Server 2010)
Create a file plan to manage records in SharePoint Server 2010
Messaging Policy and Compliance (http://go.microsoft.com/fwlink/?LinkID=196071)
Managing digital assets overview (SharePoint Server 2010) describes managing digital assets,
details the users of a digital asset library, outlines key functionality for managing digital assets in
SharePoint Server 2010, and summarizes potential scenarios for managing digital assets.
Plan for asset libraries covers the planning process for managing digital assets. This process
includes steps for planning for asset libraries and describes tasks associated with planning various
aspects of a digital asset solution, such as storage and performance, permissions and security,
metadata and Search, Web Parts, views and filters, and client support.
Digital asset library topology and architecture (SharePoint Server 2010) discusses logical
architecture and topology decisions that are related to deploying digital asset libraries
The amount of storage space that is needed for the assets, and the performance issues to consider
for serving the assets to users.
How to move assets within the organization as team members contribute to creation, review,
approval, publication, and disposition of assets.
The policies to apply to assets so that asset-related actions are audited, assets are retained or
disposed of correctly, and assets important to the organization are protected.
How assets are treated as corporate records, which must be retained according to requirements
and corporate guidelines.
For information about how to plan a digital asset solution by using SharePoint Server 2010, see Plan
digital asset libraries (SharePoint Server 2010).
Asset creators This group includes people who create individual assets, such as graphic artists,
video producers, or marketing copywriters, and who submit assets to the asset library. For
example, a graphic artist might create a product logo in multiple resolutions and sizes, and in both
color and black and white, and then upload all versions of the logo to the asset library for use by
other members of a product marketing team.
Asset managers This group includes people who manage the assets in the library. They are in
charge of the end-to-end workflow from the time that an asset is first submitted, through publication,
to the time when an asset expires. They are also in charge of managing and organizing assets in
the library. For example, an asset manager might take multiple versions of a product logo and
categorize them appropriately in the library, and add important metadata such as keywords, and set
a date after which the asset cannot be used.
Asset consumers This group includes people who have to find and use assets from the library to
create other work products. For example, Web designers can use a product logo from the asset
library when they create marketing pages for product Web sites.
Depending on the scenario, there can be crossover between these groups of users. For example, users
who have permission to upload assets to the library may also have permission to categorize and
manage the assets they submit to the archive. Asset creators can also be asset consumers if they look
for and use assets that are added to other work products, which in turn are uploaded as separate
assets. For example, a video producer might use a product logo while making a marketing video for a
product, and then upload the video to the library as a separate asset.
Taken, and Length (seconds) that contribute to the metadata for a particular asset. The asset library
also has a preview mode that displays a thumbnail and some of this metadata when you hover the
pointer over an asset. Enterprise keywords can be assigned to assets to make them more easily found
through search queries. Keywords can be assigned by asset creators when a new asset is uploaded, or
can be added later by an asset manager. Users can rate assets, a capability that provides additional
metadata for assets. The metadata can then be used when assets are displayed in a Web Part. For
example, if you have a library of training videos that users have viewed and rated, you can use a Web
Part to display the top-rated videos on a Web page.
Asset creators and managers work directly in the asset library to upload, categorize and manage
assets. Asset consumers can browse the library to find assets for inserting into projects in other
applications. Consumers can browse an asset library from Microsoft Office applications and insert an
asset into the open application, such as Microsoft Word or Microsoft PowerPoint.
There are four ways to display digital assets to users in SharePoint Server 2010:
The specific methods that you use to display asset to users of your asset library will vary depending on
who the users are, how they have to use assets from the library, and which methods for displaying
assets are most appropriate for an asset library scenario.
In addition to the features that are part of the asset library, you can take advantage of SharePoint
Server features such as workflows, routing, rules, and policies. These features help manage the assets
as they come into the asset library, track the progress of assets, automate publication of assets on
approval, and set the expiration for assets.
Scenario
Description
Scenario
Description
Team site
Corporate archive
Scenario
Description
See Also
Plan digital asset libraries (SharePoint Server 2010)
As a general document library for digital assets at the team level This can be as simple as a
place to store images, audio, and video files for use by your team. You might give everyone on the
team permissions to upload, organize and manage assets, or you might restrict the task of
organizing and managing assets to a small subset of people on your team.
Note:
SharePoint Server 2010 does not support live streaming of audio or video content.
As a centralized repository for digital assets for the organization In this situation, you use
content approval and workflow for all assets that are added to the library, and you might have
people with different roles who are responsible for separate stages of the approval process. For
example, graphic designers and audio/video producers could upload assets to the library. But a
content manager could be responsible for triaging incoming assets and approving them for
publication, in addition to assigning additional metadata to the assets.
Determine how many asset libraries are needed This determination, as in the earlier analysis and
planning steps, also depends on how the asset library will be used. For example, if you have individual
teams that must use asset libraries for collaboration, and who must use content governance such as
versioning while they work on assets, you can create an asset library for each team site that needs one.
You can then let the teams manage their own assets. If you want the asset library to serve as a largescale centralized repository for use by many teams, you might create a single asset library and adjust
the permissions to restrict those who use, manage, and search the library. For more information, see
Document library planning (SharePoint Server 2010).
Note:
If you enable the disk-based cache for a Web application, every site collection within that Web
application will use the cache. If you do not have to have the disk-based cache for most the
sites, consider putting in a separate Web application only those site collections containing an
asset library that requires the disk-based cache.
Decide where to create the asset library Where you create the asset library depends on how you
plan to use it. For a general asset library that will be used at the team level, you might create the asset
library at the site level. For a centralized repository, you might create the asset library at the site
collection level. If the asset library will be used with a Web publishing site, place the library in the same
site collection as the publishing site so that asset files that are used by publishing pages are available
to the publishing site. Use your asset analysis to determine who creates and uses assets, and how
those assets are used. This will help you decide where asset libraries are needed in the enterprise.
Choose a fixed or collaborative library Depending on your scenario, the asset library will be either
primarily a fixed library, where completed assets are checked in and the library is read-only, or it will be
a collaborative environment, where versioning is enabled for the library, and users who have
appropriate permissions are able to both read and write to existing assets.
Decide how to organize the asset library You can plan to store all assets in the root of the asset
library, and use custom views to display assets to library users based on certain criteria. You can also
use folders to hold assets based on criteria that you specify. For example, you might put all videos in
one folder and audio files in another, or you might create folders based on products and put all assets
related to a particular product into each folder. Refer to your asset analysis to determine the most
common scenarios for how assets are used in your organization.
Plan workflows
You use workflows to perform management tasks on assets in the asset library as you do with
documents in a document management library. Important questions include the following: Do assets
have to be reviewed and approved before they can be used by asset consumers? Who is responsible
for managing the expiration of assets? Are assets retained or deleted after expiration? For more
information, see Content type and workflow planning (SharePoint Server 2010).
Plan policies
For each content type to be used in your asset library, you must to plan the information management
policies that determine how assets are audited, retained, and labeled. For more information, see
Information management policy planning (SharePoint Server 2010).
Important:
SharePoint Server 2010 does not automatically apply Information Rights Management (IRM)
protection to audio or video content that is stored in a SharePoint Server 2010 asset library.
Additionally, when audio or video assets stored in SharePoint Server 2010 are viewed by a
user, copies of those assets might be stored in the users local browser cache. The SharePoint
Server 2010 media player supports playing IRM-protected audio and video formats where the
DRM protection was applied by an external IRM provider that is supported by Microsoft
Silverlight 3 or subsequent versions. For more information, see Digital Rights Management
(DRM) (http://go.microsoft.com/fwlink/?LinkId=154933).
Feature
Description
Podcasts
Content Organizer
Feature
Description
Published links
Throttling controls the rate at which audio and video files are downloaded to the client so that overall
performance on the site is not affected. Bit Rate Throttling also allows for progressive downloading and
viewing of these assets by users. For more information about the disk-based cache, see Plan for
caching and performance (SharePoint Server 2010). For information about how to enable and configure
Bit Rate Throttling, see Bit Rate Throttling Readme (http://go.microsoft.com/fwlink/?LinkId=154962).
Media Web Part and field control Used to display embedded video in a Web page.
Image Web Part and field control Used to display images on a Web page.
Content by query Web Part Used to display items from all sites in a site collection, a selected
site or subsite, or a specific list or library. The query can be configured to return a list of items
based on list and content types, and can be filtered and targeted to a specific audience.
When you design Web pages for sites, consider which fields to expose to users in Web pages and Web
Parts to help users find the assets they need. You can customize the information that is displayed when
a user lets the pointer pause on an asset in the asset library by editing the Thumbnail view in the
Library Settings page.
users access the asset library, and must they all have the Silverlight 3 player installed? Will the
organization require a managed deployment of the Silverlight 3 client to all desktops, or will you let
users install the client on an as-needed basis? For more information about Silverlight 3, see Silverlight
Overview (http://go.microsoft.com/fwlink/?LinkId=154002).
Note:
When a user who does not have Silverlight 3 installed on a computer tries to play an audio or
video asset, that asset opens with whatever media application is set as the default player on
the computer.
See Also
Managing digital assets overview (SharePoint Server 2010)
The relationship between digital asset libraries and content databases in the logical architecture.
Optimizing a server farm with a binary large object (BLOB) cache or with Bit Rate Throttling.
Scaling out a server farm with dedicated databases or server hardware for digital assets, if it is
necessary, to accommodate a large volume of digital assets.
In this article:
As another example, for a large corporate training site which will contain training videos used by
internal employees, you might place the asset library in the top-level site of a site collection that uses its
own content database, and that has no other sites under it in the site hierarchy. By doing this, you can
ensure that there is sufficient storage space for the files that will be uploaded to the asset library. This
also lets you plan for future expansion, because the content database is already isolated by itself, and
does not share content with any other sites in your solution.
The following figure shows an example of the logical architecture for when an asset library is put in a
separate site collection with a content database that is separate from the rest of the sites:
The following table summarizes these two approaches. Note that you can implement a combination of
these two approaches.
Area
Description
Usage
Area
Suggested Content
Browser Locations list for
the publishing site. This will
enable content creators to
access the asset library
when they insert assets
into Web pages within
SharePoint Server 2010, or
within Microsoft Office
2010 suite applications,
such as Microsoft Word.
Management
When you plan to incorporate the management of digital assets into your solution, you should carefully
consider the quantity and size of the files that will be stored and also how they will be used. This will
help you design your site architecture when you determine where the asset library should be located.
BLOB cache The disk-based BLOB cache controls the caching for binary large objects (BLOBs),
such as frequently used image, audio, and video files, and other files that are used to display Web
pages, such as .css and .js files. The BLOB cache should always be enabled if your solution will
include asset libraries, and is enabled on every front-end Web server in a server farm.
Bit Rate Throttling Bit Rate Throttling is an Internet Information Services (IIS) 7.0 extension that
meters the download speeds of media file types and data between a server and a client computer.
Bit Rate Throttling can be enabled on every front-end Web server in a server farm, and it should
always be enabled if your solution will include audio or video files in asset libraries. For more
information, see Bit Rate Throttling (http://go.microsoft.com/fwlink/?LinkId=155151).
Maximum file upload size The maximum upload file size is a setting that is used by the
SharePoint Server 2010 Web application that specifies the maximum size of a file that a user can
upload to the server. The maximum file upload size is configured for every Web application on the
server that hosts Central Administration, and should be adjusted to accommodate the size of files
that will be uploaded to asset libraries.
For more information, see Plan for caching and performance (SharePoint Server 2010).
If your digital asset library solution will be used to store a very large amount of content, you should
consider using Remote Blob Storage (RBS) to move the storage of large binary data (BLOBs) from
Microsoft SQL Server 2008 to an external storage solution. RBS is not a feature of SharePoint Server
2010 or Internet Information Services (IIS) 7.0. For more information, see Overview of Remote BLOB
Storage (SharePoint Server 2010).
BLOB cache is enabled in IIS 7.0 and stored on every front-end Web server.
If Bit Rate Throttling is used, it must be installed and configured in IIS 7.0 on every front-end Web
server.
Additionally, the server that hosts the Central Administration Web site is used to configure the
maximum file upload size for each Web application it contains.
Note:
Depending on the size of your server farm and the kind of solution that you are implementing,
you might have additional servers that are designated for specific roles, such as Search
databases, or query and index servers.
The following illustration shows a typical three-tier server farm topology with components added for a
digital asset library topology:
Callout
Element
For example, if you plan to use an asset library for storing training videos, you must consider the
average size of each video, and the estimated total number of videos that will be needed for your
organization. You must also consider the number of users who will view the videos, and which videos
are likely to be requested most frequently.
For each main component in a digital asset library topology, consider the following issues:
Database storage Is there sufficient storage capacity on the content database servers for all the
files that users will upload? It is important to understand the average size of the files and the
number of files that you expect the users will upload to the server.
BLOB Cache storage Is there sufficient storage capacity on the front-end Web servers for the
files that will be cached?
Remote BLOB storage (RBS) If you will have large volumes of content, you should consider
using RBS to move storage of BLOBs out of the content database and into an external storage
solution. For more information, see Overview of Remote BLOB Storage (SharePoint Server 2010).
The logical architecture of your digital asset library plan will influence options for scaling out a server
farm. If a digital asset library is contained in a dedicated site collection, you can easily move the
database to a dedicated server, if it is necessary, to improve capacity and performance.
See Also
Plan digital asset libraries (SharePoint Server 2010)
Managing digital assets overview (SharePoint Server 2010)
Plan for caching and performance (SharePoint Server 2010)
This article provides links to worksheets that you can use to record information that you gather and
decisions that you make as you plan your deployment of Microsoft SharePoint Server 2010. Use these
worksheets in conjunction with not as a substitute for Planning and architecture for SharePoint
Server 2010.
To do this
Plan site
navigation
(SharePoint
Server 2010)
To do this
Plan managed
metadata
(SharePoint
Server 2010)
Determine basic
taxonomy, including
term, usage, owner,
and group.
Plan managed
metadata
(SharePoint
Server 2010)
Determine
taxonomy including
detailed identifying
characteristics such
as measurements.
Plan managed
metadata
(SharePoint
Server 2010)
Plan to share
metadata
information using
managed metadata
services and
connections.
Document
management
planning
(SharePoint
Server 2010)
Identify document
management
planning
stakeholders and
record document
management
practices.
Document
management
planning
Record information
gathered when
analyzing document
(SharePoint
Server 2010)
To do this
usage.
Document
management
planning
(SharePoint
Server 2010)
Policy worksheet
(http://go.microsoft.com/fwlink/?LinkID=165883)
Plan information
management
policies for content
types.
Records
management
planning
(SharePoint
Server 2010)
Document
management
planning
(SharePoint
Server 2010)
Upgrade worksheet
(http://go.microsoft.com/fwlink/?LinkId=179928)
Record information
about your
environment while
you prepare for
upgrade.
Metadata-based
routing and
storage planning
(SharePoint
Server 2010)
To do this
Metadata-based
routing and
storage planning
(SharePoint
Server 2010)
To do this
Document
managemen
t planning
(SharePoint
Server 2010)
Record
information
gathered when
analyzing
document
usage.
Plan for
backup and
recovery
(SharePoint
Server 2010)
Plan content
deployment
(SharePoint
Server 2010)
Metadatabased
To do this
routing and
storage
planning
(SharePoint
Server 2010)
effective part of
your metadatabased routing
and storage
solution.
Metadatabased
routing and
storage
planning
(SharePoint
Server 2010)
Determine and
record how the
content
organizer
settings in your
site can be an
effective part of
your metadatabased content
routing and
storage
solution.
Document
Plan a content
managemen type.
t planning
(SharePoint
Server 2010)
Plan
managed
metadata
(SharePoint
Server 2010)
Determine
taxonomy
including
detailed
identifying
characteristics
such as
measurements
.
Document
managemen
t planning
(SharePoint
Server 2010)
Plan libraries
based on sites
and on
document
types.
Document
managemen
Identify
document
To do this
t planning
management
(SharePoint planning
Server 2010) stakeholders
and record
document
management
practices.
In-place records planning
worksheet(http://go.microsoft.com/fwlink/?LinkId=185011&clcid=0x409
)
Records
managemen
t planning
(SharePoint
Server 2010)
Identify record
types and
content types
to be stored in
normal
document
libraries.
Plan
managed
metadata
(SharePoint
Server 2010)
Plan to share
metadata
information
using managed
metadata
services and
connections.
Plan
incoming email
(SharePoint
Server 2010)
Plan incoming
e-mail in order
to enable
SharePoint
sites to receive
and store email messages
and
attachments in
lists and
libraries.
Document
managemen
t planning
(SharePoint
Server 2010)
Plan
information
management
policies for
content types.
Plan sites
To do this
(http://go.microsoft.com/fwlink/?LinkID=167837)
and site
collections
(SharePoint
Server 2010)
site collections
and sites, and
record
decisions
about site
themes and
navigation.
Plan site
navigation
(SharePoint
Server 2010)
Plan for
using
themes
(SharePoint
Server 2010)
Term sets planning
worksheet(http://go.microsoft.com/fwlink/?LinkId=163486)
Plan
managed
metadata
(SharePoint
Server 2010)
Determine
basic
taxonomy,
including term,
usage, owner,
and group.
Plan and
prepare for
upgrade
(SharePoint
Server 2010)
Record
information
about your
environment
while you
prepare for
upgrade.