Upload
durgaksv
View
74
Download
0
Embed Size (px)
Citation preview
SHAREPOINT 2010
READING MATERIALS
Overview of SharePoint Architecture
This article provides an overview of the architectures of Microsoft SharePoint
Foundation and SharePoint Server, including the platform stack, the Microsoft
ASP.NET-IIS integrated request pipeline, the server and client object models, the
execution process system for sandboxed solutions and farm solutions, and more.
What Is SharePoint?
The use of the plural term "architectures" in the title is not a mistake. SharePoint has
many architectures, partly because "architecture" has many meanings in the context
of software development, but also because SharePoint itself is many things—things
that in the past would have been distinct applications or platforms.
The following is a selection of some of the most important things that SharePoint is:
A portal server with delegated administration. SharePoint enables
information workers (IW) who have no knowledge of website design or
website administration to create, almost instantly, attractive and functioning
websites. This relieves information technology (IT) departments from the
burden of creating and administering the sites, and it empowers the IWs to
create their own sites for teams, blogs, wikis, and other purposes.
A groupware application kit. SharePoint provides a platform on which IWs
can create collaboration solutions that include document libraries and
workspaces, workflows, wikis, blogs, and team-oriented lists, such as Events,
Announcements, and Tasks. Microsoft SharePoint Workspace (formerly
Microsoft Office Groove 2007) provides an offline experience for these
collaboration solutions.
A workflow host. Business processes can be systematized and modeled
with workflows that are triggered by associated events; for example, the
addition of a document to a document library.
A content management application. SharePoint Server Enterprise Content
Management (ECM) features include document management, records
management, and web content management.
A Business Intelligence (BI) application kit. The Microsoft Business
Connectivity Services (BCS) features of SharePoint enable data from non-
SharePoint sources, such as a SAP installation or Oracle database, to be
accessed (read/write) just as if it were an ordinary SharePoint list.
The operating system of an intranet. SharePoint can provide for an intranet
many of the functions that an operating system provides for a computer,
including storing and copying files, hosting services, starting applications, and
securing data. (This is not to imply that SharePoint can only be used on an
intranet. SharePoint can also host extranet and Internet-facing solutions.)
A host for services. SharePoint deployments make data available through a
client object model, the REST-based Windows Communication Foundation
(WCF) Data Services (formerly ADO.NET Data Services), and many out-of-
the-box ASMX web services. In addition, the SharePoint Service Application
Framework provides a platform that enables developers to build scalable
middle-tier services that can provide data or processing resources to other
SharePoint features.
A data store. SharePoint stores data as multicolumn lists in a Microsoft SQL
Server database. You can query the data by using LINQ and also using
Collaborative Application Markup Language (CAML). The data can be
mirrored, backed up, restored, and, depending on the edition of SQL Server
being used, you may be able to take snapshots of the data store.
A data and processing layer for multiple user interfaces (UIs). Besides its
native UI of webpages (including special versions for mobile devices), which
can contain ECMAScript (JavaScript, JScript), SharePoint also supports
access from Microsoft Silverlight applications and the Microsoft SharePoint
Workspace client application. With the SharePoint client object model, you
can access SharePoint using Windows Presentation Foundation (WPF),
Windows Forms, or any other managed code application.
This article discusses the architectures of SharePoint 2010 (with many links to more
detailed information) in several senses, including the platform stack on which
SharePoint runs, the configuration layers, the client and server object models, the
services framework, the HTTP request pipeline, and the worker process system.
SharePoint Development Platform
Figure 1 shows how SharePoint Foundation is built on Microsoft .NET Framework
3.5, ASP.NET, and Internet Information Services (IIS). SharePoint is also built on
SQL Server, but you can install SQL Server on a dedicated server that does not
have SharePoint installed, which is typical in a production farm. All of these platforms
must be running on a 64-bit installation of Windows Server 2008 on the server
computers. SharePoint Server, in turn, is built on SharePoint Foundation. There are
two editions of SharePoint Server: Standard and Enterprise.
Figure 1. The platform stack for SharePoint development
Perhaps the most noteworthy aspect of the figure is that IIS and ASP.NET are
shown as a single platform. This is because SharePoint requires that IIS operate in
integrated mode with ASP.NET. Hence, from a SharePoint point of view, they are
effectively a single web-hosting application. For more information about this, see the
next section, SharePoint as an ASP.NET-IIS Application.
In Figure 1, the smaller boxes that have no fill represent some selected subparts of
the platform that contains them, or on which they depend. The two thin, downward-
pointing arrows indicate some specific dependencies that are shown only as
examples. Many other specific dependencies are not shown in the figure. The thick,
left-pointing arrows indicate that the entity on the right side accesses the entity to
which the arrow points. For example, BCS accesses external databases.
SharePoint as an ASP.NET-IIS
Application
As the High Level Object Model section later in this article shows in more detail, the
highest level of organization in a SharePoint deployment, other than the farm itself, is
the web application. A web application in SharePoint terminology is closely related to
what is called a website in IIS terminology. An IIS website monitors for incoming
requests through a particular port, and it checks for a particular host header or IP
address, or both. Every SharePoint Foundation web application is hosted in an IIS
website that has the same name as the web application. It can be helpful, especially
when you are trying to see the relation between SharePoint and IIS from a high and
broad perspective, to think of the SharePoint web application and its corresponding
IIS website as a single entity.
Nevertheless, the SharePoint web application and the IIS website are not quite the
same thing (and they are represented by different classes in the SharePoint object
model: the SPWebApplication class and the SPIisWebSite class). For one thing,
although there is usually a one-to-one relation between SharePoint web applications
and IIS websites, this is not always the case. It is possible to extend a SharePoint
web application to multiple IIS websites, although that is not a common design.
Figure 2 shows the IIS websites and application pools on a SharePoint Foundation
front-end web server.
Figure 2. IIS Manager on a SharePoint Foundation front-end web server
Just as in any application that is built on the ASP.NET-IIS integrated pipeline, when
a front-end web server receives a request from a client for a page or other resource
in a SharePoint site, the request is passed through a pipeline of units that process
the request. This processing includes authenticating the user, verifying the user’s
authorization, building the response, sending the response, and finally, logging the
request. For more information about the integrated pipeline, see ASP.NET
Integration with IIS 7.
The response to any request is produced by an HTTP handler object. Requests are
assigned to one or another HTTP handler object (or to a handler factory class that
creates HTTP handler objects) depending on the resource requested and the HTTP
verb in the request. The assignment is determined by a stack of configuration files
named applicationhost.config, machine.config, and web.config.
The request pipeline also contains HTTP modules. Modules are assemblies that
typically contain one or more event handlers or define new events that other
modules can handle. An HTTP module can register for one or more events in the life
cycle of the request. They are often used to preprocess requests or postprocess the
response. The result of a module’s preprocessing is stored in the HttpContext object.
For example, the value of the User property is produced by an authentication
module.
The processing of a request by HTTP modules and an HTTP handler is governed by
an HttpApplication object or an object derived from that class. SharePoint installs a
global.asax file in the root of each web application (IIS website) that identifies
SPHttpApplication as the class from which an HTTP application object is created.
SharePoint also modifies the pipeline with a custom HTTP module
(SPRequestModule), and with changes to the default applicationhost.config file. For
detailed information about SharePoint and the integrated pipeline, see Microsoft
SharePoint Foundation as an ASP.NET Application.
Figure 3 shows the relations among the classes that handle HTTP requests for a
SharePoint front-end web server.
Figure 3. SharePoint customizations of the HTTP request pipeline
In addition to its use of the integrated pipeline, SharePoint uses some other features
of IIS and technologies from ASP.NET. Among them are the following:
Active pages (aspx files): SharePoint pages are ASP.NET pages.
SharePoint controls are referenced in the page markup with a registered
"SharePoint" prefix. (For more information about the ASP.NET page parsing
and compiling system, see Understanding ASP.NET Dynamic Compilation.
Note that the standard page parser of ASP.NET compiles a page the first time
it is requested unless the page is explicitly set not to be compiled. However,
SharePoint pages that have been customized by a SharePoint website owner
are stored in the SharePoint content database and are not compiled when
they are accessed. SharePoint uses a custom virtual path provider, an
internal class named SPVirtualPathProvider that is derived from
VirtualPathProvider, to locate a requested page from either the file system or
the content database and load it.
The master page/content page distinction: A SharePoint page is a merger
of a master page and a content page. For more information, see ASP.NET
Master Pages and Master Pages. (For some SharePoint Server pages, a third
foundational page is involved in the merger, a page layout.)
Web Parts: Web Parts actually originated in an early version of SharePoint.
The idea was adopted by ASP.NET. In most SharePoint Web Part
development situations, we recommend that you use the ASP.NET version,
but in some situations the original SharePoint incarnation is a better choice.
The SharePoint UI for mobile devices also uses the ASP.NET concept of
registered Web Part adapters. For more information about Web Parts in
SharePoint, see Building Block: Web Parts and Building Block: Mobile Pages,
Controls, and Adapters.
User controls (.ascx files): Many SharePoint web controls and Web Parts
are built with ASP.NET user controls.
Web services (.asmx files): Some, but not all, SharePoint web services are
implemented as ASP.NET ASMX services. For more information about
ASP.NET web services in SharePoint, see ASP.NET Web Services.
Virtual directories: SharePoint maps several virtual directories in each IIS
website to physical folders in the SharePoint root, which is the folder
%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\.
When you as a developer need to provision SharePoint web applications with
images, resource files, and other important files, they are deployed to the
appropriate physical folder on the front-end web servers. This process is
handled automatically by the solution deployment mechanism of SharePoint.
For example, user controls are deployed to %ProgramFiles%\Common
Files\Microsoft Shared\web server extensions\14\ControlTemplates (or a
subfolder), which is mapped to the virtual directory _controltemplates.
ASP.NET development experience can be an advantage for a SharePoint developer,
but the SharePoint development experience is different from the ASP.NET
experience in many ways. Some examples of the differences are as follows:
SharePoint has its own installation and deployment model. For more
information, see SharePoint Deployment Models later in this article.
SharePoint makes a distinction, unknown in ASP.NET, between application
pages and site pages. For more information, see Pages, Parsing, and Safe
Mode later in this article.
SharePoint has its own systems for modifying web.config files. For more
information, see Working with Web.config Files.
The ASP.NET worker process model is modified in SharePoint. See Process
and Execution Trust Model later in this article.
For more information about how SharePoint development differs from ASP.NET
development, see ASP.NET vs. SharePoint: How Development Differs.
SharePoint Configuration Stack
SharePoint configuration settings exist at several levels. As in all ASP.NET
applications that use the integrated pipeline, some fundamental settings are in the
machine.config file, the global web.config file, and the applicationhost.config file,
which is the IIS configuration store. SharePoint makes no changes in the default
versions of the first two files. It does make some changes in the IIS configuration
store. For more information about the changes, see Microsoft SharePoint Foundation
as an ASP.NET Application.
Each IIS website and, therefore, each SharePoint web application, can have a
web.config file in its root folder. This file is substantially customized by SharePoint
whenever a SharePoint web application is created. For more information about the
changes, see Microsoft SharePoint Foundation as an ASP.NET Application.
SharePoint also takes advantage of the fact that web.config files can be applied to
specific virtual or physical folders within a web application. For example, SharePoint
puts a web.config file in the virtual directory _layouts\mobile (which is mapped to the
physical directory %ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\TEMPLATE\LAYOUTS\MOBILE\). Among other things, the web.config
file registers a series of filters that control how a page is rendered, based on the
capabilities of the mobile device that has requested the page.
All of the configuration files discussed so far must be identical across all front-end
web servers. The SharePoint deployment model and its system for programmatically
modifying web.config files helps ensure conformity to this rule. For more information,
see Building Block: Solutions and Working with Web.config Files.
Farm-wide configuration settings are stored in the SharePoint configuration database
on the computer that is running SQL Server in the farm. Configuration for specific
types of websites is contained in various kinds of XML files, such as the Onet.xml
file, and configuration for specific instances of websites is contained in the content
database. In addition, several classes in the SharePoint object model have property
bags that can be used to store custom configuration information for specific objects,
such as objects that represent websites, Features, alerts, and files.
Finally, context information for specific HTTP requests is contained in the
ASP.NET HttpContext object of the request. The SharePoint object model adds an
SPContext class that does not inherit HttpContext; however, it gets many of its
property values from the current HttpContext object and adds other properties to
represent SharePoint-specific context information, such as the current website, list,
and list item.
SharePoint Deployment Models
SharePoint solutions are generally not installed by using MSI or ClickOnce
technology. (Some exceptions are noted later.) SharePoint has its own installation
system. Instead of MSI files, the solutions are packaged in SharePoint solution
package files. These are CAB files that have a special extension: .wsp. SharePoint
solution package files can contain several kinds of elements, including assemblies,
user controls, custom ASP.NET pages, XML configuration files, resource files,
images, list definitions, Web Parts, Features, and others. ECMAScript files and
Silverlight .xap files can also be deployed to the servers by using SharePoint
Solution Packages.
There are two kinds of solutions in SharePoint: farm solutions and sandboxed
solutions. The differences between them are discussed in this section and in Worker
Processes, Farm Solutions, and Sandboxed Solutions later in this article.
Note:
The terms "solution" and "feature" are familiar in software development. The first
thing to note about the SharePoint deployment model is that these terms are names
of formal components of SharePoint that are defined in this section. By convention,
"Feature" is capitalized when it refers to the SharePoint component of that name.
Throughout this article, I will follow the additional convention of italicizing "farm
solution," "sandboxed solution," and "solution" when the SharePoint component is
being referenced. When either "solution" or "feature" is lowercase and not italic, it is
being used in its ordinary sense.
Installation of a SharePoint solution package is a multi-step process:
1. Adding: A solution package file is added to one of two stores.
o Farm solutions are deployed by farm administrators to the farm's
solution store, which is in the farm's configuration database. This is
done by using either the SharePoint Management Shell or the object
model.
o Sandboxed solutions are deployed to a specific site collection's
Solution Gallery by a site collection administrator. The gallery is a
special SharePoint list, so it is in the content database. Solution
deployment to the gallery is done through the Site Actions UI of the
site collection or by using SharePoint Management Shell. For
information about the difference between site collections and websites,
see Middle Level Object Model later in this article.
Thus, SharePoint Solution Package files are never installed to the file system
of any server, although elements of a farm solution may be installed to the file
system when the solution is deployed.
2. Deploying: The solution package is unpacked and its elements are deployed
to their appropriate places.
o For a farm solution, this step also requires a farm administrator and
can be done by using either Central Administration or SharePoint
Management Shell, or the object model. Some examples of how
elements are deployed: user control files (.ascx) are copied to
%ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\TEMPLATE\ControlTemplates and assemblies are
deployed to the global assembly cache or to a web application's \bin
folder. If there are SharePoint Features (defined later) in the farm
solution, they are in this step copied to a subfolder of
%ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\TEMPLATE\FEATURES.
o For sandboxed solutions, the deployment step is taken by a site
collection administrator. There are limits on what kinds of elements can
be in sandboxed solutions and where they can be deployed. For
example, nothing can be deployed to the file system of the servers
from a sandboxed solution. Features in sandboxed solutions are
deployed to the content database.
It is also in this second step that any Features in the solution are installed in
the Feature Gallery of the farm, web application, site collection, or website,
depending on the scope of the Feature. (For more information about the
relations of farm, web applications, site collections, and websites to one
another, see Content Hierarchy later in this article.)
Within a SharePoint solution package, there can be an additional level of
encapsulation because a solution can have one or more SharePoint Features. A
Feature can be installed at the scope of the farm, the web application, the site
collection, or the website. After it is installed, a Feature must be activated by owners
of any website within the scope; so Activating becomes a third step of installation
for Features. Features can contain content types, controls, custom actions, custom
fields, files, workflows, list instances, list templates, event receivers, and document
converters; although some of these cannot be included in certain scopes. (Features
that are deployed in sandboxed solutions can be scoped only to a site collection or
website. For site collection-scoped features in sandboxed solutions, the second and
third steps are combined. The Features are activated when the solution is deployed.)
Note:
SharePoint is not consistent in its terminology with regard to installation. The terms
adding, deploying, and activating are the most frequently used to refer to the three
steps of installation; but depending on what tool is used to complete a step and
whether the solution is farm or sandboxed, you will see a variety of terminology. The
first step may be called adding, installing, or uploading. The second step may be
called deploying, activating or installing. There is a similar inconsistency in the terms
for reversing these steps; but most commonly, reversing the second step is called
retracting and reversing the first step is called removing. The third step, which
applies only to Features, is always called activating, and its reversal is always called
deactivating.
Some SharePoint solutions target one of the client object models, either exclusively
or in addition to targeting the server object model: the ECMAScript, Silverlight, and
Microsoft .NET Framework client object models. (For more information about the
client object models, see Client Object Models in SharePoint later in this article.)
There is nothing unusual about the installation of the client portion of such solutions.
The script files that define the ECMAScript object model are downloaded to a
client computer when a page that references them is opened.
Similarly, a Silverlight .xap executable is downloaded to the client computer
when a page that is hosting it is accessed. The SharePoint assemblies that
contain the Silverlight client object model are encased in the .xap file. Those
assemblies are Microsoft.SharePoint.Client.Silverlight.dll and
Microsoft.SharePoint.Client.Silverlight.Runtime.dll. (It is also possible to cache these
assemblies on the front-end web server. For details, see RIA Technologies:
Benefits, Tradeoffs, and Considerations.)
Stand-alone .NET Framework applications (such as a WPF application) that
target the SharePoint client object model are installed just as any other client
applications: using MSI files or ClickOnce. The assemblies that contain this
client object model, Microsoft.SharePoint.Client.dll and
Microsoft.SharePoint.Client.Runtime.dll, must be distributed as part of the solution.
The redistributable is located at SharePoint Foundation 2010 Client Object
Model Redistributable.
For more information about the processing of client-side logic in SharePoint, see
Client Application Models in SharePoint 2010.
For more information about the deployment system, see Building Block: Features,
Building Block: Solutions, and Packaging and Deployment.
Process and Execution Trust Model
In the simplest scenarios, the process model of SharePoint is the same as any other
ASP.NET application; but in SharePoint, the distinction between farm solutions and
sandboxed solutions entails some more complex scenarios.
Worker Processes, Farm Solutions, and Sandboxed Solutions
When an HTTP request is received by a front-end web server, a special driver,
HTTP.SYS, detects the request and routes it to the application pool that is handling
requests for the targeted IIS website, and thus, the targeted SharePoint web
application. Every application pool has an IIS worker process (w3wp.exe) in which
the request pipeline for each request is executed. (For more information about the
IIS 7.0 worker processes and application pools, see Introduction to IIS 7
Architecture.) On a SharePoint server, the IIS worker process runs in the application
pool account, which gives the process read and write permissions to SharePoint
resources. On a multiserver farm, the application pool account is a domain user that
is not a machine administrator on any server in the farm, but is a member of the
WSS_WPG, WSS_ADMIN_WPG, and IIS_USERS groups on each server. (This
should be a different account from the farm administration account. The latter is also
not a local machine administrator on any farm server. The farm account is a member
of all the same groups as the application pool account and also the
WSS_RESTRICTED_WPG_V4 and Performance Monitor User groups. An exception
is made for the application pool of the Central Administration web application: its
application pool account is the farm account. Also, the SharePoint 2010 Timer
Service executes in the context of the farm account.) For more information about the
accounts needed in a SharePoint farm, see Plan for administrative and service
accounts (Office SharePoint Server).
Figure 4 shows how an IIS worker process that is running on a front-end web server
processes an HTTP request.
Figure 4. Request processing model for full-trust farm solution
However, unlike a standard ASP.NET application, SharePoint makes a distinction
between sandboxed solutions and farm solutions. Farm solutions run in the IIS
worker process just like any ASP.NET application. Sandboxed solutions run in a
specially restricted execution environment. This is necessary because sandboxed
solutions are installed on (and scoped to) SharePoint site collections without the
intervention of the IT professionals that are managing the SharePoint farm. To
prevent rogue or poorly performing code from slowing or crashing the application
pool, SharePoint imposes restrictions on what the code in a sandboxed solution can
do. As a crucial part of the implementation of this system, sandboxed solutions must
run in a special sandboxed worker process (SPUCWorkerProcess.exe).
When a request attempts to access a sandboxed solution, a SharePoint execution
manager that runs in the IIS worker process finds a sandbox worker process (or
starts one, if none is running) in which the code of the sandboxed solution will run. In
principal, this sandboxed worker process can be started on any server in the farm
that is running the SharePoint 2010 User Code Host service
(SPUCHostService.exe). (In the UI of the Central Administration application, this is
known as the Microsoft SharePoint Foundation Sandboxed Code Service.)
The server that is running the SharePoint 2010 User Code Host service can be, but
does not have to be, the front-end web server on which the IIS worker process is
running. Which server is used is configurable in the Central Administration
application: Administrators can choose to have each sandboxed process run in "local
mode," which means that each request for a sandboxed solution is processed on the
same front-end web server on which the IIS worker process is running; or they can
have the execution manager start each sandboxed process in "remote mode," also
known as "affinity mode." In affinity mode, the execution manager looks for a server
that is running the SharePoint 2010 User Code Host service and which already has
created an application domain inside its SPUCWorkerProcess.exe process for the
very same sandboxed solution. (This would be the case if that same sandboxed
solution was requested before, possibly by another user on another site collection.) If
there is a matching application domain, the request is sent to that same application
domain for handling. If none of the servers that are running the SharePoint 2010
User Code Host service already has an application domain for the sandboxed
solution, the execution manager assigns the request to the least busy of those
servers. The server then creates the needed application domain and processes the
request for the sandboxed solution. The application domain stays alive after the
request is processed and is reused if there is another request for the same
sandboxed solution.
By default, all sandboxed solutions that are handled by a given server run in the
same sandbox worker process, but this is configurable through the object model.
Each sandboxed solution gets its own application domain within the common
process, and this, too, is configurable through the object model. The SharePoint
2010 User Code Host service runs in an account that has the same rights as a
typical application pool account. It should be a member of the WSS_WPG,
WSS_ADMIN_WPG, and IIS_USERS groups on the server on which the service
instance is running.
Code Execution and Access Constraints on Sandboxed Solutions
All code that runs in this sandbox worker process is subject to execution and access
constraints. There are two systems of constraints: One applies to all and only calls to
any assembly, except Microsoft.SharePoint.dll, whether it is a SharePoint assembly
or not. The other applies to all and only calls made to the parts of the SharePoint
Foundation object model that are in the assembly Microsoft.SharePoint.dll. The calls
that this second system applies to are not just calls in custom SharePoint solutions.
Calls to Microsoft.SharePoint.dll from other SharePoint assemblies (that have
themselves been called by custom code) such as Microsoft.SharePoint.Linq.dll are
also subject to this constraint.
The first system of is imposed by two mechanisms:
1. A highly restrictive code access security (CAS) policy significantly limits what
code in the sandboxed worker process can do. This policy is defined in the
wss_usercode.config file in %ProgramFiles%\Common Files\Microsoft
Shared\web server extensions\14\CONFIG, and it is referenced in the
web.config file in %ProgramFiles%\Common Files\Microsoft Shared\web
server extensions\14\UserCode. Among the restrictions imposed by the CAS
policy are the following:
o Code in the sandbox cannot call unmanaged code.
o Code in the sandbox cannot call the Microsoft .NET Framework 3.5
reflection APIs.
o Code in the sandbox can call only the .NET Framework 3.5 assemblies
that have the AllowPartiallyTrustedCallersAttribute attribute. This
blocks access to about two-thirds of all the .NET Framework 3.5 APIs,
including System.Printing, for example.
Note:
The CAS policy makes an exception for strong-named Microsoft Office
assemblies. These are granted full trust.
2. Secondly, the sandboxed worker process has a low-privileged security token.
o The token denies the process the right to read from or write to the file
system.
o The token denies the process the right to call to the network.
Therefore, only resources available on the server that is running the
sandboxed worker process may be accessed. An external database,
for example, cannot be accessed.
o The token denies the process the right to write to the registry.
o The token denies the right to call to any assembly that is not in the
general assembly cache, even if it has the
AllowPartiallyTrustedCallersAttribute attribute and would otherwise
be eligible to be called from the sandboxed worker process.
As noted, a second system of constraints imposes restrictions on what APIs in
Microsoft.SharePoint.dll can be directly called by code in the sandboxed worker
process, and a call to any forbidden API in the object model results in an exception
(which is caught and reported to the user as an error). The implementation of these
restrictions is accomplished by a pair of specially restricted versions of the
Microsoft.SharePoint.dll assembly, sometimes called shim assemblies, that are located
in %ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\UserCode\assemblies. One of the two assemblies is loaded by the
sandboxed worker process. The other assembly is loaded in a special proxy process
(SPUCWorkerProcessProxy.exe) that runs in full trust and that is also managed by the
SharePoint 2010 User Code Host. The standard Microsoft.SharePoint.dll assembly is
also loaded in this proxy process.
The main job of the two shim assemblies is to filter out forbidden SharePoint classes
and members. When the sandboxed solution calls an approved API, the first shim
assembly passes it to the second in the proxy process, which in turn passes it to the
standard Microsoft.SharePoint.dll. Any returned results are passed back to the original
calling code. This cross-process interaction is possible through .NET Framework
remoting. A sandboxed worker process and a full-trust proxy process are always
started together and paired with one another. If either process crashes, the other is
also stopped.
The shim assemblies also have a secondary job. Some SharePoint APIs are
available to sandboxed solutions, but only with special restrictions on the parameters
that are passed to them. It is the shim assemblies that enforce these input
restrictions and ensure that an exception is thrown when there is a violation. The
only case of this in SharePoint Foundation 2010 are the SPSite and SPSite
constructors. These constructors can be called in sandboxed solutions, but only
URLs or GUIDs that refer to the site collection in which the sandboxed solution is
running can be passed to them.
Note:
Because the second shim assembly and the standard Microsoft.SharePoint.dll run in a
full-trust process, permitted APIs in the SharePoint object model can do some things
that would otherwise be forbidden in a sandboxed solution. For example, the
GetLocalizedString method can read .resx files even though sandboxed solutions
cannot generally read from the disk. (However, a file cannot be deployed to disk in
sandboxed solution, so the .resx file would have to be previously installed as a farm
solution.)
The following are some of the restrictions on the SharePoint object model that can
be accessed:
The SPWebApplication class cannot be accessed. Among other things, this
means that a sandboxed solution cannot access anything outside its hosting
site collection.
Almost all classes in the Microsoft.SharePoint.WebControls namespace
cannot be accessed, which means that you are mainly restricted to ASP.NET
controls in sandboxed solutions.
For a complete list of APIs in Microsoft.SharePoint.dll that are available to
sandboxed solutions, see Microsoft.SharePoint.dll APIs Available from Sandboxed
Solutions.
Important:
The deployment stage of a sandboxed solution itself runs in a sandboxed worker
process and is subject to the same execution constraints. For example, you cannot
deploy a file to the disk when you are deploying a sandboxed solution. This is the
main reason why a user control (ASCX file) cannot be in a sandboxed solution. See
SharePoint Deployment Models for information about the deployment stage.
Resource Usage Restrictions on Sandboxed Solutions
Sandboxed solutions are also subject to three kinds of resource usage restrictions
that can be organized based on the kind of entity to which the restriction applies and
the kind of entity on which the penalty for exceeding the restriction is imposed.
Per Request with the Request Penalized: There is a hard limit to how long
a sandboxed solution can take to finish. By default, this is 30 seconds. If a
sandboxed solution exceeds the limit, the request (but not the sandboxed
worker process) is terminated. (This limit is configurable, but only through
custom code against the object model. The relevant parts of the object model
cannot be accessed by sandboxed solutions, so no sandboxed solution can
change the limit.)
Per Request with the Process Penalized: A set of 15 resource limits apply
to requests. If a request exceeds one of them, the process (and all the
sandboxed solutions that are running in it) is terminated.
Per Day/Per Site Collection with the Site Collection Penalized: Each site
collection is subject to a configurable maximum of daily resource points.
These points accumulate based on an algorithm that takes into account the
use of resources in the 15 resource categories by the sandboxed solutions
that are installed in the site collection. When a site collection exceeds its
maximum allowed points, all sandboxed solutions in the site collection are
terminated and no more can run for the rest of the day.
SharePoint provides a solution validator framework that can be used to develop
custom solution validators, such as a validator that verifies whether a solution is
signed with a specific certificate. The validators in a site collection run when a
sandboxed solution is activated (that is, deployed, in the terminology used earlier in
this article). The activation of any invalid solution is blocked. If a validator is updated
or a new validator is added, each activated solution is rechecked by the validators
the next time it is executed. Invalid solutions are deactivated. For an introduction to
custom validators, see Developing, Deploying, and Monitoring Sandboxed Solutions
in SharePoint 2010.
For more information about the sandbox restrictions, see Sandboxed Solutions and
its child topics and the Microsoft patterns and practices guidelines for Sandboxed
Solutions.
Figure 5 shows how an HTTP request is handled when it accesses a sandboxed
solution.
Figure 5. Request processing model for sandboxed solutions
The SPUCHostService.exe, SPUCWorkerProcess.exe, and
SPUCWorkerProcessProxy.exe files are located at %ProgramFiles%\Common
Files\Microsoft Shared\web server extensions\14\UserCode.
Note:
A solution that is designed to run in the sandbox can be deployed by a farm
administrator as a farm solution. It might perform better if it is, because it would run
in the IIS worker process instead of the sandboxed worker process.
Not all SharePoint execution is in an IIS worker process, a sandboxed worker
process, or the proxy process. The following are some examples:
The SharePoint Timer Service (owstimer.exe) runs on all servers and is used
to execute prescheduled timer jobs. It runs under the farm account.
The SharePoint Tracing Service (wsstracing.exe) runs under the local service
account.
The SharePoint Administration Service (wssadmin.exe) runs under the local
system account.
Within the category of farm solutions, a further distinction can be made when the
requested resource is an .aspx page. If the requested page is what SharePoint calls
an application page, the returned page is passed to the regular ASP.NET page
parser; but if the requested page is what SharePoint calls a site page, the returned
page is routed through a special safe mode parser. The distinction between the two
kinds of parsing is best understood in light of the distinction between the two kinds of
pages. For more information about both subjects, see Pages, Parsing, and Safe
Mode later in this article. (Application pages cannot be included in sandboxed
solutions. All pages installed as part of a sandboxed solution use safe mode
parsing.)
Assembly Deployment, Execution, and Persistence
Farm solutions divide into two types depending on where their assemblies are
deployed and the trust level of the assemblies' execution:
GAC/Full Trust: The assemblies are deployed to the global assembly cache
(GAC) of every front-end web server in the farm and run with full trust. They
are callable from any SharePoint web application on the farm.
Bin/CAS: The assemblies are deployed to the \bin folder (on every front-end
web server) of a specific SharePoint web application and their trust level is
determined by a CAS policy referenced in the web application's web.config
file. They have to be separately deployed to every SharePoint web application
that needs to call them.
Tip:
We recommend that you use the Bin/CAS model only when neither full-trust
farm solutions nor sandboxed solutions (nor the hybrid solutions described in
Hybrid Solution Techniques) are possible for your solution.
Noncompiled files for both kinds of farm solutions—including, for example, images,
user controls, and string resources—are deployed to subfolders of
%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\.
Sandboxed solutions are deployed inside a SharePoint solution package (.wsp file)
to the Solution Gallery of a specific site collection. Thus, they are deployed and
persisted in the site collection's content database. As noted earlier, they do not run in
full trust: Instead, they run within a highly restricted CAS policy and can only call a
restricted subset of the SharePoint object model. A sandboxed solution can be
accessed only in site collections to which it is deployed.
When a sandboxed solution is accessed for the first time, such as when a user
navigates to a page that contains a Web Part from a sandboxed solution, any
assemblies in the solution are unpacked from the solution package and copied to the
file system of the server that is handling the sandbox request. The default location is
C:\ProgramData\Microsoft\SharePoint\UCCache, but this is configurable on each server that
is running the User Code Host Service. (Recall that the server that handles the
sandbox request is not necessarily the front-end web server that is handling the
initial HTTP request. The User Code Host Service can be run on back-end
application servers in the farm instead.) Because the sandboxed worker process
cannot copy anything to the file system, the copying is done by the User Code Host
Service.
The assemblies do not stay in the file cache perpetually. When the user session that
accessed the assemblies finishes, the assemblies stay in the cache for only a short
time, and they may be reloaded from there if another user session accesses them.
Eventually, if they are not accessed, they are removed according to a proprietary
algorithm that takes into account how busy the server is and how much time has
gone by since the assemblies were last accessed. If the sandboxed solution is used
after that time, the assemblies are unpacked again and copied to the UCCache.
Caution:
Administrators, developers, and third-party code should not add, remove, or load
anything from the UCCache. It should be accessed only by the SharePoint
infrastructure.
Hybrid Solution Techniques
The SharePoint solutions architecture includes a technique by which a sandboxed
solution can call custom operations that run in full trust. The technique requires that
a farm solution be developed that includes one or more classes that derive from
SPProxyOperation. Each of these defines an operation that will run in full trust and
can be called from sandboxed solutions by using the
ExecuteRegisteredProxyOperation method. Specifically, these full-trust proxy
operations execute in the same proxy process (SPUCWorkerProcessProxy.exe) that
was described earlier in Worker Processes, Farm Solutions, and Sandboxed
Solutions. The proxy operations can return data to the sandboxed solution.
Like all farm solutions, the assembly with the proxy operations can be deployed only
if it is from a trusted source.
Figure 6 shows how a request that accesses a sandboxed solution is processed
when the sandboxed solution makes a call to a full-trust proxy.
Figure 6. Request processing model when a sandboxed solutions calls a full-
trust proxy
The preceding description might give the impression that, with the hybrid technique,
a farm solution and a sandboxed solution are always developed together by the
same development team. In fact, the farm solution may be developed specifically to
provide certain operations to any and all sandboxed solutions that need those
services, including sandboxed solutions that are developed by other teams. For
example, because a sandboxed solution cannot write to the SharePoint Unified
Logging Service (ULS) logs, a farm solution that opened proxy logging operations to
sandboxed solutions would be very useful.
Another hybrid technique uses client-side code to access the resources that cannot
be accessed from a sandboxed solution. For example, a sandboxed solution could
include a custom site page with JavaScript that makes calls to the SharePoint
ECMAScript client object model. Also, a sandboxed solution could include a Web
Part that hosts a Silverlight application. The latter application can make calls to the
SharePoint Silverlight client object model. For more information about the client-side
code in SharePoint, see Client Object Models in SharePoint later in this article.
For more information about hybrid solution techniques, see Hybrid Approaches.
Pages, Parsing, and Safe Mode
As noted earlier in SharePoint as an ASP.NET-IIS Application, SharePoint makes
extensive use of the master page/content page distinction. But SharePoint
Foundation also divides its ASPX pages along a different axis: It distinguishes
between application pages and site pages. Both of these kinds of pages can be
mergers of master and content pages and, indeed, every ASCX page that is built into
SharePoint, whether it is an application page or a site page, is a combination of a
master and content page. Hereafter, in this section, there is no further mention of the
master/content page distinction.
Application pages differ from site pages in the following ways:
Typical purpose: Application pages tend to be function-oriented, especially
functionality that is needed by many kinds of websites within a given web
application; for example, the standard form for creating a new list item is an
application page. Site pages tend to be content-oriented; for example, the list-
of-lists page of a standard team site. However, exceptions to both tendencies
are possible. Indeed, we currently recommend that third-party developers
develop custom Web Parts, which can be added to site pages, to handle their
solution's functionality whenever possible, rather than develop custom
application pages.
Customizablility: Site owners (and other users who have appropriate
permissions) can customize site pages, but not application pages. Users can
also add an entirely new ASCX page to a website's Site Pages gallery, but
only web application administrators can install a new application page.
Class inheritance: Application pages are objects of the LayoutsPageBase
class or the UnsecuredLayoutsPageBase class. Site pages are objects of the
WikiEditPage class or the WebPartPage class. (All of these classes derive
from the ASP.NET Page class.)
Web Part support: Application pages cannot have Web Part zones or
dynamic Web Parts. They can have static Web Parts, but there is little point to
using a static Web Part instead of an ordinary control on an application page
because end users cannot customize application pages anyway. Some kinds
of site pages can have static Web Parts, and other kinds can have Web Part
zones with dynamic Web Parts. See later in this section for more information.
Storage location: Application pages are stored on the file system of the front-
end web servers in the _layouts virtual directory of a web application (which
maps to the %ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\TEMPLATE\LAYOUTS physical directory) or one of its
subdirectories. A site page that has not been customized is stored in other
subdirectories of %ProgramFiles%\Common Files\Microsoft Shared\web
server extensions\14\TEMPLATE, most typically in
%ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\TEMPLATE\SiteTemplates and %ProgramFiles%\Common
Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES. A
site page that has been customized, such as with Microsoft SharePoint
Designer, is stored in the content database of the website for which it was
customized. New site pages that have been added to the Site Pages gallery
are stored just as customized pages.
Note:
Even an uncustomized site page has an entry in the content database; but
whereas the entry of a customized page contains the ASPX markup that
constitutes the page, the entry for an uncustomized page contains the path of
the .aspx file on the local front-end web server. An uncustomized page can be
shared by many websites. If it is, it is referenced in each website's content
database, with all the entries pointing to the same physical file. For example,
every Team Site has a content database entry pointing to the default Team
Site home page. If the home page is customized on any of the sites, it is
copied into the page's entry in the content database in its customized form,
and the pointer to the uncustomized version is removed.
Sometimes the uncustomized site page is referred to as a page template and
the pages in the content database as page instances. However, remember
that if the page is not customized in a particular website, the "instance" of the
page is simply the database entry pointing back to the file on the file system.
Availability: An application page can be accessed from every website in the
web application and is therefore shared among all the websites. But a site
page is available only to a user of the website where it is deployed.
(Uncustomized site pages are shared by multiple websites, as noted earlier,
but only websites where they have been specifically provisioned either as part
of a Feature or as part of a site definition.)
Parsing mode: Application pages are parsed in direct mode, which just
means that they are parsed by the standard ASP.NET page parser. The first
time an application page is requested, it is parsed and compiled and cached
in the front-end web server's memory, where it remains until the application
domain or the entire IIS host is recycled. With every subsequent request for
the page, it is served from the cache, if it is there. Uncustomized site pages
are also parsed in direct mode, but customized site pages, and new pages
that are added to the Site Pages gallery, are parsed in safe mode. Safe mode
processing differs from direct mode (that is, from standard ASP.NET page
processing) in the following ways:
o Only controls (including Web Parts) that are registered as safe in the
web application's web.config file are rendered.
o Inline server-side code is not allowed in safe mode, and an error page
is returned to the user if the safe mode parser finds inline code on the
requested site page. Inline code includes <script> elements, such as
<script runat="server"> [code is here] </script>, and control event handlers,
such as <asp:button OnClick="MyButtonHandler()" />. (Code behind that is
compiled into a separate assembly is allowed, and so is embedded
ECMAScript.)
o The page is not compiled. (And, thus, any compilation directives in the
file are ignored.)
Note:
The terms safe mode parsing, safe mode processing, and safe mode
rendering are used interchangeably in SharePoint documentation.
Security and performance are the motivations for the two kinds of pages, especially
the difference in processing mode. One of the purposes of SharePoint is to delegate
administrative control to ordinary business users instead of requiring the intervention
of network administrators and IT professionals. For this reason, users are allowed to
add new pages and customize existing pages. If these users were allowed to add
any control or Web Part they wanted or add any code blocks they wanted to the
pages, there is a great danger that poor performing or malicious code would be
added to a page. The reason that pages that use safe mode are not compiled is that
there may be thousands of pages on a SharePoint installation. If every one of them
was compiled into an assembly and loaded in memory, the performance of the
server would be degraded, and only recycling the application domain would remove
them. Moreover, recycling the application domain would remove all assemblies, not
just the seldom-used pages. There is also a limit on the number of assemblies that
can be loaded in an application domain that is imposed by the .NET Framework.
The safe mode parser only creates a control tree for the page, which can be
unloaded again from memory immediately after use. On the other hand, pages that
are shared, such as application pages and uncustomized site pages should be
compiled on first use, because these pages are used a lot and subsequent requests
for them can be handled much faster if the pages are cached as assemblies in the
server memory. That is why they run in direct mode.
Security Note:
It is possible to allow inline code, unsafe controls, or both, on selected customized
site pages. You can do both things by adding one or more <PageParserPath>
elements to the <SafeMode> element of the <SharePoint> section of the web
application's web.config file. You can use the attributes of the <PageParserPath>
element to specify a customized site page or set of customized site pages, and to
enable inline code and unsafe controls for the designated site pages. However, you
should use extreme caution when you make these kinds of changes, because they
cancel the security benefits of safe mode. For example, if you allow inline code for all
pages that have names on the pattern Contoso*.aspx in the directory
/sites/contoso/SitePages, anyone with the right to add pages can create a page that has
a name following that pattern and add it to that directory, including a page that
contains malicious or poor-performing code. (The directory path is a "virtual path"
that points to a set of files in the content database.) Notice that allowing unsafe
controls only enables such controls that are added in an editing tool, such as
SharePoint Designer. When an end user adds a Web Part to a page in the browser,
the Web Part must still be registered as safe even if unsafe controls have been
enabled in a <PageParserPath> element.
You can turn on compilation for selected customized site pages by using an attribute
of the <PageParserPath> element. This might be useful if you have reason to
believe that the customized page will be visited often enough to justify compiling it
into a DLL cached in memory.
Within the category of site pages, there are additional distinctions. In SharePoint
Foundation, there are standard site pages and Web Part site pages. Standard site
pages are wiki-enabled pages that allow inline Web Parts. Standard pages are
objects of a class that derives from WikiEditPage. Web Parts pages, on the other
hand, derive from WebPartPage. They have one or more Web Part zones into which
Web Parts can be added, and they have no wiki-editable area.
SharePoint Server 2010 adds a third kind of site page: PublishingPage. (There is
also a PageLayout class in SharePoint Server 2010, but this is an extension of the
master page/content page system of ASP.NET, not another kind of site page.)
SharePoint also has a set of built-in pages that are designed for mobile devices.
They do not use the ASP.NET master page/content page technology, and they are
not divided into application pages and site pages. SharePoint mobile pages are all
application pages, and they are located in the \_layouts\Mobile folder. There is one
respect in which a SharePoint mobile page is more like a customized site page: If the
page contains a mobile Web Part adapter, the adapter must be registered as a safe
control or it is not rendered.
For more information about page types in SharePoint, see Building Block: Pages and
User Interface, ASP.NET vs. SharePoint: Page Development, SharePoint Page
Types, and Publishing Programming Model. For more information about mobile
pages, see Building Block: Mobile Pages, Controls, and Adapters and Overview of
Mobile Pages and the Redirection System. For more information about safe controls
and safe mode, see Microsoft SharePoint Foundation as an ASP.NET Application.
Data Model, Data Management, and
Query System
The primary data structure in SharePoint Foundation is the list. Every list belongs to
a list type. Similarly, every column in a list has a field type, and every list item has a
content type. External data—that is, data from outside the SharePoint content
databases—can also be shown and managed in SharePoint.
Lists
Data in SharePoint Foundation is primarily stored as tables much as it is in a
relational database, except that the tables are called "lists" in SharePoint lingo.
Indeed, the back-end storage of content data for a SharePoint Foundation web
application is in one or more SQL Server databases. These are called content
databases. (There is also a special configuration database on the computer that is
running SQL Server that holds farm configuration data, and a special BDC database
that supports Microsoft Business Connectivity Services (BCS). For more information
about BCS, see External Lists and the Business Connectivity Service later in this
article.) However, there are some differences between relational database tables
and SharePoint Foundation lists:
Data is not queried by SQL. Instead, data is queried in server-side code either
by LINQ or by queries formulated in CAML. For more information about
server-side data querying, see Building Block: Queries and Views and the
topic Querying from Server-side Code, along with its child topics. You can
programmatically write data to the lists using either the server object model or
the LINQ to SharePoint provider. For more information, see Managing Data
with LINQ to SharePoint. From client-side code, data is queried by using
either the client object model or WCF Data Services (formerly ADO.NET Data
Services). For more information about client-side data querying, see Querying
from Client-side Code.
Caution:
Directly accessing the back-end computer that is running SQL Server by
using SQL queries, stored procedures, or any other method is not supported.
A list can have a column whose possible values are the values of a column on
a different list. The lookup column relationship between the lists is somewhat
like a foreign key relationship between two relational tables. However, the
field on the target list that provides the values is not necessarily the foreign
key. All SharePoint Foundation lists have an ID column. This column is, in
effect, always the foreign key in any lookup relationship. For more information
about lookup relationships in SharePoint Foundation, see Lookups and List
Relationships and List Relationships in SharePoint 2010.
Lists can be joined just as tables can, but with some restrictions. There must
be a lookup relation between the lists or they cannot be joined. For more
information about list joins, see List Joins and Projections.
A SharePoint Foundation document library is a special kind of list in which
each row includes an attached document, and the other columns are data
about the document, such as its author, when it was last edited, and who has
it checked out. Picture libraries are similar except that the attached file is an
image file. For more information, see Building Block: Lists and Document
Libraries.
Every list has a list type, and SharePoint Foundation includes many built-in list types
that enable end-users to create the most common kinds of business and team
solutions. Among these are Announcements, Tasks, and Calendar. Developers can
also create custom list types. For more information about list development, see
SharePoint List Data Model.
Content Types and Field Types
A row in a list—that is, a list item—also has a type. These are called content types.
Each is basically a set of columns and metadata. The simplest is the built-in Item
content type. All other content types are derived from Item. SharePoint Foundation
includes many built-in content types, such as Event and Announcement. Developers
can create custom content types. For more information about content types, see
Building Block: Content Types, Content Types, and SharePoint Columns, Lists, and
Content Types.
A column in a list, also known as a "field," also has a type, and it is distinct from the
data type of the values that can be stored in the field. A SharePoint Foundation field
type includes not only information about the underlying data type, but also
information about how the data is formatted and rendered on forms, such as the
forms for creating, displaying, and editing specific list items. For example, it is the
field type that determines whether a field value is entered as string or from a drop-
down list of values. Many field types are built-in to SharePoint Foundation, such as
the Modified By field on a document library and the Due Date field on a Task list.
Developers can create custom field types. For more information, see Building Block:
Columns and Field Types, Custom Field Types, and SharePoint Columns, Lists, and
Content Types.
External Lists and the Business Connectivity Service
External data, such as data in an SAP installation or Oracle database, can also be
represented as a list on a SharePoint Foundation page and within SharePoint
Workspace and Microsoft Office client applications. The Microsoft Business
Connectivity Services (BCS) of SharePoint Foundation enables read/write access to
this data.
The critical components of BCS are Business Data Connectivity (BDC) service
models. Each model is an XML file that describes a type of external data source,
such as SAP services. One or more specific instances of the data source, such as a
particular SAP database, are defined in the model, including connection and security
information about the data source. The business entities in the data source, such as
Customer or Order, are represented in the model by external content types, and the
model also defines relationships between these entities. Finally, the model defines,
for each entity, a set of standard operations, called stereotyped operations, that can
be performed on the entity, including create, retrieve, update, and delete operations.
For more information about the structure of BDC models, see BDC Model
Infrastructure. The models are stored in a dedicated database on the SharePoint
farm computer that is running SQL Server, which is distinct from the configuration
database and the content databases. This database is called the metadata store.
After a model is added to the metadata store, users can access the external data in
a variety of ways. For example, in SharePoint Foundation, users can create a
SharePoint list out of an external content type, such as Customer, or add a column
of data from the external source to an existing list. SharePoint Server 2010 has
some BCS enhancements: It includes some built-in Web Parts for working with
external data, and it enables users to search the external data. Also, SharePoint
Workspace and Microsoft Office client applications can access and display the
external data directly. Finally, with SharePoint Server 2010, users can index and
search the external data sources.
A service named Business Data Connectivity service manages the interactions
between SharePoint and the external data source. The service runs on an
application server in the farm. There is also a BDC Runtime that runs on all front-end
web servers. When a SharePoint client application requests external data, the BDC
Runtime on the front-end web server requests the metadata that defines the BDC
model from a locally cached copy of the BDC metadata store. The runtime then uses
the metadata provided to perform data operations directly on the external system.
Similarly, on client computers that are running SharePoint Workspace and Microsoft
Office client applications, a BDC Client Runtime enables direct client access to the
external data by using the BDC model, which is also cached on the client computer
(although the SharePoint Server 2010 farm is still needed for long-term persistence
of the BDC models). The external data itself can be cached on the client computer to
enable an offline experience.
After the BDC service is running and the needed BDC models are registered, end
users can create non-code solutions that involve external data. For more complex
solutions, the BCS Runtime APIs enable developers to make custom Web Parts or
other solutions to interact with the external data. Because a BDC model provides a
kind of translation between operations in code and the stereotyped operations of the
external data source, the same APIs can be used for all external data sources no
matter how different their individual access systems are. BDC solutions are
packaged and deployed as farm solutions.
Figure 7 shows some of the major components of BCS and their relationships.
Figure 7. BCS runtime and deployment components
The BDC service is built in conformance with the Service Application Framework of
SharePoint Foundation. See also Services and the Service Application Framework
and Services Hierarchy later in this article.
For more information about BCS architecture, see BDC Architecture, Mechanics of
Using Business Connectivity Services, Business Data Connectivity (BDC) Service,
and External Data in SharePoint 2010.
Services and the Service Application
Framework
Services on a SharePoint farm can be usefully divided into four groups:
Windows Services
Web Services
IIS Web Services
Configuration Services
For details and examples of each of these four kinds of services, see Background:
Service Entities in Microsoft SharePoint Foundation.
Services in the latter two categories can be created to conform to the Service
Application Framework. Many of the services built-in to SharePoint Foundation and
SharePoint Server implement the framework. Moreover, the framework lets
developers build scalable middle-tier shared services that are hosted in SharePoint
Foundation.
A service that conforms to the framework can be split into multiple configured farm-
scoped instantiations (CFSIs). Each of these provides the functionality of the service,
but each has its own individual permission and provisioning settings. A CFSI is not
an actual running process on a particular server. The same CFSI can be running on
multiple servers, but it is not the same as the entirely abstract service itself either.
Each of the servers on which the CFSI runs has its own actual instance (a running
process) of the CFSI. Moreover, more than one CFSI of a given service can be
running on the same server or servers. Thus, the framework provides a means for
different versions of the same basic service to be available simultaneously. A
consuming application on a front-end web server can target a specific CFSI.
Figure 8 shows the services and service instances on a hypothetical 10-server farm.
This figure is repeated, with a more detailed explanation of its contents, in
Background: Service Entities in Microsoft SharePoint Foundation. For this article,
note only that the light translucent rectangles represent services, the darker
translucent rectangles represent CFSIs (also known as service applications), and the
smaller solid rectangles represent instances of services. The CFSIs are present only
for the services that implement the Service Application Framework, which in this
example are the Usage Service, the Application Discovery and Load Balancer
Service, the Security Token Service, and the BDC Service.
Figure 8. Services and service instances on a typical 10-server farm
Applications that need to consume a particular CFSI of a service do so through
proxies. The front-end web server that hosts the application has a proxy to represent
the service itself and a second proxy to represent the CFSI that is being targeted.
The proxies are not depicted in Figure 8, but Figure 9 shows a single-server
SharePoint Foundation farm immediately after installation. Note also the following:
Web services that implement the Service Application Framework are
represented with a dot-bordered box. At initial installation, each has a single
CFSI, sometimes called a "service application".
The service proxies belong to the farm, but each CFSI proxy (also known as a
service application proxy) belongs to a web application. The content
publishing web application and the Central Administration web application
each have their own proxy for the Business Data Catalog CFSI, and they
each have their own for the Usage and Health Data CFSI. Neither has a proxy
for the Subscription or Application Discovery and Load Balancer CFSIs at
initial installation.
Figure 9. Services, CFSIs, service instances, and web applications in a
newsingle server deployment
For more information about services in SharePoint and the Service Application
Framework architecture, see Background: Service Entities in Microsoft SharePoint
Foundation, Service Application Framework Architecture, and SharePoint Service
Application Topologies.
Site Definitions and Web Templates
What makes it possible for ordinary business users to create their SharePoint
websites without the intervention of IT professionals is the fact that types of websites
in SharePoint are given detailed, stored definitions. Using the SharePoint UI, users
can then instantiate a particular website from any of the defined types. There are
actually two kinds of definitions of site types: site definition configurations and web
templates. A site definition is stored on the file system of the front-end web servers,
in a subfolder of %ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\TEMPLATE\SiteTemplates, as a set of XML configuration files and
possibly also page files and other supporting files. A web template is stored in a
SharePoint Solution Package (.wsp file) in the content database, specifically in the
Solution Gallery of a site collection. Either kind of type definition specifies such
things as a default home page, various aspects of the default look-and-feel and
layout of the site's pages, the types of lists available in sites of the specified type,
and other configuration details of the site type.
For more information, see Building Block: Web Sites and Site Collections and the
Site Types: WebTemplates and Site Definitions node of the SharePoint Foundation
SDK.
SharePoint Security
The SharePoint security system protects deployments from both errant users and
errant code.
User Security
SharePoint Foundation supports security for user access at the website, list, folder,
and item levels. Security management is role-based at all levels. The authorization
process assumes that the user has already been authenticated, which refers to the
process by which the current user is identified. SharePoint Foundation does not
implement its own system for authentication or identity management, but instead
relies solely on external systems, whether Windows authentication or non-Windows
authentication.
Authentication
SharePoint supports several forms of authentication. The default is Windows claims-
based authentication. The claims-based identity model for SharePoint is built upon
Windows Identity Foundation (WIF). Under this model, the user presents an identity
to your SharePoint farm as a set of claims. One claim could be the user's name,
another might be an email address. An external identity system is configured to give
SharePoint all the information that it needs about the user with each request, along
with cryptographic assurance that the identity data comes from a trusted source.
Other types of supported authentication include Windows classic authentication and
ASP.NET forms-based authentication. For more information about authentication
and SharePoint, see the Getting Started with Security and Claims-Based Identity
Model and SharePoint Claims-Based Identity nodes of the SharePoint Foundation
SDK.
Authorization
Access to websites, lists, folders, and list items is controlled through a role-based
membership system by which users, and groups of users, are assigned to roles that
authorize their access to SharePoint objects. By default, permissions are inherited in
the sense that a user who has certain permissions for an object, such as a list, will
have the same permissions for its child objects, such as folders and list items.
However, it is possible to break inheritance and assign to users and groups a
different set of permissions to a child object. A role definition is a set of rights, such
as rights to read, create, or delete. A role assignment associates a user or group
with a role definition.
SharePoint supports two kinds of groups: domain groups and SharePoint groups.
Domain groups remain outside SharePoint control; users cannot use SharePoint to
define, browse, or modify domain group membership. SharePoint groups are scoped
to the site-collection level, and they can be used only within the site collection.
Domain groups can be used anywhere within the scope of the Active Directory
service.
For more information, see Authorization, Users, and Groups.
Code Security
Much of the code security story for SharePoint was already described in earlier
sections. In this section, different parts of the story are very briefly pulled together,
and some gaps in the story are filled.
Every web application runs in an IIS application pool that processes HTTP requests.
The pool itself runs in a user account known as the application pool identity. In a
multiserver farm, this is usually a domain user. The application pool identity is the
user identity for code that runs in an IIS worker process. However, access to various
SharePoint objects is determined by the permissions of the user who has made the
request that is being processed. The isolation of web applications into separate
application pools ensures that if one of them crashes, the others are not affected.
The IIS worker process calls assemblies that may operate under their own additional
restrictions. If the assembly is loaded out of the global assembly cache, it operates in
full trust. However, if the assembly is loaded out of the web application's \bin
directory, it is subject to the trust limitations that are defined by a CAS policy.
If the request is for a sandboxed solution, the SharePoint execution manager that
runs in the IIS worker process spawns a sandboxed worker process. The latter
process runs within a highly restrictive CAS policy, is limited to a subset of the
SharePoint server object model, and can only access resources within the site
collection to which the solution was deployed.
If the request is for a customized site page, all Web Parts on the page must be
registered as safe controls and, by default, the page is not returned at all if it
contains inline code blocks.
Server Object Model in SharePoint
The server object model in SharePoint is large, and only some of the truly critical
classes can be described in this article. These classes can be usefully divided into
three hierarchies: the Physical Objects Hierarchy, the Content Hierarchy, and the
Services Hierarchy. Each is described briefly in the following subsections with links
to more extended discussions. For a synoptic overview of the major classes from all
three hierarchies, see Server and Site Architecture: Object Model Overview.
Physical Objects Hierarchy
The Physical Objects Hierarchy includes classes that represent physical entities,
such as servers and farms—the two most important.
A SharePoint Foundation farm, and its configuration database, is represented by the
SPFarm class. A server farm consists of one or more physical servers. These may
include one or more front-end web servers, zero or more application servers, and a
computer running SQL Server that may be hosted on a dedicated database server or
on one of the other servers in the farm. (If it is a dedicated server, SharePoint is not
actually installed on it, although it is still seen as a member of the farm in the farm
management UI of the Central Administration application.) A farm may consist of just
a single server. If the farm has multiple front-end web servers, they are usually load-
balanced. You can use any hardware or software load-balancing solution, including
the built-in NLB (Network Load Balancing) in Windows Server 2008. SharePoint
does not itself supply the load-balancing.
SPFarm inherits from SPPersistedObject, which means that the object (there is only
one) that instantiates the class persists in the configuration database. The three
most important child classes of SPFarm are SPServer, SPService, and SPSolution.
A physical server in a SharePoint Foundation farm is represented by the SPServer
class. In addition to many inherited members, it has an Address property that holds
the IP address of the server and a Role property that identifies the server's role in the
farm. It also has a ServerInstances property that holds references to all the instances
of Windows services and web services that are running on the server. SPServer
also inherits from SPPersistedObject, so server objects are persisted in the
configuration database.
For more information about the Physical Objects Hierarchy in the object model, see
The Physical Objects Hierarchy of Microsoft SharePoint Foundation and
Background: Physical Objects in Microsoft SharePoint Foundation.
Content Hierarchy
The Content Hierarchy includes classes that represent publishable items of data,
such as list items. There are also classes that represent nested containers of data,
such as lists, content databases, websites, site collections, and web applications.
High Level Object Model
Beneath the farm, the broadest content container is the web application, which is
represented by the SPWebApplication class. An SPWebApplication object
represents a content-publishing web application in SharePoint Foundation. It
contains one or more content databases, which hold the data of one or more site
collections. Each such web application is served by at least one (and usually only
one) IIS website and typically has its own application pool in IIS. Also, each web
application has its own security and authentication settings. The SharePoint
Foundation object model provides some hooks into the web application's other life as
an IIS object through the IisSettings and ApplicationPool properties. For more
information about the relation between SharePoint web applications and IIS, see
SharePoint as an ASP.NET-IIS Application earlier in this article.
The SPWebApplication class has a ContentDatabases property that holds all its
child content database objects.
Every web application contains one or more content databases. Each of these is
represented by the SPContentDatabase class. A content database is a SQL Server
database that contains all the data (lists, list items, blog posts and comments, wiki
pages, and documents in document libraries) and the customized page files that
constitute the site collections that belong to the database. Objects that represent
each child site collection are in the Sites property.
Both SPWebApplication and SPContentDatabase inherit from
SPPersistedObject, so these objects persist in the farm's configuration database.
For more detailed discussions of web applications, content databases, and their
classes, see The Content Hierarchy of Microsoft SharePoint Foundation and
Background: Content Entities in Microsoft SharePoint Foundation.
Middle Level Object Model
At the middle level of the content hierarchy are site collections and their subsites. An
SPWeb object represents a single website. An SPSite object represents a collection
of websites within a SharePoint web application that are grouped together for mainly
administrative reasons. (The SPSite class is not a collection in the sense of a class
that implements ICollection.)
The SPSite class has a RootWeb property that holds its child top-level website.
(Top-level websites were called "root webs" in the first version of SharePoint
Foundation, Microsoft SharePoint Team Services.) In turn, the SPWeb object that
represents the top-level website has a Webs property that holds all its immediate
child subsites (but not the subsites of those subsites). (The AllWebs property returns
all the descendent sites and the top-level website.)
Among the SharePoint elements that can be scoped to the site collection level are
master pages, Web Parts, themes, lists, content types, and Features. A site
collection can also be a unit of backup and restoration. It is also the level at which
groups of users are created and assigned default permissions. Site collections are
the largest possible scope for a search in SharePoint Foundation, although broader
search scopes are possible in SharePoint Server 2010.
The content of a site collection is always included within a single content database.
Websites can be children of other websites, and all websites belong to a site
collection. The SPWeb class has dozens of properties and methods for
programmatic handling of every aspect of the website, including users, lists, fields,
content types, Features, alerts, and much more.
For much more information about site collections and websites, see Building Block:
Web Sites and Site Collections, The Content Hierarchy of Microsoft SharePoint
Foundation, and Background: Content Entities in Microsoft SharePoint Foundation.
Tip:
Both SPWeb and SPSite evolved from early versions of what is now called
"SharePoint" before there was a .NET Framework. Even today they wrap some COM
objects. The .NET Framework garbage collector does not know how to release these
COM resources. Accordingly, both classes implement the IDisposable interface. If
they are not disposed of, website and site collection objects cause memory leaks on
the farm servers. It is essential that SharePoint developers call the Dispose method
of every SPWeb and SPSite that their code creates. There are some subtleties
about disposing of such objects. For example, website and site collection objects
that are obtained from the SPContext object should not be disposed of. Developers
should carefully study Disposing Objects.
Low Level Object Model
At the heart of SharePoint are lists and list items, which are represented,
respectively, by the SPList and SPListItem classes. The SPList class has members
for programmatically adding, deleting, and retrieving list items, and also for
managing metadata about the list such, as its content types and fields. The
SPListItem class has members for managing the item's fields, the values of its
fields, its content type, and any associated workflows. Lists can have folders that
give them a hierarchical structure. Folders are represented by the SPFolder class.
Note that, although any given list item has a specific content type, the object model
provides only the SPListItem class to represent all list items. Hence, working with
list items and their fields is, in many ways, like working in a weakly typed
environment. SharePoint includes a tool, SPMetal, that can generate code for an
object relational mapping. The generated code defines classes for each content type
in a website and, for each field in the content type, it declares a strongly typed
property. The tool makes it possible for LINQ queries to be strongly typed. For
example, if a developer mistakenly refers to the DueDate field of the Task content
type as "DateDue", the compiler catches the mistake if SPMetal is used and the
reference is to a property of a Task type object, myTask.DateDue. However, without
SPMetal, the reference would have to be to a member of the fields collection of an
SPListItem object, myItem["DateDue"]. The mistake would not be caught until run time.
Each field (column) on a list item is represented by an SPField object.
For more information about lists, list items, folders, and fields, see Building Block:
Lists and Document Libraries, Building Block: Columns and Field Types, and
SharePoint List Data Model.
Services Hierarchy
The Services Hierarchy includes classes that represent web services, Windows
services, other types of services, instances of services, and CFSIs of services (see
Services and the Service Application Framework earlier in this article).
A SharePoint Foundation service is represented by a class that inherits from
SPService. The class provides members that get information about the jobs the
service is performing. If a service implements the Service Application Framework,
the SPService object has an Applications property that holds all the CFSIs of the
service that are running on the farm. A CFSI of a service is represented by an object
of a class that inherits from the SPServiceApplication class.
Every SPService object has an Instances property that holds all the instances of the
service that are running on various servers in the farm. The instances that host a
particular CFSI are held in the ServiceInstances property of the
SPServiceApplication object that represents the CFSI. No more than one instance
of each CFSI runs on any one server. However, a given service can have multiple
CFSIs, and they can run on the same servers. Moreover, a given CFSI (and, thus, a
given service) can run on multiple servers, in which case each server has its own
actual instance (a running process) of the CFSI. If the service has no CFSIs, it still
has instances on each server on which it runs, but there can be no more than one
instance of such a service on a given server. Each instance is represented by an
object of a class derived from SPServiceInstance.
Applications that consume services that conform to the framework are represented
by proxies. Here, also, there is a proxy object for the service as a whole and a proxy
for the particular CFSI that is being consumed. The consumer proxy for a service is
represented by an SPServiceProxy object and the proxy for the CFSI is represented
by an SPServiceApplicationProxy object.
Figure 10 illustrates the relationships among the main classes in the Service
Application Framework.
Figure 10. Relation of major classes in the Service Application Framework
The following kinds of objects are persisted in the configuration database because
these classes inherit from SPPersistedObject:
SPService
SPServiceApplication
SPServiceInstance
SPServiceProxy
SPServiceApplicationProxy
For more information about the services object model, see The Services Hierarchy of
Microsoft SharePoint Foundation and Background: Service Entities in Microsoft
SharePoint Foundation.
Client Object Models in SharePoint
There are three client object models in SharePoint Foundation: one each for
Microsoft Silverlight applications, Microsoft .NET Framework applications, and
ECMAScript. They are almost the same in the APIs that they expose. The *.js files
that contain the ECMAScript client object model, like all *.js files, are downloaded
automatically to the user's computer when a page that references the object model is
accessed. (The standard built-in master page for SharePoint references these files.)
The assemblies that contain the Silverlight object model can be downloaded in the
.xap file, but another alternative is to download at run time the file
%ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\TEMPLATE\LAYOUTS\ClientBin\Microsoft.SharePoint.Client.xap,
which encases the Microsoft Silverlight assemblies.
The .NET Framework object model can be called only if the assemblies that contain
the object model have been installed to the client computer. You must use the official
redistribution package, SharePoint Foundation 2010 Client Object Model
Redistributable.
These object models provide a subset of the classes in the server-side
microsoft.sharepoint.dll assembly, although many of the class names have been slightly
changed (usually by dropping the "SP" at the beginning of the class name). The
client object models are implemented as a WCF service (.../_vti_bin/client.svc), but they
use web bindings to implement efficient request batching. Commands are serialized
into XML and sent to the server in a single HTTP request. For every command, a
corresponding server object model call is made, and the server returns a response to
the client in compacted JavaScript Object Notation (JSON) format, which the proxy
parses. The client APIs provide a familiar, object-oriented interface to the WCF
service, so developers are shielded from the details of the service. In particular, the
client-side runtime handles all communication between the clients and server.
Microsoft.SharePoint.Client is the core namespace used for the Microsoft .NET
Framework managed and Silverlight object models, and SP is the core namespace
for the ECMAScript object model. Client objects inherit from the ClientObject class
(ECMAScript: ClientObject).
SharePoint code on a client begins by retrieving a client context object that
represents the current request context, and through this context, you can obtain
access to client objects at the site-collection level or lower in the SharePoint
Foundation hierarchy. Client objects inherit from the ClientObject class
(ECMAScript: ClientObject), and you can use them to retrieve properties for a
specific SharePoint object, to retrieve child objects and their properties, or to retrieve
child items from a collection.
After a client object is obtained, a query is defined and loaded. This is followed by a
call of the ExecuteQuery method or the ExecuteQueryAsync method (ECMAScript:
executeQueryAsync) to send the query to the server. The query commands are
packaged as XML and processed on the server by the WCF service, Client.svc,
which runs the batched commands by calls to the server-side object model.
Returned data is sent back to the client by the service as JSON data.
Figure 11 shows the major components and events of the client's interaction with the
server when the client object models are used.
Figure 11. Client and server interaction with the client object models
Note:
The Silverlight client object model in SharePoint is not supported on Windows
Phone 7.
For more information about the client object models, see the following topics:
Using the SharePoint Foundation 2010 Managed Client Object Model
Using the Client APIs
Managed Client Object Model
Object Model Hierarchy and Identity
Client Context as Central Object
Client Application Models in SharePoint 2010
Note:
The client object models are not the only way to query SharePoint list data from a
client application. SharePoint also supports a WCF Data Services (formerly
ADO.NET Data Services) interface to the list data. For more information, see Data
Model, Data Management, and Query System earlier in this article. The section Low
Level Object Model earlier in this article mentions that the server object model treats
content types and their field types in a weakly typed manner, but that the SPMetal
tool enables strongly typed programming against these entities. A parallel point
applies to client-side computing: Content types are weakly typed in the client object
model, but they are strongly typed when you are programming against the WCF
Data Services interface.
Workflows in SharePoint
Like all workflows, SharePoint workflows model and systematize business
processes. However, SharePoint workflows are generally oriented around the
SharePoint list data model. In most cases, each instance of a SharePoint workflow
embodies processes that surround an item in a list or document library. Indeed, the
most common kinds of SharePoint workflow are workflows that are associated with a
list or with one or more content types. Some SharePoint workflows are manually
started, but they are most commonly designed to start automatically in response to
some event connected with a list item or library item, such as adding, deleting, or
updating an item.
There are also workflows associated with websites rather than lists or content types.
These are always started manually (or programmatically), not automatically in
response to some event. In addition, they are generally used to systematize
processes that transcend particular list items, such as retrieving and setting values of
multiple list items across different lists, or performing non-list operations, such as
creating and configuring subsites.
Note:
SharePoint Designer envisages two Reusable and Globally Reusable workflows.
These are really just list workflows that you can use on multiple lists without having
to re-create them for each of those lists.
Workflows in SharePoint are built on the framework provided by Windows Workflow
Foundation (WF). When a workflow is running in SharePoint, the WF runtime engine
is hosted in the SharePoint process. The WF runtime engine loads and unloads
workflow templates and provides sequencing and persistence for workflows. The
persistence services are crucial because they enable workflows to remain active
through discontinuous user sessions, through resets of the front-end web server, and
even through reboots of the server.
For many of its services, WF enables customization by hosting applications.
SharePoint provides custom implementations of the following services for the
engine: transaction, persistence, notifications, roles, tracking, and messaging. For
example, when a workflow instance reaches a point at which it is waiting for user
input, SharePoint unloads that workflow instance from memory and persists its data
in the content database. Then, when an appropriate event occurs that requires that
the workflow instance start again, such as when a user enters input, SharePoint re-
instantiates the workflow instance by using persisted data, so the workflow instance
can receive and handle the event as necessary.
A SharePoint workflow type is represented by two entities that work in partnership
with each other. First, there is a workflow definition. These can be defined in code
and compiled into an assembly, or defined in XOML markup. When the workflow
type is defined in XOML, it is called a declarative or "no code" workflow, and it
persists uncompiled in the content database until it is called, at which point it is
compiled just-in-time for use. The workflow definition, in either compiled or
declarative form, specifies the parameters, events (such as activation), and
sequence of activities in the workflow. It also defines the branching structures of the
workflow and the conditions that determine the paths of execution.
The partner of the workflow definition is the workflow template definition. A workflow
template definition is an XML file that contains the information SharePoint requires to
instantiate and run the workflow, such as the following:
Name and description of the workflow
Class within the workflow assembly to call
Identity of the workflow assembly
Location of any custom forms used in this workflow
You can store these XML files in either of two locations. The first is
%ProgramFiles%\Common Files\Microsoft Shared\web server
extensions\14\TEMPLATE\lcid\Workflow. For example, the template definition of the
built-in moderation workflow is stored in the moderationworkflow.xml file. The second
location is the Workflows list of the root website of a site collection. The built-in
Three-state workflow is an example. Regardless of where it is stored, at run time, the
workflow template definition is used to create an SPWorkflowTemplate object, which
is cached to speed up the creation of workflow instances.
You can associate workflow templates with lists (including document libraries),
content types, and websites. For any workflow template that is associated with a list
or content type, an item of that list or content type can have an instance of the
workflow in progress. Although there can be only one instance of a specific workflow
type in progress at any one time for a given item, any item can have multiple
workflows in progress, each of a different type.
You can create compiled workflows by using the Microsoft Visual Studio workflow
designer. You can also create declarative workflows by using SharePoint Designer.
Workflows are installed as Features at the site collection level. But you can also
"publish" a workflow directly from SharePoint Designer to a website, in which case
there is no Feature.
A workflow type is available for a list, content type, or website only if it is associated
with the list, content type, or website. These associations are stored in the content
database of each site collection. This association data typically includes whether the
workflow is started automatically or by users. If a workflow is added to multiple
content types, lists, or websites, it will have one entry for each such association.
Likewise, if you add multiple workflows to a specific content type, list, or website, the
database contains one entry for each workflow that is added to the content type, list,
or website.
For more information about the SharePoint workflow infrastructure, see Introduction
to Workflows in SharePoint Foundation.
SHAREPOINT 2010 – FEATURES
Microsoft SharePoint Server 2010 is a rich server application for the enterprise that facilitates
collaboration, provides full content management features, implements business processes, and
provides access to information that is essential to organizational goals and processes. It provides an
integrated platform to plan, deploy, and manage intranet, extranet, and Internet applications across
and beyond the enterprise.
Site collections overview
The sites in a site collection have shared administration settings, common navigation, and
other common features and elements. Each site collection contains a top-level site and (usually) one
or more sites below it in a hierarchical structure.
You must group your site's content and features into a site collection. This provides the
following benefits:
For site designers, a site collection's galleries and libraries (such as the master page
gallery or the site collection images library) provide a means for creating a unified, branded
user experience across all sites in the site collection.
For site collection administrators, a site collection provides a unified mechanism and
scope for administration. For example, security, policies, and features can be managed for a
whole site collection; Site Collection Web Analytics Reports, audit log reports, and other data
can help administrators track site collection security and performance.
For farm administrators, site collections provide scalability for growth based on how much
content is stored. Because each site collection can use a unique content database,
administrators can easily move them to separate servers.
For site authors, a site collection's shared site columns, content types, Web Parts,
authoring resources, workflows, and other features provide a consistent authoring
environment.
For site users, a site collection's unified navigation, branding, and search tools provide a
unified Web site experience.
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.
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.
Language If language packs have been installed on the Web server, you can select a
language-specific site template when you create a new site. Text that appears on the site is
displayed in the site template’s language.
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.
Web pages You can make each site have a unique welcome page and other pages.
Site layouts You can make unique layouts or master pages available in a site.
Themes You can change colors and fonts on a site.
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.
Workflows You can make each site have unique workflows.
Site templates included in SharePoint Server 2010
The following section contains information about the site templates that are included in
SharePoint Server 2010. Although you can use a site template with its default configuration, you can
also change the site’s default settings by using the site administration pages, and then saving the site
as a new template. In addition, you can modify a template's design and features by using Microsoft
SharePoint Designer 2010 or Microsoft Visual Studio 2010.
The following table lists every site template, describes the purpose of each, and indicates
whether the template is available at the site collection level, site level, or both. The category that is
used to group the templates might be different, depending on the level at which a site is created.
Template Purpose Category in
Site
Collection
Category in
Site
< Select
template later>
An empty site for which you can select a template
later.
Custom N/A
Assets Web
Database
An assets database to keep track of assets,
including asset details and owners.
N/A Web
Databases
Basic Meeting
Workspace
A site on which you can plan, organize, and
capture the results of a meeting. It provides lists for
managing the agenda, meeting attendees, and
documents.
Meetings Meetings
Basic Search
Center
A site that provides the search functionality. The
site includes pages for search results and
advanced searches.
Enterprise Search
Blank Meeting
Workspace
A blank meeting site that you can customize based
on your requirements.
Meetings Meetings
Blank Site A blank site that you can customize based on your Collaboration Blank &
Template Purpose Category in
Site
Collection
Category in
Site
requirements. Custom
Blog A site on which a person or team can post ideas,
observations, and expertise that site visitors can
comment on.
Collaboration Content
Business
Intelligence
Center
A site for presenting business intelligence data. It
provides document libraries for storing documents,
images, data connections, and dashboard Web
Parts. It also provides lists for linking content from
PerformancePoint Services in Microsoft
SharePoint Server 2010.
Enterprise 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
Contacts Web
Database
A contacts database to manage information about
people that your team works with, such as
customers and partners.
N/A Web
Databases
Decision
Meeting
Workspace
A site on which you can track status or make
decisions at meetings. It provides lists to create
tasks, store documents, and record decisions.
Meetings Meetings
Document
Center
A site on which you can centrally manage
documents in your enterprise.
Enterprise Content
Document
Workspace
A site on which 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 Collaboration,
Content
Template Purpose Category in
Site
Collection
Category in
Site
Enterprise
Search Center
A site that provides the search functionality. The
welcome page includes a search box that has two
tabs: one for general searches and another for
searches for information about people. You can
add and customize tabs to focus on other search
scopes or result types.
Enterprise Search
Enterprise Wiki A site on which you can publish knowledge that
you capture and want to share across the
enterprise. It provides an easy content editing
experience in a single location for co-authoring
content, for discussions, and for managing
projects.
Publishing Collaboration,
Content
FAST Search
Center
A site for delivering the FAST search experience.
The welcome page includes a search box with two
tabs: one for general searches and another for
searches for information about people. You can
add and customize tabs to focus on other search
scopes or result types.
Search
Group Work Site This template provides a groupware solution that
teams can use to create, organize, and share
information. It includes the Group Calendar,
Circulation, Phone-Call Memo, the document
library and the other basic lists.
Collaboration Collaboration
Issues Web
Database
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
Microsoft
Project Site
A site that supports team collaboration on projects.
This site includes Project Documents, Project
Issues, Project Risks, and Project Deliverables lists
that might be linked to tasks in Microsoft Project
Collaboration Tracking
Template Purpose Category in
Site
Collection
Category in
Site
Server 2010.
Multipage
Meeting
Workspace
A site on which you can plan a meeting and
capture the meeting's decisions and other results.
It provides lists for managing the agenda and
meeting attendees. It also provides two blank
pages that you can customize based on your
requirements.
Meetings Meetings
My Site Host A site that hosts personal sites (My Sites) and the
public People Profile page. This template has to be
provisioned only once per User Profile Service
Application.
This template is available only at the site collection
level.
Enterprise N/A
Personalization
Site
A site for delivering personalized views, data, and
navigation from this site collection to My Site. It
includes Web Parts that are specific to
personalization and navigation that is optimized for
My Site sites.
This template is available only at the site level.
N/A Blank &
Custom
PowerPoint
Broadcast
Center
A site for hosting Microsoft PowerPoint 2010
broadcasts. Presenters can connect to the site and
create a link for remote viewers to watch a slide
show in a Web browser.
Enterprise N/A
Projects Web
Database
A project tracking database to track multiple
projects, and assign tasks to different people.
N/A Web
Databases
Publishing
Portal
A starter site hierarchy that you can use for an
Internet site or a large intranet portal. You can use
distinctive branding to customize this site. It
Enterprise N/A
Template Purpose Category in
Site
Collection
Category in
Site
includes a home page, a sample press releases
site, a Search Center, and a logon page. Typically,
this site has many more readers than contributors,
and it is used to publish the Web pages by using
approval workflows.
This site enables content approval workflows, by
default, for a more formal and controlled publishing
process. It also restricts the rights of anonymous
users so that they can see only content pages, and
they cannot see SharePoint Server 2010
application pages.
This template is available only at the site collection
level.
Publishing Site A blank site for expanding your Web site and
quickly publishing Web pages. Contributors can
work on draft versions of pages and publish them
to make them visible to readers. This site includes
document and image libraries for storing Web
publishing assets.
N/A Content
Publishing Site
with Workflow
A site for publishing Web pages on a schedule by
using approval workflows. It includes document
and image libraries for storing Web publishing
assets. By default, only sites that have this
template can be created under this site.
This template is available only at the site level
when the Publishing Portal template is used to
create the top-level site.
N/A Content
Records Center A site that is designed for records management.
Records managers can configure the routing table
to direct incoming files to specific locations. The
site also enables you to manage whether records
Enterprise Data
Template Purpose Category in
Site
Collection
Category in
Site
can be deleted or modified after they are added to
the repository.
Social Meeting
Workspace
A site on which you can plan social occasions. It
provides lists for tracking attendees, providing
directions, and storing pictures of the event.
Meetings Meetings
Team Site A site on which a team can organize, author, and
share information. It provides a document library,
and lists for managing announcements, calendar
items, tasks, and discussions.
Collaboration Collaboration
Visio Process
Repository
A site on which teams can view, share, and store
Visio process diagrams. It provides a versioned
document library for storing process diagrams, and
lists for managing announcements, tasks, and
review discussions.
Collaboration Content
Site navigation overview
Site navigation provides the primary interface for site users to move around on the sites and
pages on your site. Microsoft SharePoint Server 2010 includes a set of customizable and extensible
navigation features that help orient users of your site so they can move around on its sites and pages.
This article describes the navigation controls that are available in SharePoint Server 2010. It does not
explain how to add navigation controls to Web pages, how to configure navigation controls, or how to
create custom navigation controls.
Navigation controls overview
Navigation controls can be displayed on master pages, page layouts, and—by using Web Part
zones—directly in a page's content.
SharePoint Server 2010 bases its navigation model on the hierarchical structure of the site collection.
By using the navigation features, you can link to the following:
Sites below the current site
A site's peer sites
Sites higher in the site structure
Web pages in a site
Additionally, you can create links to arbitrary locations, such as to an external Web site.
Navigation links in SharePoint 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.
Administration hierarchy
This article describes the administrator roles that correspond to the Microsoft SharePoint
Server 2010 server and site hierarchy. Many people can be involved in managing SharePoint Server
2010. Administration of SharePoint Server 2010 occurs at the following levels:
Server farm
Shared services
Sites
Document library or list
Individual items
Levels of administration
The following groups of users have administrative permissions at different levels of the administration
hierarchy:
Server or server farm level
Farm Administrators group Members of the Farm Administrators group have
permissions to and responsibility for all servers in the server farm. Members can perform all
administrative tasks in Central Administration for the server or server farm. Members of this
group can also use Windows PowerShell to create and manage configuration database
objects. They can assign administrators to manage service applications, which are instances
of shared services. This group does not have access to individual sites or their content.
Administrators group Members of the Farm Administrators group have permissions to
and responsibility for all servers in the server farm. Members can perform all administrative
tasks in Central Administration for the server or server farm. Members of this group can also
use Windows PowerShell to create and manage configuration database objects. They can
assign administrators to manage service applications, which are instances of shared services.
This group does not have access to individual sites or their content.
Shared services level
Service administrators These administrators are delegated by the farm administrator.
They can configure settings for a specific service application within a farm. However, these
administrators cannot create service applications, access any other service applications in the
farm, or perform any farm-level operations, including topology changes. For example, the
service application administrator for a Search service application in a farm can configure
settings for that Search service application only.
Feature administrators A feature administrator is associated with a specific feature or
features of a service application. These administrators can manage a subset of service
application settings, but not the entire service application. For example, a Feature
administrator might manage the Audiences feature of the User Profile service application.
Site level
Site collection administrators These administrators have the Full Control permission
level on all Web sites within a site collection. They have access to content in all sites in that
site collection, even if they do not have explicit permissions on that site.
Site owners By default, members of the Owners group for a site have the Full Control
permission level on that site. They can perform administration tasks for the site, and for any
list or library within that site. They receive e-mail notifications for events, such as the pending
automatic deletion of inactive sites and requests for site access.
SHAREPOINT SERVER 2010
INSTALLATION
Installing software prerequisites
To install Windows Server 2008 or Microsoft SQL Server, you can go to the Web sites listed in this
section. You can install all other software prerequisites through the SharePoint Server Start page.
Most of the software prerequisites are also available from Web sites listed in this section. The Web
Server (IIS) role and the Application Server role can be enabled manually in Server Manager.
Microsoft SQL Server 2008 SP1
Cumulative update package 2 for SQL Server 2008 Service Pack 1
Microsoft SQL Server 2005 SP3
Cumulative update package 3 for SQL Server 2005 Service Pack 3
Microsoft Windows Server 2008 Standard SP2
Windows Server 2008 with SP 2 FIX: A hotfix that provides a method to support the token
authentication without transport security or message encryption in WCF is available for the .NET
Framework 3.5 SP1
Windows Server 2008 R2 FIX: A hotfix that provides a method to support the token authentication
without transport security or message encryption in WCF is available for the .NET Framework 3.5 SP1
Microsoft .NET Framework 3.5 Service Pack 1
Microsoft SQL Server 2008 Express Edition Service Pack 1
Windows Identity Framework for Windows Server 2008
Windows Identity Framework for Windows Server 2008 R2
Microsoft Sync Framework v1.0
Microsoft Filter Pack 2.0
Microsoft Chart Controls for Microsoft .NET Framework 3.5
Windows PowerShell 2.0
Microsoft SQL Server 2008 Native Client
Microsoft SQL Server 2008 Analysis Services ADOMD.NET
Microsoft Silverlight 3
ADO.NET Data Services Update for .NET Framework 3.5 SP1 for Windows Server 2008 SP2
ADO.NET Data Services Update for .NET Framework 3.5 SP1 for Windows Server 2008 R2 or
Windows 7
SQL Server 2008 R2 November CTP Reporting Services Add-in for Microsoft SharePoint
Technologies 2010
Microsoft Server Speech Platform
Speech recognition language for English
Speech recognition language for Spanish
Speech recognition language for German
Speech recognition language for French
Speech recognition language for Japanese
Speech recognition language for Chinese
Browser details
You should review the details of the Web browser that you have or plan to use in your organization to
ensure that the Web browser works with SharePoint Server 2010 and according to your business
needs.
Internet Explorer 8 (32-bit)
Internet Explorer 8 (32-bit) is supported on the following operating systems:
Windows Server 2008 R2
Windows Server 2008
Windows Server 2003
Windows 7
Windows Vista
Windows XP
Known limitations
There are no known limitations for Internet Explorer 8 (32-bit).
Internet Explorer 7 (32-bit)
Internet Explorer 7 (32-bit) is supported on the following operating systems:
Windows Server 2008
Windows Server 2003
Windows Vista
Windows XP
Known limitations
There are no known limitations for Internet Explorer 7 (32-bit).
Install SharePoint Server 2010
To install and configure SharePoint Server 2010, follow these steps:
1. Run the Microsoft SharePoint Products Preparation Tool.
2. Run Setup, which installs SQL Server 2008 Express and the SharePoint product.
3. Run SharePoint Products Configuration Wizard, which installs and configures the
configuration database, the content database, and installs the SharePoint Central
Administration Web site. This wizard also creates your first SharePoint site collection.
FARM CONFIGURATION
Configure usage and health data collection
This article provides information about configuring usage and health data collection in
Microsoft SharePoint Server 2010. The system writes usage and health data to the logging folder and
to the logging database.
You can use only Central Administration to configure usage and health data collection.
To configure usage and health data collection by using Central Administration
1. Verify that the user account performing this procedure is a member of the Farm
Administrators group.
2. In Central Administration, on the Home page, click Monitoring.
3. On the Monitoring page, in the Reporting section, click Configure usage and health data
collection.
4. On the Configure usage and health data collection page, in the Usage data collection section,
enable usage data collection by selecting the Enable usage data collection text box.
5. In the Event Selection section, select the events to log by selecting the check box next to the
events in the Events to log list.
6. In the Usage data collection settings section, type the path of the folder you want usage and
health information to be written to in the Log file location box. The path that you specify must
exist on all farm servers.
7. Type the maximum disk space for the logs in gigabytes (between 1 and 20 GB) in the
Maximum log file size box.
8. In the Health data collection section, select the Enable health data collection check box. To
change the collection schedules, click Health Logging Schedule. A list of timer jobs that
collect health data is listed. Click any of the timer jobs to change its schedule, or disable that
timer job.
9. In the Logging Database Server section, to change the authentication used, select either the
Windows authentication or SQL authentication option.
To configure usage data collection by using Windows PowerShell
1. Verify that you meet the following minimum requirements:
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command,
and then press ENTER:
Set-SPUsageService [-LoggingEnabled {1 | 0}] [-UsageLogLocation <Path>] [-
UsageLogMaxSpaceGB <1-20>] [-Verbose]
Important:
You must specify a path for UsageLogLocation that exists on all farm servers.
Enable usage data logging by typing -LoggingEnabled 1. Specify the maximum amount of
drive space used for logging with the UsageLogMaxSpaceGB parameter.
Note:
We recommend that you use Windows PowerShell when performing command-line administrative
tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility
with previous product versions.
To configure usage data collection for a specific event type by using Windows PowerShell
The event types listed on the Configure usage and health data collection page in Central
Administration are the same as Usage Definitions in Windows PowerShell. You can use only
Windows PowerShell to configure usage definitions individually. Moreover, you can configure only the
DaysRetained setting.
To configure usage data logging for a specific event type using Windows PowerShell
1. Verify that you meet the following minimum requirements:
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command,
and then press ENTER:
Set-SPUsageDefinition -Identity <GUID> [-Enable] [-DaysRetained <1-30>] [-Verbose]
Use the Enabled switch to enable usage logging for this usage definition. Use DaysRetained
to specify how long the usage data is retained in the log before being deleted. The range is 1
to 30 days. To view the progress of the command, use the Verbose parameter.
To log usage data in a different logging database by using Windows PowerShell
1. Verify that you meet the following minimum requirements:
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command,
and then press ENTER:
Set-SPUsageApplication -DatabaseServer <Database server name> -
DatabaseName <Database name> [-DatabaseUsername <User name>] [-DatabasePassword
<Password>] [-Verbose]
You must specify the value for the DatabaseServer parameter, even if the new database is on
the same database server as the old one. You must use both the DatabaseUsername and the
DatabasePassword parameters if the database owner is a different user account that the one
you with which you are logged on. To view the progress of the command, use the Verbose
parameter.
Configure diagnostic logging
The SharePoint Server 2010 environment might require configuration of the diagnostic loggings
settings after initial deployment or upgrade and possibly throughout the system’s life cycle. The
guidelines in the following list can help you form best practices for the specific environment.
Change the drive that logging writes to. By default, diagnostic logging is configured to write
logs to the same drive and partition that SharePoint Server 2010 was installed on. Because
diagnostic logging can use lots of drive space and writing to the logs can affect drive
performance, you should configure logging to write to a drive that is different from the drive on
whichSharePoint Server 2010 was installed. You should also consider the connection speed
to the drive that logs are written to. If verbose-level logging is configured, lots of log data is
recorded. Therefore, a slow connection might result in poor log performance.
Restrict log disk space usage. By default, the amount of disk space that diagnostic logging
can use is not limited. Therefore, limit the disk space that logging uses to make sure that the
disk does not fill up, especially if you configure logging to write verbose-level events. When
the disk restriction is used up, the oldest logs are removed and new logging data information
is recorded.
Use the Verbose setting sparingly. You can configure diagnostic logging to record verbose-
level events. This means that the system will log every action that SharePoint Server 2010
takes. Verbose-level logging can quickly use drive space and affect drive and server
performance. You can use verbose-level logging to record a greater level of detail when you
are making critical changes and then re-configure logging to record only higher-level events
after you make the change.
Regularly back up logs. The diagnostic logs contain important data. Therefore, back them up
regularly to make sure that this data is preserved. When you restrict log drive space usage, or
if you keep logs for only a few days, log files are automatically deleted, starting with the oldest
files first, when the threshold is met.
Enable event log flooding protection. Enabling this setting configures the system to detect
repeating events in the Windows event log. When the same event is logged repeatedly, the
repeating events are detected and suppressed until conditions return to a typical state.
You can set the level of diagnostic logging for the event log and for the trace log. This will limit the
types and amount of information that will be written to each log. The following tables define the levels
of logging available for the event log and trace log:
Event log levels
Level Definition
None No logging occurs.
Critical This message type indicates a serious error that has caused a major failure in the
solution.
Error This message type indicates an urgent condition. All error events should be
investigated.
Warning This message type indicates a potential problem or issue that might require attention.
Warning messages should be reviewed and tracked for patterns over time.
Information Information messages do not require any action, but they can provide valuable data
for monitoring the state of your solution.
Verbose This event log level corresponds to lengthy events or messages.
Trace log levels
Level Definition
None No trace logs are written.
Unexpected This level is used to log messages about events that cause solutions to stop
processing. When set to log at this level, the log will only include events at this level.
Monitorable This level is used to log messages about any unrecoverable events that limit the
solution’s functionality but do not stop the application. When set to log at this level,
the log will also include critical errors (Unexpected level).
High This level is used to log any events that are unexpected but which do not stall the
processing of a solution. When set to log at this level, the log will include warnings,
errors (Monitorable level) and critical errors (Unexpected level).
Medium When set to this level, the trace log includes everything except Verbose messages.
This level is used to log all high-level information about operations that were
performed. At this level, there is enough detail logged to construct the data flow and
sequence of operations. This level of logging could be used by administrators or
support professionals to troubleshoot issues.
Verbose When set to log at this level, the log includes messages at all other levels. Almost all
actions that are performed are logged when you use this level. Verbose tracing
produces many log messages. This level is typically used only for debugging in a
development environment.
To configure diagnostic logging by using Central Administration
1. Verify that the user account that is performing this procedure is a member of the Farm
Administrators SharePoint group.
2. In Central Administration, on the Home page, click Monitoring.
3. On the Monitoring page, in the Reporting section, click Configure diagnostic logging.
4. On the Diagnostic Logging page, in the Event Throttling section, you can configure event
throttling as follows:
To configure event throttling for all categories:
a. Select the All Categories check box.
b. Select the event log level from the Least critical event to report to the event log list.
c. Select the trace log level from the Least critical event to report to the trace log list.
To configure event throttling for one or more categories:
d. Select the check boxes next to the categories that you want.
e. Select the event log level from the Least critical event to report to the event log list.
f. Select the trace log level from the Least critical event to report to the trace log list.
To configure event throttling for one or more sub-categories (you can expand one or more
categories and select any sub-category):
g. Click (+) next to the category to expand the category.
h. Select the check box next to the sub-category.
i. Select the event log level from the Least critical event to report to the event log list.
j. Select the trace log level from the Least critical event to report to the trace log list.
To configure event throttling for all categories back to default settings:
k. Select the All Categories check box.
l. Select Reset to default from the Least critical event to report to the event log list.
m. Select Reset to default from the Least critical event to report to the trace log list.
5. In the Event Log Flood Protection section, select the Enable Event Log Flood Protection
check box.
6. In the Trace Log section, in the Path box, type the path of the folder to which you want logs to
be written.
7. In the Number of days to store log files box, type the number of days (1-366) that you want
logs to be kept. After this time, logs will automatically be deleted.
8. To restrict how much disk space the logs can use, select the Restrict Trace Log disk space
usage check box, and then type the number gigabytes (GB) you want to restrict log files to.
When logs reach this disk size, older logs will automatically be deleted.
9. After you have made the changes that you want on the Diagnostic Logging page, click OK.
To configure diagnostic logging by using Windows PowerShell
1. Verify that you meet the following minimum requirements:
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command,
and then press ENTER:
Set-SPLogLevel -TraceSeverity {None | Unexpected | Monitorable | Medium | High | Verbose}
-EventSeverity {None | Information | Warning | Error | Critical | Verbose} [-Identity <Category
name…>] -Verbose
You can use the Identity parameter to specify one or more categories to change — for
example, Administration. If you do not specify the value for the Identity parameter, all
categories are changed.
To view the current settings, type Get-SPLogLevel, and then press ENTER.
To set all categories back to default levels, type Clear-SPLogLevel, and then press ENTER.
E-mail integration
After the initial installation of Microsoft SharePoint Server 2010, you can configure incoming and
outgoing e-mail. These additional settings are optional, but might be useful if you want to work with e-
mail in the server farm.
CREATE A WEB APPLICATION
A Web application is composed of an Internet Information Services (IIS) Web site that acts as a
logical unit for the site collections that you create. Before you can create a site collection, you must
first create a Web application.
Each Web application is represented by a different IIS Web site with a unique or shared application
pool. You can assign each Web application a unique domain name, which helps to prevent cross-site
scripting attacks.
You use Web applications to isolate content. When you create a new Web application, you also
create a new content database and define the authentication method used to connect to the
database. In addition, you define an authentication method to be used by the IIS Web site in
SharePoint Server 2010.
SharePoint Server 2010 offers two ways of authenticating users, as follows:
Classic mode authentication, through which users log on to a Web application by using
Windows authentication.
Claims-based authentication, through which users log on to a Web application by using
Windows authentication, forms-based authentication (FBA), or Trusted Identity provider
(SAML). If you use FBA or SAML, you must perform additional configuration steps. For more
information about claims-based authentication,
This article describes how to create a Web application that uses Windows-classic
authentication.
Tip:
If you want to use Windows-claims authentication instead, see Create a Web application that
uses Windows-claims authentication (SharePoint Server 2010).
Before you perform this procedure, confirm that:
Your system is running Microsoft SharePoint Server 2010.
You have your logical architecture design in place. For more information, see Logical
architecture components (SharePoint Server 2010).
You have planned authentication for your Web application. For more information, see Plan
authentication methods (SharePoint Server 2010), Configure Kerberos authentication
(SharePoint Server 2010) and Choose security groups (SharePoint Server 2010).
You have selected the service applications that you want to use for your Web application. For
more information, see Service application and service management (SharePoint Server
2010).
If you use Secure Sockets Layer (SSL), you must associate the SSL certificate with the Web
application's IIS Web site after the IIS Web site has been created. For more information about
setting up SSL, see How to Setup SSL on IIS 7.0
(http://go.microsoft.com/fwlink/?LinkId=187887).
You have read about alternate access mappings.
If you have User Account Control (UAC) turned on in Windows, and you use Windows
PowerShell 2.0 to create a Web application, you must right-click the SharePoint 2010
Management Shell and select Run as administrator.
You can create a Web application by using the SharePoint Central Administration Web site or
Windows PowerShell. You typically use Central Administration to create a Web application. If you
want to automate the task of creating a Web application, which is common in enterprises, use
Windows PowerShell. After the procedure is complete, you can create one or several site collections
on the Web application that you have created.
To create a Web application that uses Windows-classic authentication by using Central
Administration
1. Verify that you have the following administrative credentials:
To create a Web application, you must be a member of the Farm Administrators
SharePoint group and member of the local Administrator group on the computer
running Central Administration.
2. On the Central Administration Home page, in the Application Management section, click
Manage web applications.
3. On the ribbon, click New.
4. On the Create New Web Application page, in the Authentication section, click Classic Mode
Authentication.
5. In the IIS Web Site section, you can configure the settings for your new Web application by
selecting one of the following two options:
Click Use an existing web site, and then select the Web site on which to install your
new Web application.
Click Create a new IIS web site, and then type the name of the Web site in the
Name box.
6. In the IIS Web Site section, in the Port box, type the port number you want to use to access
the Web application. If you are creating a new Web site, this field is populated with a random
port number. If you are using an existing Web site, this field is populated with the current port
number.
Note:
The default port number for HTTP access is 80, and the default port number for HTTPS access is
443. If you want users to access the Web application without typing in a port number, they should
use the appropriate default port number.
7. Optional: In the IIS Web Site section, in the Host Header box, type the host name (for
example, www.contoso.com) you want to use to access the Web application.
Note:
In general, this field is not set unless you want to configure two or more IIS Web sites that share the
same port number on the same server, and DNS has been configured to route requests to the same
server.
8. In the IIS Web Site section, in the Path box, type the path to the IIS Web site home directory
on the server. If you are creating a new Web site, this field is populated with a suggested
path. If you are using an existing Web site, this field is populated with the current path of that
Web site.
9. In the Security Configuration section, configure authentication and encryption for your Web
application.
In the Authentication Provider section, click Negotiate (Kerberos) or NTLM.
Note:
To enable Kerberos authentication, you must perform additional configuration. For more information,
see Configure Kerberos authentication (SharePoint Server 2010).
In the Allow Anonymous section, click Yes or No. If you choose to allow anonymous
access, this enables anonymous access to the Web site by using the computer-
specific anonymous access account (that is, IIS_IUSRS).
Note:
If you want users to be able to access any site content anonymously, you must enable anonymous
access for the entire Web application zone before you enable anonymous access at the SharePoint
site level; later, site owners can configure how anonymous access is used within their sites. If you do
not enable anonymous access at the Web application level, you cannot enable anonymous access
later, at the site level. For more information, see Choose security groups (SharePoint Server
2010).
In the Use Secure Sockets Layer (SSL) section, click Yes or No. If you choose to
enable SSL for the Web site, you must configure SSL by requesting and installing an
SSL certificate. For more information about setting up SSL, see How to Setup SSL
on IIS 7.0 (http://go.microsoft.com/fwlink/?LinkId=187887).
2. In the Public URL section, type the URL for the domain name for all sites that users will
access in this Web application. This URL will be used as the base URL in links shown on
pages within the Web application. The default URL is the current server name and port, and is
automatically updated to reflect the current SSL, host header, and port number settings on
the page. If you are deploying SharePoint Server 2010 behind a load balancer or proxy
server, then this URL may need to be different than the SSL, host header, and port settings
on this page.
The Zone value is automatically set to Default for a new Web application.
Note:
You can change the zone when you extend a Web application. For more information, see Extend a
Web application (SharePoint Server 2010).
3. In the Application Pool section, do one of the following:
Click Use existing application pool, and then select the application pool you want to
use from the drop-down menu.
Click Create a new application pool, and then type the name of the new application
pool or keep the default name.
For more information, see Logical architecture components (SharePoint Server 2010).
2. Under Select a security account for this application pool, do one of the following:
Click Predefined to use a predefined security account, and then select the security
account from the drop-down menu.
Click Configurable to specify a new security account to be used for an existing
application pool.
Note:
You can create a new account by clicking the Register new managed account link.
3. In the Database Name and Authentication section, choose the database server, database
name, and authentication method for your new Web application, as described in the following
table.
Item Action
Database Server Type the name of the database server and Microsoft SQL Server instance you
want to use in the format <SERVERNAME\instance>. You can also use the
default entry.
Database Name Type the name of the database, or use the default entry.
Database
Authentication
Select the database authentication to use by doing one of the following:
If you want to use Windows authentication, leave this option
selected. We recommend this option because Windows authentication
automatically encrypts the password when it connects to SQL Server.
If you want to use SQL authentication, click SQL
authentication. In the Account box, type the name of the account you
want the Web application to use to authenticate to the SQL Server
database, and then type the password in the Password box.
Note:
SQL authentication sends the SQL authentication password to the SQL
Server unencrypted. We recommend that you only use SQL authentication
if you force protocol encryption to the SQL Server of encrypt your network
traffic by using IPsec.
4. If you use database mirroring, in the Failover Server section, in the Failover Database
Server box, type the name of a specific failover database server that you want to associate
with a content database.
5. In the Service Application Connections section, select the service application connections
that will be available to the Web application. In the drop-down menu, click default or custom.
You use the custom option to choose the services application connections that you want to
use for the Web application.
6. In the Customer Experience Improvement Program section, click Yes or No.
7. Click OK to create the new Web application.
To create a Web application that uses Windows-classic authentication by using Windows
PowerShell
1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. You
also need to be a member of the local Administrators group on the computer running
Windows PowerShell. In addition, some procedures require membership in the SQL Server
fixed server roles dbcreator and securityadmin.
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. At the Windows PowerShell command prompt, type the following command:
New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -
ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>
Where:
<Name> is the name of the new Web application.
<ApplicationPool> is the name of the application pool.
<ApplicationPoolAccount> is the user account that this application pool will run as.
<Port> is the port on which the Web application will be created in IIS.
<URL> is the public URL for the Web application.
Example
New-SPWebApplication -Name "Contoso Internet Site" -ApplicationPool
"ContosoAppPool" -ApplicationPoolAccount (Get-SPManagedAccount
"DOMAIN\jdoe") -Port 80 -URL "http://www.contoso.com"
Note:
We recommend that you use Windows PowerShell when performing command-line administrative
tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility
with previous product versions.
Create a Web application that uses Windows-claims authentication
This article describes how to create a Web application that uses Windows-claims authentication.
If you use Secure Sockets Layer (SSL), you must associate the SSL certificate with the Web
application's IIS Web site after the IIS Web site has been created. For more information about
setting up SSL, see How to Setup SSL on IIS 7.0
(http://go.microsoft.com/fwlink/?LinkId=187887).
You have read about alternate access mappings.
If you have User Account Control (UAC) turned on in Windows, and you use Windows
PowerShell 2.0 to create a Web application, you must right-click the SharePoint 2010
Management Shell and select Run as administrator.
You can create a Web application by using the SharePoint Central Administration Web site or
Windows PowerShell. You typically use Central Administration to create a Web application. If you
want to automate the task of creating a Web application, which is common in enterprises, use
Windows PowerShell. After the procedure is complete, you can create one or several site collections
on the Web application that you have created.
To create a Web application with Windows-claims authentication by using Central
Administration
1. Verify that you have the following administrative credentials:
To create a Web application, you must be a member of the Farm Administrators
SharePoint group and a member of the local Administrators group on the computer
running Central Administration.
2. On the Central Administration Home page, in the Application Management section, click
Manage web applications.
3. On the ribbon, click New.
4. On the Create New Web Application page, in the Authentication section, click Claims
Based Authentication.
5. In the IIS Web Site section, you can configure the settings for your new Web application by
selecting one of the following two options:
Click Use an existing web site, and then select the Web site on which to install your
new Web application.
Click Create a new IIS web site, and then type the name of the Web site in the
Name box.
6. In the IIS Web Site section, in the Port box, type the port number you want to use to access
the Web application. If you are creating a new Web site, this field is populated with a random
port number. If you are using an existing Web site, this field is populated with the current port
number.
Note:
The default port number for HTTP access is 80, and the default port number for HTTPS access is
443. If you want users to access the Web application without typing in a port number, they should
use the appropriate default port number.
7. Optional: In the IIS Web Site section, in the Host Header box, type the host name (for
example, www.contoso.com) you want to use to access the Web application.
Note:
In general, this field is not set unless you want to configure two or more IIS Web sites that share the
same port number on the same server, and DNS has been configured to route requests to the same
server.
8. In the IIS Web Site section, in the Path box, type the path to the IIS Web site home directory
on the server. If you are creating a new Web site, this field is populated with a suggested
path. If you are using an existing Web site, this field is populated with the current path of that
Web site.
9. In the Security Configuration section, choose whether or not to use allow anonymous
access and whether or not to use Secure Sockets Layer (SSL).
Under Allow Anonymous, click Yes or No. If you choose to allow anonymous
access, this enables anonymous access to the Web site by using the computer-
specific anonymous access account (that is, IIS_IUSRS).
Note:
If you want users to be able to access any site content anonymously, you must enable anonymous
access for the entire Web application zone before you enable anonymous access at the SharePoint
site level; later, site owners can configure how anonymous access is used within their sites. If you do
not enable anonymous access at the Web application level, you cannot enable anonymous access
later, at the site level. For more information, see Choose security groups (SharePoint Server
2010).
Under Use Secure Sockets Layer (SSL), click Yes or No. If you choose to enable
SSL for the Web site, you must configure SSL by requesting and installing an SSL
certificate. For more information about setting up SSL, see How to Setup SSL on
IIS 7.0 (http://go.microsoft.com/fwlink/?LinkId=187887).
2. In the Claims Authentication Types section, select the authentication that you want to use
for the Web application.
If you want to enable Windows authentication, select Enable Windows
Authentication and, in the drop-down menu, select Negotiate (Kerberos) or NTLM.
For more information, see Configure Kerberos authentication (SharePoint
Server 2010).
If you do not want to use Integrated Windows authentication, clear Integrated
Windows authentication.
If you want users' credentials to be sent over a network in a nonencrypted form,
select Basic authentication (password is sent in clear text).
Note:
You can select basic authentication or integrated Windows authentication, or both. If you select both,
SharePoint Server 2010 will offer both authentication types to the client Web browser. The client
Web browser then determines which type of authentication to use. If you only select basic
authentication, ensure that SSL is enabled; otherwise, the credentials can be intercepted by a
malicious user.
If you want to enable forms-based authentication, select Enable Forms Based
Authentication (FBA), and then enter the membership provider name and the role
manager name in the boxes.
For more information, see Configure forms-based authentication for a claims-
based Web application (SharePoint Server 2010).
Note:
If you select this option, ensure that SSL is enabled; otherwise, the credentials can be intercepted by
a malicious user.
If you have set up Trusted Identity Provider authentication in Windows PowerShell,
the Trusted Identity provider check box is selected.
For more information, see Configure authentication using a SAML security token
(SharePoint Server 2010).
You can use one or more claims authentication types. For more information, see Plan
authentication methods (SharePoint Server 2010).
3. In the Sign In Page URL section, choose one of the following options to sign into SharePoint
Server 2010:
Select Default Sign In Page URL if you want users to be redirected to a default sign-
in Web site for claims-based authentication.
Select Custom Sign In page URL and then type the sign-in URL if you want users to
be redirected to a customized sign-in Web site for claims-based authentication.
2. In the Public URL section, type the URL for the domain name for all sites that users will
access in this Web application. This URL will be used as the base URL in links shown on
pages within the Web application. The default URL is the current server name and port, and is
automatically updated to reflect the current SSL, host header, and port number settings on
the page. If you are deploying SharePoint Server 2010 behind a load balancer or proxy
server, then this URL may need to be different than the SSL, host header, and port settings
on this page.
The Zone value is automatically set to Default for a new Web application.
Note:
You can change the zone when you extend a Web application. For more information, see Extend a
Web application (SharePoint Server 2010).
3. In the Application Pool section, do one of the following:
Click Use existing application pool, and then select the application pool you want to
use from the drop-down menu.
Click Create a new application pool, and then type the name of the new application
pool or keep the default name.
4. Under Select a security account for this application pool, do one of the following:
Click Predefined to use a predefined security account, and then select the security
account from the drop-down menu.
Click Configurable to specify a new security account to be used for an existing
application pool.
Note:
You can create a new account by clicking the Register new managed account link.
5. In the Database Name and Authentication section, choose the database server, database
name, and authentication method for your new Web application as described in the following
table.
Item Action
Database Server Type the name of the database server and Microsoft SQL Server instance you
want to use in the format <SERVERNAME\instance>. You can also use the
default entry.
Database Name Type the name of the database, or use the default entry.
Database
Authentication
Select the database authentication to use by doing one of the following:
If you want to use Windows authentication, leave this option
selected. We recommend this option because Windows authentication
automatically encrypts the password when it connects to SQL Server.
If you want to use SQL authentication, click SQL
authentication. In the Account box, type the name of the account you
want the Web application to use to authenticate to the SQL Server
database, and then type the password in the Password box.
Note:
SQL authentication sends the SQL authentication password to the SQL
Server unencrypted. We recommend that you only use SQL authentication
if you force protocol encryption to the SQL Server of encrypt your network
traffic by using IPsec.
6. If you use database mirroring, in the Failover Server section, in the Failover Database
Server box, type the name of a specific failover database server that you want to associate
with a content database.
7. In the Service Application Connections section, select the service application connections
that will be available to the Web application. In the drop-down menu, click default or custom.
You use the custom option to choose the services application connections that you want to
use for the Web application.
8. In the Customer Experience Improvement Program section, click Yes or No.
9. Click OK to create the new Web application.
To create a Web application that uses Windows-claims authentication by using Windows
PowerShell
1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. You
also need to be a member of the local Administrators group on the computer running
Windows PowerShell. In addition, some procedures require membership in the SQL Server
fixed server roles dbcreator and securityadmin.
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. To create a Windows-claims authentication provider, at the Windows PowerShell command
prompt, type the following command:
$ap = New-SPAuthenticationProvider
To create a Web application that uses Windows-claims authentication, at the Windows
PowerShell command prompt, type the following command:
$wa = New-SPWebApplication -Name <ClaimsWindowsWebApplication> -ApplicationPool
<ClaimsApplicationPool> -ApplicationPoolAccount <ClaimsApplicationPoolAccount> -URL
<URL> -Port <Port> -AuthenticationProvider $ap
Note:
We recommend that the application pool account is a managed account on the server farm.
Where:
<Name> is the name of the new Web application that uses Windows claims
authentication.
<ApplicationPool> is the name of the application pool.
<ApplicationPoolAccount> is the user account that this application pool will run as.
<URL> is the public URL for the Web application.
<Port> is the port on which the Web application will be created in IIS.
Example
$ap = New-SPAuthenticationProvider
$wa = New-SPWebApplication -Name "Contoso Internet Site" -ApplicationPool
"ContosoAppPool" -ApplicationPoolAccount (Get-SPManagedAccount
"DOMAIN\jdoe") -URL "http://www.contoso.com" -Port 80 -AuthenticationProvider $ap
Create a site collection (SharePoint Server 2010)
Published: May 12, 2010
A site collection is a group of Web sites that have the same owner and share administration settings,
for example, permissions. When you create a site collection, a top-level site is automatically created
in the site collection. You can then create one or more subsites below the top-level site.
A site collection must exist within a Web application. You can create a site collection based on an
existing Web application, or you can create a Web application and then create a site collection within
that application. For more information, see Create a Web application (SharePoint Server
2010).
If your Web application is for a single project or for use by a single team, you should use a single site
collection to avoid the overhead of managing multiple sites. However, complex solutions benefit from
multiple site collections because it is easier to organize content and manage permissions for each site
collection. For example, because there is no built-in navigation from one site collection to another,
having multiple site collections can provide an additional layer of security for site content.
SharePoint provides site templates in the following categories: collaboration, meetings, enterprise,
publishing, and custom. When you create a site collection, you select the template that matches what
you want the site to do. For example, choose the Publishing Portal template if you want to create a
large intranet site that has many more readers than contributors.
Before you create a site collection, ensure that the following prerequisites are available:
A Web application in which to create the site collection.
A quota template, if you plan to define values that specify how much data can be stored in a
site collection and the storage size that triggers an e-mail alert to the site collection
administrator. For more information, see Create, edit, and delete quota templates
(SharePoint Server 2010).
A custom managed wildcard path, if you plan to create the site collection somewhere other
than under the root (/) directory or the /sites/ directory. For more information, see Define
managed paths (SharePoint Server 2010).
To create a site collection by using Central Administration
1. Verify that you have the following administrative credentials:
To create a site collection, you must be a member of the Farm Administrators
SharePoint group on the computer that is running the SharePoint Central
Administration Web site.
2. On the Central Administration Web site, in the Application Management section, click Create
site collections.
3. On the Create Site Collection page, in the Web Application section, if the Web application in
which you want to create the site collection is not selected, on the Web Application menu click
Change Web Application, and then click the Web application in which you want to create the
site collection.
4. In the Title and Description section, type the title and description for the site collection.
5. In the Web Site Address section, select the path to use for your URL (for example, a wildcard
inclusion path such as /sites/, or the root directory (/).
If you select a wildcard inclusion path, you must also type the site name to use in your site's
URL.
6. In the Template Selection section, in the Select a template list, select the template that you
want to use for the top-level site in the site collection, or click the Custom tab to create an
empty site and apply a template later.
7. In the Primary Site Collection Administrator section, type the user name (in the form
DOMAIN\username) for the user who will be the site collection administrator.
8. In the Secondary Site Collection Administrator section, type the user name for the secondary
administrator of the site collection.
Designating a secondary site collection administrator is a best practice to ensure that
someone can manage the site collection when a primary site collection administrator is not
present.
9. If you are using quotas to manage storage for site collections, in the Quota Template section,
click a template in the Select a quota template list.
10. Click OK.
Create a site collection by using Windows PowerShell
You typically use Windows PowerShell to create a site collection when you want to automate the task,
which is common in enterprises.
To create a site collection by using Windows PowerShell
1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. From the Windows PowerShell command prompt (that is, PS C:\>), type the following
command and press ENTER:
Get-SPWebTemplate
$template = Get-SPWebTemplate "STS#0"
New-SPSite -Url "<URL for the new site collection>" -OwnerAlias "<domain\user>" -Template
$template
This example retrieves a list of all available site templates and then creates a site collection
by using the Team Site template. For more information, see New-SPSite and Get-
SPWebTemplate.
We recommend that you use Windows PowerShell when performing command-line
administrative tasks. The Stsadm command-line tool has been deprecated, but is included to
support compatibility with previous product versions.
Add a content database
You can use the procedures that are described in this article to create a new content database and
attach it to a Web application.
To add a content database to a Web application by using Central Administration
1. Verify that the user account that is being used to perform this operation is a member of
the Farm Administrators SharePoint group. If you are using Windows authentication to
connect to SQL Server, the user account must also be a member the SQL Server
dbcreator fixed server role on the SQL Server instance where the database will be
created. If you are using SQL authentication to connect to SQL Server, the SQL
authentication account that you specify when you create the content database must have
dbcreator permission on the SQL Server instance where the database will be created.
2. On the SharePoint Central Administration Web site, click Application Management.
3. In the Databases section, click Manage content databases.
4. On the Manage Content Databases page, click Add a content database.
5. On the Add Content Database page:
a. Specify a Web application for the new database.
b. Specify a database server to host the new database.
c. Specify the authentication method that the new database will use and supply an account
name and password, if they are necessary.
Important:
The account name and password must already exist as a SQL Server login.
d. Specify the name of the failover database server, if one exists.
e. Specify the number of top-level sites that can be created before a warning is issued. By
default, this is 9,000.
f. Specify the total number of top-level sites that can be created in the database. By default,
this is 15,000.
g. Click OK.
To add a content database to a Web application by using Windows PowerShell
1. Verify that you meet the following minimum requirements:
If you are using Windows authentication to connect to SQL Server, the user account must
also be a member the SQL Server dbcreator fixed server role on the SQL Server instance
where the database will be created. If you are using SQL authentication to connect to SQL
Server, the SQL authentication account that you specify when you create the content
database must have dbcreator permission on the SQL Server instance where the
database will be created.
2. On the Start menu, click Administrative Tools.
3. Click SharePoint 2010 Management Shell.
4. At the Windows PowerShell command prompt, type the following command:
New-SPContentDatabase -Name <ContentDbName> -WebApplication
<WebApplicationName>
Where <ContentDbName> is the name of the content database to create and
<WebApplicationName> is the name of the Web application to which the new database is
attached.
Note:
To attach an existing content database to a Web application, use the Windows PowerShell cmdlet
Mount-SPContentDatabase.
We recommend that you use Windows PowerShell when performing command-line administrative
tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility
with previous product versions.
Introduction to the SharePoint 2010
Server Ribbon
With the release of the 2007 Microsoft Office system, Microsoft introduced a new
user interface structure, known as the ribbon, that replaced the previous application
drop-down menus and toolbars. The ribbon came about after much research
suggested that certain applications, such as Microsoft Word, contained so many
commands that users had trouble finding what they needed.
The premise behind the ribbon is that it provides a more results-driven interface.
Users focus on what they are doing, and commands are presented only for those
things they can do at a specific time. For example, there is no reason to provide
commands to the user to interact with tables or images in a document when they are
clearly typing text and do not have an image or table selected. However, by using
the Insert tab, they can easily add a table or picture. Only when they have selected
the table or picture do new command structures appear. When the table or picture
loses focus, these commands disappear.
In the 2007 Microsoft Office system, the ribbon was implemented in Microsoft Word,
Microsoft Excel, and Microsoft PowerPoint. Microsoft expanded on this and has
added the ribbon to the all the Microsoft Office 2010 applications, including Microsoft
OneNote 2010, Microsoft Access 2010, and Microsoft InfoPath 2010.
Like the Microsoft Office clients, SharePoint users were experiencing similar
challenges in finding controls to complete their work. Commands existed in multiple
places across the page, from the Site Actions menu to managing Web Parts, or to
the Edit Control Block (ECB) menus in lists. Figure 1 shows all the menus that are
available to users in a Windows SharePoint Services 3.0 site.
Figure 1. Menus and commands in Windows SharePoint Services 3.0
In Microsoft SharePoint 2010, Microsoft added the Server ribbon to SharePoint to
address the same challenges users had with the many commands in the Microsoft
Office clients. All commands and menu items have been pushed from the main
workspace in SharePoint up into the ribbon, which remains pinned to the top of the
browser window. Users of the 2007 Microsoft Office system or other applications that
have implemented the ribbon will find the SharePoint ribbon very easy to adjust to
because it is very similar to the Office client ribbons. It looks, works, and performs
like the Office ribbon, and has the same controls as the Office ribbon. The only
differences between the Office ribbon and the SharePoint Server ribbon are
concerned with the technologies; for example, it is not easy to show different font
renderings in the web (thin client) experience as it is in the desktop (thick client)
experience.
The ribbon in SharePoint 2010 is built on a similar architecture to the Office client
ribbon. Microsoft uses this architecture to implement the default ribbon in SharePoint
2010. This architecture also enables third-party developers to customize and extend
the existing ribbon components that are included in SharePoint, and to create
command structures.
This article explains the components of the SharePoint Server ribbon so that you can
understand how the ribbon is constructed. Then, it explains and shows how
developers can customize and extend the ribbon. The SharePoint Foundation 2010
General Reference has a section devoted to explaining the ribbon, and contains
various customization walkthroughs. When customizing the ribbon, I recommend that
you use this article in conjunction with the SharePoint Foundation 2010 General
Reference, specifically the section Server Ribbon in SharePoint Foundation.
SharePoint 2010 Server Ribbon
Architecture
The default ribbon is built by SharePoint and is based on a single file that is part of
the main installation. This file is part of the global site definition that is found in the
path {SharePoint Root}\TEMPLATE\GLOBAL\XML\CMDUI.XML. This file contains the
definitions for the ribbon components in SharePoint Foundation 2010, such as the
Browse, Page, List, Library, and Document tabs.
Although the CMDUI.xml file contains all the core Server ribbon components, this is
not how additional customizations to the ribbon are implemented. SharePoint
Features are used to implement additional changes to the ribbon. For example,
Microsoft SharePoint Server 2010 includes many things that require ribbon
modifications such as those related to Enterprise Content Management, Forms
Services, and business intelligence. These changes are all implemented by using
SharePoint Features. SharePoint developers can also customize the ribbon by using
Features as described in Creating Custom SharePoint 2010 Server Ribbon
Components, later in this article.
SharePoint 2010 has extended the Feature schema, specifically the
<CustomAction /> element, to be the vehicle for all ribbon customizations. This is
done by setting the Location attribute to CommandUI.Ribbon, and adding a
<CommandUIExtension /> child element. The SharePoint 2010 SDK provides an
overview of the Server Ribbon XML.
The following sections address the two core pieces of the ribbon: the components
that make up the visual experience and the code that runs when one of the controls
in the ribbon is clicked.
SharePoint 2010 Server Ribbon Components
The SharePoint 2010 Server ribbon has various components, as shown in Figure 2.
Figure 2. SharePoint 2010 Server ribbon components
The callout numbers in the figure point to the following specific components:
1. Tab
2. Group
3. Control
4. Contextual tab group
The next few sections briefly explain these components and their uses.
Tabs on the SharePoint 2010 Server Ribbon
Tabs are the root of the Server ribbon. They contain one or more groups, and
contain similar functions. For example, in Figure 2, the Page tab that is currently
selected contains functions that pertain to working with the current page.
Contextual Tab Groups on the SharePoint 2010 Server Ribbon
Contextual tab groups are used to provide functions that are not global to the current
context, such as the page. They appear only when certain circumstances have been
met and contain one or more tabs.
For example, the ribbon in Figure 2 shows the Library Tools contextual tab group,
which appears only when inside a document library or, as in this case, when the List
View Web Part on the current page that is associated with a document library is
selected.
Contextual tab groups hide functionality and menu choices from the user when they
are not available, and appear when applicable. Other examples of contextual tab
groups include the Editing Tools contextual tab group that appears when editing a
wiki page, or the Picture Tools contextual tab group that appears when a picture is
selected in edit mode.
Groups on the SharePoint 2010 Server Ribbon
Every tab in the ribbon contains a series of one or more groups. Groups are used to
associate controls with similar functionality. Each group is associated with a template
that defines the layout of the group and how the group should appear based on the
scale of the ribbon. The scale of the ribbon refers to situations where there are too
many controls to show in the ribbon, for example, when the browser is not in a full-
screen maximized state and is in a windowed state.
Group Templates on the SharePoint 2010 Server Ribbon
Group templates are used to define the different layout options for the controls within
a group. Microsoft includes 29 group templates in the CMDUI.xml file (to locate
them, search for the element <RibbonTemplates /> at the end of this file).
Controls on the SharePoint 2010 Server Ribbon
The ribbon would not be complete if users did not have anything to select or click.
Controls are the items that live inside the ribbon that users can interact with. Controls
reside within groups. These include things such as buttons, toggle buttons, check
boxes, text boxes and many other controls. For a complete list of all the available
controls, see Architecture of the Server Ribbon.
Each control definition contains a Command attribute that tells the ribbon
infrastructure what to do when it is clicked or selected.
Server Ribbon Commands in SharePoint 2010
The Server ribbon handles click or selection actions by the user with commands.
Those who are familiar with how the commanding infrastructure works in Windows
Presentation Foundation or Microsoft Silverlight 4 will find near parity with the Server
ribbon commanding infrastructure. Each command is named. This name is
referenced in a control. At the core, commands contain two very important details:
Whether the current command is available For example, the Delete
command is available only in a document library or if documents are selected.
What code should be run For example, the Delete command may use the
SharePoint 2010 client-side object model to delete the item from the list,
display a notification that the document was deleted, and refresh the List View
Web Part on the page.
The topic Architecture of the Server Ribbon contains additional details about exactly
how the commanding infrastructure works.
Commands in the Server ribbon are written by using ECMAScript (JavaScript,
JScript). There are two ways that you can implement commands:
Through command UI handlers
Through page components
The two options are explained in the following sections, and I discuss some
advantages and disadvantages of each option. In general, simple and relatively
small commands are suited to the command UI handler option. However, commands
that get quite complex and require a considerable amount of ECMAScript to
implement may be better suited to page components. The example ribbon
customization used in the document library sample later in this article shows how to
use each technique to perform exactly the same operation.
Implementing Server Ribbon Commands Using Command UI Handlers
Command UI handlers are implemented with a mix of declarative markup and
ECMAScript. They are defined in the same Feature element manifest in which ribbon
customizations are defined (by using the <CommandUIExtension /> element) with
a <CommandUIHandler /> element. This element contains the following three
attributes:
Command The name of the command as it will be referenced from a control.
CommandAction The ECMAScript that is executed when the command is
fired.
EnabledScript The ECMAScript that is called by the Server ribbon command
infrastructure to determine whether the command is available. This script
should return a Boolean value, TRUE if the command is available, or FALSE
if it is not available. If the command is not available, the ribbon infrastructure
applies a gray mask to the command in the ribbon and does not call the
command when the user selects it.
Advantages of Using Command UI Handlers
Command UI handlers are generally easier to write and manage for most
developers. Because they are defined declaratively, the ribbon framework handles
adding the script to any page where the command is needed by a referencing
control.
Disadvantages of Using Command UI Handlers
One of the disadvantages of command UI handlers is that they can become hard to
manage, troubleshoot, and debug when they contain a significant amount of custom
ECMAScript. Also, because they are added to every page as inline script blocks,
they cannot be cached by the browser and must be downloaded each time, adding
to the overall page weight.
Implementing Server Ribbon Commands Using Page Components
An alternative to using command UI handlers is to use a page component. A page
component is an ECMAScript object that is defined in an external script library (.js)
file. The object implements a few properties and methods that tell the Server ribbon
command infrastructure how to initialize it, what commands it can handle, and
whether a specific command is available, and can also respond when the page
component receives focus or loses focus.
This script file must be added to the same page where the ribbon customizations
appear. This can be done in various ways. One way would be to use the new
<CustomAction ScriptSrc="" /> capability in SharePoint 2010 to add the library to
all pages in a site, site collection, web application, or farm, depending on the
Feature's scope. Another approach is to add the script from managed code within a
custom application or site page (.aspx), custom user control (.ascx), or custom
server control. The following code example would add the page component file to the
page from within a Web Part.
private void LoadAndActivateRibbonContextualTab() {
SPRibbon ribbon = SPRibbon.GetCurrent(this.Page);
// Ensure ribbon exists.
if (ribbon != null) {
// Load dependencies if not already on the page.
ScriptLink.RegisterScriptAfterUI(this.Page, "SP.Ribbon.js", false, true);
// Load and activate contextual tab.
ribbon.MakeTabAvailable("Ribbon.PropertyChangerTab");
ribbon.MakeContextualGroupInitiallyVisible("Ribbon.WebPartContextualTabGroup", string.Empty);
}
}
Advantages of Using Page Components
Because all the ECMAScript lives in an external script library, it is much easier to
manage, troubleshoot, and debug a page component instead of a command UI
handler (the Microsoft Visual Studio 2010 script debugger can set breakpoints and
attach to the library). In addition, because it is an external library, browsers can
cache the library without having to request it each time it is referenced on the page.
Page components also enable greater control over commands because they can
enable or disable the page component from receiving or losing focus and handle
events in each of these cases.
In addition, because they are external libraries, one page component can handle
commands for multiple controls and so can be reused across various ribbon
customizations.
Disadvantages of Using Page Components
One disadvantage of using page components, compared to using command UI
handlers, is that page components require a considerable amount of script. This is
primarily because developers are building, registering, and initializing a script object
on the page. In addition, developers who are not familiar with object-oriented
ECMAScript techniques can find this a bit challenging.
Another disadvantage of using page components is that they must be added to the
page somehow, as this is not handled by the ribbon command infrastructure.
Customizing the SharePoint 2010
Server Ribbon
Developers are presented with two options when they want to customize the
SharePoint Server ribbon. Customizations can either be applied declaratively or
programmatically. The declarative approach, as described previously in this article, is
done by using Features; specifically the <CustomAction /> element with the
<CommandUIExtensions /> child element.
The programmatic approach involves adding the declarative constructs, as strings, to
the Server ribbon objects. The remainder of this article focuses on the declarative
approach because these techniques can be applied to the programmatic approach
also. The SharePoint 2010 SDK contains a walkthrough about customizing the
ribbon programmatically: Walkthrough: Create a Custom Web Part with a Contextual
Tab.
Customizing the Built-in SharePoint
2010 Server Ribbon Components
Developers can customize the ribbon in three ways:
Add components to the ribbon (tabs, contextual tab groups, groups, and
controls).
Modify existing components in the ribbon.
Remove existing components from the ribbon.
All three options can be performed declaratively. Server Ribbon XML walks through
the different elements. And Declarative Customization of the Server Ribbon walks
through how to add three common components to the ribbon.
Modifying and removing components such as tabs, groups, and controls are done
very much the same way with the same schema elements. You modify an element
by duplicating its ID and simply replacing its contents, very similar to the way that
content placeholders work in Microsoft ASP.NET 2.0 master pages. Removing is the
same as modifying, except that the container is left empty. For more information, see
Declarative Customization of the Server Ribbon.
Creating Custom SharePoint 2010
Server Ribbon Components
The following two sections walk through how to customize the SharePoint
2010 Server ribbon. Both walkthroughs use various techniques, and each
component is explained in detail. For the sample code for both walkthroughs, see
MSDN Sample - Customizing and Extending the SharePoint 2010 Server Ribbon.
This sample code requires only a SharePoint Foundation 2010 site collection.
The first sample, WebPartRibbonContextualTab, shown in Figure 3, demonstrates
how to create a custom Web Part that uses the following ribbon customizations:
Contextual tab group
Custom tab
Custom group
Command UI handlers
Activating the contextual tab group only when the Web Part is on the page
Triggering and handling a server-side postback when a button is clicked on
the ribbon.
Figure 3. Web Part with contextual tab group
The second sample, ApplyDocumentPrefixRibbon, shown in Figure 4,
demonstrates how to implement the following customizations and techniques:
A custom group in an existing ribbon tab.
A custom group template with different layout options.
Two custom commands that perform identical actions, except that one is
implemented with a command UI handler and the other implements a custom
page component:
o The commands are disabled unless one or more documents in the
library are selected.
o When clicked, the commands open a dialog box, pass the selected
documents, and do some work based on user input.
o When the dialog box's work is complete, the dialog box closes, and the
command displays a notification message and refreshes the List View
Web Part instead of the whole page.
A custom server control that conditionally loads the page component.
Figure 4. Custom group with page component
Note:
Some markup from the sample code has been omitted for readability. For the
complete code reference, see MSDN Sample - Customizing and Extending the
SharePoint 2010 Server Ribbon.
How To: Create a Web Part–Enabled Contextual Tab and Leverage to
Postbacks
In this sample, when the Web Part is added to the page the contextual tab appears
as shown earlier in Figure 3. This tab contains two groups that provide a few buttons.
The buttons in the first group do not do anything but do show how to use one of the
default templates. However, the Write to Web Part via PostBack button issues a
postback. The Web Part contains code that checks whether the button issued the
postback, and if so, adds some text to the Web Part's contents.
Step 1: Create the Web Part
The first step is to create the Web Part. Using the new SharePoint development tools
in Microsoft Visual Studio 2010, create a SharePoint project and add a Web Part
SharePoint project item to the project. The CreateChildControls method does two
things: writes some text to the Web Part, and calls a method to handle the case
when a specific postback event is fired, as shown in the following code.
public class RibbonizedWebPart : WebPart {
private string POSTBACK_EVENT = "RibbonizedWebPartPostback";
protected override void CreateChildControls() {
this.Controls.Add(
new LiteralControl(
"<em>Ribbonized Web Part contents go here</em>"
)
);
// Handle postback from ribbon.
HandleRibbonPostback();
}
}
Next, create the method that handles the postback event. If it is a specific postback
event, it writes some additional text to the Web Part's contents, as shown in the
following code.
private void HandleRibbonPostback() {
if (this.Page.Request["__EVENTTARGET"] == POSTBACK_EVENT) {
this.Controls.Add(
new LiteralControl(
"<p>Responding to postback event from ribbon.</p>"
)
);
}
}
The last step is to implement the code that will add the custom contextual tab to the
page. This is done from the OnPreRender phase of the Web Part's life cycle. It must
get a reference to the Server ribbon and ensures the script dependencies are
already loaded on the page. Finally, to show the contextual tab, it then makes the tab
with an ID of Ribbon.PropertyChangerTab available, and tells the ribbon to make
the contextual tab with an ID of Ribbon.WebPartContextualTabGroup available
when the page loads, as shown in the following code.
protected override void OnPreRender(EventArgs e) {
LoadAndActivateRibbonContextualTab();
base.OnPreRender(e);
}
private void LoadAndActivateRibbonContextualTab() {
SPRibbon ribbon = SPRibbon.GetCurrent(this.Page);
// Ensure ribbon exists.
if (ribbon != null) {
// Load dependencies if not already on the page.
ScriptLink.RegisterScriptAfterUI(this.Page,
"SP.Ribbon.js", false, true);
// Load and activate contextual tab.
ribbon.MakeTabAvailable("Ribbon.PropertyChangerTab");
ribbon.MakeContextualGroupInitiallyVisible(
"Ribbon.WebPartContextualTabGroup", string.Empty);
}
}
Step 2: Create Server Ribbon Component Customizations
With the Web Part created, the next step is to create the Server ribbon component
customizations. To do this, you create a contextual tab group, a tab with two groups,
and a few controls.
The SharePoint development tools in Microsoft Visual Studio 2010 do not contain a
SharePoint project item template for customizing the ribbon. However, the generic
SharePoint project item Empty Element will work to contain the ribbon
customizations, so add a new one to the project.
Step 2.1: Add the Core Ribbon Markup to the Element
Add the following markup to the element.xml file in the new Element SharePoint
project item for the project.
XML
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="WebPartContextualTabs" Location="CommandUI.Ribbon">
<CommandUIExtension>
<CommandUIDefinitions />
<CommandUIHandlers />
</CommandUIExtension>
</CustomAction>
</Elements>
This will tell SharePoint the following:
The element manifest contains ribbon customizations that apply to the ribbon
everywhere (<CustomAction Location="CommandUI.Ribbon" />). There are five
options for the Location attribute. The others enable developers to specify
that the customizations should appear when the List View Web Part is present
or on the display, new, or edit forms for an item. In addition,
RegistrationType and RegistrationId enable developers to more granularly
target where the customizations appear. For example, they could be targeted
to a specific content type. All options are listed in Server Ribbon XML.
The basic structure for a ribbon customization is also included.
Step 2.2: Add a New Contextual Tab Group
Next, add the following markup that will create the contextual tab group.
XML
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="WebPartContextualTabs" Location="CommandUI.Ribbon">
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition
Location="Ribbon.ContextualTabs._children">
<ContextualGroup Id="Ribbon.WebPartContextualTabGroup"
ContextualGroupId="WebPartContextualTab"
Title="Ribbonized Web Part Tools"
Sequence="150"
Color="Green"
Command="WebPartContextualTab.OnEnableContextualTab">
</ContextualGroup>
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers />
</CommandUIExtension>
</CustomAction>
</Elements>
The <CommandUIDefinition> Location attribute tells the ribbon to add the
following contents, which are one or more <ContextualGroup /> elements, to the
contextual tabs in the ribbon.
The <ContextualGroup /> element defines the new group. It has an Id attribute that
matches the name of the contextual group that the Web Part's code told the ribbon to
make visible initially when the page loaded.
The Sequence attribute tells SharePoint the order where this contextual group
should exist when other contextual groups are present. The SharePoint contextual
groups are given sequences that increment by 100, starting with 100, which is the
Editing Tools contextual group. Therefore, our contextual group may show up first
or second if the Editing Tools group is present. For information about how to find
the names and sequences for other contextual groups, see the Custom SharePoint
2010 Server Ribbon Development Tips and Tricks section, later in this article.
The Command attribute associates this group with a command name. In some
cases, it may make sense to have script run when this tab group is selected.
However, in this case the command (implemented later) is used to tell the ribbon
when to activate the contextual group. If this were not implemented, when a user
clicked on anything it would trigger the ribbon to hide the custom group.
Step 2.3: Add a Tab to the Contextual Tab Group
With the contextual tab group created, add the following markup to add a new tab
and define the maximum size layout group template.
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.ContextualTabs._children">
<ContextualGroup Id="Ribbon.WebPartContextualTabGroup" ... >
<Tab Id="Ribbon.PropertyChangerTab"
Title="Tools" Sequence="501">
<Scaling Id="Ribbon.PropertyChangerTab.Scaling">
<MaxSize Id="Ribbon.PropertyChangerTab.MaxSize"
GroupId="Ribbon.PropertyChangerTab.PropertyGroup"
Size="LargeLarge" />
<MaxSize Id="Ribbon.PropertyChangerTab.MaxSize" ... />
</Scaling>
</Tab>
</ContextualGroup>
</CommandUIDefinition>
</CommandUIDefinitions>
There are two things to notice in this snippet around the <MaxSize /> element. It
associates the group defined later (via the GroupId attribute) with the layout option
LargeLarge (via the Size attribute) that is defined in the template.
Step 2.4: Add Groups to the Tab
Now add the groups to the new tab by adding the following markup.
XML
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.ContextualTabs._children">
<ContextualGroup Id="Ribbon.WebPartContextualTabGroup" ... >
<Tab Id="Ribbon.PropertyChangerTab" ... >
<Scaling Id="Ribbon.PropertyChangerTab.Scaling" ... >
</Scaling>
<Groups Id="Ribbon.PropertyChangerTab.Groups">
<Group Id="Ribbon.PropertyChangerTab.PropertyGroup" ... >
...
</Group>
<Group Id="Ribbon.PropertyChangerTab.PostBackGroup"
Title="PostBack" Sequence="25"
Template="Ribbon.Templates.Flexible2">
</Group>
</Groups>
</Tab>
</ContextualGroup>
</CommandUIDefinition>
</CommandUIDefinitions>
Although there are two groups in this sample, only the second one is shown in this
code listing. Notice the groups have Id attributes that match the <MaxSize
GroupId="" /> elements that were previously added.
Also notice that the groups are using a template named
Ribbon.Templates.Flexible2. This template is included in the built-in CMDUI.xml
ribbon declaration. When defining custom groups in ribbon customization Features,
Microsoft recommends that developers create their own group template instead of
using one of the provided group templates. The reason for this is that SharePoint
does not load the entire ribbon for every page request; only the parts of the ribbon
that are needed for the current context are loaded. This includes the group
templates. Therefore, if developers rely on the built-in group templates, there is a
chance the template will not be loaded for the current page and their ribbon
customizations will not appear.
In the case of this sample customization, because this is part of a Web Part and a
Web Part must be on a Web Parts page, an assumption is being made that this
template will be loaded because it is part of the Page tab, which is on every Web
Parts page.
For information about how to find the names of other templates, see Custom
SharePoint 2010 Server Ribbon Development Tips and Tricks later in this article.
Step 2.5: Add Controls to the Group
The last step in defining the visual part of the ribbon customization is to add controls
to the groups. Add the following markup to the second group (refer to MSDN Sample
- Customizing and Extending the SharePoint 2010 Server Ribbon for adding buttons
to the first group).
XML
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.ContextualTabs._children">
<ContextualGroup Id="Ribbon.WebPartContextualTabGroup" ... >
<Tab Id="Ribbon.PropertyChangerTab" ... >
<Scaling Id="Ribbon.PropertyChangerTab.Scaling" ... >
</Scaling>
<Groups Id="Ribbon.PropertyChangerTab.Groups">
<Group Id="Ribbon.PropertyChangerTab.PropertyGroup" ... >
...
</Group>
<Group Id="Ribbon.PropertyChangerTab.PostBackGroup" ... >
<Controls Id="Ribbon.PropertyChangerTab.PropertyGroup.Controls">
<Button Id="Ribbon.PropertyChangerTab.PropertyGroup.GeneralDialogButton"
LabelText="Write to Web Part"
Command="WebPartContextualTabs.OnPostback"
TemplateAlias="o1"
Sequence="15"
Image16by16="/_layouts/Images/WebPartRibbonContextualTab/16x16Placeholder.png"
Image32by32="/_layouts/Images/WebPartRibbonContextualTab/32x32Placeholder.png"
/>
</Controls>
</Group>
</Groups>
</Tab>
</ContextualGroup>
</CommandUIDefinition>
</CommandUIDefinitions>
This markup will add a new button control to the group with a label of Write to Web
Part. When this button is clicked, it will trigger the Command="". The
TemplateAlias attribute tells the Server ribbon in what position in the defined group
template to place the button. Finally, the two image attributes are used by the layouts
to show the ribbon icons in different states. These images can point to any image on
the server. In this case, they are pointing to images that were added to the project.
Step 3: Create Server Ribbon Commands
The last step is to define the two commands that were referenced in the ribbon
components. Add the following markup to the element manifest.
XML
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="WebPartContextualTabs" Location="CommandUI.Ribbon">
<CommandUIExtension>
<CommandUIDefinitions>
...
</CommandUIDefinitions>
<CommandUIHandlers>
<CommandUIHandler Command="WebPartContextualTab.OnEnableContextualTab"
CommandAction=""
EnabledScript="return true;" />
<CommandUIHandler Command="WebPartContextualTabs.OnPostback"
CommandAction="javascript:__doPostBack('RibbonizedWebPartPostback','');" />
</CommandUIHandlers>
</CommandUIExtension>
</CustomAction>
</Elements>
The first <CommandUIHandler /> has a command that is associated with the
contextual tab group. As previously discussed, this command does not do anything
except to tell the Server ribbon when it should be active. To keep it from
disappearing from the ribbon, its EnabledScript attribute will always return TRUE.
Therefore, if the contextual tab group is on the page, which it is when the Web Part
is on the page because the Web Part handles its activation, it will never disappear.
The second <CommandUIHandler /> is associated with the button control. When it
is clicked it fires a postback with an event named RibbonizedWebPartPostBack.
Recall previously the code from the Web Part is listening for that event name and
adds text to the Web Part when it sees it.
Step 4: Deploy and Test
After saving all changes, deploy the custom Web Part by pressing F5 in Visual
Studio 2010 or by clicking Start Debugging on the Debug menu.
When the initial page loads, notice that the contextual tab is not present, as shown in
Figure 5.
Figure 5. Home page of debugging site without contextual tab group
Now, put the page into edit mode by selecting the Page tab and then clicking Edit.
Insert the Web Part on the page in the default location. When the page reloads,
notice the contextual tab and the Web Part are visible, as shown in Figure 6.
Figure 6. Contextual tab and Web Part are visible
Test the postback by selecting the Tools tab in the custom contextual tab group, and
then clicking the appropriate button. The page should refresh and have additional
text in the Web Part, as shown in Figure 7.
Figure 7. Web Part responding to postback from ribbon
Also notice that the contextual tab group is appearing as the second contextual tab
group on the page. That is because the page is still in edit mode and the sequence
was set to 150, which is greater than the Editing Tools sequence. After the page is
taken out of edit mode, the custom contextual group should appear in the first
position.
Walkthrough: Add Buttons to the Document Tab and Conditionally Enable
Them
The sample for this walkthrough shows how to add a new group with buttons to an
existing ribbon. When the project is deployed, it registers a new group in the
Documents tab, which is part of the Library Tools contextual tab group. This
contextual tab group will appear only when the user is interacting with documents or
in a document library. Figure 8 shows the home page of a team site without the
ribbon, but when the Shared Documents Library is selected, as shown in Figure 9,
the contextual tab group appears with the customizations.
Figure 8. Team site home page without document library selected
Figure 9. Team site home page with document library selected
Initially two of the three buttons are not enabled. It is not until one or more
documents are selected that the commands associated with the buttons are enabled,
as shown in Figure 10.
Figure 10. Ribbon buttons enabled when a document is selected
The two latter buttons, Apply Prefix w/ CommandUI Handler and Apply Prefix w/
Page Component, do the exact same thing when clicked. However, as their names
indicate, one uses the command UI handlers and the other uses a custom page
component. When clicked, they collect a list of all the selected documents on the
page and pass them to a new dialog box, as shown in Figure 11. This dialog box
enables the user to add a prefix to the name of all selected documents.
Figure 11. Custom dialog box fired from ribbon customizations
When the Set Prefix button is clicked, the dialog box updates the names of all
documents and then closes. Depending on whether the dialog box was closed by
clicking the Set Prefix button or by clicking Cancel, the command issues a
notification message and then refreshes the List View Web Part on the page,
updating the list's contents.
Step 1: Create Server Ribbon Component Customizations
The first step is to create a new SharePoint empty project by using the SharePoint
development tools in Microsoft Visual Studio 2010. When the project is created, add
a new Empty Element project item to the project that will contain the ribbon
customizations.
Step 1.1: Add the Core Ribbon Markup to the Element
Within the element manifest, add the following markup.
XML
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="Ribbon.Documents.ApplyDocumentPrefix" Location="CommandUI.Ribbon">
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Documents.Groups._children">
<Group Id="Ribbon.Documents.ApplyDocumentPrefix"
Title="Document Naming Tools"
Description="Document Naming Tools Description"
Sequence="25"
Template="Ribbon.Templates.MsdnTemplate">
</Group>
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers />
</CommandUIExtension>
</CustomAction>
</Elements>
This will add a new group to the Document tab's groups collection named
Document Naming Tools, as indicated by <CommandUIDefinition
Location="Ribbon.Documents.Groups._children">. The group has a Sequence of 25. The
groups in the built-in SharePoint 2010 Server ribbon are numbered in increments of
10, starting at 10. This means that the custom group defined here will show up in the
third position.
In addition, the group will not use one of the existing group templates, but instead will
use a custom group template.
Step 1.2: Add Custom Group Template
Add the following markup to add a custom group to the ribbon.
XML
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Documents.Groups._children">
<Group Id="Ribbon.Documents.ApplyDocumentPrefix" ... >
...
</Group>
</CommandUIDefinition>
<CommandUIDefinition Location="Ribbon.Templates._children">
<GroupTemplate Id="Ribbon.Templates.MsdnTemplate">
<Layout Title="MsdnHorizontal">
<Section Type="OneRow">
<Row>
<ControlRef DisplayMode="Large" TemplateAlias="o1" />
<ControlRef DisplayMode="Large" TemplateAlias="o2" />
<ControlRef DisplayMode="Large" TemplateAlias="o3" />
</Row>
</Section>
</Layout>
<Layout Title="MsdnVertical">
<Section Type="ThreeRow">
<Row><ControlRef DisplayMode="Medium" TemplateAlias="o1" /></Row>
<Row><ControlRef DisplayMode="Medium" TemplateAlias="o2" /></Row>
<Row><ControlRef DisplayMode="Medium" TemplateAlias="o3" /></Row>
</Section>
</Layout>
<Layout Title="MsdnVerticalTextOnly">
<Section Type="ThreeRow">
<Row><ControlRef DisplayMode="Menu" TemplateAlias="o1" /></Row>
<Row><ControlRef DisplayMode="Menu" TemplateAlias="o2" /></Row>
<Row><ControlRef DisplayMode="Menu" TemplateAlias="o3" /></Row>
</Section>
</Layout>
</GroupTemplate>
</CommandUIDefinition>
<CommandUIDefinitions>
<CommandUIHandlers />
</CommandUIExtension>
This template, Ribbon.Templates.MsdnTemplate, contains three different layouts.
Each <Layout /> has a Title attribute, which is referenced in the <MaxSize />
element or the <Scale /> element. This tells the ribbon which template to use for the
layout. Each <Layout /> element has a <Section /> that defines how the group will
be rendered by using the Type attribute. This can be one of four options to render
the group, using one, two, or three rows, or by using a divider. For more information,
see Section Element.
The <Section /> contains one or more <Row /> elements that define each row in the
layout. These <Row /> elements contain <ControlRef /> elements that serve as
placeholders for controls. The DisplayMode attribute tells the ribbon how to render
the control, by using just the text label, the large icon, the small icon, or one of the
other choices that are defined in the schema of the ControlRef element. The
TemplateAlias attribute is used to call out a specific control placement. When
adding controls to the group, each control's TemplateAlias attribute will match one
of these TemplateAlias attributes to specify exactly where to place the control.
Now add the following markup to tell the ribbon how to render the group by using
one of the layouts in the defined template.
XML
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Documents.Groups._children">
<Group Id="Ribbon.Documents.ApplyDocumentPrefix" ... >
...
</Group>
</CommandUIDefinition>
<CommandUIDefinition Location="Ribbon.Documents.Scaling._children">
<MaxSize Id="Ribbon.Documents.Scaling.ApplyDocumentPrefix.MaxSize"
GroupId="Ribbon.Documents.ApplyDocumentPrefix"
Size="MsdnVertical"
Sequence="15" />
</CommandUIDefinition>
<CommandUIDefinition Location="Ribbon.Templates._children">
<GroupTemplate Id="Ribbon.Templates.MsdnTemplate">
...
</GroupTemplate>
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers />
</CommandUIExtension>
Figures 12, 13, and 14 show how just changing the <MaxSize Size="" /> attribute to
the different layout options can change the rendering of the group.
Figure 12. Using the MsdnHorizontal layout
Figure 13. Using the MsdnVertical layout
Figure 14. Using the MsdnVerticalTextOnly layout
Step 1.3: Add Controls to the Ribbon Group
Next, add the following markup to the element manifest file to add a few buttons to
the group.
XML
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.Documents.Groups._children">
<Group Id="Ribbon.Documents.ApplyDocumentPrefix" ... >
<Controls Id="Ribbon.Documents.ApplyDocumentPrefix.Controls">
<Button Id="Ribbon.Documents.ApplyDocumentPrefix.CustomHelpButton"
LabelText="Apply Document Prefix Help"
TemplateAlias="o1"
Sequence="15"
Image16by16="/_layouts/Images/ApplyDocumentPrefixRibbon/16x16Placeholder.png"
Image32by32="/_layouts/Images/ApplyDocumentPrefixRibbon/32x32Placeholder.png"
Command="ApplyDocumentPrefix.OnGetHelpApplyDocPrefix" />
<Button Id="Ribbon.Documents.ApplyDocumentPrefix.CustomApplyPrefixButton"
LabelText="Apply Prefix w/ CommandUI Handler"
TemplateAlias="o2"
Sequence="17"
Image16by16="/_layouts/Images/ApplyDocumentPrefixRibbon/16x16Placeholder.png"
Image32by32="/_layouts/Images/ApplyDocumentPrefixRibbon/32x32Placeholder.png"
Command="ApplyDocumentPrefix.OnApplyDocPrefixUIHandler" />
<Button Id="Ribbon.Documents.ApplyDocumentPrefix.CustomPageComponentButton"
LabelText="Apply Prefix w/ Page Component"
TemplateAlias="o3"
Sequence="19"
Image16by16="/_layouts/Images/ApplyDocumentPrefixRibbon/16x16Placeholder.png"
Image32by32="/_layouts/Images/ApplyDocumentPrefixRibbon/32x32Placeholder.png"
Command="ApplyDocumentPrefix.OnApplyDocPrefixPageComponent" />
</Controls>
</Group>
</CommandUIDefinition>
</CommandUIDefinitions>
<CommandUIHandlers />
</CommandUIExtension>
Notice that each button is wired to its own command. With the visual part of the
ribbon customization completed, the next step is to create the commands that handle
both when the buttons are available, and what they do when clicked. This is done by
using command UI handlers or page components. The next two steps will show how
to do each one.
Step 2: Create Server Ribbon Command UI Handlers
Command UI handlers are defined within the same element manifest file that
contains the ribbon visual customizations. Add the following markup to create the
first command UI handler.
XML
<CommandUIHandlers>
<CommandUIHandler Command="ApplyDocumentPrefix.OnGetHelpApplyDocPrefix"
CommandAction="javascript:
var dialogOptions = {
url: '/_layouts/ApplyDocumentPrefixRibbon/DocPrefixHelp.aspx',
title: 'Apply Document Prefix Help',
allowMaximize: true,
showClose: true,
width:500,
height:400
};
SP.UI.ModalDialog.showModalDialog(dialogOptions); " />
</CommandUIHandlers>
This command is wired to the first button by using the Command attribute. The
CommandAction attribute executes some ECMAScript that opens a dialog box by
using the SharePoint 2010 dialog box framework that points to a custom application
page that will be created later.
Add another command UI handler that will be associated with the second button.
This one does considerably more work, as shown in the following markup.
XML
<CommandUIHandlers>
<CommandUIHandler Command="ApplyDocumentPrefix.OnGetHelpApplyDocPrefix" ... />
<CommandUIHandler Command="ApplyDocumentPrefix.OnApplyDocPrefixUIHandler"
CommandAction="javascript:
function dialogCallback(dialogResult, returnValue){
SP.UI.Notify.addNotification(returnValue);
SP.UI.ModalDialog.RefreshPage(SP.UI.DialogResult.OK);
}
var selectedItems = SP.ListOperation.Selection.getSelectedItems();
var selectedItemIds = '';
var selectedItemIndex;
for (selectedItemIndex in selectedItems){
selectedItemIds += '|' + selectedItems[selectedItemIndex].id;
}
var dialogOptions = {
url: '/_layouts/ApplyDocumentPrefixRibbon/DocPrefixPrompt.aspx?selectedItems='
+selectedItemIds +'&ListId=' +SP.ListOperation.Selection.getSelectedList(),
title: 'Set Document Prefix',
allowMaximize: false,
showClose: false,
width:500,
height:400,
dialogReturnValueCallback: dialogCallback
};
SP.UI.ModalDialog.showModalDialog(dialogOptions);"
EnabledScript="javascript:
function checkIsEnabled(){
// Check items selected.
var selectedItems = SP.ListOperation.Selection.getSelectedItems();
var count = CountDictionary(selectedItems);
return (count > 0);
};
checkIsEnabled();"
/>
</CommandUIHandlers>
This one is a bit more complicated. First, it creates a new ECMAScript function that
will be used as a callback when the dialog box is closed. It displays a notification in
the browser, the little yellow message that slides in from the right side of the page,
and then refreshes the List View Web Part on the page.
It then creates a delimited list of the documents selected on the current page. Finally,
it creates a new dialog box that opens a new application page, and passes in the
selected items. When the dialog box closes, it calls the dialogCallback method that
was defined previously.
The other important piece to this is the EnabledScript attribute. This attribute
returns a Boolean value of TRUE if the command is available or FALSE if it is not
available. To determine this, it checks to see whether anything has been selected on
the page. If not, the command, and so this button, is disabled.
Step 3: Create Server Ribbon Page Component
With one button in the ribbon that uses a command that is defined in a command UI
handler, now it is time to create a page component to handle the other command.
This is done by adding a new ECMAScript file to the Visual Studio project, ideally in
a folder mapped to the {SharePoint Root}/TEMPLATE/LAYOUT/{ProjectName} directory. This
ensures that there is only one instance of the library on the front-end web server that
is used by all sites.
Step 3.1: Declare the Page Component Object
After the file is added to the project, add the following script to the library to declare
the ECMAScript object that this library will contain, and a few constructor and
initialization methods that will create an instance of the page component and add it
to the client-side ribbon manager. This is shown in the following markup.
// Register the page component object.
Type.registerNamespace('ApplyDocumentPrefix');
// Helper methods to set up and initialize the page component.
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent = function
ApplyDocumentPrefix_PageComponent() {
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.initializeBase(this);
}
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.initialize = function () {
ExecuteOrDelayUntilScriptLoaded(Function.createDelegate(null,
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.initializePageComponent),
'SP.Ribbon.js');
}
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.initializePageComponent = function () {
var ribbonPageManager = SP.Ribbon.PageManager.get_instance();
if (ribbonPageManager !== null) {
ribbonPageManager.addPageComponent(ApplyDocumentPrefix.ApplyDocumentPrefixPageCompone
nt.instance);
}
}
Step 3.2: Create the Page Component Object Prototype and init Method
Now add the following script for the object prototype and the core init method. As its
name indicates, this method initializes the object by creating a few arrays that list
and map commands to specific functions within the object.
// Page component object.
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.prototype = {
init: function ApplyDocumentPrefix_PageComponento$init() {
// Array of commands that can be handled that are associated with handler methods.
this.handledCommands = new Object;
this.handledCommands['ApplyDocumentPrefix.OnApplyDocPrefixPageComponent'] =
this.onApplyDocPrefixPageComponent;
// Array of commands that can be handled that are associated with canHandler methods.
this.canHandledCommands = new Object;
this.canHandledCommands['ApplyDocumentPrefix.OnApplyDocPrefixPageComponent'] =
this.onApplyDocPrefixPageComponent_canExecute;
// Array of commands.
this.commandList = ['ApplyDocumentPrefix.OnApplyDocPrefixPageComponent'];
},
getId: function ApplyDocumentPrefixPageComponent_PageComponent$getId() {
return "ApplyDocumentPrefixPageComponent";
}, ...
}
Notice that the name of the commands in the arrays match the value of the <Button
Command="" /> attribute added previously when defining the visual components of
the ribbon customization.
Step 3.3: Add Methods to Tell the Ribbon Manager What Commands This Page
Component Handles, and How and When to Handle Commands
Next, add four methods that tell the client-side ribbon manager what commands are
available, and how and when to handle them, as shown in the following code.
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.prototype = {
...
getFocusedCommands: function
ApplyDocumentPrefixPageComponent_PageComponent$getFocusedCommands() {
return [];
},
getGlobalCommands: function
ApplyDocumentPrefixPageComponent_PageComponent$getGlobalCommands() {
return this.commandList;
},
canHandleCommand: function
ApplyDocumentPrefixPageComponent_PageComponent$canHandleCommand(commandID) {
var canHandle = this.handledCommands[commandID];
if (canHandle)
return this.canHandledCommands[commandID]();
else
return false;
},
handleCommand: function
ApplyDocumentPrefixPageComponent_PageComponent$handleCommand(commandID,
properties, sequence) {
return this.handledCommands[commandID](commandID, properties, sequence);
},
...
}
The canHandleCommand method serves the same purpose as the command UI
handler's EnabledScript attribute in that it tells the ribbon manager whether the
command is available. In the previous snippet, the method uses the array created in
the object's initializer to call a specific method in the object. The handleCommand is
similar in that it serves the same purpose as the command UI handler's
CommandAction attribute. It, too, uses an array to point to another method for the
specified command.
Step 3.4: Add the Specific Command Methods
The next step is to add the methods that were defined in the object's initializer and
that are called to determine when the command is available
(onApplyDocPrefixPageComponent_canExecute) and what happens when the
command is executed (onApplyDocPrefixPageComponent).
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.prototype = {
...
onApplyDocPrefixPageComponent: function () {
var selectedItems = SP.ListOperation.Selection.getSelectedItems();
var selectedItemIds = '';
var selectedItemIndex;
for (selectedItemIndex in selectedItems) {
selectedItemIds += '|' + selectedItems[selectedItemIndex].id;
}
var dialogOptions = {
url: '/_layouts/ApplyDocumentPrefixRibbon/DocPrefixPrompt.aspx?selectedItems=' +
selectedItemIds + '&ListId=' + SP.ListOperation.Selection.getSelectedList(),
title: 'Set Document Prefix',
allowMaximize: false,
showClose: false,
width: 500,
height: 400,
dialogReturnValueCallback: PageComponentCallback
};
SP.UI.ModalDialog.showModalDialog(dialogOptions);
},
onApplyDocPrefixPageComponent_canExecute: function () {
var selectedItems = SP.ListOperation.Selection.getSelectedItems();
var count = CountDictionary(selectedItems);
return (count > 0);
}
...
}
function PageComponentCallback(dialogResult, returnValue) {
SP.UI.Notify.addNotification(returnValue);
SP.UI.ModalDialog.RefreshPage(SP.UI.DialogResult.OK);
}
Step 3.5: Add Final Object Registration, Initialization, and Notification Script
With the page component object complete, the last steps are to register it on the
page, create it, and tell the client-side ribbon that anything that was waiting for this
script to finish loading it has been loaded and initialized. This is shown in the
following code.
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.prototype = {
...
}
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.registerClass
('ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent',
CUI.Page.PageComponent);
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.instance =
new ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent();
ApplyDocumentPrefix.ApplyDocumentPrefixPageComponent.initialize();
SP.SOD.notifyScriptLoadedAndExecuteWaitingJobs("ApplyDocumentPrefix.UI.js");
At this point, the page component has been created and can now be added to the
page.
Step 4: Create Server Ribbon Page Component Loader
Next, the page component must be added to the page. In this sample a custom
server control is used to do this. Add a new Empty Element SharePoint project item
to the project. Use the <Control /> element to register a new delegate control with
the following markup.
XML
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Control Id="AdditionalPageHead"
ControlClass="MSDN.SharePoint.Samples.ApplyDocumentPrefix.PageComponentScriptLoader"
ControlAssembly="$SharePoint.Project.AssemblyFullName$" />
</Elements>
This will add the server control PageComponentScriptLoader to the
AdditionalPageHead content placeholder to all pages in the current site, or
whatever the scope of the Feature is. Now add a new code file to the SharePoint
project item, and add the following code to implement the server control.
public class PageComponentScriptLoader : WebControl {
protected override void OnPreRender(EventArgs e) {
SPRibbon ribbon = SPRibbon.GetCurrent(this.Page);
// Ensure ribbon exists and current list is a document library
// (otherwise, no need for extra ecmascript load).
if (ribbon != null && SPContext.Current.List is SPDocumentLibrary) {
// Load dependencies if not already on the page.
ScriptLink.RegisterScriptAfterUI(this.Page, "SP.Ribbon.js", false, true);
// Load page component.
. ScriptLink.RegisterScriptAfterUI(this.Page,
"ApplyDocumentPrefixRibbon/ApplyDocumentPrefix.UI.js", false, true);
}
base.OnPreRender(e);
}
}
This will first get a reference to the Server ribbon. When the user is working with a
document library, it will first verify that dependent scripts are on the page, followed
by registering the page component.
The last step here is to add a <SafeControl /> entry to the site's web.config file. An
Empty Element SharePoint project item does not automatically add a <SafeControl
/> entry, but it does give us a way to do to it. In Solution Explorer in Visual Studio
2010, select the Empty Element. In the Properties window, click the […] builder
button, as shown in Figure 15.
Figure 15. Manually adding a Safe Control Entry with SharePoint development
tools in Visual Studio 2010
In the Safe Control Entries dialog box, add a new entry, and then verify that the
namespace matches the namespace of the server control created earlier.
Figure 16. Safe Control Entries dialog box
Step 5: Create the Custom Dialog Box
The last step is to create the dialog box that is called by the custom ribbon
commands and that does the majority of the work. Add a new Application Page
SharePoint project item to the Visual Studio project.
Step 5.1: Implement the Visual Part of the Dialog Box (.aspx)
In this case, the dialog box uses a few of the SharePoint administration form user
controls, so a few references are needed, as shown in the following code.
<%@ Register TagPrefix="wssuc" TagName="InputFormSection"
Src="~/_controltemplates/InputFormSection.ascx" %>
<%@ Register TagPrefix="wssuc" TagName="InputFormControl"
src="~/_controltemplates/InputFormControl.ascx" %>
<%@ Register TagPrefix="wssuc" TagName="ButtonSection"
Src="~/_controltemplates/ButtonSection.ascx" %>
In the PlaceHolderMain content placeholder, add the following markup to create a
form with an ASP.NET DataList control that will display a list of all the documents
that are selected.
<asp:Content ID="Main" ContentPlaceHolderID="PlaceHolderMain" runat="server">
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td>
<wssuc:InputFormSection runat="server"
Title="Selected Documents"
Description="The following documents have been selected
to have the specified prefix added to their titles.">
<Template_InputFormControls>
<tr>
<td>
<asp:DataList ID="SelectedDocumentsDataList" runat="server"
RepeatColumns="2" CellPadding="2" CellSpacing="5">
<ItemTemplate><li><%# DataBinder.Eval(Container.DataItem,
"File.Name").ToString()%></li></ItemTemplate>
</asp:DataList>
</td>
</tr>
</Template_InputFormControls>
</wssuc:InputFormSection>
<wssuc:InputFormSection runat="server"
Title="Document Prefix"
Description="Prefix to add to the selected document
titles.">
<Template_InputFormControls>
<wssuc:InputFormControl LabelText="Prefix to add to the selected documents:"
runat="server">
<Template_control>
<asp:TextBox ID="DocumentPrefixTextBox" runat="server" />
</Template_control>
</wssuc:InputFormControl>
</Template_InputFormControls>
</wssuc:InputFormSection>
<wssuc:ButtonSection runat="server" ShowStandardCancelButton="FALSE"
TopButtons="TRUE">
<Template_Buttons>
<asp:Button ID="SetPrefixButton" class="ms-ButtonHeightWidth" runat="server"
Text="Set Prefix" OnClick="OnClickSetPrefixButton" />
<asp:Button ID="CancelButton" class="ms-ButtonHeightWidth" runat="server"
Text="Cancel" OnClientClick=
"SP.UI.ModalDialog.commonModalDialogClose(SP.UI.DialogResult.cancel,
'Assignment of prefix cancelled.'); return false;" />
</Template_Buttons>
</wssuc:ButtonSection>
</td>
</tr>
</table>
</asp:Content>
Step 5.2: Implement the Business Logic in the Code-Behind (.aspx.cs)
The code-behind for this application page is straightforward. It needs to perform the
following tasks:
Get a list of all the selected documents that are passed in on the
QueryString.
Get a reference to the list that contains the documents passed in on the
QueryString.
Show the items that are selected by binding the collection of selected
documents to the ASP.NET DataList control.
When clicked, update the file names of all the selected items.
When finished, write some ECMAScript to the
PlaceHolderAdditionalPageHead content placeholder that closes the dialog
box, sending the result back to the calling page.
Add the following code to the application page's code-behind file.
public partial class DocPrefixPrompt : LayoutsPageBase {
List<SPListItem> _selectedListItems = new List<SPListItem>();
protected override void OnLoad(EventArgs e) {
// Get all the selected documents.
SPList selectedDocumentLibrary =
SPContext.Current.Web.Lists[new Guid(
Request.QueryString["ListId"]
)];
string[] selectedItems =
Request.QueryString["selectedItems"].ToString().Split('|');
for (int index = 1; index < selectedItems.Length; index++) {
_selectedListItems.Add(
selectedDocumentLibrary.GetItemById(
int.Parse(selectedItems[index]))
);
}
// Bind to the repeater.
SelectedDocumentsDataList.DataSource = _selectedListItems;
SelectedDocumentsDataList.DataBind();
}
protected void OnClickSetPrefixButton(object sender, EventArgs e) {
foreach (SPListItem listItem in _selectedListItems) {
listItem["Name"] =
DocumentPrefixTextBox.Text + " " + listItem.File.Name;
listItem.Update();
}
CloseDialogOnSuccess();
}
private void CloseDialogOnSuccess() {
ContentPlaceHolder pageHead = this.Master.FindControl("PlaceHolderAdditionalPageHead") as
ContentPlaceHolder;
if (pageHead != null)
pageHead.Controls.Add(
new LiteralControl("
<script language='javascript'>
ExecuteOrDelayUntilScriptLoaded(closeDialog,'sp.js');
function closeDialog(){
SP.UI.ModalDialog.commonModalDialogClose(SP.UI.DialogResult.OK, 'Prefix assigned to selected
documents.');
}
</script>"));
}
}
Step 6: Deploy and Test the Custom Web Part
After saving all changes, deploy the custom Web Part by pressing F5 in Visual
Studio 2010 or by clicking Start Debugging on the Debug menu.
When the initial page of the team site opens, click the Shared Documents Library.
Selecting the Documents tab on the ribbon should make the ribbon customizations
visible, as shown earlier in Figure 9. After a document is selected, all the buttons in
the custom group will be enabled, as shown earlier in Figure 10. Clicking one of the
two Apply Prefix […] buttons triggers the dialog box shown earlier in Figure 11.
When the user clicks the Set Prefix button, the dialog box updates the selected file
names and then closes. The command then issues a notification message that the
changes have been applied, and refreshes the List View Web Part.
Custom SharePoint 2010 Server
Ribbon Development Tips and Tricks
When customizing the SharePoint 2010 Server ribbon, developers have the ability to
make a wide range of changes. There are various controls that can be used,
templates that could be reused, and groups and tabs that can be modified or added
to. Thankfully, the majority of the ribbon is constructed declaratively or, in the case of
page components, resides in script files that are easily readable compared to
compiled code. This means that developers have a great supply of code samples
available to them after SharePoint is installed!
The trick is knowing where to look and how to find these examples. The base Server
ribbon and all the ribbon declarations can be found in the {SharePoint
Root}\TEMPLATE\GLOBAL\XML\CMDUI.XML file in the global site definition. Additional
changes made by things like SharePoint Server 2010 Enterprise Content
Management are typically found in various Features. Simply searching all *.xml files
for the <CommandUIExtension> element will show a list of all the Features that
contain ribbon extensions.
The following sections help point developers in the right direction for a few common
scenarios when customizing the ribbon.
Finding Tab, Group, and Control Names and Sequences
One common task is to create new tabs, add groups to tabs, or modify existing
controls. The first step is finding the ID or name of the tab. The SharePoint 2010
SDK contains a list of all tabs and their locations. For more information, see Default
Server Ribbon Customization Locations. The names of tabs are descriptive enough
that it should be obvious which name goes with which tab. This page also contains a
list of the names of all groups and controls in these groups. The only thing missing is
the sequence and template alias.
To find the sequence and template alias, open the CMDUI.xml file and search for the
relevant tab, group, or control ID listed in the SDK. This takes you to relevant entries
that should answer any questions about the control.
Always Get a Clean Page Request: Clear the Browser Cache
When customizing the ribbon, developers will undoubtedly write ECMAScript and
reference images. The quantity of ECMAScript and images and ribbon
customizations depends on the complexity of the application.
One focus of Microsoft when refactoring the SharePoint 2010 UI and developing the
ribbon was to limit the weight of the page, or the combined size of all things required
on a page, as much as possible. To do this, SharePoint aggressively caches CSS
files and ECMAScript libraries in the browser. This in turn gives users a much faster
page load time, because fewer files are requested on subsequent requests.
Although a big advantage for users, it can also create problems for developers.
Changes made between debugging sessions may not appear because the browser
is not downloading the latest script or customizations. As a good practice after
deploying a solution and while waiting for it to load, use the Internet Explorer
Developer Toolbar.
Figure 17. Clearing the IE cache and force downloads for all files
The Internet Explorer Developer Toolbar also provides a way to explore script files.
To verify that the browser has downloaded the latest version of custom script files,
use the Script tab and select the script file that has been loaded by the page. If the
external script file is not listed, it was not added to the page. Figure 18 shows
selecting the page component external script library from a previous sample and
viewing its contents.
Figure 18. Script debugging with the IE Developer Toolbar
Conclusion
This article explains the core components that make up the Microsoft SharePoint
2010 Server ribbon. It then walks you through how to create two sample ribbon
changes that use different customization techniques. In addition, this article also
provides guidance about when to consider the different command implementation
options, either the command UI handlers or page components, and offers some tips
and tricks for doing ribbon customization development.
Configure a SharePoint Server 2010 farm
for business intelligence by using NTLM
Integrated Windows authentication enables Windows clients to seamlessly
authenticate with Microsoft SharePoint Server without having to manually provide
credentials (user name/password). Two protocol types often used to authenticate are
the Kerberos protocol and the NT LAN Manager (NTLM) protocol. This article
describes NTLM authentication detailing options for each SharePoint Server service,
and it shows you the steps that are required to configure a Microsoft SharePoint
Server 2010 environment for performing business intelligence tasks that use NTLM.
To review the advantages and disadvantages of Kerberos authentication and NTLM
authentication, see Overview of Kerberos authentication for Microsoft SharePoint
2010 Products.
The step-by-step instructions in this document cover several SharePoint Server 2010
scenarios that can be configured to use NTLM; links to additional resources are also
provided. The scenarios covered include the following:
Scenario 1: Core configuration
Scenario 2: SQL Server and Analysis Services Configuration
Scenario 3: Reporting Services configuration
Scenario 4: PerformancePoint Services configuration
Scenario 5: Connect to SQL Server data from Excel and publish to a
SharePoint site by using Excel Services
Scenario 6: PowerPivot for SharePoint 2010 configuration
Scenario 7: Create a data-connected Web diagram and publish to a
SharePoint site by using Visio Services
You may have to configure Kerberos due to the deployment topology of the IT
assets, but in many production and test scenarios this is not necessary. If you want
to learn more about scenarios for various service applications dedicated to business
intelligence, see the white paper Configuring Kerberos Authentication for Microsoft
SharePoint 2010 Products.
SharePoint Server 2010 in Classic
Mode Authentication with NTLM
In SharePoint Classic mode, NTLM is the default protocol used for authentication
flow into and out of the SharePoint Server farm, while claims authentication is used
for authentication flow within the farm. This can introduce a configuration pitfall
where you expect Windows Integrated authentication to use the client credentials to
authenticate with a remote data source without an authorization barrier, but this is
not allowed by the “double-hop” limitation in NTLM. The connection from the client to
the SharePoint farm is considered the first hop, and the connection from the
SharePoint farm to the remote data source is the second hop. To learn more about
claims and the three authentication scenarios, incoming authorization, inter/intra-
farm authorization, and outgoing authorization, see Overview of Kerberos
authentication for Microsoft SharePoint 2010 Products
In such cases, SharePoint 2010 Products must use the trusted subsystem model for
data-tier access. As shown in the following illustration, a trusted subsystem uses an
account of a trusted user for access to external systems.
Note:
The independent account is called different things between SharePoint Server and
SQL Server products. SharePoint Server calls this the Unattended Service Account
while SQL Server calls it an Unattended Execution Account. It is important to know
that it is a generic account, independent of the client and not being passed through
the client.
SharePoint 2010 Products use one of the following strategies to implement trusted
subsystems and enable data tier access in NTLM:
Prompt to the user for data source credentials
Embedded logon
Stored database credentials
Either one of the strategies creates a “first-hop” connection to the data tier, which
eliminates the NTLM “second hop”. Using stored data source credentials eliminates
the additional credential prompt when you are using the business intelligence
applications. All users of the SharePoint Server resource share the same access to
the data resources because only one data source credential can be stored on the
SharePoint Server resource.
Using SQL Server products, you can also prompt the user for data source
credentials.
Data access options for business
intelligence products in SharePoint
Server 2010
This section lists the data access options for each business intelligence product
when the SharePoint farm is configured to use Classic mode authentication with
NTLM and when the farm connects to remote data sources. Each SharePoint Server
2010 service implements its access to the data tier differently.
The Secure Store Service is a frequently used method for removing the double-hop
problem while authenticating to external sources of data. The walkthrough in this
article lists the steps that are required for enabling this deployment scenario by using
Classic mode authentication with NTLM. The sequence of events that occurs is as
follows:
1. A SharePoint Server 2010 user accesses a data-connected object such as an
Excel Services or PowerPivot worksheet, Visio Services Web drawing, or
PerformancePoint Services dashboard.
2. If the object is configured to use Secure Store for data authentication, the
business intelligence Service Application calls the Secure Store Service to
access the Target Application specified by the object.
3. The service application uses an unattended account to authenticate with the
remote data source.
If the authentication is successful, the data is displayed to the user within the
context of the worksheet, Web drawing, or dashboard.
Although the steps are similar, there are some differences between service
applications. To learn more about how to configure the Secure Store Service for
services in SharePoint Server 2010, see Use Secure Store with SQL Server
Authentication.
There are methods to embed user logon information into queries that allow a direct
connection to the external system. For example, in PerformancePoint Services a
Multidimensional Expression (MDX) function can be used to apply dynamic OLAP
security to access SQL Server Analysis Services values.
Important:
Authentication methods may have different names with similar purpose and
functionality. For example, in PerformancePoint Services, Per User Identity refers to
Integrated Windows authentication. The clarifications are made in the following table.
Service Application Implementation Detail
Excel Services
Excel Services Application supports three data authentication
methods:
Integrated Windows authentication: Use to allow for
Windows clients to seamlessly authenticate with the
data source without manually providing credentials
(user name/password). This method does not work with
remote data sources unless Kerberos authentication is
configured.
Secure Store Service Authentication: Use when you
want to access multiple system resources without
having to provide authentication credentials one or
more times. Also use when you must support individual
and group mappings.
None: use when the Excel Services Application uses
incoming connection strings to connect to the database.
Depending on the specific database provider, the
database can use the connection string to authenticate
the user.
Tip:
Use this method when you want quick access to data
for a single person and have no specific options for
parsing the string.
To learn more see Plan Excel Services authentication
(SharePoint Server 2010).
PerformancePoint
Services
PerformancePoint Services supports three data authentication
methods:
Per User Identity: Use to apply data-level security on
the database. This is the same as Excel’s and Visio
Service’s Integrated Windows Authentication in that
each user’s account is used to access all data sources.
This method does not work with remote data sources
unless Kerberos authentication is configured.
Note:
External data sources must reside within the same
domain to authenticate to the external data sources;
otherwise authentication will fail.
Unattended Service Account: Use to access all data
sources from a single shared user account. This is a
low privileged domain account stored in the Secure
Store Service. In establishing your unattended service
account, first determine whether this account has the
necessary access to the data sources that will be
required in the Dashboard.
Custom Data: Use to make SQL Server Analysis
Services include the currently authenticated user name
as a parameter on the custom data field in an Analysis
Services connection string. The Custom data option is
only used for Analysis Services data sources and can
be used against SQL Server 2005 Analysis Services
and SQL Server 2008 Analysis Services servers.
Visio Services
Integrated Windows authentication: Use to enable
Windows clients to seamlessly authenticate with the
data source without having to manually provide
credentials (user name/password). This method does
not work with remote data sources unless Kerberos
authentication is configured.
Secure Store Service: Use Visio Graphics Service to
map the user’s credentials to an independent credential
that has access to the database and use the Secure
Store Service.
This authentication model can only be used by
drawings that use an ODC file to specify the
connection. The ODC file specifies the target
application that is used for credential mapping.
Unattended Service Account: Visio Graphics Service
provides an authentication method where an
administrator creates a mapping for all users through a
single account. The mapped account is called the
unattended service account and is a low-privilege
Windows domain account that is given access to
databases through the Secure Store Target Application.
The Visio Graphics Service impersonates this account
when it connects to the database if no other
authentication method is specified.
This is the default authentication method if no ODC file
is used in the Visio Web drawing that specifies a
different authentication method.
PowerPivot for
SharePoint 2010
When you are accessing an Excel worksheet with PowerPivot
data, the PowerPivot service application accesses the local
Analysis Services VertiPaq engine, which does not cross
computer boundaries to a server outside the SharePoint farm.
In case of data refresh, the PowerPivot service application
uses credentials stored in Secure Store Services to refresh
data from an external Analysis Services database.
SQL Server 2008 R2
Reporting Services1
Each report and its data sources can be configured to prompt
for credentials or use preconfigured credentials that are stored
as part of the report or data source’s metadata, and the option
that is configured will be used when the user executes the
report. In the case of an unattended report execution, such as
a scheduled subscription, SQL Server Reporting Services
uses the Unattended Execution Account stored on the report
server to access the external data source.
1 SQL Server 2008 R2 is not a service application in SharePoint Server 2010 and is
not claims-aware; it does not take advantage of the intra-farm claims authentication
architecture.
SharePoint Server 2010 business
intelligence in a multi-tier scenario
The following diagram shows the deployment scenario used to configure SharePoint
Server 2010 business intelligence in the sections. As noted earlier in the discussion
about subsystems, the front-end service authenticates and authorizes the client and
then authenticates with additional back-end services, without passing the client
identity to the back end system. The back-end system "trusts" the front-end service
to perform authentication and authorization on its behalf. The farm topology is load
balanced and scaled out between multiple tiers to demonstrate how identity
delegation would work in multi-server, multi-hop scenarios. Load balancing on the
SharePoint Server front-end Web and SQL Server Reporting Services servers was
implemented by using Windows Server 2008 Network Load Balancing (NLB). How to
configure NLB and NLB best practices are not covered in this document. For more
information on NLB, refer to Overview for Network Load Balancing.
Note:
The topology in this example may be more or less complex than your own, but the
essential characteristics of the client, SharePoint Server 2010 farm, and external
system remain the same. For more information on how to design and build a
production SharePoint Server environment, see Deployment for SharePoint Server
2010.
Base configuration
There are scenarios that you can follow for configuration between the various
services. Steps in this section show how to configure PerformancePoint Services,
Excel Services, and Visio Services when you have not run the Farm Configuration
Wizard. If you select the option to configure your farm by using a wizard, the wizard
helps you create a default site collection and automatically configures your selection
of service applications. The scenario assumes that you have chosen to configure
everything yourself. To learn more about the different scenarios to deploy
SharePoint Server 2010, see:
Deploy a single server with a built-in database (SharePoint Server 2010)
Deploy a single server with SQL Server (SharePoint Server 2010)
As you walk through the scenarios, you will recognize other differences in
configuration.
Step 1: Create a Web application on SP10WFE-01.
To learn more see Create a Web application that uses Windows-classic
authentication (SharePoint Server 2010). From the article configure using following
steps.
1. Browse to Central Administration and select Application Management and
Manage Web Applications.
2. In the toolbar, select New and create your Web application.
3. Select Windows “classic mode” Authentication.
4. Configure the port and host header for each Web application.
5. Select NTLM as the Authentication Provider
Note:
If you select Negotiate and Kerberos authentication is not configured,
authentication will default back to NTLM.
6. Under application pool, select Create New Application Pool and then select
the Managed Account.
Note:
A Managed Account is an Active Directory user account that uses credentials
managed by and contained within SharePoint Server. To see how to register
a new Managed Account, see Configure automatic password change
(SharePoint Server 2010).
Note:
It is a security practice to use a separate managed account to run each
service application.
When creating the new Web applications, you also create a new zone, the default
zone, configured to use the Windows authentication provider. Zones represent
different logical paths for gaining access to the same sites in a Web application and
may imply various authentication methods for a specified Web application.
If users will be able to access site content anonymously, enable anonymous access
for the Web application zone before you enable anonymous access at the
SharePoint site level; later, site owners can configure how anonymous access is
used within their sites. To learn more about zones, see the section planning zones
for Web applications, in Plan authentication methods (SharePoint Server 2010).
Step 2: Create a site collection on SP10WFE-01. Follow the steps in Create a site
collection (SharePoint Server 2010).
SQL Server and Analysis Services configuration
In this section, you configure the SQL Server 2008 R2 database server and the SQL
Server 2008 R2Analysis Services server for access by the business intelligence
applications and install the AdventureWorks sample databases and AdventureWorks
sample cube.
Step For information, see
Install the SQL Server engine instance on dbsrvSQL
and the Analysis Services instance on dbsrvSQLAS.
Open ports 1433 and 1434 on dbsrvSQL.
Configuring the Windows
Firewall to Allow SQL Server
Access
Open port 2383 on dbsrvSQLAS.
Configure windows firewall to
enable Analysis Services
Access
Enable TCP/IP and Named Pipes for the SQL Server
engine instance on dbsrvSQL.
How to: Enable or Disable a
Server Network Protocol
(SQL Server Configuration
Manager)
Download the sample databases from CodePlex and
install them on both dbsrvSQL and dbsrvSQLAS. The
install packages includes the sample Analysis
Services project. You must manually deploy it.
Install the Analysis Services sample project and
deploy the sample cube.
Installing Analysis Services
Sample Database
Reporting Services configuration
In this section, you will configure SQL Server 2008 R2Reporting Services to publish
reports to a SharePoint site and view them in the SharePoint site. For an overview of
the architecture for Reporting Services in SharePoint Server integration, see
http://msdn.microsoft.com/en-us/library/bb283324.aspx.
Step For information,
see
Install SharePoint Server 2010 on the SP10App-02 and join it
to the SharePoint Server farm.The report server computer
requires SharePoint Foundation 2010 or SharePoint Server
2010 as a prerequisite.
How to: Configure
SharePoint
Integration on
Multiple Servers
Install SQL Server 2008 R2Reporting Services in SharePoint
integrated mode on SP10App-02.
How to: Configure
SharePoint
Integration on
Multiple Servers
Configure a domain account to run the report server instance.
Note:
How to: Configure a
Service Account for
Reporting Services
You must use domain user credentials to run your report
server instance if both of the following are true:
Your report server instance does not run on the same
computer as your front-end Web server.
Your report server instance runs on the same server
as the SharePoint Server databases.
In rsreportserver.config, remove the <RSWindowsNegotiate> tag if
it exists under <Authentication>.
How to: Modify a
Reporting Services
Configuration File
Use the Trusted Account option when you set up report
server integration in SharePoint Central Administration.
This account is not used to access the data tier. It enables the
Reporting Services Add-in for SharePoint Server 2010 to
communicate with the Reporting Services Windows service on
SP10App-02.
How to: Configure
Report Server
Integration in
SharePoint Central
Administration
Test the report server integration by accessing the link http://<
hostname >/<site
>/_layouts/ReportServer/SiteLevelSettings.aspx.
Download the sample reports from CodePlex and publish the
sample reports to the SharePoint site.
How to Publish a
Report to the
SharePoint Library
Deploying Models
and Shared Datasets
to a SharePoint Site
Locate the sample reports in the SharePoint Server catalog,
configure the DataSources\AdventureWorks2008R2 shared
data source to prompt for credentials, and select the Use as
Windows credentials check box.
How to: Create and
Manage Shared Data
Sources (Reporting
Services in
SharePoint
Integrated Mode)
Test the report view by opening a sample report in the
SharePoint site. You should be prompted to input your
Windows credentials. Type the credentials of a user who has
access to the AdventureWorks2008R2 database.
PerformancePoint Services configuration
In this section, you configure PerformancePoint Services. You will configure security
so that users have access to external data systems. For more detailed steps, see
Set up and configure PerformancePoint Services (step-by-step).
Step For information, see
If you decide to open
PerformancePoint Dashboard
Designer from a site other than the
Business Intelligence Center, see
Enable the PerformancePoint
Services site feature.
Enable the PerformancePoint Services site
feature
If you did not run the Configuration
Wizard to create service applications
and proxies, you must create a
PerformancePoint Service
application.
You must also start the
PerformancePoint Services service.
You can manage services by using
Central Administration or by using
Windows PowerShell 2.0 cmdlets.
Create a PerformancePoint Services service
application (SharePoint Server 2010)
"Starting or stopping a service" in Manage
services on the server (SharePoint Server
2010)
After you create a PerformancePoint
Services service, it is a best practice
Managed Accounts in SharePoint 2010
(http://go.microsoft.com/fwlink/?LinkId=19822
to create and register a new service
account for an existing application
pool dedicated for PerformancePoint
Services. To do this, run the following
Windows PowerShell script to grant
the account access to the associated
content database. The following is an
example.
PS C:\> $w = Get-
SPWebApplication(“ <your Web
application> ”)
PS C:\>
$w.GrantAccessToProcessIdentity(
" <insert service account> ")
This step is necessary for
PerformancePoint Services to work
correctly. Be aware that this action
grants db_owner access to the
SharePoint Foundation content
databases.
Note:
SQL Server Authentication is not
supported to the content databases.
9)
Create and configure a Secure Store
Service application and Proxy. This is
required to store the Unattended
Service Account password for a
PerformancePoint Services service
application.
To initialize the Secure Store Service
Configure the Secure Store Service
(SharePoint Server 2010)
Note:
Only specific sections apply to
PerformancePoint Services configuration.
Sections about how to create a target
application, refer to the following
sections of Configure the Secure
Store Service (SharePoint Server
2010).
Initialize an instance of a
Secure Store Service
application
Refresh the encryption key
application or how to set credentials for a
target application do not apply to
PerformancePoint as they do for Visio and
Excel Services.
Make sure that the service application
connection, PerformancePoint
Services service application, and
Secure Store Service are associated
with the Web application.
1. In Central Administration, in
the Application Management
section, click Manage Web
applications.
2. On the Web Applications tab,
click Service Connections. A
Service Application
Associations page appears.
This shows either the default
group or a custom group of
service applications associated
with the Web application.
Important:
If you did not select Make this
application service the
default when you created the
Add or remove a service application
connection to a Web application (SharePoint
Server 2010)
PerformancePoint Services
service application, you will
not see the PerformancePoint
Services Service Application
Proxy selected.
Configure the unattended service
account. The unattended service
account must be set for
PerformancePoint Services to
connect to data sources other than
the currently authenticated user. The
Unattended Service account is set
after you configure the
PerformancePoint Service
application. The setting is located in
Manage service applications in
Central Administration under the
PerformancePoint Services
management page.
Configure the unattended service account for
PerformancePoint Services
By default, all locations are trusted.
You may want to limit access to
PerformancePoint Services data
sources or any object dependent on a
data source by making available one
or more sites, lists, or document
libraries instead of the complete site
collection. You can enable trusted
locations for PerformancePoint
Services before or after you enable
PerformancePoint Services features
in sites and site collections.
Enable trusted locations for PerformancePoint
Services
Create a data connection for Analysis Configure Analysis Services data source time
Services.
To learn how to configure Analysis
Services to work with time intelligence
feature, see Configure Analysis
Services data source time settings by
using Dashboard Designer.
settings by using Dashboard Designer
Test data connectivity by creating a
basic dashboard.
If you have successfully created a
PerformancePoint Services enabled
site collection, you should be able to
open PerformancePoint Dashboard
Designer and connect to an external
data source.
Video: Creating a basic dashboard by using
PerformancePoint Dashboard Designer
Connect to SQL Server data from Excel and publish to a SharePoint site by
using Excel Services
Excel Services Application is a shared service that you can use to view and edit
workbooks in Excel Web Access. The following Excel Services scenario assumes
that a Web application exists and that NTLM authentication is configured as
described in Scenario 1: Core Configuration at the beginning of the article.
Step For more
information, see:
Define a new trusted location from which Excel files can be
loaded.
Note:
You can also use the default trusted file location for Excel
Manage Excel
Services trusted
locations
Services that SharePoint Server 2010 creates automatically. To
learn more about how to plan security, see Plan Excel Services
authentication (SharePoint Server 2010).
Set up and configure Secure Store Service for Excel Services
Application in Microsoft SharePoint 2010 Products. Set the
credentials for an application ID to include in the next step.
Configure Secure
Store Service for
Excel Services
Connect an Excel 2010 client to the correct SQL Server server.
In the steps outlined in Connect to (import) SQL Server data you
will complete procedures in a Data Connection Wizard.
Select the database and table that you want in your Excel
worksheet.
Determine a file name to save a data connection file and
type a description.
Select the Authentication button to specify how the
external data source is accessed if the workbook is
published to a SharePoint Server site and is opened in a
Web browser. You will select Windows Authentication,
SSS (Secure Store Service), or None. Select SSS and
enter the Application ID that you configured in the
previous step so that Excel Services can use it to
authenticate.
Warning:
Make sure that the database is not opened in exclusive mode.
Connect to
(import) SQL
Server data
Also see:
Overview of
connecting to
(importing) data
Publish the Excel workbook to SharePoint Server 2010.
Publish a
workbook to a
SharePoint site
PowerPivot for SharePoint 2010 configuration
In this scenario, you add PowerPivot to your existing SharePoint Server 2010
installation on SP10App-02.
Step For information, see
Follow the instructions at Microsoft Support to add
Setup1000.exe.config to the path
%ProgramFiles%\Microsoft SQL Server\100\Setup
Bootstrap\SQLServer2008R2\x64 on SP10App-02.
Install PowerPivot in the existing SharePoint Server farm
on SP10App-02
How to: Install
PowerPivot for
SharePoint on an
Existing SharePoint
Server
Configure the server.
Steps from How to:
Install PowerPivot for
SharePoint on an
Existing SharePoint
Server
Upload a PowerPivot workbook (includes installation
steps).
Steps from How to:
Install PowerPivot for
SharePoint on an
Existing SharePoint
Server
View the workbook.
Steps from How to:
Install PowerPivot for
SharePoint on an
Existing SharePoint
Server
Create a data-connected Web diagram and publish to a SharePoint site by
using Visio Services
Visio Services in Microsoft SharePoint Server 2010 is a service application that lets
users share and view Microsoft Visio Web drawings. The service also enables data-
connected Microsoft Visio 2010 Web drawings that can be refreshed and updated
from various data sources while published on a SharePoint Server site. For example,
a shape can display the number of units currently at a specified stage in a process,
or can configure color when a number goes over or under a specified threshold.
The following Visio Services scenario assumes that a Web application exists and
that NTLM authentication is configured as described in Scenario 1: Core
Configuration.
Step For more information, see:
Note:
Plan security for Visio Graphics Service service
application. Also plan for performance and other
considerations.
Plan Visio Services security
(SharePoint Server 2010)
Plan Visio Services deployment
If you did not run the Configuration Wizard to create
service applications, you must create a Visio
Graphics Service application.
Create a Visio Graphics Service
service application (SharePoint
Server 2010)
Set up and configure Secure Store Service for Visio
Services Application in Microsoft SharePoint 2010
Products.
Data authentication for Visio
Services
Video: Steps for configuring
Visio Services with Secure Store
Video: Configuring Visio
Services with the Unattended
Service Account
In Visio Professional or Premium, create a data-
connected Web diagram. The Data Selector Wizard
resembles the wizard used in Excel Services.
Import data from Excel, SQL
Server, SharePoint sites, and
other external sources
Publish the Visio Web diagram to SharePoint
Server 2010.
Publish a diagram as a Web
drawing