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 +'&amp;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