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 thingsthings 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 nonSharePoint 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-ofthe-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, downwardpointing 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 users 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 modules 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.

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.

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 o

Code in the sandbox cannot call unmanaged code. Code in the sandbox cannot call the Microsoft .NET Framework 3.5 reflection APIs.

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.

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 o

The token denies the process the right to write to the registry. 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 solutionsincluding, for example, images, user controls, and string resourcesare 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 fulltrust 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 listof-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 frontend 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.

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 datathat is, data from outside the SharePoint content databasescan 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 listthat is, a list itemalso 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 dropdown 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 farmscoped 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 claimsbased 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 farmsthe 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 loadbalanced. 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 reinstantiates 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 templates 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 sites 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> Assets Web Database Basic Meeting Workspace

An empty site for which you can select a template later. An assets database to keep track of assets, including asset details and owners. 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.

Custom

N/A

N/A

Web Databases

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 Blank Site

A blank meeting site that you can customize based on your requirements. A blank site that you can customize based on your

Meetings

Meetings

Collaboration

Blank &

Template

Purpose

Category in Site Collection

Category in Site

requirements. Blog A site on which a person or team can post ideas, observations, and expertise that site visitors can comment on. 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. Charitable Contributions Web Database A database to track information about fundraising campaigns including donations made by contributors, campaign-related events, and pending tasks. Contacts Web Database A contacts database to manage information about people that your team works with, such as customers and partners. Decision Meeting Workspace Document Center Document 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. A site on which you can centrally manage documents in your enterprise. 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 Enterprise Meetings N/A N/A Enterprise Collaboration

Custom Content

Data

Web Databases

Web Databases

Meetings

Content

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. 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. 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

Collaboration

N/A

Web Databases

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. 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. 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. 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. Projects Web Database Publishing Portal A project tracking database to track multiple projects, and assign tasks to different people. 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 Web Databases N/A Enterprise N/A N/A Blank & Custom Enterprise N/A Meetings Meetings

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. 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. 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 N/A Content N/A Content

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. 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. 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 Collaboration Collaboration Meetings Meetings

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, andby using Web Part zonesdirectly 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 systems 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 verboselevel 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 None Critical Definition No logging occurs. 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 None Unexpected Definition No trace logs are written. 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 solutions 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. j. Select the event log level from the Least critical event to report to the event log list. 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. l. Select the All Categories check box. 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 email 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. 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 computerspecific anonymous access account (that is, IIS_IUSRS). Note: In the Authentication Provider section, click Negotiate (Kerberos) or NTLM.

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 Database Server Action 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 Database Authentication Type the name of the database, or use the default entry. 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 computerspecific 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 signin 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 Database Server Action 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 Database Authentication Type the name of the database, or use the default entry. 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 fullscreen 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.

When clicked, the commands open a dialog box, pass the selected documents, and do some work based on user input.

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 PartEnabled 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/intrafarm 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 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.

Excel Services

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 supports three data authentication methods:

Per User Identity: Use to apply data-level security on the database. This is the same as Excels and Visio Services Integrated Windows Authentication in that each users 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

PerformancePoint Services

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.

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 users 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 Visio Services 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. When you are accessing an Excel worksheet with PowerPivot data, the PowerPivot service application accesses the local PowerPivot for SharePoint 2010 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. 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 sources metadata, and the option SQL Server 2008 R2 that is configured will be used when the user executes the Reporting Services1 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 Install the SQL Server engine instance on dbsrvSQL and the Analysis Services instance on dbsrvSQLAS.

For information, see

Configuring the Windows Open ports 1433 and 1434 on dbsrvSQL. Firewall to Allow SQL Server Access Configure windows firewall to Open port 2383 on dbsrvSQLAS. enable Analysis Services Access

How to: Enable or Disable a Enable TCP/IP and Named Pipes for the SQL Server Server Network Protocol engine instance on dbsrvSQL. (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. 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. Installing Analysis Services Sample Database

Step

For information, see

Install SharePoint Server 2010 on the SP10App-02 and join it How to: Configure to the SharePoint Server farm.The report server computer requires SharePoint Foundation 2010 or SharePoint Server 2010 as a prerequisite. SharePoint Integration on Multiple Servers How to: Configure Install SQL Server 2008 R2Reporting Services in SharePoint integrated mode on SP10App-02. SharePoint Integration on Multiple Servers Configure a domain account to run the report server instance. How to: Configure a Service Account for Note: 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. How to: Modify a Reporting Services Configuration File How to: Configure Report Server

In rsreportserver.config, remove the <RSWindowsNegotiate> tag if it exists under <Authentication>. 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 Integration in Reporting Services Add-in for SharePoint Server 2010 to SharePoint Central communicate with the Reporting Services Windows service on Administration SP10App-02. Test the report server integration by accessing the link http://< hostname >/<site >/_layouts/ReportServer/SiteLevelSettings.aspx. How to Publish a Report to the Download the sample reports from CodePlex and publish the sample reports to the SharePoint site. 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 If you decide to open PerformancePoint Dashboard Designer from a site other than the Business Intelligence Center, see 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.

For information, see

Enable the PerformancePoint Services site feature

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 Managed Accounts in SharePoint 2010 Services service, it is a best practice (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 = GetSPWebApplication( <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 Configure the Secure Store Service Service application and Proxy. This is (SharePoint Server 2010) required to store the Unattended Service Account password for a PerformancePoint Services service application. To initialize the Secure Store Service 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).

application or how to set credentials for a target application do not apply to PerformancePoint as they do for Visio and Excel Services.

Initialize an instance of a Secure Store Service application

Refresh the encryption key

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, Add or remove a service application click Service Connections. A connection to a Web application (SharePoint 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 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. 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. Create a data connection for Analysis Configure Analysis Services data source time Enable trusted locations for PerformancePoint Services Configure the unattended service account for PerformancePoint Services

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. 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.

settings by using Dashboard Designer

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 Define a new trusted location from which Excel files can be loaded. Note: You can also use the default trusted file location for Excel

For more information, see:

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. 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.

Configure Secure Store Service for Excel Services

Select the database and table that you want in your Excel worksheet. Connect to

Determine a file name to save a data connection file and type a description.

(import) SQL Server data Also see: Overview of connecting to (importing) data

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. Publish a Publish the Excel workbook to SharePoint Server 2010. 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 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. How to: Install Install PowerPivot in the existing SharePoint Server farm on SP10App-02 PowerPivot for SharePoint on an Existing SharePoint Server Steps from How to: Install PowerPivot for Configure the server. SharePoint on an Existing SharePoint Server Steps from How to: Upload a PowerPivot workbook (includes installation steps). Install PowerPivot for SharePoint on an Existing SharePoint Server Steps from How to: Install PowerPivot for View the workbook. 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 dataFor information, see

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 Note: Plan security for Visio Graphics Service service application. Also plan for performance and other considerations.

For more information, see: Plan Visio Services security (SharePoint Server 2010) Plan Visio Services deployment

If you did not run the Configuration Wizard to create Create a Visio Graphics Service service applications, you must create a Visio Graphics Service application. service application (SharePoint Server 2010) Data authentication for Visio Services Set up and configure Secure Store Service for Visio Video: Steps for configuring Services Application in Microsoft SharePoint 2010 Products. Video: Configuring Visio Services with the Unattended Service Account In Visio Professional or Premium, create a dataImport data from Excel, SQL Visio Services with Secure Store

connected Web diagram. The Data Selector Wizard Server, SharePoint sites, and resembles the wizard used in Excel Services. Publish the Visio Web diagram to SharePoint Server 2010. other external sources Publish a diagram as a Web drawing